ggt-devel — Development discussion list

Re: [ggt-devel] gmtl-config run-time problem

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

Doug McCorkle wrote:
> On Jun 26, 2007, at 2:02 PM, Patrick Hartling wrote:
>=20
>> Doug McCorkle wrote:
>>> Hello,
>>> 	When I try to run gmtl-config with 0.5.2 I get this error:
>>>
>>> objects:/Volumes/data/VE_Suite_Deps/vrjuggler-2.0-svn/build-darwin
>>> mccdo$ /opt/local/bin/gmtl-config
>>> Traceback (most recent call last):
>>>    File "/opt/local/bin/gmtl-config", line 67, in ?
>>>      elif options.cxxflags or options.libs:
>>> AttributeError: Values instance has no attribute 'libs'
>>>
>>> Any thoughts on the problem?
>>   1. Remove the usage of options.libs since GMTL doesn't have =20
>> libraries.
> OK.
>=20
>>   2. Avoid using gmtl-config if you can.
>=20
> I was just trying to use 0.5.1 with vrj 2.0.3 which I know is not the  =

> "official" way to do things but wanted to upgrade my overall =20
> environment.

OK, well, that should work except for the bug that you identified. I'll t=
ry
to make a GMTL 0.5.3 release as soon as I can.

 -Patrick


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

Re: [ggt-devel] gmtl-config run-time problem

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

On Jun 26, 2007, at 2:02 PM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> Hello,
>> 	When I try to run gmtl-config with 0.5.2 I get this error:
>>
>> objects:/Volumes/data/VE_Suite_Deps/vrjuggler-2.0-svn/build-darwin
>> mccdo$ /opt/local/bin/gmtl-config
>> Traceback (most recent call last):
>>    File "/opt/local/bin/gmtl-config", line 67, in ?
>>      elif options.cxxflags or options.libs:
>> AttributeError: Values instance has no attribute 'libs'
>>
>> Any thoughts on the problem?
>
>   1. Remove the usage of options.libs since GMTL doesn't have  
> libraries.
OK.

>   2. Avoid using gmtl-config if you can.

I was just trying to use 0.5.1 with vrj 2.0.3 which I know is not the  
"official" way to do things but wanted to upgrade my overall  
environment.

Doug

Re: [ggt-devel] gmtl-config run-time problem

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

Doug McCorkle wrote:
> Hello,
> 	When I try to run gmtl-config with 0.5.2 I get this error:
>=20
> objects:/Volumes/data/VE_Suite_Deps/vrjuggler-2.0-svn/build-darwin =20
> mccdo$ /opt/local/bin/gmtl-config
> Traceback (most recent call last):
>    File "/opt/local/bin/gmtl-config", line 67, in ?
>      elif options.cxxflags or options.libs:
> AttributeError: Values instance has no attribute 'libs'
>=20
> Any thoughts on the problem?

  1. Remove the usage of options.libs since GMTL doesn't have libraries.
  2. Avoid using gmtl-config if you can.

 -Patrick


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

[ggt-devel] gmtl-config run-time problem

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

Hello,
	When I try to run gmtl-config with 0.5.2 I get this error:

objects:/Volumes/data/VE_Suite_Deps/vrjuggler-2.0-svn/build-darwin  
mccdo$ /opt/local/bin/gmtl-config
Traceback (most recent call last):
   File "/opt/local/bin/gmtl-config", line 67, in ?
     elif options.cxxflags or options.libs:
AttributeError: Values instance has no attribute 'libs'

Any thoughts on the problem?

Doug

Doug McCorkle - Research Assistant
Iowa State University
Virtual Engineering Research Group
www.vrac.iastate.edu/~mccdo

Re: [ggt-devel] Building gmtl for MacPorts

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

Doug McCorkle wrote:
> Hello,
>      I am trying to update the gmtl build in MacPorts with the latest  =

> release but am running into problems with the build steps required =20
> for MacPorts. MacPorts uses this scheme as noted here:
>=20
> http://trac.macosforge.org/projects/macports/wiki/BuildPhases
>=20
> When prefix is specified to install gmtl into destroot, that is the =20
> prefix that is ultimately stored in the fpc file for the gmtl =20
> installation prefix. It seems MacPorts expects another command line =20
> variable like stage_prefix or sandbox_prefix that allows the =20
> installation to be staged but the location not written to *config, =20
> pc, and fpc files. I see where other packages employ scripts and sed =20
> to overwrite these changes, which I can do, but it seems there may be  =

> a better solution or adding the above mentioned prefix and associated  =

> target. What are everyones thoughts on this subject? I know there was  =

> a similar discussion on the cppdom list about build methods and steps  =

> which I am still working on for cppdom. I hoping that a simpler =20
> solution can be arrived at here.

