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

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

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 = mDev->getData();
>>>>>>>
>>>>>>>    for ( unsigned int i = 0; i < 16; ++i )
>>>>>>>    {
>>>>>>>       double_mat.mData[i] = 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
>>>> 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 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 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.

 -Patrick


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