proposal: collada profiles

Hi, it’s been some time since I visited here…

Lately, I’ve been working on PaperVision3D library for Flash players, which uses DAE files as 3D model assets.

The problem:

Papervision3D uses a Collada parser written in ActionScript 3

To create the DAE files, I tried to use Blender, which has a collada import/export plugin written in Python.

It’s been almost impossible to make DAE files to work correctly; exporting cubes and spheres works nice, but if you move from that, you begin having countless problems with geometry, materials, transforms, etc.

In an older post some people might remember, I discussed the problem of Collada, in order to support rarely used features it has become an extremely complex file format that makes creating custom parsers very difficult… the answer I received was that Collada was meant to be used with the official collada DOM, and to be used as an intermediate file format, not as a release file format.

Well, it happens that Blender or papervision3D don’t have the chance of using colladaDOM because they’re written in different languages (python and AS3), and in the case of Papervision, DAE files are being used as a final, release asset files. And it’s not the only one; engines like Ogre or Irrlicht use Collada as final files. It’s a trend that’s not going to stop.

My proposal, is this: to create a “profile” system.

Basically, a Profile would define a limited subset of the features supported by a given library. Libraries reading or writing DAE files would have to filter their data according to a given profile.

A practical case: Papervision3D Collada parser only supports a limited set of features of collada, when I export a DAE file, I have the risk of exporting tags not supported by papervision, at the end the model does not show up, and makes me expend a lot of time trying to fix the 3D model.

Now, papervision could provide a “papervision profile” which has a list of features that are mandatory, and which ones should be completely removed.

At export time, the user could choose “papervision profile” in the export plugin, and when exporting, the plugin could tweak the DAE file to match the requirements of the profile, or in case it cannot be tweaked, to warn the user with an error message: “you are using feature X which is not supported by Y profile”

I beleave that the profile system could greatly help developers in their independent collada parsers which only need to support a little subset of the collada library, and supporting the whole set is just not an option.

This could also help artists and designers when exporting to 3D engines to avoid using features not supported by them, and specially to avoid the “why my 3D model is not showing up!?” problem.

I hope you like this proposal!



I don’t think profiles are needed. The Collada Refinery exists for this very purpose - refining a collada document to some other format, potentially a stripped down version of collada.

Many refinery conditioners exist to do some of what you want.

This is I believe the best approach, as it moves the programming effort out of the exporter / importer framework and into a seperate module which only needs to be aware of collada. Adding a new feature such as a profile would require every exporter to implement this feature, and if the profile had non standard elements they’d have to implement these.

So papervision needs to specifiy the conditioner pipeline required, implement any conditioners which don’t exists, and then you have what you require without requiring a change in the spec.