I don't know if a simpler solution is possible. One would hope that fixin=
g
it for CppDOM would allow a fix to be devised for GMTL--or vice versa. It=

would be good to get this issue resolved, but I don't know how to fix it =
for
either case.

 -Patrick


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

Re: [ggt-devel] Building gmtl for MacPorts

[Daniel E. S. <dan...@gm...>]

Look at the juggler fpc files.  There is a ${fp_cwd} variable (or
something close to it) that can you can set prefix with using relative
paths.

-D

On 6/26/07, Doug McCorkle <mc...@ia...> wrote:
>
> On Jun 26, 2007, at 11:01 AM, Doug McCorkle wrote:
>
> > Hello,
> >     I am trying to update the gmtl build in MacPorts with the
> > latest release but am running into problems with the build steps
> > required for MacPorts. MacPorts uses this scheme as noted here:
> >
> > http://trac.macosforge.org/projects/macports/wiki/BuildPhases
> >
> > When prefix is specified to install gmtl into destroot, that is the
> > prefix that is ultimately stored in the fpc file for the gmtl
> > installation prefix. It seems MacPorts expects another command line
> > variable like stage_prefix or sandbox_prefix that allows the
> > installation to be staged but the location not written to *config,
> > pc, and fpc files. I see where other packages employ scripts and
> > sed to overwrite these changes, which I can do, but it seems there
> > may be a better solution or adding the above mentioned prefix and
> > associated target. What are everyones thoughts on this subject? I
> > know there was a similar discussion on the cppdom list about build
> > methods and steps which I am still working on for cppdom. I hoping
> > that a simpler solution can be arrived at here.
> >
> > Doug
>
> I forgot to mention that I was also thinking that a potential
> solution would be to use the flagpoll functionality that sets the
> prefix based on where the fpc file resides. This solution seems to be
> somewhat of a hack because the underlying build problem is still
> present but would solve the problem without many changes to the
> current build system.
>
> Doug
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>


-- 
Daniel E. Shipton
Software Engineer, Infiscape Corp.

Re: [ggt-devel] Building gmtl for MacPorts

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

On Jun 26, 2007, at 11:01 AM, Doug McCorkle wrote:

> Hello,
>     I am trying to update the gmtl build in MacPorts with the  
> latest release but am running into problems with the build steps  
> required for MacPorts. MacPorts uses this scheme as noted here:
>
> http://trac.macosforge.org/projects/macports/wiki/BuildPhases
>
> When prefix is specified to install gmtl into destroot, that is the  
> prefix that is ultimately stored in the fpc file for the gmtl  
> installation prefix. It seems MacPorts expects another command line  
> variable like stage_prefix or sandbox_prefix that allows the  
> installation to be staged but the location not written to *config,  
> pc, and fpc files. I see where other packages employ scripts and  
> sed to overwrite these changes, which I can do, but it seems there  
> may be a better solution or adding the above mentioned prefix and  
> associated target. What are everyones thoughts on this subject? I  
> know there was a similar discussion on the cppdom list about build  
> methods and steps which I am still working on for cppdom. I hoping  
> that a simpler solution can be arrived at here.
>
> Doug

I forgot to mention that I was also thinking that a potential  
solution would be to use the flagpoll functionality that sets the  
prefix based on where the fpc file resides. This solution seems to be  
somewhat of a hack because the underlying build problem is still  
present but would solve the problem without many changes to the  
current build system.

Doug

[ggt-devel] Building gmtl for MacPorts

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

Hello,
     I am trying to update the gmtl build in MacPorts with the latest  
release but am running into problems with the build steps required  
for MacPorts. MacPorts uses this scheme as noted here:

http://trac.macosforge.org/projects/macports/wiki/BuildPhases

When prefix is specified to install gmtl into destroot, that is the  
prefix that is ultimately stored in the fpc file for the gmtl  
installation prefix. It seems MacPorts expects another command line  
variable like stage_prefix or sandbox_prefix that allows the  
installation to be staged but the location not written to *config,  
pc, and fpc files. I see where other packages employ scripts and sed  
to overwrite these changes, which I can do, but it seems there may be  
a better solution or adding the above mentioned prefix and associated  
target. What are everyones thoughts on this subject? I know there was  
a similar discussion on the cppdom list about build methods and steps  
which I am still working on for cppdom. I hoping that a simpler  
solution can be arrived at here.

Doug

[ggt-devel] GMTL 0.5.2 released

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

Shortly after making the GMTL 0.5.1 release, I spotted a bug in the
generated gmtl.fpc file that somehow slipped my attention during testing.=
 It
is now fixed, and GMTL 0.5.2 has been uploaded to SourceForge. The source=

can be downloaded from the following link:

