' (Current Version: pre-alpha) '

New Home

The OgreCollada project (wiki, forum and source) can now be found on sourceforge: OgreCollada (NOTE: website seems to have been abandoned since Dec 2008, and spam added to the front page in Aug 2009. Access the wiki history to get at the actual Ogre Collada information. One of the external links on the wiki triggered the virus alert in my antivirus program. This note was added Jan, 2011.) This is also a work in progress so some information may still be outdated. The rest of this page is outdated.


OgreCollada is a project intended to replace the current ColladaPlugin with updated and complete COLLADA support, at least so far as Ogre is concerned. That is, everything in COLLADA that applies to Ogre, OgreCollada will support.

NOTE: Currently, OgreCollada in plugin form also replaces CgProgramManager, since the current design requires that the code have access to the CgProgram class, but a compile- and runtime-dependency on the CgProgramManager library was not desired. This design is likely to change in the near future, but at this time, if you build and use OgreCollada in plugin form, disable loading of your CgProgramManager plugin; the OgreCollada plugin provides the CgProgramManager plugin internally. Note also that the CgProgram and CgProgramFactory code are Ogre 1.4.6; this means that the changes made to the 1.6 (CVS HEAD) code stream are currently potentially incompatible with OgreCollada.


OgreCollada is released under the MIT license. In other words, do with it what you like, don't claim it as your own invention, and no warranty expressed or implied and so on. Yes, static-linking is fine (and preferred).



OgreCollada leverages the actively-developed and MIT-licensed FCollada library, developed and maintained by Feeling Software. The OgreCollada source distribution includes all of the FCollada source needed to build OgreCollada.


OgreCollada also depends, obviously, on Ogre. Specifically, the OgreMain library. It is assumed that if you are interested in using OgreCollada, that you already have Ogre available somewhere on your development machine.

Mogre (optional)

If you intend to build the Managed C++ (C++/CLI, aka CLR) configurations of OgreCollada, you need to have access to the Mogre OgreMain library and header files.


OgreCollada builds and runs on Windows and Linux at present.


Windows projects for Visual C++ 8.0 are provided.


On Linux, the current build script support is Scons; autotools support will be added in the future.


Currently OgreCollada is available only in source form.


You can get the source from anonymous SVN, at
(Link seems to be dead - Jan4, 2011)

You will most likely be prompted to accept the SSL certificate we used — we use a self-signed certificate; it is not there for trust, but for password security.

Anonymous access credentials:
username: anonymous
password: anonymous

If I get a chance, I will figure out how to make SVN/mod_svn accept empty username and passwords.

Building From Source


Building from source gives you the option of building OgreCollada as an Ogre plugin, or as a static library.

On Windows, you need to do the following once you have obtained the source:

  • Change the project settings for Debug/Release/Debug DLL/Release DLL to point to where your OgreMain header (.h) and lib (.lib) files exist. If you are using an Ogre SDK, this will be in $(OGRE_HOME)/OgreMain/include and $(OGRE_HOME)/lib.
    • If you are building ColladaViewer, you need to point the ColladaViewer project to where your wxWidgets headers and libs exist.
    • If you are building the Debug CLR and/or Release CLR configurations, you need to point the project settings to where the Mogre OgreMain headers and libs exist.
  • Build Solution
    • For Ogre Plugin: Select Debug DLL or Release DLL. Plugin will be copied to the bin/ directory in the OgreCollada source root.
    • For static library: Select Debug or Release. Currently, the recommended method of linking OgreCollada as a static library is to include it in your project and link it implicitly via the Project Dependencies feature in Visual Studio. This means you will need also the FCollada, FArchiveXML and LibXML projects in your solution as well, and have those set as dependencies of your project executable.


(I have not performed the Linux build myself — the SCons build files were provided by another developer). Currently, the only way to build on Linux is with SCons. In the future, autotools scripts will be available for OgreCollada.


Binary SDK builds of the library are not yet available.


OgreCollada comes with some development tools, primarily used while I was testing the library, so they are not intended to be full-featured content-development tools, but instead, can serve as tools to verify that what you exported as COLLADA will look as you expect in your Ogre app, without having to fire up the app.

Ogre ColladaViewer

A simple viewer application that allows you to preview your COLLADA document in an Ogre render window. This app is implemented as a wxWidgets application for portability; in order to build this application you will need to have wxWidgets headers and libs available on your system. The Linux build scripts check for wxWidgets presence; currently Windows users will need to point the ColladaViewer project settings to where your wxWidgets headers and libraries exist. In the future, license permitting, I will include the prebuilt wxWidgets headers and libs with OgreCollada.

