[fluxus] lotsa stuff

[Glauber Prado]

Dave Griffiths wrote:
> 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).
>
>   

Can be lazy but is clever also.

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

If you think you can make it better go for it, i think this is good as is,
now could be better this other way , maybe, im not really qualified to say.
> What I need to think about is how this would work if we needed to mix
> physics and (maybe heirachical) animation data... hmm...
>
>   

i dont understand this quite well also but are you planning on having 
animation
from external packages (hint-blender :) for character animation) mixed 
with physics?

once i saw a bit thief way to do that, was with ode also the guy made a 
normal animation and
binded cubes to the character feet to make it kick some boxes, was a 
cool way for doing something
otherwise very complex if solved in software level i think, anyway just 
a thought.

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

ah okay this makes it also more descriptive a nice improvement i think, 
but for live coding it
can make it hard as more typing, not so sure as i never really did it 
with pressure, about updating the docs
i would like to make a request :) when you change some function and dont 
want to update it on
the same time let some flag there i can go and fix it later, though im 
more focused in finish translating it
i dont mind to go back and forth a bit :).
>
>> 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! :)
>
>   
heheheh, i hadnt thought about this also very cool way of making living 
creatures :).


>
> I'll add a switch to builddocs so you can choose the language at runtime.
>
>   
very nice i was looking at the sources but i couldnt make it work yet 
just substituting the
locale and compiling the docs and changing the helpmap file didnt worked 
the docs
didnt appeared in fluxus. I might be doing something wrong here, no 
problems also i
know for sure it'll work later as the current system is working.
 
i have some other things to say but dont want to bloat here.

cheers

grebs.