1.4.0, visual_scene, FCDocument and refs

We’ve applied for, but not received the 1.4.0 schema, so I’m stabbing in the dark.

For speed reasons (max exporting + game editor importing / game artwork xml compiling) we plan to export our scenes as multiple collada files. The scene contains assets which contain a path and a selection. Each asset maps to a collada file. So we need to export a index file that references these other files to recreate the scene.

We plan to use collada for this index file. At first I thought we would have to reference each object in each file. (Which would be a bit of a nightmare).

Then I noticed visual_scene and instance_visual_scene. I could just give instance_visual_scene a url containing a path as well as a name. The Scene would just be a collection of instance_visual_scene, one for each file.

So for instance:

<?xml version="1.0" encoding="utf-8" ?> 
<COLLADA xmlns="http://www.collada.org/2005/11/COLLADASchema" version="1.4.0"> 
         <authoring_tool>3dsmax Collada exporter v2.07</authoring_tool> 
      <unit name="Inches" meter="0.01"></unit> 
      <instance_visual_scene url="./file1.dae#part1_max"></instance_visual_scene> 
      <instance_visual_scene url="./file2.dae#part2_max"></instance_visual_scene> 

Perfect, only it doesn’t work with FCDocument. (It has one FCDSceneNode, and it has to be from the library_visual_scenes of the file.)

Looking at the code of FCDocument I’m surprised at how inflexible it is. FCDocument is quite far off a generic collada api. I hope it’s nothing to do with future collada api.

I would expect a collada api to hand me an object structure version of the collada xml file. The user being able to override reader classes (that create the objects (so by overriding a reader class you can make it return your own version of it’s corresponding object)). It being left up to the user weather to create writer classes or extend the reader classes to output the data in their own format.

Existing code aside, is what I’m after something permitted by the format?
Does the format permit instance_visual_scene’s urls to refer to files?
Does the format permit multiple instance_visual_scenes in <scene> ?

It seams to me to be a sensible way of working with large amounts of xml data.

Joe Burmeister

Eurocom Ltd
(Max/Maya Tools)

Hi Joe,

I’m glad to hear you’ve decided to check out the FS import classes. They are definitely not meant to be a complete API, they are meant to speed up the writing of our importers by hiding the COLLADA from the application-specific layer. It sounds to me like what you are interested in is Sony’s COLLADA DOM, which does give you object structures of the COLLADA XML file.

Now, about the schema: You’ll have to apply to Khronos to get access to the un-released schema. It should be available publicly in the near future. The FS import classes do take many shortcuts, right now, so they don’t support all the uncommonly-used features of COLLADA.


Hi Guillaume,

That’s a relief. I’m a old RenderWare OpenExport man you see (worked with it at csl for 3 years), which had a xml format like Collada. So I’m keen to have at least the same level of abstraction and overrideablity.
Where can I get hold of Sony’s COLLADA DOM? (For 1.4.0 if possible)

Anyway, that aside, on to my issue.

We have applied to Khronos for the 1.4.0 schema (through KevT) a while ago, waiting on it arriving.
But in the mean time, can you tell me if Collada’s instance_visual_scene and Scene tags support what I’m after?
I’m happy enough to fudge something to write out the index Collada file for the time being. I just wait to make sure it will be valid Collada.


Eurocom Ltd
(Max/Maya Tools)

The COLLADA DOM for 1.3.x and 1.4.0 is included in the pre-release package on the khronos web site.

Once your application has been reviewed and accepted, you should receive a document that you have to sign and fax back. And then only you have access to the schema, specification and DOM.

Since the ratification is scheduled for January 3rd, and that most of us will be on vacation the last week of December, you need to make sure you are finished with the registration process early next week. If you have not received the document after registering, please send us an e-mail at collada@collada.org.

