Writing with COLLADA-DOM?

Hi, my name is Chris Hanson, with 3D Nature. We make the World Construction Set and Visual Nature Studio 3D landscape rendering and animation products. We’ve kept an eye on COLLADA for a while, since the SIGGraph debut a few years ago, but we’ve never implemented support for it.

We’ve been sort of forced into it at this point because Google Earth adopted COLLADA as their 3D object format in their latest version 4. We have a Google Earth KML exporter as part of our Scene Express add-on.

We’ve been looking at COLLADA-DOM library for a couple weeks, trying to get a grasp on how to use it. Frankly, it’s scary.

We have yet to successfully get a simple textured box written out. We’re still mired in thousand-line demo programs that are concerned with asset databases and derived templates and lots of seriously deep stuff.

I’m really concerned that COLLADA-DOM is impractical for most developers to support. Doing anything basic with the library seems so complex that one has little idea where to start. We’ve implemented uncounted 3D object format readers and writers in my programming lifetime, but never anything as top-heavy as COLLADA.

Equally worrisome is that each edition of the library seems incompatible with the previous one. The docs even suffer the problem – we found numerous places where the docs refer to some technique that we later find is deprecated or even removed from the current library.

Are we missing something here? It seems like COLLADA is a great idea for object interchange between game developers with industrial-strength needs for asset management, shaders, complex bone and constraint requirements and such. For anyone who doesn’t have an entire XML-compliant development team to dedicate to it, it sort of looks like an elephant designed by committee.

At this point, we’re looking at just taking some COLLADA sample files and hand-writing the XML ourselves by printf. It would probably make our exporter considerably faster and keep several megabytes of code size off of our application. I’m dreading the day when we need to read COLLADA files.

You should consider FCollada, which is an open-source library created by our company, Feeling Software. It is designed for backward compatibility and is already in use in many applications, including ColladaMaya, ColladaMax, the Feeling Viewer, and Epic’s Unreal Engine 3, in addition to several confidential projects for our other customers. It supports import and export, and is generally higher level than the DOM.

http://www.feelingsoftware.com/content/ … 3/lang,en/

There are a few samples available with it, and lots of additional “sample” code in ColladaMaya and ColladaMax.

We also offer consulting services should you need help with supporting COLLADA in your application.

We had glanced at FCollada before, but didn’t see anything that looked like an object-writng demo, so I wasn’t even sure if FCollada was a write or just a reader. The FCollada page didn’t really say either, so we moved on to looking at the COLLADA-DOM.

Is there some sample source anywhere that shows FCollada being used to write something like a cube, start to finish?

Also, (directed to the larger COLLADA community, not FCollada specifically) what is the purpose of COLLADA-DOM if it’s unusably complex? Is anyone using it?

FCollada is evolving quickly. It used to only support import, until about a month ago. ColladaMaya is now using FCollada for export too. We don’t have that much sample code, because our primary concern is to make FCollada as powerful as possible for our primary applications and for our paying customers.

Good luck,

Christian

I’m using it. IMO it isn’t unusably complex. It is complex, but the complexity is due to all the features it supports and all the little niceties it provides you. Here’s some of the stuff you get (these examples are geared toward reading Collada, as I’ve only written a reader so far):

[ul]- No manual xml or text parsing at all. For example a <float_array> element maps to an array of C++ float values, without you having to do anything.

  • A complete mapping of every element in Collada to a C++ object. The DOM provides you access to everything in Collada.
  • Automatic reference resolution. I don’t have to try to find what element “#myVertices” is referring to. The element being referred-to can even be in a totally separate xml document… the DOM just takes care of these things.
  • The concept of a Collada database to provide efficient query support. Want to loop over all the <mesh> elements in a Collada document but don’t feel like finding them all yourself? This is very easy to do with the DOM. I’ve worked with APIs that don’t provide support for this sort of thing, and it’s a huge PITA. All information is cached to make the queries very efficient, and great care is taken to ensure that the cache remains synchronized with the actual Collada elements.
  • An integration library to make it easy to convert from Collada to your format/runtime.[/ul]The cost of reducing the complexity of the DOM is sacrificing some of the features mentioned above. All of those features are worthwhile so I don’t have a problem with the DOM’s level of complexity.

Having said that, it’s the schema that defines Collada and not the DOM. What I mean by that is that it’s perfectly valid to use other libraries such as FCollada, or your own custom code, to work with Collada. As long as it conforms to the schema it’s valid Collada.

If you have specific questions/issues, feel free to ask. I’m sure someone will help you out. However there is a forum specifically for the Collada DOM, so it might be better to post there.

If you’re still having problems with this I can code up a working example that demonstrates this for you, sometime tonight or tomorrow.

I can’t speak about the backward compatibility issues, but I definitely agree that there were many inconsistincies between the spec and the schema/DOM, and this was pretty annoying. However 1.4.1 was just released, and every issue/inconsistency I’ve encountered with the 1.4 spec has been fixed.

