Specification for binary <source> data

Hi,

In order to speed-up the loading/saving of complex collada geometries, shouldn’t the specification offer alternative binary formats for <source> elements ?
If the specification enforces the exact binary format, then compatibility would be guaranteed between DCC tools, because each DCC tool would know how to extract the binary data.
Most of Collada specification could remain ascii. Only <source> elements could reference external binary files.

COLLADA does allow for externalized <source> data. I recommend reading about the <accessor> element in the COLLADA 1.5.0 specification.

A form of this optimization is implemented in the COLLADA DOM open source project too.

Really ?
Do you know the specific C++ class in Collada DOM that does this kind of optimization ?

It’s in these source files:

http://collada-dom.svn.sourceforge.net/ … p?view=log
http://collada-dom.svn.sourceforge.net/ … p?view=log

That’s interesting.

However, this “.raw” export option is specific to Collada-DOM. How many DCC tools support this option ?

If there was an “official” .raw (whose format is given in the specification), then binary format could be widely supported by any dcc tool.

Is it something that will happen in future specifications ?

The COLLADA DOM implementation of “.raw” stems from the capabilities of the <accessor> element, as documented in the specification, and the nature of opaque URI resources. I.e. its the <accessor> that describes the (in this case external) resource that is referenced by a standard URI.

So that in that sense it is standard COLLADA although I do not have marketing data about other tools that support it.

A good understanding about URI processing is key. As with any format that is external to COLLADA, and there are many thanks to the numerous image formats, it is up to the URI processor to dereference (i.e. retrieve) the resource. As long as the I/O software has a media type handler to retrieve the data then the <accessor> information provides the mapping from that external storage to the <source> and <input> elements.