Re: [ggt-devel] [vrjuggler-info] Getting gmtl Matrix data from a PositionalInterface

[Patrick H. <pa...@in...>]

Doug McCorkle wrote:
>=20
> On Jun 12, 2007, at 8:45 AM, Patrick Hartling wrote:
>=20
>> Patrick Hartling wrote:
>>> Doug McCorkle wrote:
>>>> On Jun 7, 2007, at 7:51 AM, Patrick Hartling wrote:
>>>>
>>>>> Doug McCorkle wrote:
>>>>>> Hello,
>>>>>>
>>>>>>       When getting the matrix information from a PositionalInterfa=
ce
>>>>>> such as head position the matrix returned is a Matrix44f. Is it
>>>>>> possible to get a Matrix44d?
>>>>> Not from gadget::PositionProxy::getData(). The chain of data from
>>>>> the input
>>>>> device to your application object is all in single-precision
>>>>> floating-point
>>>>> data.
>>>>>
>>>> OK.
>>>>
>>>>>> Is there any easy way to convert from a
>>>>>> float matrix to a double matrix? Thanks for the help.
>>>>> Given the nature of C/C++, the simplest way that I know of to do it=

>>>>> would be
>>>>> the following:
>>>>>
>>>>>    gmtl::Matrix44d double_mat;
>>>>>    gmtl::Matrix44f float_mat =3D mDev->getData();
>>>>>
>>>>>    for ( unsigned int i =3D 0; i < 16; ++i )
>>>>>    {
>>>>>       double_mat.mData[i] =3D float_mat.mData[i];
>>>>>    }
>>>>>
>>>> This is what we are doing now.
>>>>
>>>>> You could easily make a function with a signature such as this to
>>>>> hide the
>>>>> details:
>>>>>
>>>>>    gmtl::Matrix44d convert(const gmtl::Matrix44f& m);
>>>>>
>>>>> You could even take it a step further and make a generic GMTL-style=

>>>>> generator function. There might be some template-based approach
>>>>> that would
>>>>> allow for the loop to be unrolled, but I don't know what that would=

>>>>> be off
>>>>> the top of my head.
>>>>>
>>>> I was hoping for something like this. I will look into it. Thanks.
>>>
>>> I was thinking about this some more last night, and I just put
>>> together the
>>> attached code. The loop gets unrolled, and it will work for any
>>> pairing of
>>> gmtl::Matrix<S,R,C>/gmtl::Matrix<T,R,C> where S is convertible to T. =
If
>>> Boost.Lambda could be used, the code would be simpler because the
>>> separate
>>> set<...>() helper function and the usage of boost::bind() wouldn't be=

>>> needed, but in my experience, when data members are involved,
>>> boost::bind()
>>> always has to be used.
>>
>> I thought of a way to use Boost.Lambda. See the attachment.
>>
>>> Nevertheless, the loop unrolling and inlining should
>>> result in better performance than a regular for loop.
>>
>> I may have overstated this. I haven't done any performance tests on th=
is,
>> and boost::bind() carries with it a fair amount of overhead. There is
>> plenty
>> of inlining that can be taken advantage of, but the number of
>> instructions
>> executed is probably more than when using a loop. The question, then, =
is
>> whether the cost of those extra instructions is different than the
>> cost of
>> the branch instructions needed for looping.
>>
>=20
> Thanks! I will give this a try. After thinking about this more over the=

> past few days I wondered if it would be possible to generalize this to
> the datatype within gmtl? I thought that most underlying datatypes in
> gmtl are raw arrays so did not know if this could even be extended to
> quats and all the other gmtl datatypes.

That would require rather more sophisticated type traits than current exi=
st
in GMTL, and I think that the conversion functions would still have to be=

specialized on a per-type basis. For example, you wouldn't want to copy t=
he
internal array from a gmtl::Quatf to a gmtl::Vec4i just because they both=

have four values.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/