Hi,
On Sun, 2009-08-16 at 21:24 -0500, Carsten Neumann wrote:
> Hello,
>
> > On Tue, 2009-08-11 at 11:25 -0500, Carsten Neumann wrote:
> > hmm, not 100% sure. One line of thought I had was to route the times
> > into the blender and let the blender poll the interpolators. That's kind
> > of half way between this one and the old one. Ideally it would look
> > something like:
> >
> >
> > DEF Blender1 Blender
> > {
> > slots
> > [
> > Slot
> > {
> > source CoordInterpolator
> > }
> >
> > Slot
> > {
> > source CoordInterpolator
> > }
> > }
> >
> > DEF TS1 TimeSensor
> > {
> > startTime 10
> > stopTime 20
> >
> > fadeInTime 8
> > fadeOutTime 18
> >
> > fadeType linear
> > }
> >
> > DEF TS2 TimeSensor
> > {
> > startTime 20
> > stopTime 30
> >
> > fadeInTime 18
> > fadeOutTime 28
> >
> > fadeType linear
> > }
> >
> > ROUTE TS1.fraction TO Blender1.slots[0].time
> > ROUTE TS1.weight TO Blender1.slots[0].weight
> >
> > ROUTE TS2.fraction TO Blender1.slots[1].time
> > ROUTE TS2.weight TO Blender1.slots[1].weight
>
> hm, this could work. I was thinking to use an Interpolator as input for
> the weight so that blending is controllable by an "animation" of its
> own. That may be overkill though.
the idea behind merging it into the timesensor it to at least give some
predictability, e.g. you know that time and weight values propagate out
at the same time.
> The current FieldConnectors can not target an entry in an MField, can
> they?
no, but it is something I wanted to have for a long time. I'll probably
give it a try.
> I've started implementing the ManagedConnectors using a
> GetFieldHandle and an EditFieldHandle for the source/dest fields, which
> solves the problem of how to create a connection between fields of
> different "type" (e.g. SF<T> to MF<T>).
ok, but there is one particular thing I really don't like and this is
the use of the framehandler to do the propagating. That is something
I really would like to avoid. Though I like the idea of the backward
connection, which is kind of similar to the slot idea. The general
form might be a new kind of field which just references something
else somewhere.
> Also, please keep in mind that I need this to be manageable at runtime,
> the number of animations that affect a character at a time may change a
> lot depending on what the app needs.
ok.
> Oh, and one thing I forgot to
> mention so far: it should be possible to clone a character and get a
> copy that can be animated independently (that was another thing the
> AnimationTemplate was for, given a "root" it could locate the targets
> for AnimTracks in it and target AnimChannels at them).
I guessed as much from the code. And it softens the pipeline comment
below because with routes I guess you would have to push a lot
of things into the tree and start working with prototypes.
So taking a step back. Could we factor your original approach so that
it is kind of a glue between more general parts which could also be
used independently. E.g. split the current interpolator so that they
have the track part you need and a derived interpolator part which has
the fraction and value fields so it behaves like the original (vrml)
one ?
> > In order to get the order right one approach I was thinking about
> > was to have the blenders as frame task and to make the frame tasks store
> > inside the frame handler a priority queue and call commit every time the
> > priority changes. That should strike a reasonable balance for the commit
> > calls and still keep it flexible.
>
> I'm not sure I fully understand this part. What is the priority in the
> p-queue? And why/what would make that priority change?
the priority just an assigned value, e.g something like 10 for time
sensors and 50 for blenders. The change is from the last time sensor
(prio 10) to the first blender (prio 50). The effect is that
it is guaranteed that after all time sensors are done, commitChanges
is called so the time sensor values are propagated to the blenders
before their eval function is called.
> > The TimeSenor might need a new name.
> >
> > What I'm not so happy with, that would move us a little towards a
> > pipeline infrastructure.
>
> hm, yes.
but on the other hand jumping through hoops might not be the best thing
to do. But my current feeling is we are in the process of building
something which forces the app to use our routes at least in part.
kind regards,
gerrit
------------------------------------------------------------------------------
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
