Hi Carsten,
> For a general solution it is probably acceptable to go through the
> string accessors, it would be nice if it was possible to allow the user
> to replace this with something that requires knowledge of the type of
> the field being changed but can use e.g. the vector interface to modify
> values.
>
Could you please explain it better? How could such thing be accomplished ?
> ok. What is the reason for FieldWrapper<T>::Interpolate taking two
> FieldWrapper<T> arguments and not two T arguments ?
>
Well, actually, there is no reason... Thanks for pointing it out...
> Also, in what sense IS FieldWrapper<Quaternion> A Quaternion, i.e. why
> does it publicly derive from it?
>
Because in the beginning I wanted every field to be able to update itself
via the "Interpolate" method, i.e. I wanted to do something like this:
TransformPtr tr = Transform::create();
FieldWrapper<Quaternion> fw_q(Quaternion(Vec3f(1,0,0), deg2rad(60)));
tr->setRotation(fw_q);
In this way I thought I'd be able to directly update the field just by
calling FieldWrapper<Quaternion>::Interpolate. Well, I was wrong.
> I'm trying to understand why this is necessary or a good thing to do; so
> what could something like the following not do?
>
> // base template
> template <class FieldT>
> struct FieldValueInterpolator;
>
>
> // partial specialization for SF
> template <class ValueTypeT, Int32 NamespaceI>
> struct FieldValueInterpolator<SField<ValueTypeT, NamespaceI> >
> {
> typedef SField<ValueTypeT, NamespaceI> SFieldType;
> typedef typename SFieldType::ArgumentType ArgumentType;
>
> void updateField(Real32 fract, ArgumentType val0, ArgumentType val1,
> FieldContainerPtr pCont, UInt32 fieldId)
> {
> SFieldType *pCastSF = static_cast<SFieldType *>(
> pCont->getField(fieldId));
>
> // interpolate between val0 and val1 depending on fract,
> // which is in [0,1]
>
> // write value to pCastSF using pCastSF->setValue()
> }
> };
>
> // partial specialization for MF
> template <class ValueTypeT, Int32 NamespaceI>
> struct FieldValueInterpolator<MField<ValueTypeT, NamespaceI> >
> {
> typedef MField<ValueTypeT, NamespaceI> MFieldType;
> typedef typename MFieldType::ArgumentType ArgumentType;
>
> void updateField(Real32 fract, ArgumentType val0, ArgumentType val1,
> FieldContainerPtr pCont, UInt32 fieldId)
> {
> MFieldType *pCastMF = static_cast<MFieldType *>(
> pCont->getField(fieldId));
>
> // interpolate between val0 and val1 depending on fract,
> // which is in [0,1]
>
> // write value to pCastMF using pCastMF->push_back(),
> // (*pCastMF)[i] etc.
> }
> };
>
> Admittedly, I have not fully thought through this idea and I'm not
> convinced that all the static typing is necessary/helpful at this level,
> but something similar might be used at a very low level to avoid the
> string accessors (sorry, for being pedantic about this, I don't like
> string based interfaces much ;) ).
>
>
This seems to be a very good way to interpolate the two values, but:
- How do I get the "fieldId" parameter ?
- Is there any way to know what kind of value we are dealing with other
than looking at the name string ? (I need to know the type in order to
be able to perform the interpolation!)
> hm, GeoProperties are the ones that come to mind that already exist in
> the system and are quite likely to be animated.
> Let me know if these do not help and you need some containers for
> experimentation.
>
Sorry but no, they don't help... I need a FieldContainer with some
MFields inside...
Thanks a lot!
Cheers,
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
