[fluxus] lotsa stuff

[dave]

On Sat, 2007-06-30 at 02:48 -0300, Glauber Prado wrote: 
> 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?

Yes - eventually

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

There are various ways to blend the animation and physics depending what
you are trying to achieve. I haven't thought too deeply about it yet,
but it's something to keep in mind.

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

Good point - yes I'll do this, I'm generally updating the docs whenever
I change the code at the same time (the only way to actually keep it up
to date I think) but I'll flag the functions that have changed where so
we know which translations need revising. I also want to do a general
pass over all the functions before 0.13 is released - I'll do this soon
and flag any changes I make for this too. 

Another thing you might be able to help me with - seeing as you are a
blender guy :) Would it be possible to get hold of (or be pointed in the
direction of) some test data to write importers for? I guess everything
from a simple cube to a fully texture mapped, skinned character with
animation data. Example files would be fine - I've briefly looked but I
can't find suitable stuff online.

cheers,

dave