[Fluxus] more collada commits

[Matt Jadud]

On Nov 29, 2007 5:46 AM, Dave Griffiths <dave at pawfal.org> wrote:
> really change is the way the geometry data is stored. fwiw the first thing
> I do with the collada file is use xml.ss to convert it to a big sexpr, so
> the rest could remain the same.
>
> The alternative extreme is to use a binary format and write it all in C++,
> this would be fastest and maybe would provide a good alternative to
> collada rather than a slightly different ascii format. I'm not very keen
> on binary 3D formats though.

Hi Dave,

Something I've done in the past as a half-way in this space may apply
for you as well. I've always thought it was a bit hacky, but who
knows.

You can write out your scenes as Scheme expressions. Then,
read-and-eval them in. This, of course, is glacially slow for large
armounts of data. Eg.

(let ([h (make-hash-table)])
  (hash-table-put! h 1 1)
  (hash-table-put! h 2 2)
  ...)

for millions of elements.

The benefit of writing it out is that you can read the file, and
parsing it is easy: (eval (read fp)). (I think 'eval' is dangerous,
and perhaps even more so for a file you're 'read'ing...). What you can
do, though, is after you get things the way you like, you can use
MzScheme to compile the expression. I think the compiler collection is
your friend here.

The idea is, it sits on disk as a bytecompiled, zipped file. It comes
into memory quite quickly, and the process of reading and writing the
file is not all that different from the read/eval loop, because
MzScheme has libraries to make this almost trivially different than
the uncompressed/uncompiled approach.

Someone in the PLT group may have a more elegant AND efficient
solution. I found it worked acceptably as a file format for libraries
of assembly instructions and their metadata, where each file often has
tens to hundreds of thousands (or more) instructions and their
associated metadata to be loaded.

Hope that helps.

Cheers,
Matt