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

[Doug M. <mc...@ia...>]

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.

Doug