Current navigation is extremely limited: only the mouse scroll wheel is recognized, to zoom in and out of your scene. Holding down CTRL while scrolling zooms at 1/10 the rate.

Ogre ColladaConverter

This is a work-in-progress command-line application intended to perform the same tasks as the OgreXmlConverter tool — namely, produce Ogre .mesh, .skeleton and .material files from the content contained within the COLLADA document. It is in very early stages of development — at last check, it crashes with programmable materials because there is no render window created by this application.


Currently, there is a need to provide altered versions of these two Feeling Software plugins; see below in the COLLADA FX section.

Language Bindings

C# (C++/CLI)

I have got a start on Managed C++ (C++/CLI, aka CLR) bindings for OgreCollada. This works for me with a particular build setup — since it depends on the Mogre build of Ogre, you needs to link it against the Ogre libs as built within the Mogre project. This means in turn that you need to have Mogre in source form, or at least the OgreMain libs and headers from the version of Mogre you are using. Given the above, this support is listed as "experimental", but know that it does work. Limitations: currently no support for resource-created notifications in the Managed version of OgreCollada.

These bindings are available in the "Debug CLR" and "Release CLR" project configurations of OgreCollada.

Using OgreCollada

OgreCollada is as compatible with the COLLADA 1.4.x specification as FCollada is. (There is one missing feature in FCollada, mentioned in the TODO list below). This means that so long as the DCC tool you are using emits compliant 1.4.x COLLADA, OgreCollada should be able to import that document without problems.

The major additions to COLLADA in 1.4.x versus the 1.3 and prior versions, are COLLADA Physics and COLLADA FX.


