[fluxus] commits and bunnies

[Dave Griffiths]

>> * (osc-msg) - I had to overhaul this a bit for a performance I'm doing -
>> it's much better now, but it changes things - rather than return the
>> values for the last osc message of the specified name, calling it
>> repeatedly returns every message recieved. so calling it once per frame
>> is probably now not enough (unless you are sure your frame rate is
>> higher than your osc message rate - probably not something to assume)
>
> im not exactly sure what this change entails, do you mean that osc-msg are
> now
> stored in a buffer (or something) which now acts as a fifo rather than
> lifo (as
> previously). or something all together different?+

yup, it's now a fifo, wheras previously it was not buffered at all. It
maxes out at 256 sets of values per message name, but you'll need to clear
the buffer every frame to avoid lag

>> * last but not least, a script that imports (triangulated) obj model
>
> this [works] also, in that a fragment like (make-obj (load-obj
> "object.obj"))
> will import and build the object, but it seems there are still a few
> issues. the
> filename doesnt seem to use the new 'searchpaths', [ie. needs a full
> path], and

indeed, the loading is from native scheme, so I need to add a (fullpath
"filename") which will search the internal searchpaths for you - oops

> for some reason it looks like the clipping plane clips polys from the
> object
> when its still some distance away.

are you sure it's not an issue of scale? the model is very small - try
scaling it up.

> i tried exporting some models from blender, as 'wavefront .obj' but it
> seems to
> miss quite a few polys.

it ignores non trianglular faces, this is a issue with the poly primitive
I need to think through a little more - fluxus is designed for speed, so I
don't really want to support indexed verts (mixed face topologies are slow
to render)

it's better to preprocess the model to be triangulated - tristrips are
fastest, but hard to compute. this is how game engines deal with model
data. more scheme scripts to do this offline I think...

the importer also has yet to deal with normals and texture coordinates,
but that's trivial to add now.

> out of curiosity, is there some reason for all the anonymous functions in
> the importer?

you mean the explicit use of lambda in the function definitions? I've just
been learning how to write scheme properly lately :) I'm actually totally
addicted now.

cheers,

dave