Collada features

Building the Collada Plugin

The OSG Collada plugin depends on the Open Source Collada DOM library. The current version of the DOM is 2.2. It can build a library for Collada version 1.4 or Collada version 1.5 documents. Both a static and a dynamic library can be build. The osg Collada plugin has only been tested to work with the 1.4 variants of the library. The Collada DOM library itself depends on (a part of) Boost, libxml2, pcre, pcrecpp, minizip, zlib. Precompiled libraries for different platforms and compilers are included in the Collada DOM download from sourceforge. As of December 2011, testing indicates that the plugin still does not work with the COLLADA DOM version 2.3.x, but does work with the 2.2.

In order to build the Collada OSG plugin CMake will try to find the DOM library by using the COLLADA_DIR environment variable. If CMake can not find it specify the COLLADA_DOM_ROOT and reconfigure. The precompiled dependencies used by the DOM will automatically be found and filled in. If only the static library is found CMake will use this and if only the dynamic library is found it will use that library. If both static and dynamic libraries are found it will by default pick the static library. If you switch on the advanced options in CMake you may overrule this setting by manually changing the COLLADA_USE_STATIC option.

Developer info

A description of the Collada extensions for specific OpenSceneGraph functionality can be found at the OSG Collada extensions page on the Collada wiki.

Tool info

This section should contain information specific to the Collada exporters in various tools and if/how they can export files that the OSG Collada plugin will be able to read. Quirks of the various exporters can be listed here along with workarounds if they exist.

Softimage XSI

The current version of Crosswalk (4.1) includes a Collada 1.4.1 exporter which seems to do a good job of exporting valid Collada files. There are a few quirks:

You need to check "Export XSI normals" on the ExportCrossWalkOptions - Settings page before exporting, otherwise the models will have no normals.

The exporter correctly exports Lambert, Phong and Constant materials. Blinn is always exported with a shininess of 0 so it is unusable, use Phong instead.

There were recent fixes to the OSG Collada plugin to support the way XSI exports animation. Apparently, the animations didn't always contain channels for all X, Y and Z components. OSG SVN as of 2010-03-22 has the fix for this, and animations are read correctly now.

The hierarchy will be respected:

Objects will be placed under MatrixTransforms (the object name will be put on the MatrixTransform), so the hierarchy will be MT - Geode - Geometry.

Objects under other objects will be the same in OSG, so the hierarchy will be MT with 2 children, one Geode - Geometry and the other MT - Geode - Geometry of the child object.

Nulls become MatrixTransforms too, so an object under a null will become MT - MT - Geode - Geometry.

You can also create a "Model" node in XSI, these also become MatrixTransforms under which the rest of the model will be.

For some reason, the name of the material of an object becomes the name of the Geometry in OSG. For example, if I have a sphere called redsphere, with a material called red, this will result in a hierarchy MT("redsphere") - Geode(unnamed) - Geometry("red").

Animation:

Animation Sources are exported as separate animations.

Animation Tracks (as seen in the Animation Mixer) are not exported.

You can still do some edits to Sources in the mixer, as long as you then freeze the clip by doing Clip - Freeze to New Source or Freeze and Replace before exporting.

Compounds must also be frozen with Freeze to New Source to work, and if you had transitions in the Compound they will work once frozen to a new Source.

Using Merge to New Source (with multiple clips selected) is an alternate way to do what a compound would do, but transitions won't have any effect then (even if you also selected the transitions before doing Merge to New Source).

TODO/Wishlist

Solve differences in drawables, DAE reader should place multiple collation elements into multiple primitivesets in a single geometry where possible (only when same material)