The TODO list below identifies COLLADA Physics support as a post-1.0 issue. This may move up in priority (likely, will, since I will need it personally, but it is one of those things that will be done when it's done). In short, OgreCollada will simply parse the COLLADA Physics objects and fire notifications when they are complete, so that the application can deal with the physics data how it likes. No particular support for or integration with any physics library is planned, or implied — OgreCollada will simply provide to the application the raw physics data and physics body/shape data, when it encounters any.


COLLADA 1.4.x introduced support for the programmable graphics pipeline. COLLADA FX can best be thought of as an XML version of CgFX/.fx (the nVidia and Microsoft "effect file" formats). COLLADA FX's native/preferred high-level shader language is Cg; this is not surprising considering that the COLLADA FX specification was created by nVidia personnel. (Note: While GLSL is also supported in COLLADA FX, there are no plans at present in OgreCollada to support shaders defined in <profile_GLSL> blocks.)

While some may see this as a limitation, the fact that Cg has a stable API and the current implementation of Cg (version 2.0) supports Shader Model 4.0 hardware, makes this a wise choice (in my opinion) for the preferred shading language in COLLADA FX. This also means that unless you are a masochist, you will most likely provide your shader effects to your artists in the form of CgFX files (those using Maya and Max, anyway), since the ColladaMaya and ColladaMax plugins (also developed and maintained by Feeling Software) have native COLLADA FX support, and can import CgFX files directly into the applications.

Upon export, the CgFX effects are converted into COLLADA FX (much the same way that you can perform this conversion in nVidia's FX Composer), and it is that form that FCollada (and therefore OgreCollada) read the programmable effect. One problem with the current stock ColladaMaya and ColladaMax plugins is in how they handle <annotation> elements in COLLADA FX.

The reason this is a problem is that OgreCollada needs to have some way to tie uniform shader parameters to the Ogre named and named-auto parameters available; the COLLADA FX specification does not provide enough unique and standard information to allow this mapping without additional information embedded in the effect file. The solution in OgreCollada to support these mappings is to leverage the COLLADA FX <annotation> element, for use in providing those bindings in the shader source code. The following is excerpted from the Notes.txt file in the doc/ folder in the OgreCollada source root:

Mapping COLLADA FX uniform variables to Ogre named/named-auto params

To hook up named auto-params, use annotation named "param_named_auto" and the textual
auto-param type name as listed in the Ogre Manual:

<newparam sid="WVP">
    <annotate name="param_named_auto">
    <float4x4>0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0</float4x4>

OgreCollada will match the parameter name in the newparam
sid to the Ogre param_named_auto provided as the string value in the "param_named_auto"
annotation. The newparam value (the <float4x4> element contents above) in this case is
ignored, as is the COLLADA FX <semantic> element.

To hook up named params, similar to above, except that

  1. the annotation name is "param_named"
  2. any value provided in the annotation is ignored by OgreCollada

<newparam sid="Kd">
    <annotate name="param_named">

The named parameter type will be extracted from the <newparam> type. Any value in the
type element (the "1" in the <float> type element above, for example) will be used as a
default value.

For named params and named auto-params that are array values (such as a light position in
an array of N lights), append the Ogre auto-param type name with the object's array index.

<newparam sid="light0Pos">
    <annotate name="param_named_auto">
    <float3>0 0 0</float3>

The "/0" above indicates that this should be treated as the 0'th light in an array of N
lights. This is the same as providing an "extra_params" value to a named auto-param in an
Ogre material script.

Note that while this does place additional burden on the shader author, there really is no other way to leverage the wide variety of auto-parameters that Ogre provides to GPU programs.

The ColladaMaya and ColladaMax source code is provided in OgreCollada as modified versions of the base source available from Feeling Software, until I can make a patch for them that passes through all shader annotations unfiltered. Once that patch is available in the original versions distributed by Feeling Software, I will remove the altered versions from the OgreCollada source.

Multiple-Cg-profile support

The way that CgFX and .fx work is that each technique targets a single shader profile. Ogre, on the other hand, can check against a list of supported profiles. The design decision to provide this support in OgreCollada is to leverage the <shader>-element annotations to provide additional profiles to check. At present, however, FCollada does not track that information. Therefore, the COLLADA FX support in OgreCollada is limited to a single shader profile per technique, as in CgFX and .fx.

Using OgreCollada In Your Program

OgreCollada's public interface is very simple, by design. In short, you create an instance of the importer/exporter class, import or export a COLLADA document (which populates an Oge SceneManager instance you provide), and then optionally release the instance of the importer/exporter class you created. The following example shows how to import a COLLADA document into your Ogre application

Importing COLLADA documents
#include "OgreCollada.h"

using namespace OgreCollada;

int main(int argc, char* argv[])
    // assumes you have a pointer to valid Ogre::Root and Ogre::SceneManager instances
    ImpExp* pImpExp = CreateImpExp(pRoot, pSceneMgr); // you can also set these two values later

    return 0;

(edit by trs79, replaced ReleaseImpExp with DestroyImpExp)

The above code will load the contents of your COLLADA doc (whose name is contained in the string pointed to by pDaeFilename) into the Ogre scene managed by the SceneManager instance pointed to by pSceneMgr. OgreCollada will not clear your scene when importCollada is called; this allows you to import multiple documents into the same scene.

Each instance of the OgreCollada ImpExp object corresponds to one COLLADA document. An attempt to call importCollada a second time after a document has been loaded will cause the method to fail silently. If you need to load more than one document, make more than once instance of the ImpExp class.

Exporting COLLADA documents

There currently is no support for creating COLLADA documents from an Ogre scene. This is a possible feature for post-release, but for 1.0 there are no plans for converting an Ogre scene to COLLADA.

That said, you are perfectly able to alter a COLLADA document that you imported, and save out to COLLADA the altered version. In fact, that is what the IResourceNotification callback interface was created to support.

The reason that there is no inherent support for hooking up the Ogre objects created during import, to their corresponding FCollada objects, is twofold. First, the Ogre MovableObject "any" and "userDefinedObject" slots do not work that well with the naked pointers provided by FCollada. Second, it is entirely possible (even likely) that the user would want to use those slots for other purposes. For that reason, OgreCollada simply will call back into the calling code to let it know that something was created, and will also provide the code with the Ogre object created and the corresponding FCollada object, and let the code decide what it wants to do with that information.

If you want to alter the FCollada document based on changes in the Ogre application, it is up to you as the application developer to figure out how you want to track the relationships between the Ogre objects and their source FCollada objects, and how and when to update the FCollada document objects. Leveraging the IResourceNotification callback mechanism is the only way you will be notified of the creation of Ogre objects so that you can manage those Ogre/FCollada relationships. Note that if you plan to update the FCollada document in order to save an altered version, you need to include the proper FCollada headers. The FCollada API is documented in doxygen/HTML form in the FCollada/documentation directory.



The final alpha release will be feature-complete. The following issues are still outstanding before that can happen:

  • Support for multi-pass programmable materials (not started; single-pass is complete)
  • Skeletal Animation support finished (in-progress)
  • Patch FCollada to support the way that SketchUp exports its scene graph (not started)
  • Patch ColladaMaya and ColladaMax to pass through all original parameter annotations (in-progress)


(no issues identified yet; depends on Alpha completion)


(no issues identified yet; depends on Beta completion)


  • Parse COLLADA Physics for the sole purpose of providing COLLADA Physics callbacks to the application

See also