I am sorry, but detailed COLLADA 1.4.0 discussions are not allowed publicly until the specification is made public.
This being said, what you are trying to do should work fine. Alias did a demo at SigGraph last year where they had modified the COLLADA import/export to exploit the multiple representation aspect of COLLADA to create a ‘scene file’ that points to all the assets within the <scene> element. Each asset was stored as a separate file, that itself may be a multiple collection of files.

But the nice part was that at each level of the hierarchy it was possible to not parse further, but instead use the simplified representation available at this level.

The demo was designing a city, where each block was first a cube. By selecting an object, the user could enable the higher level of detail representation, and so on. The modifications applied to the scene at the higher level (rotating a block) would be applied to all the objects in the hierarchy.

Now that we have many features in COLLADA, we want to focus on asset management and techniques like the above. Our goal is to form a working group on this subject, and we would are looking for more participation. Please let us know if you are interested in joining the design group.

– Remi

Actually that is what the library elements are for…

I’m a bit confused about <scene>

The specification says:

The <instance_physics_scene> element may occur any number of times.
The <instance_visual_scene> element may occur any number of times.
The <extra> element may occur any number of times.

Great just what I need.

But the schema says:

The instance_physics_scene element may only appear once.
The instance_visual_scene element may only appear once.
The extra element may appear any number of times.

but also:

<xs:element name=“instance_physics_scene” type=“InstanceWithExtra” minOccurs=“0” maxOccurs=“unbounded”>
<xs:element name=“instance_visual_scene” type=“InstanceWithExtra” minOccurs=“0”>

What’s going on? Why does instance_physics_scene text say the limit is only one, but the actual schema def say “unbounded”? I guess human error, but what is it meant to be?

As I said before, ideally we want Collada to support multiple instance_visual_scene in a <scene>, and for those instance_visual_scene to be to referenced in from other files. Looks like instance_visual_scene url can be to another file, so it’s just multiple instance_visual_scene is the problem at the moment. We could just use <extra>, but it would be nice for it to be in the standard format. (Means any future views, editors, etc load the scene as we see it.)

Joe Burmeister

(Max/Maya Tools)

This is errata. Thanks for catching them.

These are correct. The schema is the formal definition and should be followed when there is a descrepency between it and the specification.

The current design allows for only one visual scene instantiation. The way to composite the scene is by creating <library_nodes> and creating a <visual_scene> that assembles the root nodes that you want for that scene. This is the one <visual_scene> that you then instantiate.

The current design allows for only one visual scene instantiation. The way to composite the scene is by creating <library_nodes> and creating a <visual_scene> that assembles the root nodes that you want for that scene. This is the one <visual_scene> that you then instantiate.

Damn. But isn’t this something people will want?
With a scene, you may well want seperate, referenced <visual_scene> nodes for world sectors and dynamic object hierarchies (like characters). If you can control the reference resolving, then you can choose world sectors of different LOD for different distances. If you change your character, then you don’t need to update the character in your art package scene and rexport the scene. This braking up of the scene saves on export time, it will also save on import time as your level editor need only reimport the visual_scene that has changed.

Joe Burmeister

Eurocom Ltd
(Max/Maya Tools)

Just thought I’d chime in:

Personally, I think the schema should allow for multiple <instance_visual_scene>/<instance_physics_scene> elements. I think it’s a good idea to have multiple <visual_scene> elements for the different blocks of a game, especially if each block of a game is loaded dynamically.

For the DCC plug-ins and the viewers, though, it should be okay to support loading only one <instance_visual_scene>, or merging multiple <instance_visual_scene>, on an import flag…


Yes, that’s why you can do it the way I described.

A document has one <scene> (the whole world) that can instantiate one <visual_scene> (everything you can see). A <visual_scene> is populated by <node> elements, where nodes are models, cameras, and lights.

Those are <node> elements in <library_nodes>. You should be able to do what you describe with the existing system.

What’s wrong with modelling them as <node> elements like in previous versions of COLLADA?