http://sourceforge.net/project/showfiles.php?group_id=3D43735&package_id=3D=
50702&release_id=3D518784

 -Patrick


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

[ggt-devel] GMTL 0.5.1 released

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

GMTL 0.5.1 has been posted to SourceForge. This release has some importan=
t
enhancements since the 0.4 series, including the following:

   * Headers are installed into a versioned directory to allow for parall=
el
     GMTL installations.
   * The use of pkg-config has been replaced by Flagpoll (visit
     https://realityforge.vrsource.org/view/FlagPoll/WebHome for more
     information), also to allow for parallel GMTL installations.
   * The new type gmtl::Frustum, submitted by Benjamin Schulz, has been
     added, and PyGMTL bindings for it are ready for use.
   * A helper function called gmtl::convertTo<...>() has been added for
     quickly converting between gmtl::Matrix<...> instantiations that onl=
y
     vary by data type. See the header gmtl/Misc/MatrixConvert.h. This
     file requires the use of Boost.

The source can be downloaded from the following link:

https://sourceforge.net/project/showfiles.php?group_id=3D43735&package_id=
=3D50702&release_id=3D518776

RPMs for several Linux distributions are available from the Infiscape Yum=

repository. To get started with our repository, install one of the follow=
ing
RPMs:

http://www.infiscape.com/packages/rhel/4/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/rhel/5/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/fedora/6/noarch/infiscape-release-1.0-1=
=2Efc.noarch.rpm

Other packages will be forthcoming.

 -Patrick


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

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

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

On Jun 25, 2007, at 8:21 PM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> 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?
>
> I went ahead and checked in a documented version of the function in  
> the new
> file gmtl/Misc/MatrixConvert.h. It will be included with the 0.5.1  
> release
> that will happen tonight.
>
>
Great! This release will also have the build fix in for the pc files  
which I am after. We have been using the matrix conversion in our  
code for a week with no issues.

Doug

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 went ahead and checked in a documented version of the function in the n=
ew
file gmtl/Misc/MatrixConvert.h. It will be included with the 0.5.1 releas=
e
that will happen tonight.

 -Patrick


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

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/

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

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

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/

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

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

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

Doug McCorkle wrote:
>=20
> On Jun 12, 2007, at 8:45 AM, Patrick Hartling wrote:
>=20
>> 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 PositionalInterfa=
ce
>>>>>> 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 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 th=
is,
>> 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.
>>
>=20
> 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 exi=
st
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 t=
he
internal array from a gmtl::Quatf to a gmtl::Vec4i just because they both=

have four values.

 -Patrick


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

[ggt-devel] Frustum.h with proper indentation

[Benjamin S. <bes...@go...>]

LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqIGdndC1oZWFkIGJlZw0KKg0KKiBHR1Q6IEdlbmVyaWMgR3JhcGhpY3MgVG9vbGtpdA0K
Kg0KKiBPcmlnaW5hbCBBdXRob3JzOg0KKiBCZW5qYW1pbiBTY2h1bHoNCioNCiogLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N
CiogRmlsZTogRnJ1c3R1bS5oDQoqIERhdGUgbW9kaWZpZWQ6IDIwMDQvMTIvMTQgMDM6MzU6MDEN
CiogVmVyc2lvbjogMS4wDQoqIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoqDQoqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiBnZ3QtaGVhZCBlbmQgKi8NCi8qKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KiogZ2d0LWNwciBiZWcNCioNCiogR0dUOiBUaGUgR2VuZXJpYyBHcmFwaGljcyBUb29sa2l0DQoq
IENvcHlyaWdodCAoQykgMjAwMSwyMDAyIEFsbGVuIEJpZXJiYXVtDQoqDQoqIFRoaXMgbGlicmFy
eSBpcyBmcmVlIHNvZnR3YXJlOyB5b3UgY2FuIHJlZGlzdHJpYnV0ZSBpdCBhbmQvb3INCiogbW9k
aWZ5IGl0IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgR05VIExlc3NlciBHZW5lcmFsIFB1YmxpYw0K
KiBMaWNlbnNlIGFzIHB1Ymxpc2hlZCBieSB0aGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uOyBl
aXRoZXINCiogdmVyc2lvbiAyLjEgb2YgdGhlIExpY2Vuc2UsIG9yIChhdCB5b3VyIG9wdGlvbikg
YW55IGxhdGVyIHZlcnNpb24uDQoqDQoqIFRoaXMgbGlicmFyeSBpcyBkaXN0cmlidXRlZCBpbiB0
aGUgaG9wZSB0aGF0IGl0IHdpbGwgYmUgdXNlZnVsLA0KKiBidXQgV0lUSE9VVCBBTlkgV0FSUkFO
VFk7IHdpdGhvdXQgZXZlbiB0aGUgaW1wbGllZCB3YXJyYW50eSBvZg0KKiBNRVJDSEFOVEFCSUxJ
VFkgb3IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuIFNlZSB0aGUgR05VDQoqIExl
c3NlciBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlIGZvciBtb3JlIGRldGFpbHMuDQoqDQoqIFlvdSBz
aG91bGQgaGF2ZSByZWNlaXZlZCBhIGNvcHkgb2YgdGhlIEdOVSBMZXNzZXIgR2VuZXJhbCBQdWJs
aWMNCiogTGljZW5zZSBhbG9uZyB3aXRoIHRoaXMgbGlicmFyeTsgaWYgbm90LCB3cml0ZSB0byB0
aGUgRnJlZSBTb2Z0d2FyZQ0KKiBGb3VuZGF0aW9uLCBJbmMuLCA1OSBUZW1wbGUgUGxhY2UsIFN1
aXRlIDMzMCwgQm9zdG9uLCBNQSAwMjExMS0xMzA3IFVTQQ0KKg0KKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqIGdndC1jcHIgZW5kICov
DQoNCiNpZm5kZWYgX0dNVExfRlJVU1RVTV9IXw0KI2RlZmluZSBfR01UTF9GUlVTVFVNX0hfDQoN
CiNpbmNsdWRlIDxnbXRsL1BsYW5lLmg+DQoNCm5hbWVzcGFjZSBnbXRsDQp7DQoJLyoqDQoJKiBU
aGlzIGNsYXNzIGRlZmluZXMgYSBWaWV3IEZydXN0dW0gVm9sdW1lIGFzIGEgc2V0IG9mIDYgcGxh
bmVzDQoJKg0KCSogQGluZ3JvdXAgVHlwZXMNCgkqLw0KCXRlbXBsYXRlIDxjbGFzcyBEQVRBX1RZ
UEU+DQoJY2xhc3MgRnJ1c3R1bQ0KCXsNCgkJcHVibGljOg0KCQkJdHlwZWRlZiBEQVRBX1RZUEUg
RGF0YVR5cGU7DQoJCQl0eXBlZGVmIEZydXN0dW08REFUQV9UWVBFPiBGcnVzdHVtVHlwZTsNCg0K
CQkJLyoqIEFuIGVudW0gdG8gbmFtZSB0aGUgcGxhbmUgaW5kaWNpZXMuIA0KCQkJKiAgVG8gaGF2
ZSB5b3Ugbm90IG11c3QgcmVtZW1iZXIgdGhvc2UgbnVtYmVycw0KCQkJKi8NCgkJCWVudW0gUGxh
bmVOYW1lcw0KCQkJew0KCQkJCVBMQU5FX0xFRlQgPSAwLAkJLyoqPCBsZWZ0CWNsaXBwaW5nIHBs
YW5lIGVxdWFscyAwICovDQoJCQkJUExBTkVfUklHSFQgPSAxLAkvKio8IHJpZ2h0CWNsaXBwaW5n
IHBsYW5lIGVxdWFscyAxICovDQoJCQkJUExBTkVfQk9UVE9NID0gMiwJLyoqPCBib3R0b20JY2xp
cHBpbmcgcGxhbmUgZXF1YWxzIDIgKi8NCgkJCQlQTEFORV9UT1AgPSAzLAkJLyoqPCB0b3AJY2xp
cHBpbmcgcGxhbmUgZXF1YWxzIDMgKi8NCgkJCQlQTEFORV9ORUFSID0gNCwJCS8qKjwgbmVhcglj
bGlwcGluZyBwbGFuZSBlcXVhbHMgNCAqLw0KCQkJCVBMQU5FX0ZBUiA9IDUJCS8qKjwgZmFyCWNs
aXBwaW5nIHBsYW5lIGVxdWFscyA1ICovDQoJCQl9Ow0KDQoJCQkvKioNCgkJCSogQ29uc3RydWN0
cyBhIG5ldyBmcnVzdHVtIHdpdGggYWxsIHBsYW5lcyBpbiBkZWZhdWx0IHN0YXRlDQoJCQkqLw0K
CQkJRnJ1c3R1bSgpDQoJCQl7DQoJCQkNCgkJCX0NCg0KCQkJLyoqDQoJCQkqIENvbnN0cnVjdHMg
YSBuZXcgZnJ1c3R1bSB3aXRoIHRoZSBnaXZlbiBwcm9qZWN0aW9uIG1hdHJpeC4NCgkJCSoNCgkJ
CSogQHBhcmFtIHByb2pNYXRyaXggdGhlIHByb2plY3Rpb24gbWF0cml4IG9mIHlvdXIgY2FtZXJh
IG9yIGxpZ2h0IGV0Yy4gdG8gY29uc3RydWN0IHRoZSBwbGFuZXMgZnJvbQ0KCQkJKi8NCgkJCUZy
dXN0dW0oY29uc3QgZ210bDo6TWF0cml4NDRmICYgcHJvak1hdHJpeCkNCgkJCXsNCgkJCQl0aGlz
LT5leHRyYWN0UGxhbmVzKHByb2pNYXRyaXgpOw0KCQkJfQ0KDQoJCQkvKioNCgkJCSogQ29uc3Ry
dWN0cyBhIG5ldyBmcnVzdHVtIHdpdGggZ2l2ZW4gcHJvamVjdGlvbiBhbmQgbW9kZWx2aWV3IG1h
dHJpY2llcy4NCgkJCSogdGhlIG1hdHJpY2llcyBhcmUgbXVsdGlwbGllZCBpbiB0aGlzIG9yZGVy
IDogTSA9IHByb2pNYXRyaXggKiBtb2RlbHZpZXdNYXRyaXguDQoJCQkqIHRoZSBwbGFuZXMgYXJl
IHRoYW4gZXh0cmFjdGVkIGZyb20gTS4NCgkJCSoNCgkJCSogQHBhcmFtIG1vZGVsdmlld01hdHJp
eCB0aGUgbW9kZWx2aWV3IG1hdHJpeCBvZiB5b3UgY2FtZXJhIG9yIGxpZ2h0IGV0Yy4gdG8gY29u
c3RydWN0IHRoZSBwbGFuZXMgZnJvbQ0KCQkJKiBAcGFyYW0gcHJvak1hdHJpeCB0aGUgcHJvamVj
dGlvbiBtYXRyaXggb2YgeW91ciBjYW1lcmEgb3IgbGlnaHQgb3Igd2hhdCBldmVyDQoJCQkqLw0K
CQkJRnJ1c3R1bShjb25zdCBnbXRsOjpNYXRyaXg0NGYgJiBtb2RlbHZpZXdNYXRyaXgsIGNvbnN0
DQoJCQlnbXRsOjpNYXRyaXg0NGYgJiBwcm9qTWF0cml4KQ0KCQkJew0KCQkJCXRoaXMtPmV4dHJh
Y3RQbGFuZXMobW9kZWx2aWV3TWF0cml4LCBwcm9qTWF0cml4KTsNCgkJCX0NCg0KCQkJLyoqDQoJ
CQkqIGV4dHJhY3RzIHRoZSBwbGFuZXMgZnJvbSB0aGUgZ2l2ZW4gcHJvamVjdGlvbiBtYXRyaXgu
DQoJCQkqDQoJCQkqIEBwYXJhbSBwcm9qTWF0cml4IHRoZSBwcm9qZWN0aW9uIG1hdHJpeCBvZiB5
b3UgY2FtZXJhIG9yIGxpZ2h0IG9yIHdoYXQgZXZlcg0KCQkJKi8NCgkJCXZvaWQgZXh0cmFjdFBs
YW5lcyhjb25zdCBnbXRsOjpNYXRyaXg0NGYgJiBtb2RlbHZpZXdNYXRyaXgsDQoJCQljb25zdCBn
bXRsOjpNYXRyaXg0NGYgJiBwcm9qTWF0cml4KQ0KCQkJew0KCQkJCXRoaXMtPmV4dHJhY3RQbGFu
ZXMocHJvak1hdHJpeCAqIG1vZGVsdmlld01hdHJpeCk7DQoJCQl9DQoNCgkJCS8qKg0KCQkJKiBl
eHRyYWN0cyB0aGUgcGxhbmVzIGZyb20gdGhlIGdpdmVuIHByb2plY3Rpb24gYW5kIG1vZGVsdmll
dyBtYXRyaWNpZXMuDQoJCQkqIHRoZSBtYXRyaWNpZXMgYXJlIG11bHRpcGxpZWQgaW4gdGhpcyBv
cmRlciA6IE0gPSBwcm9qTWF0cml4ICogbW9kZWx2aWV3TWF0cml4Lg0KCQkJKiB0aGUgcGxhbmVz
IGFyZSB0aGFuIGV4dHJhY3RlZCBmcm9tIE0uDQoJCQkqDQoJCQkqIEBwYXJhbSBtb2RlbHZpZXdN
YXRyaXggdGhlIG1vZGVsdmlldyBtYXRyaXggb2YgeW91IGNhbWVyYSBvciBsaWdodCBldGMuIHRv
IGNvbnN0cnVjdCB0aGUgcGxhbmVzIGZyb20NCgkJCSogQHBhcmFtIHByb2pNYXRyaXggdGhlIHBy
b2plY3Rpb24gbWF0cml4IG9mIHlvdSBjYW1lcmEgb3IgbGlnaHQgZXRjLiB0byBjb25zdHJ1Y3Qg
dGhlIHBsYW5lcyBmcm9tDQoJCQkqLw0KCQkJdm9pZCBleHRyYWN0UGxhbmVzKGNvbnN0IGdtdGw6
Ok1hdHJpeDQ0ZiAmIHByb2pNYXRyaXgpDQoJCQl7DQoJCQkJY29uc3QgZ210bDo6TWF0cml4NDRm
ICYgbSA9IHByb2pNYXRyaXg7DQoNCgkJCQkvL2xlZnQNCgkJCQl0aGlzLT5tX3BsYW5lc1tQTEFO
RV9MRUZUXS5zZXROb3JtYWwoIGdtdGw6OlZlYzNmKCBtWzNdWzBdICsgbVswXVswXSwgbVszXVsx
XSArIG1bMF1bMV0sIG1bM11bMl0gKyBtWzBdWzJdICkgKTsNCgkJCQl0aGlzLT5tX3BsYW5lc1tQ
TEFORV9MRUZUXS5zZXRPZmZzZXQobVszXVszXSArIG1bMF1bM10pOw0KCQkJCS8vcmlnaHQNCgkJ
CQl0aGlzLT5tX3BsYW5lc1tQTEFORV9SSUdIVF0uc2V0Tm9ybWFsKCBnbXRsOjpWZWMzZiggbVsz
XVswXSAtIG1bMF1bMF0sIG1bM11bMV0gLSBtWzBdWzFdLCBtWzNdWzJdIC0gbVswXVsyXSApICk7
DQoJCQkJdGhpcy0+bV9wbGFuZXNbUExBTkVfUklHSFRdLnNldE9mZnNldChtWzNdWzNdIC0gbVsw
XVszXSk7DQoJCQkJLy9ib3R0b20NCgkJCQl0aGlzLT5tX3BsYW5lc1tQTEFORV9CT1RUT01dLnNl
dE5vcm1hbCggZ210bDo6VmVjM2YoIG1bM11bMF0gKyBtWzFdWzBdLCBtWzNdWzFdICsgbVsxXVsx
XSwgbVszXVsyXSArIG1bMV1bMl0gKSApOw0KCQkJCXRoaXMtPm1fcGxhbmVzW1BMQU5FX0JPVFRP
TV0uc2V0T2Zmc2V0KG1bM11bM10gKyBtWzFdWzNdKTsNCgkJCQkvL3RvcA0KCQkJCXRoaXMtPm1f
cGxhbmVzW1BMQU5FX1RPUF0uc2V0Tm9ybWFsKCBnbXRsOjpWZWMzZiggbVszXVswXSAtIG1bMV1b
MF0sIG1bM11bMV0gLSBtWzFdWzFdLCBtWzNdWzJdIC0gbVsxXVsyXSApICk7DQoJCQkJdGhpcy0+
bV9wbGFuZXNbUExBTkVfVE9QXS5zZXRPZmZzZXQobVszXVszXSAtIG1bMV1bM10pOw0KCQkJCS8v
bmVhcg0KCQkJCXRoaXMtPm1fcGxhbmVzW1BMQU5FX05FQVJdLnNldE5vcm1hbCggZ210bDo6VmVj
M2YoIG1bM11bMF0gKyBtWzJdWzBdLCBtWzNdWzFdICsgbVsyXVsxXSwgbVszXVsyXSArIG1bMl1b
Ml0gKSApOw0KCQkJCXRoaXMtPm1fcGxhbmVzW1BMQU5FX05FQVJdLnNldE9mZnNldChtWzJdWzNd
ICsgbVszXVszXSk7DQoJCQkJLy9mYXINCgkJCQl0aGlzLT5tX3BsYW5lc1tQTEFORV9GQVJdLnNl
dE5vcm1hbCggZ210bDo6VmVjM2YoIG1bM11bMF0gLSBtWzJdWzBdLCBtWzNdWzFdIC0gbVsyXVsx
XSwgbVszXVsyXSAtIG1bMl1bMl0gKSApOw0KCQkJCXRoaXMtPm1fcGxhbmVzW1BMQU5FX0ZBUl0u
c2V0T2Zmc2V0KG1bM11bM10gLSBtWzJdWzNdKTsNCgkJCX0NCg0KCQkJZ210bDo6UGxhbmU8REFU
QV9UWVBFPiBtX3BsYW5lc1s2XTsNCgl9Ow0KDQoJdHlwZWRlZiBGcnVzdHVtPGZsb2F0PiBGcnVz
dHVtZjsNCgl0eXBlZGVmIEZydXN0dW08ZG91YmxlPiBGcnVzdHVtZDsNCn07DQoNCiNlbmRpZiAv
KiBfR01UTF9GUlVTVFVNX0hfICovDQo=

