External Data Source?

I looked through the 1.41 API and samples but could find any reference to calling external data sources. What I would like to do is to have a main scene file, that contains references to external collada sources, or even have more sources nested within those. So say for example that I have a game level. It would make sense for the level model to be in one file, and the player model to be in another. This could also be used to make very complex scenes much more managable. Everything from lighting and camera rigs to generic skeletons to LOD could be implimented this way and swapped on the fly. Can this be done?

Thanks, and my appologies if the answer to this is painfully obvious.

well “on the fly” implies run-time behavior, which COLLADA tries not to define. Also, COLLADA is not meant to be a delivery format. But I guess some people are trying to use it that way anyways.

But you are on the right path and COLLADA has been designed from the start to allow you to achieve what you are asking about. Maybe it doesn’t come through very easily in the documentation. And what do you mean by API? are you talking about the COLLADA specification or the COLLADA DOM or FCOLLADA libraries?

So heres the thing. COLLADA uses URI all over the place. If you want to know more about URI check out RFC 3986: URI General Syntax. Using URI’s you can make external references to files. You can make external references to internet resources. You can even make external references to database querries.

Here is an example. In a normal “monolithic” COLLADA document (monolithic meaning it is holding EVERYTHING, geometries, lights, animations, etc) you get something like this
<instance_geometry url="#GEO_01">

The #GEO_01 is a URI fragment. The last part of a URI where you can specify a specific location within the resource identified. If you don’t have any resource identified before the fragment it means “within this document”

OK so now lets externalize this:
<instance_geometry url=“file:///c:/some/directory/geometries.dae#GEO_1”>

That would be an absolute URI pointing to an external dae file and then saying to get GEO_1. You can also use relative URIs which would look just like relative paths. ie. url="…/…/resources/geometries.dae#GEO_01"

Hope this helps,

Thanks alorino. That is exactly what I wanted. Maybe you should change up some of the “keywords” in the documentation so it would be more obvious. By on the fly I mean one could specify object with several different “url’s” for different LOD’s or skeletons or whatever, which an app would then store and call when needed. Collada’s goal is to be a universal intermediate format from what I understand, and not a delivery format as you mentioned, but having a human readable and human editable format is appealing enough to make people like me use it for things that it wasn’t intended for. Why not?

Obviously Collada has documentation and not API. I was tired when I wrote my post.

Cool. Yeah I have always been thinking that game data be stored in <extra> elements. It would be really easy.

  <node id="base">
    <instance_geometry url="#base_geo">
      <bind_material>   //Do the material binding stuff
    <extra type="LOD">
      <technique profile="MYENGINE">
        <LOD distance="50">#LOD_1</LOD>
        <LOD distance="100">#LOD_2</LOD>
... somewhere else in the file.. or other files
  <node id="LOD_1">
    <instance_geometry url="#geo_LOD_1">
      <bind_material>   //Do the material binding stuff
  <node id="LOD_2">
    <instance_geometry url="#geo_LOD_2">
      <bind_material>   //Do the material binding stuff

I figure you can do the LOD based on the node and not the geometry so you can LOD the effects and materials that are bound to it. Also you can switch between an instance_controller to instance_geometry if you don’t want to skin something far away.

Using the same type of extra you can specify other game related relationships. Like if something takes damage. After x amount switch to geo_2.