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

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

On Jun 12, 2007, at 10:57 PM, Doug McCorkle wrote:

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

The template functions worked great! Thanks for the help. Will these  
be included in future releases of GMTL?

Doug