include for COLLADA_ELEMENT*


i just started with collada dom and want to try a really simple example. the loading of a document works, now i want to do some stuff on it. for this i need the call: unsigned int geometryElementCount = doc.getDatabase()->getElementCount(NULL, COLLADA_ELEMENT_GEOMETRY, NULL);
unfortunately it doesn’t know COLLADA_ELEMENT_GEOMETRY. what header do i have to include? where can i start off to learn these essentials, i haven’t found anything on it in the programmer manual.

You can find pretty much all the string constants for element names in domConstants.h

In my experience the best place to start is with the conditioner samples that come with the dom. You can look at the source to see what headers to #include and look at the project settings to see what libs to link against. You need to grab libxml2 (including iconv and zlib) before you can build and use the dom in your own projects. This might be discussed in the programming guide, or it might be in a release notes or readme.txt file somewhere with the dom, I can’t remember.

From there if you read over the programming guide you’ll get a good understanding of programming with the dom. After that everything is pretty straight-forward… I refer to the spec & schema frequently to find out what I want to do and the meaning of various Collada elements, and that information is usually perfectly reflected in the dom, so it’s pretty obvious what to do programmatically.

One last thing: it’d be a good idea to grab the latest dom available from sourceforge via svn. The last official release (from July) has some annoying memory leaks and performance issues that’ve been fixed in the latest code available on sourceforge.

Yes domConstants.h has all of those strings.
Very recently (it may be in SVN may not be yet) I changed a few of the strings. there are COLLADA_ELEMENT_* and COLLADA_TYPE_. The difference between the two is that there are quite a few elements that share the same type but have different names. The ELEMENT_ strings are those elements. The time to use these are the create methods should use COLLADA_ELEMENT_* and the database getElement* methods COLLADA_TYPE_*.

Also good news. We are near completion of creating a binary distribution package for the DOM and Refinery. Included in this is the DOM built as a DLL. Also the headers have been cleaned up so if you are compiling against them you don’t need to have the libxml2 headers. And there will be a new sample that demonstrated creating a simple textured cube from scratch.

This should all hopefully be coming out within a week.



I just came upon a confusing issue with the domConstants.h that is supplied with Refinery. I found the following when searching for INPUT in include/1.4/dom/domConstants.h as installed by Refinery:


(Note that I’ve edited out some unrelated search results)

When doing the same search in include/1.4/dom/domConstants.h in the 1.4.1 DOM source installation I found this:


I’m not sure which is correct but for the time being I’m using the Refinery version.


Hmmm… may have spoken too soon. I tried calling pPolylist->createAndPlace(COLLADA_TYPE_INPUTLOCALOFFSET) and I am returned a NULL pointer. Then I tried pPolylist->createAndPlace(“InputLocalOffset”) with the same result. Just for kicks I also tried pPolylist->createAndPlace(COLLADA_ELEMENT_INPUT) and still no luck.

Is there something obvious I’m missing here? I’ve been at this for a while today so I wouldn’t be surprised.


Yes! You have not updated your non-refinery version of the COLLADA DOM to version 1.2.0.

The changes to the constants happened for this version. It is also the version that the Refinery uses.

There are different uses for the two types of constants (but for the majority of cases they can both be used interchangably). The COLLADA_TYPE_* constants refer to COLLADA element types that are defined in the schema. The COLLADA_ELEMENT_* constants refer to COLLADA element names in the schema. There are times when the element’s name is not the same as the element’s type, and input is the most common example of this. For example, the input elements found in <triangles> have the name “input” but the type “inputLocalOffset”.

As for their uses in the DOM, the function documentation should state whether the element type name or the element name is required. The only real places that this matters (off the top of my head) are the createElement and createAndPlace daeElement functions, they require the element name so use COLLADA_ELEMENT_, and the getElementCount and getElement daeDatabase functions, which ask for the typename so use COLLADA_TYPE_.


Excellent! Thanks for the info. I’m actually in the middle of converting over to doing everything offline with conditioners (I used to link the DOM into my engine and load DAEs directly) so I’ll soon be able to get rid of the “other” version of Collada in my tree and only use the one shipped with Refinery.

Thanks again for your help.


Depending on the scope of your project you may still want to support loading COLLADA directly in your application.

It is useful for “fast-path” content rendering. When an artist wants to visualize a document in the engine or tweek something about the content they can load the .dae directly without having to run the whole thing through the refinery process.

But as stated earlier, it depends on the scope of your project. Maintaining the two import paths may be more of a hassle than what its worth for small projects. Also if the conditioning step is relatively quick and painless, it may not be a problem.



I can compile using TYPE constants but get an undefined external when linking.
Including domConstants.h doesn’t help…
I end up using strings e.g. “geometry” instead :shock:

You probably have some linker settings wrong. Using raw strings is fine, but be aware that in some situations you want to use the schema type name (e.g. when calling daeDatabase::getElement*) and sometimes you want to use the element name (e.g. when calling daeElement::createAndPlace).

ok, cheers :slight_smile: