Should I use FBX or COLLADA?

I think both are interesting, but overly complex. I haven't used FBX nearly as much, but the overgeneralization of Collada (and the fact that its specification doesn't define a standard method for doing some things like linking animations to bones, at least last I looked) put me off of it.

I wouldn't use either for actual game data either -- they're too verbose. They should be used as intermediate formats, and turned into a more compact and efficient representation for your game itself.

Quote:

Original post by jpetrie I think both are interesting, but overly complex. I haven't used FBX nearly as much, but the overgeneralization of Collada (and the fact that its specification doesn't define a standard method for doing some things like linking animations to bones, at least last I looked) put me off of it. I wouldn't use either for actual game data either -- they're too verbose. They should be used as intermediate formats, and turned into a more compact and efficient representation for your game itself.

Alright thanks for your opinion! I planned to use my game's format but I just need to get the models into my game engine to convert them. Also, jpetrie, do you think you could take a look at this thread and see if you know what's wrong since you've gotten it to work yourself?

I haven't used Collada, but I have written a tool to convert FBX files to my own binary format. I find the FBX APIs to be pretty confusing. The documentation isn't very clear and it's hard to find concise examples of how to do various things... and it seems like they change things around quite a bit from version to version that can break your tools. That said, I did manage to get something working in about a week starting from scratch (and having never really implemented a skeletal animation system before on my own).

I'll look at your build errors later when I get home (and check it against my code). I do recall having to define a special preprocessor symbol to get it to link properly.

I think the best solution (especially in a commercial setting) would be to just write custom exporters for 3DS Max and/or Maya to export everything the way you want. This is the route I plan to go when I get tired of dealing with the FBX SDK.

Quick answer is: "No, you shouldn't use FBX or COLLADA"

I've not had experience with FBX but juding by the crap job it makes converting 3d models from one expensive app to another I don't hold out much hope for the SDK.

Likewise Collada might not be a bad intermediate format, but you'll need to convert it to binary to be efficient and that leaves you with another format that is full of holes.

Better to just write a plugin or find one that already outputs the stuff you need. Like maybe the MD2 one or something.

If you want to support non-Autodesk programs Collada is best. I agree what jpetrie said, that it's needlessly complicated, but still there is no better alternative.

Quote:

Original post by Rubicon Better to just write a plugin or find one that already outputs the stuff you need. Like maybe the MD2 one or something.

Yep, like I said 18 threads ago, when this journey began...

just write a python script from Blender to export your bone shapes, and anything else you need.

Quote:

Original post by Daaark Quote: Original post by Rubicon Better to just write a plugin or find one that already outputs the stuff you need. Like maybe the MD2 one or something. Yep, like I said 18 threads ago, when this journey began... just write a python script from Blender to export your bone shapes, and anything else you need.

I don't understand how to get the documentation for the api for 2.55 and this will have been my third revision of my blender plug in. I've wasted moths rewriting my plug in over and over I'm not doing it again plan and simple.

The API has been locked down and is very unlikely to change. The parts of the API that deal with accessing scene data (all you need) hasn't changed, and won't be changing at all. The only parts in flux are the parts that deal with interfacing with Blender's gui and other functionality.

Quote:

Original post by jpetrie I think both are interesting, but overly complex. I haven't used FBX nearly as much, but the overgeneralization of Collada (and the fact that its specification doesn't define a standard method for doing some things like linking animations to bones, at least last I looked) put me off of it.

If you don't have to use either for some reason, don't. You may as well make your own exporter as the collada exporters all have problems anyway and many of the FBX ones have issues as well. If I were making an engine I'd make my own format that is simple and keeps skeleton and mesh data separate and then make a converter from collada or fbx to that data to cover the animation tools I didn't want to waste time supporting directly.

Quote:

Original post by thatguyfromthething Quote: Original post by jpetrie I think both are interesting, but overly complex. I haven't used FBX nearly as much, but the overgeneralization of Collada (and the fact that its specification doesn't define a standard method for doing some things like linking animations to bones, at least last I looked) put me off of it. If you don't have to use either for some reason, don't. You may as well make your own exporter as the collada exporters all have problems anyway and many of the FBX ones have issues as well. If I were making an engine I'd make my own format that is simple and keeps skeleton and mesh data separate and then make a converter from collada or fbx to that data to cover the animation tools I didn't want to waste time supporting directly.

I already have my own format but you don't seem to realize that you actually have to get the models into your engine from a modeling application. My plan was to load the fbx or collada mesh into my class then save it out under my format instead of writing a plug in for just one of the many modeling applications out there.

Not that I'm professing to know much about the subject, but I too have been recently been looking into supporting various model formats in my engine. I was leaning towards COLLADA due to it's physics support (I just have a simple OBJ converter at this stage), and its apparent ubiquity.

I too was planning to convert to a native binary format (which is literally the serialised version of the internal classes - thank you Boost).

