Hello Gerrit,
Gerrit Voß wrote:
> I finally managed to factor out the csm animation bits. They are
> currently not commit into the svn but available from
>
> http://www.cgmt.org/user/gerrit/OpenSG.svn.git/
>
> in the animation branch.
thanks. I've been looking at it during the day.
> Let's try to come up with a way to unify both approaches.
- where is FieldConnector::process() implemented? Or more accurate,
where is the actual copying from src to dst field happening?
Oh, nvm found it in OSGFieldContainer.inl, is that location an
historical artefact?
- for unification of the approaches:
what I call Animation can basically become a TimeSensor with a bunch of
Interpolators, so that there is a single object to deal with for
animations that modify many different values.
where I don't have a good solution yet (but really need one, so ideas
very welcome), is the blending of multiple animations; I see two
difficulties this introduces:
1) the output of multiple interpolators has to be temporarily stored
somewhere and there needs to be a trigger to perform the actual blending
and storing of the final value. Alternatively something has to know that
it is the first thing to write to a field in this frame and sets an
absolute value, while all subsequent writes in this frame make relative
changes. The latter sounds fairly brittle to me though.
2) since the blend weights change over time (e.g. to fade one anim out,
fade another in) the natural choice seems to control the weights with an
animation of their own, but then there is an ordering dependency between
animations.
One thing we have come up with is to feed interpolators always into a
blender object that has the real connection to the target field. By
allowing a field connector to write into a fixed index of an MF we could
accumulate the results over all inputs and also feed weights for each
into the blender and compute the weighted average as output. The
question with this is how to trigger the actual blending? We could
derive the blender objects from FrameTask and have them run as a task
after the time sensors (something would have to ensure they are at the
back of the task list). Also this does not really help with 2) above
because the weights need to available for the blending (so they can not
be the result of blending ;) ), which means there are
BlendableInterpolators and NonBlendableInterpolators; hmpf, don't like
that idea a lot...
As has been said before, basically there needs to be an efficient way to
take multiple inputs and move them to a single output and a way to deal
correctly with the resulting ordering problem (outputs should only be
written after all input that will change this frame has actually changed).
Any ideas/hints to solve this are very welcome :)
Cheers,
Carsten
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
