Sign in to follow this  
lucky6969b

What is your preferred 3d format?

Recommended Posts

I find that many bodies in the world claim that their format was a standard.
I am confused. I am looking for a good format. Microsoft's simply proprietary,
On the aspect of Exporters, I find collada a good choice. But their format is deemed to be intermediate. I want to know what is the general workflow of 3d modelling? Yes, I need to do it myself. Of course, the x format was obsolete, .x3d is pretty new. What else?
Thanks
Jack

Share this post


Link to post
Share on other sites
None.

No 3D format has ever been a standard, and none ever will be (for a long time at least). 3D data is very versatile, and there is lots of differences in what information each format was designed to store, and HOW it needs to be stored.

So the best format, is to open up the scripting portion of your DCC, and write out a file that stores what you need, how you need it. :)

Share this post


Link to post
Share on other sites
Either you use a standard intermediate format, such as COLLADA, and compile it into your own game-ready format yourself:
[DCC program]---[i]Export[/i]---> Intermediate format ---[i]Compile[/i]---> Game-ready format --->[Game]

Or you write your own exporters:
[DCC program]---[i]Custom Export[/i]---> Game-ready format --->[Game]

Share this post


Link to post
Share on other sites
Okay, another stupid question. I have gone to collada web site, I can't seem to find its download hyperlink.
I just found its source code. Do I have to compile it myself?
Thanks
Jack

Share this post


Link to post
Share on other sites
What code did you download? I didn't think that there was an official "source code" for collada...

There are a few different API's that you can use to import/parse collada files, such as:
http://assimp.sourceforge.net/
http://collada.org/mediawiki/index.php/FCollada
http://collada.org/mediawiki/index.php/COLLADA_DOM

Or if you want to parse it manually, you can follow the official specification of the format:
http://www.khronos.org/files/collada_spec_1_5.pdf

Share this post


Link to post
Share on other sites
here
[url]
https://github.com/KhronosGroup/OpenCOLLADA
[/url]

You have to logon to the server

Also, what about exporting from 3ds max? Do I use one of the plug-ins you mentioned?
Thanks
Jack

Share this post


Link to post
Share on other sites
here
[url] https://github.com/KhronosGroup/OpenCOLLADA [/url]
You have to logon to the server.
Also, what about exporting from 3ds max? Do I use one of the plug-ins you mentioned?

As well, why do I need the source code (followed the links you mentioned) once you have the pre-built files such as dle etc?
Thanks Jack

Share this post


Link to post
Share on other sites
If you have max, you can just go ahead and write out your own file with the scripting language. Then you won't have to go through the pain of 2 conversions!

Share this post


Link to post
Share on other sites
Start reading at the official Python site. Just make sure you are reading about the right version.

http://www.python.org/doc/

After you have the basic syntax down, just read the Max documentation to see what their specific API is.

Share this post


Link to post
Share on other sites
WHat model format you want to use may depend on what game engine or framework your using. XNA still natively supports .X files. .obj, .dae and .fbx come up aswell. I believe .fbx was intended for transferring between different DCC's rather than straight usage though

Share this post


Link to post
Share on other sites
I find that using standard formats are overkill for use in games. Very few professional games use collada or x files. You want your data to be read quickly so I prefer chunk based binary formats. A lot of games like dynasty warriors use chunk based formats. Many games like any using Sony phyrengine use a binary scene graph format. Hyper dimensions neptunia also uses scene graph based format. Many games like saints row the third use flat binary files. Use whatever you want just be sure you can read the data fast.

Share this post


Link to post
Share on other sites
[quote name='yadango' timestamp='1344039203' post='4965989']
I find that using standard formats are overkill for use in games. Very few professional games use collada or x files. You want your data to be read quickly so I prefer chunk based binary formats. A lot of games like dynasty warriors use chunk based formats. Many games like any using Sony phyrengine use a binary scene graph format. Hyper dimensions neptunia also uses scene graph based format. Many games like saints row the third use flat binary files. Use whatever you want just be sure you can read the data fast.
[/quote]

Definitely agreed. Two objectives of a good model format for games are to get the data in fast and have it already in a format, or close to a format, that's suitable for sending directly to the GPU via a draw call.

Share this post


Link to post
Share on other sites
[quote name='6677' timestamp='1344009553' post='4965869']
WHat model format you want to use may depend on what game engine or framework your using. XNA still natively supports .X files. .obj, .dae and .fbx come up aswell. I believe .fbx was intended for transferring between different DCC's rather than straight usage though
[/quote] XNA doesn't actually use [i]any[/i] of those formats. The Content manager compiles them to a new format at compile time. It also take all your images and compiles them to DDS.

Share this post


Link to post
Share on other sites
[quote name='Asesh' timestamp='1344052099' post='4966030']
I prefer FBX. Though FBX SDK is a pain to deal with. You can even password protect your FBX files
[/quote]

FBX is an interchange format. It was made to help standardize moving large complicated scenes between the big programs.

In a game you want a quick, lean format that easily maps to your own data structures. You can't do that when you are opening up big bloated files, parsing them, storing them in their own data structures, and then slowly transforming them into your own data structures. It does nothing but waste memory and processor cycles. You're digging through a giant haystack trying to find useful bits.

The same thing happens with image files. That's why uncompressed TGA and DDS became standardized. With TGA you just read the header which told you how big the file was, allocated that much memory, and just dumped the rest of the file directly to ram. Writing them was just as simple.

DDS is even better to load, just dump it straight to the GPU in it's compressed form.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this