COLLADA - experiences?
Author
Hello,
I am starting to work on the content pipeline of my engine project. Its currently a hobbyist project and because of the limited possibilities in this one-man-show I try to keep time for experiments small.
I read through the COLLADA documents, and it looks like it is what I am looking for. A standard format. Makes it possible to have 3d artists working with their software of choice, Maya, Max, Blender, XSI and so on. No need to write exporters for x programs.
The documents could be conditioned with so called "Conditioners". Small tools that remove any unnecessary nodes, convert polygons to triangles, reorganize and optimize meshes, convert coordinate systems and so on. So that the engine can get clean and conditioned xml as input. It should even possible to add engine-specific properties or even extend the format to contain a game-specific level description.
Theory sounds good. But how is practice? Does anyone have experience with Collada. How do the shaders work? From what I read, it supports Cg - but I do not want to work with Cg.
What does Maya export? Where are the stumbling blocks?
I am thankful for any experience report and advice.
It designed for handling large amount of assets being used by multiple people in multiple environments. I honestly suggest you stay away from it until you need something that heavyweight.
I have to disagree with MENTAL, but then I never want to have to interact with the 3DS Max or Maya SDKs ever again. I've paid my dues in that respect, now I want to get on with making games.
Seriously though, I've just been looking into using Collada for our engine at work and I'm fairly impressed. There are exporters for the important DCC packages, and you get a choice of (at least) two file handling libraries, Collada DOM and FCollada. I've gone for FCollada, just because its API seems a little more sane than Collada DOM, but I would certainly encourage you to check them both out and see which one suits you best.
As for shader support, I don't really know. I do know that Collada associates a material name with a set of polygons, which is good enough for me to go and hook that up to our material system, which supports non-shader equipped hardware as well as SM3.0 hardware. YMMV.
Regarding what you can get out of Maya, meshes, skeletons, animations, material and texture information, lights, cameras, and some additional extra data. Chances are it's got everything you want :-).
HTH.
Seriously though, I've just been looking into using Collada for our engine at work and I'm fairly impressed. There are exporters for the important DCC packages, and you get a choice of (at least) two file handling libraries, Collada DOM and FCollada. I've gone for FCollada, just because its API seems a little more sane than Collada DOM, but I would certainly encourage you to check them both out and see which one suits you best.
As for shader support, I don't really know. I do know that Collada associates a material name with a set of polygons, which is good enough for me to go and hook that up to our material system, which supports non-shader equipped hardware as well as SM3.0 hardware. YMMV.
Regarding what you can get out of Maya, meshes, skeletons, animations, material and texture information, lights, cameras, and some additional extra data. Chances are it's got everything you want :-).
HTH.
Author
@Gooberius
Thank you for the info. I will have a look at FCollada (just know Collada DOM until now).
@MENTAL
I think I need the whole amount of assets.
But I am also thinking about using it just as an intermediate format. Need to investigate into it.
Also read somewhere that it is possible to externalize data - e.g. meshes. Then .dae could describe scene setup, animations, physics etc., but vertex and polygon data in a separate optimized (fast to load) format.
On the other hand, both parser APIs (Collada DOM, FCollada) seem to be a bit too heavyweight for my taste. Add unnecessary dependencies. For example I use tinyxml in the engine for different purposes, which is great and ... tiny. But Collada DOM and FCollada both depend on libxml. So the engine would depend on two xml parsers.
Need to think more about which way to go.
Thank you for the info. I will have a look at FCollada (just know Collada DOM until now).
@MENTAL
I think I need the whole amount of assets.
But I am also thinking about using it just as an intermediate format. Need to investigate into it.
Also read somewhere that it is possible to externalize data - e.g. meshes. Then .dae could describe scene setup, animations, physics etc., but vertex and polygon data in a separate optimized (fast to load) format.
On the other hand, both parser APIs (Collada DOM, FCollada) seem to be a bit too heavyweight for my taste. Add unnecessary dependencies. For example I use tinyxml in the engine for different purposes, which is great and ... tiny. But Collada DOM and FCollada both depend on libxml. So the engine would depend on two xml parsers.
Need to think more about which way to go.
At the moment we use DirextX-XFiles as an intermediate format. Import from it into your personal engine format is ok. Needs some work but eventually you'll get it. But the different exporters for various 3D modellers are horrible. Most of them choke on some sort of anims or another, destroy the normals or simply trash the frame hierarchy matrices if you happen to have the wrong view activated at the time of exporting.
After encountering problems over problems we decided to go for Collada as well. I'm not advanced enough at the topic to tell a story, but I heard in various other places that people successfully use Collada. Exporters from 3DSMax and Maya are freely available and are said to be good. The format itsself can hold alot of different data kinds but you don't need to use them all. I'm definitly going for it, it still sounds better than writing an exporter for every modelling package on my own. At the same time, I'm also interested in any experiences you may have collected on that topic.
Bye, Thomas
After encountering problems over problems we decided to go for Collada as well. I'm not advanced enough at the topic to tell a story, but I heard in various other places that people successfully use Collada. Exporters from 3DSMax and Maya are freely available and are said to be good. The format itsself can hold alot of different data kinds but you don't need to use them all. I'm definitly going for it, it still sounds better than writing an exporter for every modelling package on my own. At the same time, I'm also interested in any experiences you may have collected on that topic.
Bye, Thomas
I've implemented a Collada importer for the C4 Engine, and I'm pretty happy with it. The exporters for Maya and 3DSMax are in very good shape (the Maya one is slightly better), but I've found that the exporters available for smaller art programs like Blender can be rather poor.
Our experience is similar to those of Schrompf. We also used Microsoft X files but current state of exporters for DCC applications is just plain horrible. Plus, certain kinds of animations like morphing are simple not supported by X files.
For the moment we switched to dotXSI format because XSI is used by our artists and there is a simple API provided by Softimage for parsing dotXSI files. But for our next project we will try to switch to COLLADA because it has a much wider support than dotXSI.
I just noticed a book on COLLADA subject:
http://www.amazon.com/Collada-Sailing-Digital-Content-Creation/dp/1568812876
can anyone recommend it?
For the moment we switched to dotXSI format because XSI is used by our artists and there is a simple API provided by Softimage for parsing dotXSI files. But for our next project we will try to switch to COLLADA because it has a much wider support than dotXSI.
I just noticed a book on COLLADA subject:
http://www.amazon.com/Collada-Sailing-Digital-Content-Creation/dp/1568812876
can anyone recommend it?
I am doing the collada import for the Jad Engine (www.jadengine.com). It is a great format and definetly use it. Why?
1. It has everything you may need
2. There are exporters for each major 3d software package
3. There are open source tools for parsing and working with those files
4. It is backed up by Sony, used for PS3
5. Backed up by the Khronos group for mobile development.
I personally use it using .NET 2.0. So I was forced to do everything because there are no libs for importing in .NET. You can use the .net xsd.exe tool to generate classes from the collada xsd. This won't work from the start, you still need to do some modifications after it (but few). After this you can just Deserialize a collada file (xml) into a tree of objects that is using the generated classes. Parsing that tree and loading/exporting to your own format is very easy then.
If you plan to use C++, there are libs for doing this, and is very very easy to use. Just don't start using it until you find all the tools you can use, because by doing this you may end up in just having to write only a few lines for loading your data.
1. It has everything you may need
2. There are exporters for each major 3d software package
3. There are open source tools for parsing and working with those files
4. It is backed up by Sony, used for PS3
5. Backed up by the Khronos group for mobile development.
I personally use it using .NET 2.0. So I was forced to do everything because there are no libs for importing in .NET. You can use the .net xsd.exe tool to generate classes from the collada xsd. This won't work from the start, you still need to do some modifications after it (but few). After this you can just Deserialize a collada file (xml) into a tree of objects that is using the generated classes. Parsing that tree and loading/exporting to your own format is very easy then.
If you plan to use C++, there are libs for doing this, and is very very easy to use. Just don't start using it until you find all the tools you can use, because by doing this you may end up in just having to write only a few lines for loading your data.
Author
Thanks for your information. Its invaluable input for me.
In conclusion I will do the following:
A conversion Tool in two flavours: gui and command-line (for batch processing).
It will parse collada-files and write my propriety format (binary and optimized for the engine structures). The tool will also do some conditioning on the data, like triangulate and optimize the meshes, convert and preprocess images and so on. Format will e.g. contain materials, animations, meshes and a scene graph with anonymsous or named nodes.
And I will use FCollada or Collada DOM only in the conversion tool, not in the engine. XSD Code generators seem to have problems with collada or generate too large source files (source: https://collada.org/public_forum/viewtopic.php?t=449&highlight=xsd).
In the future the converter will have a preview function (using collada as input, doing the conversion to temporary files and starting the engine preview ).
So, a lot of work for me now ;-)
Will post my experiences when done.
In conclusion I will do the following:
A conversion Tool in two flavours: gui and command-line (for batch processing).
It will parse collada-files and write my propriety format (binary and optimized for the engine structures). The tool will also do some conditioning on the data, like triangulate and optimize the meshes, convert and preprocess images and so on. Format will e.g. contain materials, animations, meshes and a scene graph with anonymsous or named nodes.
And I will use FCollada or Collada DOM only in the conversion tool, not in the engine. XSD Code generators seem to have problems with collada or generate too large source files (source: https://collada.org/public_forum/viewtopic.php?t=449&highlight=xsd).
In the future the converter will have a preview function (using collada as input, doing the conversion to temporary files and starting the engine preview ).
So, a lot of work for me now ;-)
Will post my experiences when done.
We ended up writing our own Collada loader without too much trouble. It gives us the flexibility to only use the parts that we need. I do recommend strictly importing it, don't try to use it as your final model format because it does take a while to parse the xml files.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
