COLLADA – A powerful file format for digital content creation

COLLADA is an XML file schema, which allows users to exchange 3D assets between various DCC applications like “Autodesk® 3ds Max®“, “Autodesk® Maya®” or “SOFTIMAGE®|XSI™” and other interactive 3D applications. It was originally initiated by Sony Computer Entertainment® America (SCEA) to create a development format for “PlayStation® 3” and “PlayStation® Portable” projects and became a standard of The Khronos Group, which also holds the OpenGL standard.

There are a lot of problems to transfer data from one 3D application to another, because every software uses proprietary file formats, which are optimally suited to the features the application supports. Most programs also support other file formats like “Wavefront Object“, which however can only store a small set from the features list. That way it is often only possible to convert model data like polygon meshes with a single texture coordinate set and more complex data like multiple texture sets or animations get lost. Even commercial converters are not able to translate every asset completely.
So for realtime 3D or game development programmers were forced to abstain from features, which were not supported by the file formats their team was using but which became more and more important with increasing game quality. Or you had to write an exporter or importer for every 3D application, which the artists were using. Just a single im- or exporter can be a lot of work.

A solution would be a standard file format that every application can read from and write to. The first attempt was “FBX®“, which is now owned by Autodesk®. It became free to use but a long time it does not solve important issues like exchanging multi-textures between programs because the existing plug-ins were not able to do that, even though the format itself could handle it. And there is no source code to extend the plug-ins by yourself. You still had to write your own for every application.
Today “FBX®” is the most common format for asset exchange between DCC applications but not important for game programming.

In October 2006 the COLLADA format had been published. It was and is open source, easily readable XML and extendable. But there were no plug-ins and no programming kits. Because “FBX®” has got a C++ SDK it was easier to write im- and exporters for that format than for COLLADA at this time. Fortunately some month later a SDK was released and the first plug-ins for programs appeared. Today many 3D applications support the format but not all major ones like “LightWave 3D®“, which we are using. However native support is announced unofficially for the current main version.

We have already implement a COLLADA file loader into a character animation plug-in for “Viz|Artist 3.0™” called “Action Model“. And currently I am using COLLADA as standard development format for “TigerHeart” II projects.
Files are being read using the SDK and converted to “TigerHeart” objects. These can now be modified using C++ and will also be changeable in a editor later. After that object data can be stored back without destroying original COLLADA data that was not converted or modified. In doing so multiple applications can access a COLLADA file, modifying its data without loosing something that was useless for a program. A sound editor may use some 3D data for setting effects but it cannot utilize textures. Although it does not destroy those texture objects by overwriting the original file at export time, because only new and modified data is updated to the COLLADA file database. That is no standard behavior for the COLLADA runtime but can be easily integrated using the SDK.

COLLADA has got also disadvantages. Because the format is very flexible, diverse programs can store their data differently. The programmer has to adapt his software for every utilized application. And even then an update of an application or its plug-in can force him to change his code. But this is being done lots of times faster than to write an im-/exporter for every proprietary file format.
Many common file formats have got the second downside. They are very slow to load and save because much data has to be interpreted multiple times. It does not really matter at editing time but loading time is essential for interactive programs and games. Programmers are able to accelerate reading texture file content using an own format and they also are able to do it with all other data. Generally speaking it is important to convert as few as possible and often to minimize bandwidth.
COLLADA files and other development assets could be converted before they are regularly used by the project or when they are finalized. That depends on the time you are saving during the development. In any case they should be converted before the product is delivered to the customer.

I believe that COLLADA will become the standard game development format one day, if no other competitive format occurs. Currently it is already utilized by some big names like Sony®, Google™, “3ds Max®”, “Maya®”, “Unreal® Engine” or “XSI™”.

TigerHeart II: First impressions on OpenGL

I am currently implementing some classes for the new “TigerHeart” graphics engine using the OpenGL pipeline. And it is the right way because I am a beginner in OpenGL, which is a little bit more different from Direct3D than I thought. Since I am a professional in programming with Direct3D I can judge how to design interfaces, classes and their interaction so they can be used for both APIs.
A good example is shader programming: In Direct3D vertex and pixel shaders can be applied roughly independent from another. But using OpenGL you have to create a program object, to which multiple shaders can be attached. Afterwards this “program” must be linked and applied to utilize the shaders.

per vertex lighting per pixel lighting

You can see my current progression state at both images above. It is a cube model with shared, rounded vertex normals, what is not a reasonable assignment but a good test. The first one shows the common per vertex diffuse and specular lighting. It has got a poor quality because both lighting colors have to be linearly interpolated between the eight vertices.
On the second image you can see the same calculations but relocated to the pixel shader. There is no need for a normal map unless you want to add details to the object without appending vertices. The quality seams to be nearly perfect.

The mesh is rendered using vertex buffer objects (VBO), which is the fastest way to draw complex models using OpenGL, and shaders are compiled with GLSL. This language is comparable to Microsoft’s HLSL but have got some design differences. For example the compiler is integrated into the graphics driver and there is no possibility to specify shader model targets.