Re: [ggt-devel] changes tu Frustum.h -> added documentation and made code simpler.

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

Benjamin Schulz wrote:

[code snipped]

Your previous submission used tabs for indentation, and as far as I can
tell, this one does not. If there were not supposed to be formatting chan=
ges
included with your submission, please resend the file as an attachment.
Otherwise, I will go ahead and commit it as-is.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [ggt-devel] Frustum.h -> please remove the #include <gl/glew.h>

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

Benjamin Schulz wrote:
> sorry,
>=20
> i do not know why i've put this there

Already done. :) When I reviewed your submission, I didn't see nay place =
in
the code where it was needed, so I removed it before I committed it.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[ggt-devel] changes tu Frustum.h -> added documentation and made code simpler.

[Benjamin S. <bes...@go...>]

/************************************************************** ggt-head beg
 *
 * GGT: Generic Graphics Toolkit
 *
 * Original Authors:
 *   Benjamin Schulz
 *
 * -----------------------------------------------------------------
 * File:          Frustum.h
 * Date modified: 2004/12/14 03:35:01
 * Version:       1.0
 * -----------------------------------------------------------------
 *
 *********************************************************** ggt-head end */
/*************************************************************** ggt-cpr beg
*
* GGT: The Generic Graphics Toolkit
* Copyright (C) 2001,2002 Allen Bierbaum
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
 ************************************************************ ggt-cpr end */

