[fluxus] lotsa stuff

[Dave Griffiths]

> dave wrote:
>> Hi all,
>>
>> I seem to have crammed a lot into a big commit - apologies...
>>
>>
> heh
>> I've made the skinning stuff easier to use, primarally, skeletons are
>> now entirely represented by scenegraph subtrees. The means you only need
>> to specify the root primitive of your parented structure, rather than
>> building the whole skeleton out of lists or whatever to pass to the
>> skinning pfuncs - it figures it all out internally, by examining the
>> scenegraph.
>>
>>
> ah good much more readable structure now i think, thanks for this.
>> This means genskinweights can now work for proper branching skeleton
>> topologies.
>>
>> It also means that physics driven skeletons had to be changed, as the
>> physics drives primitive positions in worldspace - so parenting them all
>> together doesn't work. To get round this I've added a new
>> (hint-lazy-parent) which basically means if a primitive is parented to
>> anything, it won't pass it's transform on.
>>
>>
> this is what a parent in the scenegraph is supposed to be right?

Yes. Well, you can look at it two ways - as a transform description or as
a container.

In the case of a skeleton formed by nodes controlled by ODE, we have a
choice, describe the skeleton entirely seperately to the scenegraph -
which would involve a lot of extra duplicated code and extra scheme
overhead (describing the skeletons as lists - which in the case of normal
skeletons would be identical to the scenegraph structure anyway). The
other choice is to be allowed to just use the scenegraph as a structured
container in some cases, hence (hint-lazy-parent).

The other option is to calculate the relative transforms of the parented
nodes from the world space matrices coming from ODE, which on the one hand
would make everything work as expected, but would cause processing
overhead inverting matrices etc - and possibly a lot of special cases to
fix. Maybe I should look at this some more - I'm not ruling it out quite
yet.

What I need to think about is how this would work if we needed to mix
physics and (maybe heirachical) animation data... hmm...

>> * all the pfunc stuff
>> * make-light
>> * light-attenuation
>> * blend-mode
>> * build-polygons
>>
>>
> not so sure here a bit obscure to me yet

Sorry - a bit of a terse description, some examples:

(make-light "free" "spot")
becomes
(make-light 'free 'spot)

(build-polygons 100 0)
becomes
(build-polygons 100 'triangle-strip)

I've updated the english docs for these functions. There may be a few more
to go - (joint-param) is one I know about.

>> I've also added (blobby->poly) which extracts the blobbies mesh into a
>> polygon primitive. The idea is that we can use the blobby primitive as a
>> way of generating nice organic meshes for skinning. There should be a
>> demo on it's way to demonstrate all of this in some more coherent and
>> exciting manner.
>>
> shoudnt be the inverse, or i misunderstood?

I suppose the inverse would be something like subdivision meshes - I
haven't got that far yet :)

No, this is simply a way of extracting the resulting surface mesh of the
marching cubes algorithm - into a normal polygon primitive. This means it
doesn't have to be evaluated each frame, and we can treat it like a normal
poly mesh.

The interesting part is that we can potentially build a creature by making
it's skeleton first, positioning blobby sphere influences over each
skeleton node, make a mesh from this blobby, and skin it to the original
skeleton and animate it. Bizarre algorithmic creatures-a-gogo! :)

> i found it cool, it lives :)

Excellent!

> ps; ive commited the little i could translate up until now.

Yes, I noticed that - it's all merged in with my stuff now - thanks!
I'll add a switch to builddocs so you can choose the language at runtime.

cheers,

dave