I’m not opposed to depth and capability in the COLLADA-DOM, what we found frustrating is that there’s really no where for a COLLADA novice to start. Really, we don’t want to learn about the amazing powers of the schema and stuff, we just want to add COLLADA support to an existing application. I expect there will be more and more people following down this road as COLLADA becomes more commonplace. I’m thrilled that there might someday be a decent replacement for the mishmash of object interchange via legacy formats like 3DS, OBJ, etc. And don’t get me started on FBX… :wink:

Maybe it’s just that the COLLADA-DOM project isn’t mature to the point where the introductory documentation is there yet. I work on the OSG (OpenSceneGraph) project, and that was an issue we suffered for a long time – great code, but beginners were lost without a lot of demos.

I don’t want to make somebody go out and hold my hand and write a custom demo for me, but I was hoping such an example was already available. So far I can’t find anything that shows how to do a simple task like writing a basic geometry. At the moment we’re prototyping a writer that just blasts out xml by printf. Not pretty, but a lot less prep work – our Google Earth KML exporter works the same way.

So, opinion survey: Under what circumstances should one use the DOM and where would you recommend FCollada instead?

I definitely agree that it’d be nice to have more tutorials and introductory documentation. I think the key thing is to make sure you fully understand the spec/schema. If you have your head firmly wrapped around that then the DOM becomes obvious. But yeah, the spec/schema definitely don’t count as introductory documentation.

Also, the DOM programming guide has a brief section on how to create Collada documents from scratch, but it doesn’t cover setting up geometry unfortunately. Geometry is pretty complex in Collada due to all the levels of indirection involved. I found that sketching out on a piece of paper the structure of e.g. the <mesh> element helped me understand things more clearly.

Regarding FCollada vs the DOM, I’ve never used FCollada so I can’t comment, but this topic has been discussed a few times before.

I think we can conclude we have different mindsets on the issue.

Your goal is to be familiar with all things COLLADA, and that’s fine. But you must understand that a large number of COLLADA implementors will not wish to become experts on COLLADA and fully understand the spec and the schema and get their head firmly wrapped around it.

I would guess that fully understanding the spec/schema could take a single programmer several months, based on our initial forays into it.

We already support something like 100 different file formats (3d, GIS, etc). Many developers will be in a similar situation where they won’t have the time to dedicate to becoming a COLLADA Jedi. They’re just tasked to implement support for COLLADA and move on to the next file format in a seemingly endless uphill battle to stay current with the data storage norms du jour. :wink:

Just be aware that not all developers will have the same motivations as you.

In that case it is probable that FCOLLADA is a better choice for you, it should make it easier for you to use COLLADA without having to understand all the details.

Another solution is not to develop your own exporter/importer, but to contract it to Feeling Software, or other COLLADA Jedi contractors.

Let’s hope that in the future you will have less formats to support and have time to become a COLLADA Jedi and enjoy the power of the DOM

That’s good to hear since we had been working towards achieving that goal!

That’s a fair comparison. We are working to improve the DOM documentation and would appreciate any feedback you can offer on that.

Btw: we are looking to revive the COLLADA plugin for OSG as well!

It would be good to have some small introduction and a basic sample that imports a textured cube or triangle, for both FCollada and COLLADA-DOM.

Both COLLADA-DOM and FCollada are quite complex indeed. I’ve experimented with both to get basic collision shape import, and especially the DOM is unintuitive, even if you know the COLLADA 1.4 specification… FCollada appeared a bit easier to use, but at that time (over a month ago) it didn’t support writing yet, and convex meshes were broken. Both might be fixed now.

COLLADA-RT includes a very basic viewer based on COLLADA-DOM. The FeelingViewer, which imports COLLADA 1.4 using FCollada, is unfortunately closed source, unless you become Khronos member. So if you want to go the FCollada route, that might be an option (including Feeling Software consultancy). In case you become interested in importing COLLADA 1.4 collision/physics data, you can learn from my import struggle in the open source Bullet physics engine. It includes a basic and preliminary import sample (supporting either COLLADA-DOM or FCollada).

Download from http://bullet.sourceforge.net
In particular check for Demos/ColladaDemo/ColladaDemo.cpp

Erwin

I think the key point to understanding COLLADA for import or export is that there is a lot of indirection going on. This is pretty much essential for making a format that’s flexible enough for anyone, but it does make the learinig curve pretty steep. Once you understand how the indirections go together, the whole thing becomes much easier. Some of this you can get from the spec, other things become clearer when you follow the id links in a sample file and see how they connect together. Starting from a primitive (<triangles>) or a <node> and working your way back is a good way to see all the links.

I’d advise against doing import/export with printf/scanf, this may look easier at first but in the end you will have to do a lot more work to insure things are read/written in the proper order and format. Resolving all the forward/backward references by hand can be quite a job. Either FCollada or the COLLADA DOM will take care of this for you, resolving most indirections and converting most data to/from binary formats.