#ifndef _GMTL_FRUSTUM_H_
#define _GMTL_FRUSTUM_H_

#include <gmtl/Plane.h>

namespace gmtl
{
    /**
     * This class defines a View Frustum Volume as a set of 6 planes
     *
     * @ingroup Types
     */
    template <class DATA_TYPE>
    class Frustum
    {
        public:
            typedef DATA_TYPE DataType;
            typedef Frustum<DATA_TYPE> FrustumType;

        public:
            enum PlaneNames
            {
                PLANE_LEFT = 0,
                PLANE_RIGHT = 1,
                PLANE_BOTTOM = 2,
                PLANE_TOP = 3,
                PLANE_NEAR = 4,
                PLANE_FAR = 5
            };

            /**
            * Constructs a new frustum with all planes in default state
            */
            Frustum()
            {

            }

            /**
            * Constructs a new frustum with the given projection matrix.
            *
            * @param projMatrix   the projection matrix of you camera or
light or what ever
            */
            Frustum(const gmtl::Matrix44f & projMatrix)
            {
                this->extractPlanes(projMatrix);
            }

            /**
            * Constructs a new frustum with given projection and modelview
matricies.
            * the matricies are multiplied in this order : M = projMatrix *
modelviewMatrix.
            * the planes are than extracted from M.
            *
            * @param modelviewMatrix    the modelview matrix of you camera
or light or what ever
            * @param projMatrix            the projection matrix of you
camera or light or what ever
            */
            Frustum(const gmtl::Matrix44f & modelviewMatrix, const
gmtl::Matrix44f & projMatrix)
            {
                this->extractPlanes(modelviewMatrix, projMatrix);
            }

