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

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

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 = 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.
>

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.

Doug