Best 3Dmodel filetype for games?

[Wahooney]

It definitely is possible, but I wouldn't recommend it. It's pretty much a dead file format that doesn't support things like Skinning, multiple UV channels or multiple materials per object (not 100% sure about the last 2).

I'd recommend:

Use Max's built in .ASE format (doesn't do skinning though but it does collapse the animations into plain keyframes).
Writing a script that exports the file to an ASCII file. I find maxScript's handling of binary files to be rather inadequate.
Dust off the max sdk and write your own plugin that exports EXACTLY what you need. This is what I've done for our project. It requires a fairly deep understanding of max's internal mesh structures and a whole lot of C++. But it is really worth it.
There was a plugin floating around that exports directly to the DirectX .X file. Just google it or check www.maxplugins.de (http://www.maxplugins.de/).
I hope this helps.

[EricChadwick]

If you're using max you could also check out the Game Exporter Interface. It's a good place to start, and fairly complete right out of the box.
http://sparks.discreet.com/downloads/downloadshome.cfm?f=2&wf_id=92

[myselfhimself]

ok i used to work for mods a few years ago

first the .3ds does contain textures info (what files and uvw) and it is possible to use several textures for a single object (use the subobject or multiobject (i don't have max anymore) material type)

then it is right that you cannot save (anymore as you say) animations into .3ds (though it maybe was possible in very early versions...) as of today. Though, you can still deal with multiple .3ds files like it is done for serious sam (you could check their sdk for making mods). The way the developpers have done it is : you create your model, texture it etc.. then you animate it, then you execute a small maxscript provided in the sdk which saves every frame of your anim into one .3ds file. Then you can import every .3ds very easily their model editor (separate from 3ds) and compile the whole thing into a single model. So their .3ds basically contain the info for each vertices' position (and not the bones...) so you can do morphing.

As far as half-life (i just know for hl 1) is concerned, Valve (the developpers) have reused Quake I file format. There one .mdl file which contains : a text file saying (a something.qc) : this .smd file in the package is for reference (info about which vertices are assigned to which bone, how the bones are located, what the faces are, which bitmaps to use, how those are mapped on the model), these other ones are for animations (like : walk.smd will reffered to "walking" state and will played at 10 fps in the game)). Bitmaps used for the model are also include in the .mdl package.

What's cool with hl's file format is that everything is explicitly expressed (you can open a .smd file with notepad and realise that what's written is coords for triangles) so they should be easy to "back-engineer" them... if ever.

a small soft can read the .mdl file and is in trial : type chumbalum soft in some search engine or look up for milkshape 3d. The latter is a modeling tool; you can compile .smd files from it; you can export to many file formats with it maybe you could try and save to lots of those formats and try and analyse how each of them are build. Valve also provide an SDK for hl1 with a .exe to compile smd (all you need is a .qc file which you can write yourself). Also see for hl model viewer on the same website as milkshape.

i know little about q3 file format (and i'm realising that those formats are maybe 2 years old) : your model is divided into parts which you can animate separately (like head, body legs). quake 3 knows how to attach those parts together thanks to triangles you name and put at a place on the main mesh where you want other things to be merged. (like TRIANGLE_HEAD placed at the neck). All the animations are in a single file and one after the other and this is done precisely (let's say : frame 1 to 30 is walk, 31 to 56 is jump etc...)

I don't wanna be confusing... read more docs incase... I think there were nice articles on that on gamasustra (it tought how to create a model and adapt it for unreal 1 and q3). http://www.planetquake.com/polycount/ and see the resource section.. might be interesting..

but all this is rather for fps... and the formats i'm talking about are quite old...

yo

Jonathan

[myselfhimself]

hey
i've found this in another topic (max to mdl or sthg like that)
WEst.at']You maybe haven't set a Multi/Sub-Material to the Model, without I think .mdl files can't export.

thx to him
since I don't have max anymore.. this is the material type which has got to be used if we want to apply several textures to a single object and then export to .3ds or .mdl

jonathan

[aphexx]

as Wahooney (http://www.cgtalk.com/member.php?u=82974) already mentioned, the ASE file format is a good way to start.
only the filesize is unbelievable, since all informations are stored in ASCII.
in the beginning of G3 we also used the ase format, but as the landscape masses got bigger, we modified the format, so now we have a *.BSE format :).
we turned as many informations in the file, to be saved as binary data. vertex and mapping coordinates are predestined to be handeld in binaries.
some infos may be interesting to be left in ASCII such as map names or texture names, since you can hack the file for testing purposes, if you want to change a material in the file, without reexport it in max and reimport it in the engine.
so far good luck

[[RNS]WEst.at]

Are you building the whole g3 world in one piece and then exporting it to the *.bse file or are you splitting it up? I could think that it would need amounts of memory for having the whole file in memory all the time.

Edit: Or is the Format coded that you can load and unload parts of the file in runtime?

[aphexx]

WEst.at']Are you building the whole g3 world in one piece and then exporting it to the *.bse file or are you splitting it up? I could think that it would need amounts of memory for having the whole file in memory all the time.

Edit: Or is the Format coded that you can load and unload parts of the file in runtime?

no, its not one piece. it would be great, but you cannot work on such a big mesh inside max.
lots of uv coordinates blasting up the file.
normally the 3dsmax instance uses 1.5 - 2GB memory, when loading a bigger part of the landscape, but that its nearly impossible to work on it then.

but in our editor all the world is loaded in one file, but then we use LODing and other optimising algorithms to cope with it :)

[CHRiTTeR]

Thanks for the replies. At this point we are experimenting a little with the directX file format because the directX SDK includes an API for it. Thats less work for the coder ;)

But I'll look up some info on the ASe format and making it binary is a nice idea :deal:


sascha henrichs:
Gothic3 looks AMAZING! :thumbsup: :scream:

[Ghostscape]

.X is easy to work with from a coding perspective, but all the available exporters suck righteously.

You may want to consider coming up with your own model format, depending how much time you have to work on the system.

You can also look into the md3 format, as it is well supported and full source is available somewhere.

[aphexx]

[QUOTE=Ghostscape].X is easy to work with from a coding perspective, but all the available exporters suck righteously.
QUOTE]

hey ghostscape! what a lovely avatar! haha ;)

@chritter: there was also a nvidia format, what nvidia uses for their demos. was it called .nvb or so? this format is surely well worked out for shader supports, but there was one slight problem with this format our programmers mentioned, but i forgot what it was.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.