            /**
            * extracts the planes from the given projection matrix.
            *
            * @param projMatrix   the projection matrix of you camera or
light or what ever
            */
            void extractPlanes(const gmtl::Matrix44f & modelviewMatrix,
const gmtl::Matrix44f & projMatrix)
            {
                this->extractPlanes(projMatrix * modelviewMatrix);
            }

            /**
            * extracts the planes from the given projection and modelview
matricies.
            * the matricies are multiplied in this order : M = projMatrix *
modelviewMatrix.
            * the planes are than extracted from M.
            *
            * @param modelviewMatrix    the modelview matrix of you camera
or light or what ever
            * @param projMatrix            the projection matrix of you
camera or light or what ever
            */
            void extractPlanes(const gmtl::Matrix44f & projMatrix)
            {
                const gmtl::Matrix44f & m = projMatrix;

                //left
                this->m_planes[PLANE_LEFT].setNormal( gmtl::Vec3f( m[3][0] +
m[0][0], m[3][1] + m[0][1], m[3][2] + m[0][2] ) );
                this->m_planes[PLANE_LEFT].setOffset(m[3][3] + m[0][3]);
                //right
                this->m_planes[PLANE_RIGHT].setNormal( gmtl::Vec3f( m[3][0]
- m[0][0], m[3][1] - m[0][1], m[3][2] - m[0][2] ) );
                this->m_planes[PLANE_RIGHT].setOffset(m[3][3] - m[0][3]);
                //bottom
                this->m_planes[PLANE_BOTTOM].setNormal( gmtl::Vec3f( m[3][0]
+ m[1][0], m[3][1] + m[1][1], m[3][2] + m[1][2] ) );
                this->m_planes[PLANE_BOTTOM].setOffset(m[3][3] + m[1][3]);
                //top
                this->m_planes[PLANE_TOP].setNormal( gmtl::Vec3f( m[3][0] -
m[1][0], m[3][1] - m[1][1], m[3][2] - m[1][2] ) );
                this->m_planes[PLANE_TOP].setOffset(m[3][3] - m[1][3]);
                //near
                this->m_planes[PLANE_NEAR].setNormal( gmtl::Vec3f( m[3][0] +
m[2][0], m[3][1] + m[2][1], m[3][2] + m[2][2] ) );
                this->m_planes[PLANE_NEAR].setOffset(m[2][3] + m[3][3]);
                //far
                this->m_planes[PLANE_FAR].setNormal( gmtl::Vec3f( m[3][0] -
m[2][0], m[3][1] - m[2][1], m[3][2] - m[2][2] ) );
                this->m_planes[PLANE_FAR].setOffset(m[3][3] - m[2][3]);
            }

