[Fluxus] more collada commits

[Dave Griffiths]

> 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.

I think this is the clever way to do it (this is probably what Artem meant
too). Come to think of it I've seen it done like this in various big
graphics apps with embedded scripting languages.

The heirachical scenegraph structure of collada wouldn't really need that
many changes to become a fluxus script after it's turned into
sexpressions... hmmm

I think for the moment I'll stick to collada and not worry about loading
speed too much - and look into something like that later on.

cheers,

dave