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

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

Doug McCorkle wrote:
> On Jun 12, 2007, at 10:57 PM, Doug McCorkle wrote:
>=20
>> On Jun 12, 2007, at 10:02 PM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>> On Jun 12, 2007, at 9:13 PM, Patrick Hartling wrote:
>>>>
>>>>> Doug McCorkle wrote:
>>>>>> On Jun 12, 2007, at 8:45 AM, Patrick Hartling wrote:
>>>>>>
>>>>>>> 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
>>>>>>>>>>> PositionalInterface
>>>>>>>>>>> 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 =20
>>>>>>>>>> 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 =20
>>>>>>>> convertible to
>>>>>>>> T. If
>>>>>>>> Boost.Lambda could be used, the code would be simpler because =20
>>>>>>>> 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
>>>>>>> this,
>>>>>>> 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 =20
>>>>>>> the
>>>>>>> cost of
>>>>>>> the branch instructions needed for looping.
>>>>>>>
>>>>>> 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
>>>>> exist
>>>>> 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 the
>>>>> internal array from a gmtl::Quatf to a gmtl::Vec4i just because
>>>>> they both
>>>>> have four values.
>>>> Right. I was more thinking same type to same type restrictions.
>>> I am not sure if this could be generalized fully. I tried some
>>> stuff with a
>>> template template parameter so that the input and output types
>>> could be
>>> matched without being identified explicitly, but I haven't been
>>> able to get
>>> anything to compile yet. The basic idea I have is shown in the
>>> attached
>>> file. My current suspicion is that the variation in number of =20
>>> template
>>> parameters among GMTL types (gmtl::Matrix<T,R,C>, gmtl::Vec<T,S>,
>>> gmtl::Quat<T>, etc.) will make things tough. Beyond that, the mData
>>> member
>>> is not always an array, so specialization would be needed anyway.
>>> There may
>>> yet be a way to do it, but I am reaching the (current) limits of my
>>> understanding of C++ templates. Overloading the function that I
>>> sent out
>>> earlier is the simplest approach.
>>>
>> What you sent out earlier is very helpful. I am not trying to imply
>> that I need anything more, it was more just a thought of something
>> interesting to add to GMTL. Thanks for the effort in figuring
>> something out.
>>
>=20
> The template functions worked great! Thanks for the help. Will these =20
> be included in future releases of GMTL?

I don't know. I don't think that Allen wants to introduce a dependency on=

Boost. However, they could go into the "External" subdirectory or somewhe=
re
else to keep them out of the main fray and thus not have such a direct
dependency on Boost.

 -Patrick


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