Hello Carlo,
Carlo Orru wrote:
[SNIP - interpolate template code]
> Such template is very handy... but, since the interpolation processes for
> some different types are the same (i.e. two Real32 and two Real64 have the
> same interpolation formula), is there any way to perform the interpolation
> using the template above _without_ knowing the exact data type we are
> working
> with (i.e. all we need to know is we are dealing with a RealXX data type,
> we don't want to distinguish between Real32 and Real64! The same holds for
> UInt32 and Int32, Vec3f and Vec2f, and so on...)? Of course, Real32 and
> Int32
> would have to be treated differently...
there is no direct way to specialize a template for a group of similar
types. What can be done, however, is to introduce another level of
indirection and use something along these lines:
template <class RealTypeT>
struct RealScalarInterpolator
{
// only instantiated for floating point scalars
RealTypeT interpolate(RealTypeT v0, RealTypeT v1, float t)
{
return (1.0-t) * v0 + t * v1;
}
};
template <class IntTypeT, Int32 DimI>
struct IntVectorInterpolator
{
// only instantiated for vectors of integers
typedef ... VecType;
VecType interpolate(VecType const &v0, VecType const &v1, float t)
{
VecType retVal;
for(UInt32 i = 0; i < DimI; ++i)
retVal[i] = ...
return retVal;
}
};
template <class ValueTypeT>
struct InterpolationAlgoSwitcher;
template <>
struct InterpolationAlgoSwitcher<Real32>
{
typedef RealScalarInterpolator<Real32> Func;
};
template <>
struct InterpolationAlgoSwitch<Vec4us>
{
typedef IntVectorInterpolator<UInt16, 4> Func;
};
As you can see (especially from the omitted VecType typedef ;) ) this
gets long and complicated rather quickly. On the other hand, using
operator notation (i.e. (1.0 -t) * v0 + t * v1) the difference between a
scalar and a vector basically disappears and you might not need that
many specialized implementations.
> And now some more questions:
>
> - Does FieldDescription::getTypeId() always return the same value as
> Field::getType().getId()?
yes.
> And is such return value calculated at runtime
> or is it a default fixed value and if so, is it defined anywhere?
Yes, these values are assigned during osgInit (or to some extent when
the C++ runtime creates static member variables) when the types register
themselves. You can use this e.g. like this:
if(MFVec3f::getClassType().getId() == pField->getType().getId())
{
// ...
}
You can not use it in switch statements, as the case labels have to be
compile time constants. However, please see below why this type of
construct is often/usually a bad idea.
> I could
> use such piece of information in order to correctly perform the
> interpolation... In other words, how am I supposed to use the value
> returned
> by Field::getType().getId() or FieldDescription::getTypeId() inside a
> switch
> statement in order to know what field type I'm about to interpolate?
Please, don't do that. A switch statement (or if cascade) makes it
impossible to add types without adding to the switch. Template magic or
a callback mechanism that uses e.g. a map from the type id to a function
pointer (or even better a functor) can be added to and is therefore much
preferred.
> - To store the control point lists inside the AnimationController I'm using
> a map<FieldContainerPtr, ControlPointList<CPType>> where CPType is the
> data
> type stored inside the control points in the list: for example, a control
> point with a Quaternion inside has to be put inside a container defined as
> follows: map<FieldContainerPtr, ControlPointList<SField<Quaternion>>>.
> This involves defining a new container for _each_ data type: since I don't
> want my code to bloat, I need a way to keep the number of used containers
> as low as possible. Any suggestion here would be _greatly_ appreciated!
Do the ControlPointLists have a common interface that is independent of
the template argument ? If yes, an abstract base class could be used, if
not, is it possible to find such an interface ?
In other words: Does AnimationController need to know what CPType is?
Can it be made to work with
map<FieldContainerPtr, ControlPointListBase*> ?
kind regards,
Carsten
-------------------------------------------------------------------------
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
