Using collada as a default format for our game engine

Hi,

We are looking into a new file format for our new engine (http://www.itrango.com/demo.html) and we stumbled across Collada. The primary purpose of collada seems to be for data interchange between different DCC applications but we wanted to know if it is a good idea to use collada as a default file format for our engine. The biggest benefit we seem to have with this format is that we will have 1/more standard files describing all the elements of our engine including levels, characters, physical attributes etc. Our artists can use whatever collada supported tools to design the content and export in collada format.

The drawback seems to be that

  • It is an ASCII format so data loading may be very slow.
  • The format and tool exporters don’t appear to be mature enough yet
  • Can we enhance the format to add additional entity details for our levels?
  • Any other issues that we may be missing to understand yet?

We would really appreciate any response from people who have already gone through this format and may help us in getting to an objective conclusion regarding this format.

Regards,
Mohsin

Hi there!

So far I’m only using COLLADA for small (mostly hobby) projects, but there it goes:

COLLADA is very felxible and extendable. There are several ways to add your data: the most staigforward way is to use your own profile in <technique> attirbutes. You can see how it is done for the EQUINOX-3D profile in some of the example files. I use this to add some custom collision objects (standard currently supports only axis-aligned bounding box).

The next way is to use names of nodes or shapes. E.g. shapes under group “ground” are used to generate heightmap, nodes pointing to a shape named “knight” are replaced with game objects using position and orientation of replaced nodes.

Hi,

Thanks for the reply. Thats a good starting point. Any idea about loading times or is there a binary equivalent of the format?

Regards,
Mohsin

I’m mostly using low-poly models, so speed wasn’t a concern so far (despite using DOM parser and two-pass loading).

There is no binary equivalent, but you can use your profile to refer to binary files with raw data instead of reading numbers in the COMMON profile. Other software will simply skip your profiles and read data from the COMMON profile.

You might be interested in reading old posts:
http://www.collada.org/public_forum/viewtopic.php?p=52
http://www.collada.org/public_forum/viewtopic.php?t=117

Nice demo!

I have been working with collada support for a third-part engine in java since April.
This included support for most things in the collada specification: Geometry, textures, materials, light, static animation and skinning.
I can share some positive and negative thoughts I have encountered. This is just my personal reflections, I’m not an experienced programmer, but I have good understanding of how the collada format can work as a data format besides as an exchange format.

It is an ASCII format so data loading may be very slow.
There are fast XML parsers out there both in C++ and Java. Even if you gain a differ in loading time that is noticeable for the user your bottleneck might not be the parsing time but geometry instancing, texture data loading or any other algorithm that could be focused on if loading times are considered slow.

There is no binary format for collada as I know of.

Something to keep in mind for Collada is that the specification is very clear through its XML schema. Exporters for various DCC cannot (read should not) output data that differs from this specification. My experience is that the good specification in collada made it easy to write a reader and very easy to debug. If I encountered a problem I would almost always know if it was a fault in my reader or in the XML document not following the specification. I think that a speed increase of a programmer maintaining the reader could be considered together with the speed loss for choosing an ASCII format.
I could not get from the engine specification if you use a scene graph of some kind. This could map very well with collada depending on your internal structure in the engine.

The format and tool exporters don’t appear to be mature enough yet
I think that the format is very powerful. For example Collada 1.3 should allow you to store shader information and advanced animation support through the channel targets. Collada 1.4 should be even more powerful with physics support and additional features.
Personally, I have had several problems with the DCC exporters. I’m not the only one but the problems depends on how your engine works and what features you need from the exporter in order for your engine to work. I had problems with schema specifications due to the strict validation routines in my parser. Others had problems with missing features.

If you think that the format and tool exporter is not mature enough yet … then you have a great opportunity to point out what changes you would like to make here in the public forum or directly to the plug-in developers! It’s great to have influence to the format and developers so that you can make it more suited to your engine and its structure. And also perhaps to influence the feature of the format. My experience is that the open format for collada and open source of collada related things helped me tremendously with my work. My guess is that I would not have this chance if I worked with a closed format.
If you want feature X and the DCC tool does not export it then push the plug-in developers, report bugs and/or post feature request.

Can we enhance the format to add additional entity details for our levels?
IlyaBely’s post said is well. It is extend-able without interfere with the specification. Even if you miss elements in the collada format you can always use the existing specification and interpret them in any way you want. The node elements could be AI spawn points, exported quads could be used in a portal system etc.

Any other issues that we may be missing to understand yet?
I would suggest looking at Collada 1.4 support. The DCC plug-in should work with 1.4 when 1.4 is released so there is no point in writing a 1.3 reader. So get in contact with the development team of collada and ask them for features of the 1.4 version.

Collada could be used as a engine->collada pipeline. If your engine works with nodes similar to collada you could have a very powerful feature of recording world data, parse this into a collada document and import the document into a DCC tool for debug, rendering and even movie playback. An engine that provides engine GUI debugging in their artist favorite DCC tool is in fact such a good idea that I’m thinking of stop writing right now before anyone steals that idea! :wink:

Again, this is all my personal opinions… (and yes I tried to keep it short but failed!)
… but I hope you have gained some insight from a programmers point of view.

Thanks for all the replies. They have been extremely insightful. Apparently speed is not such a big issue so I will immediatley start looking at the specifications for Collada 1.4.

Thanks,
Mohsin

Not quite.

COLLADA is designed to be the format that is used when your data is in motion between the tools that compose your content pipeline. COLLADA is not trying to make sure that all the data from one DCC tool can be loader in another, but to make sure that all the data necessary to game developers is available through the COLLADA exporter, and that the content pipeline can take advantage of as many tools as possible, with the importer.

The fact that COLLADA can be used as an interchange format (limited to the features required by game development) is a side effect.

Regards

– Remi