Hi Carsten,
thanks for your reply!
During the last days I've been working on my framework, thus it has
undergone some changes since I wrote my last e-mail...
Now I have added the possibility for the user to separately specify the
field value (or the vector of values in case of a multi-field) to be
modified, instead of specifying the whole FieldContainer.
In order for this to work, the user has to input the value (for example
a Color3f, or a Quaternion) or the collection of values, the mask and
the field name(s). So we can have both control points holding a field
container and control points holding field value(s).
>
>> 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.
>
>
Now I don't create a new container anymore: the field container whose
fields are to be updated is handed down directly to the newly created
control point (inside the Animate() method).
>> 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 ?
>
>
The step you mentioned is no more influenced by the knowledge about the
type of core which is being dealt with: the update process now only
relies on the field(s) name(s) (requested to the user when creating the
control point list) and, of course, on the mask, which is also requested
to the user. In fact I use the getField(Char8* field_name) method to
gain acces to the field specified by 'field_name', and then I use
methods like setAbstrValue(), pushValueByStr() and getValueByStr() to
access/update the field.
>> 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.
>
>
Such approach, which is currently being worked on, consists in wrapping
field types like Quaternion, Vec3f, Color3f and so on, using a template
class. For example, if we were dealing with a Quaternion, things would
look like this:
template <>
class FieldWrapper<Quaternion> : public Quaternion
{
public:
FieldWrapper(void);
FieldWrapper(Quaternion q);
void Interpolate(Real32, FieldWrapper<Quaternion>,
FieldWrapper<Quaternion>);
void UpdateFC(FieldContainerPtr, BitVector, const Char8*);
};
In this way, I can make the wrapper class itself hold the result of the
interpolation which is to be used to update the chosen field container.
Obviously, if we were dealing with a MFColor4f we had to use a
FieldWrapper<Color4f> class, for the difference between single fields
and multi fields is handled by the control point and the animation
controller: the ControlPoint object stores the field(s) passed by the
user inside a MFVector<> object, which, in case of a single fielded
control point, has only one element inside.
> 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
>
- The actual interpolation is performed by the FieldWrapper<> class.
- MFields of different sizes are handled by the AnimationController
object, which repeatedly calls the FieldWrapper<>::Interpolate()
and FieldWrapper<>::UpdateFC() methods in order to update every
field element.
*** I don't know if this answers your question... if not,
*** could you please be more specific? What do you mean by
*** "different sizes" ? Maybe an example would make things
*** clearer... Thanks.
- The customization of the interpolation process is planned, but is
currently yet to be implemented. At the moment, only linear
interpolation is supported.
- As long as the current time value remains below the one assigned to
the first control point in the list, then the first control point's
values are used to update the specified field container. If the
current time value is above the one assigned to the last control
point in the list, then the last control point's values are used to
update the specified field container.
There's currently no support for looped or chained animations: again,
those features are planned but not being worked on at the moment.
Actually, the multi-field support has just been implemented, but is yet
to be tested, so I'm still not sure whether it works properly or not.
Could you please make some examples of field containers with
multi-fields I could test my code on ?
And also, how can the whole animation process be stored inside an OpenSG
binary file?
Thanks again for your attention, and... any suggestion is welcome!
Regards,
Carlo
-------------------------------------------------------------------------
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
