Collada binary delivery format
does a Collada binary delivery format exist or is it planned? As mentioned in the Collada documentation, the Collada XML format is not supposed to
be a delivery format which makes sense.
Of course there are a lot of binary delivery formats out there but I am wondering why not have a Collada binary delivery format similar to the
one exists in current games plus the advantages of Collada?! This would make things much easier.
as there is a need from our side regarding a binary delivery format, we need to make a decision and probably an implementation for a binary delivery format. If there would be already such a binary delivery format
e.g. a standard like Collada, which supports most of the Collada entries, the decision which binary format to take and probably not to make the implementation of it, would make things easier for us.
And I hope and think for others as well.
COLLADA is not meant to be a delivery format. We have talked about creating a COLLADA binary format but we haven't gotten past the "talked about" stages.
What about binary do you absolutely need? Is it just a smaller file size?
If so, do you need it smaller on disk or passed over the net, or does it have to be a smaller memory footprint while parsing?
Google Earth uses COLLADA as a delivery format, even though we don't recommend doing so. They took the COLLADA document and zipped it up with the images and another GE specific XML file. Since COLLADA is text it compresses REALLY well. Its just that when you uncompress it you are left with the big XML document.
COLLADA does have many hooks for allowing binary data. Just nobody is really taking advantage of it (well everyone does without realizing it using images).
COLLADA uses URI's all over the place. You can make a URI point to an external binary document. You do it already with images. You can embed image data in a COLLADA document but nobody does that. They reference a binary image file located somewhere else. Well you can do this with almost anything in COLLADA. <instance_geometry url=""> you can make that url point to a binary geometry representation if your tools understand that. There just is no standard binary geometry files like there are images.
On a lower granularity level, you can externalize your floating point data in <source> elements. Your <accessor> element has the "source" attribute that is a URI. That can point to an external binary data file. And then you can even describe with <accessor> how to access the data.
So if you want to take advantage of this in your tool chain here is a good idea. Use the <technique> elements for dual representation. Create a conditioner that takes a COLLADA document and externalizes the data you want binary and creates the <technique profile="NopsEngine"> where you put your accessor. You can even keep both <technique_common> and your <technique> around so you can still load your documents into other tools. Then in your final step in your toolchain remove from the document all of the data that you have externalized, zip it up with all your images and external data, and viola! you have a lean binary/XML hybrid delivery format which can take advantage of all of the features COLLADA brings you.
sorry for the long post but I hope it gives you plenty of ideas to solve your problems.
Andy, thanks a lot for your message.
What we do need is a binary delivery format which will be used mainly in Embedded Systems, so
a) small on disk
b) Reading / Parsing time
should be minimal.
So we will think about our delivery format. Checking about the current which do exist plus an own format.
In any case, if possible, please let me know, if a standard binary delivery format is to come.
Hi. Have you ever heard of EBML (Extensible Binary Meta Language) ?
This is some kind of binary XML, which is used by the Matroska video codec.
So you could use it to easily convert your current COLLADA XML file into this filetype and use a adequate parser to load the binary file.
I'll have a look at it
Back from holidays
Thanks, I will have a look at it.
Hi, this thread is a little old now, but I just came across now as I'm getting acquainted with COLLADA.
Originally Posted by alorino
In our application we work with fairly large polygonal models of terrain... large enough that ascii file fomats are cumbersome to work with simply because they take such a long time to load.
In addition, parts of our processing pipeline may be remote, so again large ascii file are problematic to work with if we do any kind of iteration between non-collocated stages of the pipeline over the network. Of course one can compress the files, but I'd think a binary scheme with domain knowledge would provide better compression, and simply compressing the files doesn't address the load time problem.
Now, our application is probably fairly unusual, but I'd think even for more mainstream applications shorter load times would be a benefit to productivity, and a standardized binary format for COLLADA would be highly desireable.