The problem i have is that it’s not enough for my purposes. I would like to use more kinds of URIs, for example:
<instance_geometry url="ed2k://|file|someFile.dae|51272|D525CD3C0D81E20579E7735E959E3BCA|/#carGeometry" />
or maybe:
<instance_geometry url="cacheSystem://|file|someFile.dae|51272|D525CD3C0D81E20579E7735E959E3BCA|/#carGeometry" />
etc..
Is it possible to do that?
So far, the only way i can think of doing it is putting a server listening on localhost, that will forward the petitions however necessary. For example:
<instance_geometry url="http://localhost:1337/ed2k//|file|someFile.dae|51272|D525CD3C0D81E20579E7735E959E3BCA|/#carGeometry" />
or maybe:
<instance_geometry url="http://localhost:1337/cacheSystem//|file|someFile.dae|51272|D525CD3C0D81E20579E7735E959E3BCA|/#carGeometry" />
etc..
Any ideas?
Also, is it possible to delay the retrieval of those 3rd party files, so that i can implement some sort of streaming, activating the retrieval when i feel like (for example, when approaching the boundaries of current game level, etc.)?
Is it possible to do that?
Sure, you can use any kind of URI you want, including custom URIs, as long as they conform to the URI spec. The only issue would be that other programs wouldn’t know how to work with your URIs, so they wouldn’t be able to fully load the model for display.
Also, is it possible to delay the retrieval of those 3rd party files, so that i can implement some sort of streaming, activating the retrieval when i feel like (for example, when approaching the boundaries of current game level, etc.)?
This is considered an implementation detail by Collada. Collada doesn’t provide explicit controls for this sort of thing. This means that in your app you could implement whatever policy you like for how to dereference URIs, but other apps are going to do their own thing with your data.
Ok, i see. Forgive my ignorance, but i couldn’t find it on its wiki… can i use custom URIs with Collada DOM library? Custom, as in “mosp://filehash”, that is, invented URIs.
Again, is that possible using Collada DOM library? I’m still not sure if it uses SAX, or DOM over SAX, or whether building the whole DOM means it also retrieves the external references or not.
My idea is to use external apps and libs for editing/loading contents as much as possible.
The general workflow i was thinking on was:
-Edit all contents using local filesystem references, using generic .dae editors, as well as a custom editor for <extra> data.
-Once they are in a finished state, “compile” the .dae files so that all references become custom URIs based on hash or whatever.
-Then use Collada DOM lib (if possible) and retrieve the references if/when necessary.
Would that be possible? Thanks for any suggestions!
Yeah, you can use custom URIs just fine with the DOM*. The DOM has a class called daeURI for dealing with URIs. It’ll load your URI and parse it (which it should be able to do as long as your URI conforms to the URI spec), but doesn’t do anything else with it. There’s a daeURI::getElement method which clients can use to dereference a URI and obtain an element object pointer representing the resource the URI points to. This works fine for URIs with scheme ‘file’, ‘http’, or anything else directly supported by libxml, but for your custom URIs this method would just return null since it doesn’t know how to work with your URIs. For the most part It’s up to the client application to actually do stuff with URIs, so you can implement whatever sort of URI behavior you want in your app.
The general workflow i was thinking on was:
-Edit all contents using local filesystem references, using generic .dae editors, as well as a custom editor for <extra> data.
-Once they are in a finished state, “compile” the .dae files so that all references become custom URIs based on hash or whatever.
-Then use Collada DOM lib (if possible) and retrieve the references if/when necessary.
This sounds like a good plan if you’re using Collada as the runtime format. If you have your own format you eventually convert to then I wouldn’t bother with custom URIs in the Collada models.
The biggest issue with using custom URIs is that they won’t be compatible with other apps, but your plan should work around that. There are a couple things I should warn you about though. Collada uses URIs liberally so it’s very flexible in terms of how you organize data on disk, but unfortunately some apps don’t support cross-document references very well, and require all data to be in a single file. Also, some apps don’t import <extra> data properly so when you round-trip a model through the app you lose the <extra> data. You’ll have to do some testing with whatever apps you plan on using to make sure they support the Collada features you need.
I’m talking about the latest version of the DOM in the svn repo on Sourceforge. The last official release of the DOM works with URIs slightly differently, but it should also support custom URIs. I recommend using the latest code. We’ll be doing an official release soon.
Ok. So if i understand correctly, i can let Collada DOM download http:// and file:// files, and have my app called whenever an strange uri appears? With a callback or something similar?
Is there any reason why i should prefer a different format?
I intend to use collada for an open source project, therefore i won’t use any “privative” data formats.
The project is a vehicle simulator, which will need to handle relatively moderate amounts of data. Maybe 200megs in memory once a typical scenario is loaded, most of which would be textures anyway (i want to use collada for graphics too). Is it recommended to switch to an equivalente binary format instead of .dae files? Are there any standard binary formats/converters i may want to use?
Ouch. That can be a big problem. If i use the “compile” phase, editors will only deal with local filesystem references. Do tools not even support local fs refs?
Being able to use refs is an integral part of the way i need contents to be distributed…
Ok. So if i understand correctly, i can let Collada DOM download http:// and file:// files, and have my app called whenever an strange uri appears? With a callback or something similar?
Yes, that’s right. The DOM doesn’t dereference any URIs by itself. It just reads and parses them. When you call daeURI::getElement to dereference the URI and obtain the Collada element the URI points to (assuming it points to an element… not all URIs do of course), the DOM checks to see if the URI references another document. If it does, it asks the IO plugin system to load the document. You would provide your own daeIOPlugin class that understands how to dereference your URIs. This could be implemented as just dereferencing your URI to an xml document contained in a string in memory, and then passing that to the libxml IO plugin to actually parse the xml and convert it to daeElement objects. Or you could handle all the parsing yourself if you like. I strongly recommend using the latest code in Sourceforge for writing a new daeIOPlugin class, as the daeIOPlugin interface has changed since the last official release.
Is there any reason why i should prefer a different format?
It depends entirely on your app. The main issue is that loading and parsing XML is going to be slower than loading a custom binary format. In general I would prefer to just use Collada directly, and if it turns out that’s too slow, do your own format and convert Collada to that format in the ‘compile’ phase.
Do tools not even support local fs refs?
Yeah, there are tools that don’t support any cross-document references, or they read multiple documents in, but when you save you can only save it to a single document. Or some tools will support cross-document references, but only on certain elements, e.g. <instance_node> or <instance_geometry>. In general, the Collada format affords much greater flexibility than the internal data structures of current DCC tools are capable of representing. Each app has its own quirks in terms of what it can support, so you’ll have to do some testing yourself with the apps you want to use.
Good, so i can use world.bin.dae instead of world.dae for quicker load times…
Does this mean that i could, for example, create a io plugin that loads world.zip, by passing a world.dae file (found inside the zip) to the default .dae parser? That would be a cool trick!
That’s a pity… My intention is to use only open source DCC tools, such as blender. But it may be good for the long term if i also provide ways to use the more popular packages, such as max or zmodeller. Isn’t there any reference page were features of each DCC tools are compared, or something similar?
If there are not, could you please send me the file you used for your testings in the page you mention? Thanks!
Does this mean that i could, for example, create a io plugin that loads world.zip, by passing a world.dae file (found inside the zip) to the default .dae parser?
Yep, that’s the idea. Everything you need for this is currently in the DOM, but when you actually get to implementing it you might want to contact me for further help (steven_thomas@xxx, xxx=playstation.sony.com). You would provide a daeIOPlugin that opens your zip file, gets the memory buffer containing the document, and delegates the parsing to the daeLIBXMLPlugin. You might also need to write a daeURIResolver plugin… it depends on what exactly you’re trying to do.
My intention is to use only open source DCC tools, such as blender.
When I tested Blender’s Collada support it was a bit behind the other packages, but the code was all in Python and it was very easy to edit to fix problems. You’ll have to do some testing on Blender’s Collada support to make sure it’s functional enough for you. The last updates were in July of last year… I’m not sure if there are people actively working on it or not.
Isn’t there any reference page were features of each DCC tools are compared, or something similar?
Ideally a plugin for a DCC package would provide a feature checklist so you can see exactly what it supports. Blender has a page that might help here, but I’m not sure if it’s up to date.
If there are not, could you please send me the file you used for your testings in the page you mention?
I feel pretty stupid about this but unfortunately these files were lost when my hard drive blew up a couple months ago. The model I used for external reference testing was one of the few things I didn’t have in source control. Standard rookie mistake, not having stuff backed up or under source control.
The model was pretty simple though. It consisted of four .dae files. One file contained a <material>, another contained a <geometry>, and another contained a <node>. The fourth file was the main model file, and used <instance_material>, <instance_geometry>, and <instance_node> to instantiate the elements in the other documents.