            gmtl::Plane<DATA_TYPE> m_planes[6];
    };

    typedef Frustum<float> Frustumf;
    typedef Frustum<double> Frustumd;
};

#endif /* _GMTL_FRUSTUM_H_ */

[ggt-devel] Frustum.h -> please remove the #include <gl/glew.h>

[Benjamin S. <bes...@go...>]

sorry,

i do not know why i've put this there

thanks

[ggt-devel] Plane vs. Plane intersection test -> Intersection.h

[Benjamin S. <bes...@go...>]

hello,

it works, but is probably not the fastest implementation, but
the fastest way to do it general.
would like to see this in the trunk

--------------------------------------------------------------------------
   /**
    * Tests if the given Planes intersect with each other.
    *
    * @param plane1    first plane
    * @param plane2    second plane
    * @param ray      if successfull, ray will contain the line of
intersection
    *
    * @return  true if the planes intersect; false otherwise
    */
   template<class DATA_TYPE>
   bool intersect(const Plane<DATA_TYPE>& plane1, const Plane<DATA_TYPE>&
plane2, Ray<DATA_TYPE> & ray)
   {
    const Vec<DATA_TYPE, 3> & n1 = plane1.getNormal();
    const Vec<DATA_TYPE, 3> & n2 = plane2.getNormal();
    gmtlASSERT( isNormalized(n1, GMTL_EPSILON) );
    gmtlASSERT( isNormalized(n2, GMTL_EPSILON) );

    Vec<DATA_TYPE, 3> u;
    cross(u, n1, n2);

    float    ax = (u[0] >= 0 ? u[0] : -u[0]);
    float    ay = (u[1] >= 0 ? u[1] : -u[1]);
    float    az = (u[2] >= 0 ? u[2] : -u[2]);

    // test if the two planes are parallel
    if ((ax+ay+az) < GMTL_EPSILON)
    {       // Pn1 and Pn2 are near parallel
        return false;        //could check why it failes -> in which
relations the planes lie.
    }

    // first determine max abs coordinate of cross product
    // choosing the max coordinate gives best computational stability
    int      maxc;        // max coordinate
    if (ax > ay)
    {
        if (ax > az)
            maxc = 0;
        else maxc = 2;
    }
    else
    {
        if (ay > az)
            maxc = 1;
        else maxc = 2;
    }

    // next, to get a point on the intersect line
    // zero the max coord, and solve for the other two
    Point3f p;                    // intersect point
    const float & d1 = plane1.getOffset();
    const float & d2 = plane2.getOffset();

    switch (maxc)                // select max coordinate
    {
        case 0:                // intersect with x=0
            p[0] = 0;
            p[1] = (d2*n1[2] - d1*n2[2]) / u[0];
            p[2] = (d1*n2[1] - d2*n1[1]) / u[0];
            break;
        case 1:                // intersect with y=0
            p[0] = (d1*n2[2] - d2*n1[2]) / u[1];
            p[1] = 0;
            p[2] = (d2*n1[0] - d1*n2[0]) / u[1];
            break;
        case 2:                // intersect with z=0
            p[0] = (d2*n1[1] - d1*n2[1]) / u[2];
            p[1] = (d1*n2[0] - d2*n1[0]) / u[2];
            p[2] = 0;
    }

    ray.setOrigin(p);
    ray.setDir(u);

    return true;
   }
------------------------------------------

[ggt-devel] good accompanis

[Reto R. <gur...@va...>]

Hi,

Chaepest CALIS and VAGRA online.

http://parkerokay+now.com

Remove "+" from the link.


Unforgivable Curses. No one spoke until the bell rang but when Moody had
dismissed them and they had left the classroom, a torrent of talk burst
forth. Most people were discussing the curses in awed voices  Did you