Hello Carlo,
I have a couple of questions/comments:
Carlo Orru wrote:
> I'm trying to implement some kind of animation framework into OpenSG,
> which is based on the following idea:
> the user specifies a list of control points (with each point associated
> to a time value) and the field container whose fields are to be animated
> (every control point contains a field container of the same type of the
> one we want to 'animate'). Such data is then handed down to an
> 'AnimationController' object, which calculates the current time and thus
> interpolates the control points in the given list: this stuff is done
> inside the method AnimationController::Animate(), which is called every
> frame before the actual rendering occurs.
sounds good.
[SNIP - example code]
> The Animate() method works as follows:
> after calculating the current time, a new ControlPoint object with a
> field container inside is created. Such field container is then assigned
> the correct value which has just ben retrieved from the interpolation
> between two control points, and then the update of the field container
> returned by "someNode->getCore()" can take place:
I guess I'm missing something here, but why do you have to create a new
container here? I would have expected (and your example actually seems
to support this) that there is one container in the graph and a number
of them (of the same type) as control points associated with points in
time. The update computes the interpolation between values of the
control points and stores these into the container in the graph.
> using the field mask
> provided to the ControlPointList object to identify the fields to be
> updated and checking the string returned by the
> FieldContainer::getTypeName() in order to know what tipe of core we are
> dealing with, the appropriate fields are updated via CPEdit(fcPtr,
> field_mask).
why do you need to know what type of core is being used, or what do you
do with this information, how does it influence the "the appropriate
fields are updated" step ?
> This method has been tested and seems to work fine, but I also would
> like to try a different approach such as, for example, passing a plain
> Vec3f to the ControlPoint class constructor and making the appropriate
> field do the update by itself (perhaps using some kind of Vec3f wrapper
> class with an update() method inside).
hm, I'm not sure if I understand this alternative approach, what does a
Vec3f have to do with animating a MFColor4f for example?
In general I'm not too big a fan of wrapping something as basic as a
Vec3f, especially as this class gives you full access to it's members.
Therefore a non-intrusive approach should be possible, i.e. having a
function that can interpolate between two Vec3f need not be a member
function.
Some more general question on your framework:
- What part is responsible for performing the actual interpolation
between values?
- How does it handle MFields of different sizes?
- Is there a way to customize the interpolation process for different
types or even instances of containers/fields (for example it is likely
that one would handle quaternions in a special way instead of just
interpolating linearly)?
- How is behavior for time values outside the range covered by control
points handled (e.g. are there ideas on how to do looped or chained
animations)?
Thanks,
Carsten
PS: I hope you are not discouraged by the lack of responses so far, but
there are a couple of conferences going on/coming up, that have taken
priority for the moment. I'm sure your work is of great interest to a
lot of people, so please do keep us informed :)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