I’m looking into what code I have that might be useful as samples, but it may take some time to get it cleaned up, approved and posted.

In the year since this was last posted to, has anyone developed some demo code for either FCollada or COLLADA DOM? I’d really love to see some sample code that does nothing more than imports the sample duck.dae. I’m intrigued by Collada, but that’s where I should say my interest ends. I would like to use it, but if there isn’t any sample code out there to learn from, it makes more sense for me to continue using more standard formats. And I should say, I am not in any way looking for more documentation on the schema – I have had my fill of that. I am trying to find a simple example of using either of the two parsers to read and write something simple (like a sphere, cube or the duck). I should also say that I am not looking for a massive project (e.g. somebody’s thesis) that can import/export something like duck.dae; but rather, something that is very lightweight that can be used to learn from.

You can find a tutorial / User guide on collada-DOM in the tutorials, from the collada.org front page.
Loading a .dae document in the COLLADA-DOM is only a few lines of code, documented in the Working with documents tutorial page.
I hope this helps

Thanks, Remi. Maybe I should have been more specific. I am looking for a tutorial on how to get information out of that object once it has been loaded.

So for instance, I am looking for sample code that shows you (and walks you through) how to do things like accessing a material’s ambient values. (Note that for simplicity’s sake, in my example below, I have removed all error checking.)

DAE* colladaDom = new DAE();

colladaDom->load(fileName);

int effectsCount = colladaDom->getDatabase()->getElementCount( \
NULL, COLLADA_TYPE_EFFECT, NULL);

for(int effectIndex = 0; effectIndex < effectsCount; effectIndex++)
{
domEffect* effect;
colladaDom->getDatabase()->getElement((daeElement**)&effect, \
effectIndex, NULL< COLLADA_TYPE_EFFECT, NULL);

/*
/ Or if you already have the material:
/ domEffect* effect = daeSafeCast< domEffect > \
/ (getElementFromURI(material->getInstance_effect()->getUrl()));
*/

for( arrayIndex = 0; arrayIndex < \
effect->getFx_profile_abstract_array().getCount; arrayIndex++) {

domProfile_COMMON* commonProfile = daeSafeCast   \\
    &lt;domProfile_COMMON &gt; \\
    (effect-&gt;getFx_profile_abstract_array()[arrayIndex]);

domProfile_COMMON::domTechnique::domBlinn* blinn = \\
    commonProfile-&gt;getTechnique-&gt;getBlinn();

domFloat4 &colorValues = blinn-&gt;getAmbient-&gt;getColor-&gt;getValue();
float ambient[4] = { colorValues[0], colorValues[1], \\
   colorValues[2], colorValues[3] };
std::cerr &lt;&lt; "ambientValues: " &lt;&lt; colorValues[0] &lt;&lt; "," &lt;&lt; \\
   colorValues[1] &lt;&lt; "," &lt;&lt; colorValues[2] &lt;&lt; "," &lt;&lt; \\ 
   colorValues[3] &lt;&lt; std::endl;

}
}

Granted the code above is somewhat pointless as it just iterates through all of the materials and effects, then just prints out the ambient values, and it does not even check to see if any of these objects are there before it performs method calls on them. But for a beginner, I know I would really benefit from seeing simple examples like this for extracting information out of COLLADA DOM. It is especially difficult to know if there are preferred ways to do things like this.

If you do know of any resources like that, I would really appreciate it. Thanks again for the quick response.

Is there some sample source anywhere that shows FCollada being used to write something like a cube, start to finish?

There is now some example of how to load some dae files. But how to write them ? Is there some sample source available ?

When writing, does the Dom or FCollada API take care of everything to generate the xml file ?

If yes, does someone know how to ‘attach’ an integer array to each vertex of a mesh (when the mesh is loaded) ?

Thanks a lot for this forum , it helps a lot for learning Collada

There’s sample code for creating documents with the DOM here.

I don’t know how FCollada works, but with the DOM you use a C++ object model to create the elements/attributes you want, then you call a save function to serialize everything to an xml file.

<mesh> allows for <extra> elements, so you could put your custom integer array in an <extra> element you create in the <mesh>. Documentation for working with custom data in the DOM is available here.

Thank u very much sthomas !
I’m gonna read the concept of the domAny class to store extra custom data

I found a very very good sample file of “how to create a cube from scratch” and exporting it as dae. All made with Collada Dom. I post the information here cause it can interests some people.

When u download & Install Collada Dom
Go To ColladaDomPath\samples\export

There is a source code explaining step by step how to create and export a cube. We can open the Visual Studio project at the same location to run it. (After Setting up the compiler like explained it the Programming guide)
There is a lot of comments in the source code, but still not enough for me :oops: But i’m not dead yet ^^ I’ll try again & again to work with the dom