I have no experience of FBX but I have come across another format, OpenCTM, which looks interesting (http://openctm.sourceforge.net/) what do people think about this format? If anything? I am currently clueless.

Sorry if I'm hijacking your thread SteveDeFacto, but I'm hoping you'll find this useful too...

Quote:

Original post by SteveDeFacto Quote: Original post by thatguyfromthething Quote: Original post by jpetrie I think both are interesting, but overly complex. I haven't used FBX nearly as much, but the overgeneralization of Collada (and the fact that its specification doesn't define a standard method for doing some things like linking animations to bones, at least last I looked) put me off of it. If you don't have to use either for some reason, don't. You may as well make your own exporter as the collada exporters all have problems anyway and many of the FBX ones have issues as well. If I were making an engine I'd make my own format that is simple and keeps skeleton and mesh data separate and then make a converter from collada or fbx to that data to cover the animation tools I didn't want to waste time supporting directly. I already have my own format but you don't seem to realize that you actually have to get the models into your engine from a modeling application. My plan was to load the fbx or collada mesh into my class then save it out under my format instead of writing a plug in for just one of the many modeling applications out there.

That's why I said to consider writing a converter from collada to your format. But writing an exporter from say maya to your own format is a snap so if you favor one or two content tools it's really not hard. The exporters for collada in general are pretty terrible though and I get nothing but damned problems, it's like the bane of my life lately. So I would never bother to write an exporter to collada it is just a huge waste of time. Same goes for FBX. At most, write a converter that any tools you don't want to directly support can convert to your format.

Quote:

Original post by tgjones Not that I'm professing to know much about the subject, but I too have been recently been looking into supporting various model formats in my engine. I was leaning towards COLLADA due to it's physics support (I just have a simple OBJ converter at this stage), and its apparent ubiquity. I too was planning to convert to a native binary format (which is literally the serialised version of the internal classes - thank you Boost). I have no experience of FBX but I have come across another format, OpenCTM, which looks interesting (http://openctm.sourceforge.net/) what do people think about this format? If anything? I am currently clueless. Sorry if I'm hijacking your thread SteveDeFacto, but I'm hoping you'll find this useful too...

I only schemed over it but it looks interesting but no where that I saw it said that it supported animations. To me it would be pretty much useless if it does not support animations

Quote:

I already have my own format but you don't seem to realize that you actually have to get the models into your engine from a modeling application. My plan was to load the fbx or collada mesh into my class then save it out under my format instead of writing a plug in for just one of the many modeling applications out there.

How many modeling applications are there really, 3DS Max and Maya are probably the only ones you're going to encounter in a professional setting, and then maybe Blender for hobbyist stuff, that's about it. Even if you just wrote a script/plugin for Max *or* Maya it probably (or so I speculate) would be easy enough to save to a format they both support to get your data from the application you have a plugin for, to the one you don't.

Quote:

Original post by doesnotcompute Quote: I already have my own format but you don't seem to realize that you actually have to get the models into your engine from a modeling application. My plan was to load the fbx or collada mesh into my class then save it out under my format instead of writing a plug in for just one of the many modeling applications out there. How many modeling applications are there really, 3DS Max and Maya are probably the only ones you're going to encounter in a professional setting, and then maybe Blender for hobbyist stuff, that's about it. Even if you just wrote a script/plugin for Max *or* Maya it probably (or so I speculate) would be easy enough to save to a format they both support to get your data from the application you have a plugin for, to the one you don't.

There are actually many other modeling applications such a silo and a few others. Autodesk 3DS Max cost $3,495 and Maya cost $3,495. Torrenting them is an option but torrenting an up to date working version of the SDK is not.

Blender is the only real option but I have rewritten my export plugin 3 times and wasted moths of time I could have spent on something else. Even when I had a working plugin I was unable to find anyone who used blender to make their models so I had to export the model from 3ds max or maya then import it into blender then export it to my format. In importing it into blender I would normally have to redo the texture coordinates or animations. It's a complete wast of time...

The best option is to have an intermediate format that your engine supports in order to allow you to simply convert the models directly from the modeling application into your own format without having to deal with yet another layer of BS...

Indeed SteveDeFacto, animation support at the very least is kind of essential! Thankyou for that information!!

PS - How do you do a quote in this forum please...?

Dont know about Maya but for Max I wrote a converter for the ascii file that it can export. Since it's text its easy to parse and it contains everything the original model contains (even an entire scene if need be). In this case there is no conversion loss and I only use what I needed from the files. A simple filter and compression program was all that was needed after that point.

I have worked with many formats and I found out to avoid any non-native formats if at all possible. Max/Maya to Blender is not a good idea and I can sympathize with you on recoding something over and over. Been there, done that and it sucks major you know what.

My suggestion is to use the native format of the program be it Maya, Max, Blender or Lightwave and use your own custom format in-game.

I heard a lot of good things about assimp http://assimp.sourceforge.net/
If you are looking for an API to load assets that could be what you are looking for. It has support for many formats.

But it depends what language you are using, some languages such as C#, have a great deal of support for XML, making it easy to load and save COLLADA and other XML formats. http://code4k.blogspot.com/2010/08/import-and-export-3d-collada-files-with.html

Quote:

The exporters for collada in general are pretty terrible though and I get nothing but damned problems, it's like the bane of my life lately. So I would never bother to write an exporter to collada it is just a huge waste of time. Same goes for FBX. At most, write a converter that any tools you don't want to directly support can convert to your format.

What problems have you had with COLLADA? I understand that openCOLLADA (www.opencollada.org) is quite good, and has been stable for a long time now.

The idea of COLLADA is to expose as much data as possible in XML so it is relatively easy to convert the data to your engine format using scripting or C# like languages, or to load directly in the engine.

My design recommendation is to be able to load both converted assets and source (COLLADA) assets in the engine, at least during development phases. It may take a bit longer to import source assets, but overall it save so much time when developing a game as changes can be immediately seen.