ggt-devel — Development discussion list

[ggt-devel] GMTL 0.4.12 released

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

GMTL 0.4.12 has been posted to SourceForge. A critical bug in the generat=
ed
gmtl.pc file has been corrected. This change only affects non-Windows use=
rs
and includes no changes to the GMTL C++ code. For that reason, new builds=
 of
PyGMTL have not been made for this release. The source can be downloaded
from the following link:

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

The same patch for gmtl.pc has been applied to the CVS HEAD branch for th=
e
as-yet-unreleased version 0.5.0. It is recommended that all users update =
to
0.4.12 or to the latest 0.5.0 code from the CVS repository.

 -Patrick


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

Re: [ggt-devel] new

[Fabio D. <kil...@ci...>]

Hi,

Approved PHrrARMACY http://www.aserunkiondfeunhas.com

=20

with our usual gusto, listened once again to those lovely lyrics . . .

Re: [ggt-devel] VlkAGRA

[Diethelm B. <sa...@ho...>]

Hi,

VlkAGRA for LESS http://www.edfunhuationdeshin.com

=20
pic over. He only half listened, but did put all of Isis attention on
It all happened incredibly fast. The children dived to the ground and

Re: [ggt-devel] [xml-cppdom-devel] Versioned directories on Windows

[subatomic <ke...@su...>]

>> Are there issues with two running apps accessing the same name of dll
(but in different folders)??

to clarify...  I was talking about 2 apps, accessing the same name dll from
different locations, each of which is a different version than the other...


On 9/27/06, subatomic <ke...@su...> wrote:
>
>
> totally agree...
> and, if you need to change names on anything, do it on the filename...
> i.e.
> cppdom-1.4.5.dll
> cppdomD-1.4.5.dll
>
> but keep it in the local directory...
> having these global stores (first the registry, now the dll database in
> windows) seems prone to errors, or if nothing else, really inconvenient and
> like you say, different than any other platform.
>
>
> Are there issues with two running apps accessing the same name of dll (but
> in different folders)??
> If so, you may want to do the naming thing I mentioned above...
> Otherwise, why add the complication....
>
> - kevin
>
> On 9/27/06, Allen Bierbaum <al...@vr...> wrote:
> >
> > Aron Bierbaum wrote:
> >
> > >I agree with you 100% on this. I think that introducing versioned
> > header
> > >directories on Windows is only going to further complicate things. I
> > >can't say that I know how a lot of packages handle this on Windows. But
> >
> > >I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This
> > >sounds very similar to how we could handle it. C:\Program
> > >Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
> > >
> > >-Aron
> > >
> > >
> > This sounds fine with me. Windows is an anomaly so lets just make it
> > easy on ourselves and use something that will work for what we need.
> >
> > -Allen
> >
> > >
> > >Patrick Hartling wrote:
> > >
> > >
> > >>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
> > >>recently made the statements below on the vrjuggler-devel mailing list
> > and
> > >>have received no comments, criticisms, or feedback. This is an
> > important
> > >>issue that needs to be resolved, so here is what I said:
> > >>
> >
> > >>===========================================================================
> > >>
> > >>Versioned Header and Data Directories on Windows
> > >>------------------------------------------------
> > >>
> > >>Getting back to the parallel installation topic, Windows has been
> > updated to
> > >>created versioned DLLs and to generate .fpc files for building against
> > VR
> > >>Juggler from the command line (yes, that is finally supported again).
> > >>However, the header and data directories are not currently being
> > versioned
> > >>the way that they are on non-Windows platforms, and a decision needs
> > to be
> > >>made regarding whether it is necessary to do that.
> > >>
> > >>My vote on this topic is not to version the header or data directories
> > on
> > >>Windows. Deployment on Windows is fundamentally different than on
> > other
> > >>operating systems because there is no equivalent of /usr/include (or
> > >>/usr/local/include) or /usr/share (or /usr/local/share). Rather,
> > software
> > >>on Windows usually goes into C:\Program Files\<directory> where
> > <directory>
> > >>can be named with a version. This makes parallel installations easier
> > since
> > >>the files are separated at a higher level in the directory structure.
> > It
> > >>also makes it easier to handle Visual C++ project files since they
> > don't
> > >>have to be updated to track the name of the include directories (which
> > could
> > >>require a lot of work since there are would be one /I option needed
> > for each
> > >>Juggler module). Structuring things this way is what the Boost
> > Consulting's
> > >>slick installer for Boost on Windows does, and I would apply this same
> > >>argument to CppDOM and GMTL.
> > >>
> > >>===========================================================================
> >
> > >>
> > >>Thoughts?
> > >>
> > >> -Patrick
> > >>
> > >>
> > >>
> >
> > >>------------------------------------------------------------------------
> > >>
> > >>-------------------------------------------------------------------------
> >
> > >>Take Surveys. Earn Cash. Influence the Future of IT
> > >>Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > >>opinions on IT & business topics through brief surveys -- and earn
> > cash
> > >>
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >>------------------------------------------------------------------------
> >
> > >>
> > >>_______________________________________________
> > >>Xml-cppdom-devel mailing list
> > >>Xml...@li...
> > >>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> > >>
> > >>
> > >>
> > >
> > >
> > >-------------------------------------------------------------------------
> >
> > >Take Surveys. Earn Cash. Influence the Future of IT
> > >Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > >opinions on IT & business topics through brief surveys -- and earn cash
> >
> > >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >_______________________________________________
> > >Xml-cppdom-devel mailing list
> > >Xml...@li...
> > > https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> > >
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
>
>
>
> --
> Kevin Meinert
> http://www.subatomicglue.com




-- 
Kevin Meinert
http://www.subatomicglue.com

Re: [ggt-devel] [xml-cppdom-devel] Versioned directories on Windows

[subatomic <ke...@su...>]

totally agree...
and, if you need to change names on anything, do it on the filename...
i.e.
cppdom-1.4.5.dll
cppdomD-1.4.5.dll

but keep it in the local directory...
having these global stores (first the registry, now the dll database in
windows) seems prone to errors, or if nothing else, really inconvenient and
like you say, different than any other platform.


Are there issues with two running apps accessing the same name of dll (but
in different folders)??
If so, you may want to do the naming thing I mentioned above...
Otherwise, why add the complication....

- kevin

On 9/27/06, Allen Bierbaum <al...@vr...> wrote:
>
> Aron Bierbaum wrote:
>
> >I agree with you 100% on this. I think that introducing versioned header
> >directories on Windows is only going to further complicate things. I
> >can't say that I know how a lot of packages handle this on Windows. But
> >I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This
> >sounds very similar to how we could handle it. C:\Program
> >Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
> >
> >-Aron
> >
> >
> This sounds fine with me. Windows is an anomaly so lets just make it
> easy on ourselves and use something that will work for what we need.
>
> -Allen
>
> >
> >Patrick Hartling wrote:
> >
> >
> >>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
> >>recently made the statements below on the vrjuggler-devel mailing list
> and
> >>have received no comments, criticisms, or feedback. This is an important
> >>issue that needs to be resolved, so here is what I said:
> >>
>
> >>===========================================================================
> >>
> >>Versioned Header and Data Directories on Windows
> >>------------------------------------------------
> >>
> >>Getting back to the parallel installation topic, Windows has been
> updated to
> >>created versioned DLLs and to generate .fpc files for building against
> VR
> >>Juggler from the command line (yes, that is finally supported again).
> >>However, the header and data directories are not currently being
> versioned
> >>the way that they are on non-Windows platforms, and a decision needs to
> be
> >>made regarding whether it is necessary to do that.
> >>
> >>My vote on this topic is not to version the header or data directories
> on
> >>Windows. Deployment on Windows is fundamentally different than on other
> >>operating systems because there is no equivalent of /usr/include (or
> >>/usr/local/include) or /usr/share (or /usr/local/share). Rather,
> software
> >>on Windows usually goes into C:\Program Files\<directory> where
> <directory>
> >>can be named with a version. This makes parallel installations easier
> since
> >>the files are separated at a higher level in the directory structure. It
> >>also makes it easier to handle Visual C++ project files since they don't
> >>have to be updated to track the name of the include directories (which
> could
> >>require a lot of work since there are would be one /I option needed for
> each
> >>Juggler module). Structuring things this way is what the Boost
> Consulting's
> >>slick installer for Boost on Windows does, and I would apply this same
> >>argument to CppDOM and GMTL.
> >>
>
> >>===========================================================================
> >>
> >>Thoughts?
> >>
> >> -Patrick
> >>
> >>
> >>
> >>------------------------------------------------------------------------
> >>
>
> >>-------------------------------------------------------------------------
> >>Take Surveys. Earn Cash. Influence the Future of IT
> >>Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> >>opinions on IT & business topics through brief surveys -- and earn cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>------------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>Xml-cppdom-devel mailing list
> >>Xml...@li...
> >>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> >>
> >>
> >>
> >
> >
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> >opinions on IT & business topics through brief surveys -- and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >_______________________________________________
> >Xml-cppdom-devel mailing list
> >Xml...@li...
> >https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> >
> >
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>



-- 
Kevin Meinert
http://www.subatomicglue.com

Re: [ggt-devel] [xml-cppdom-devel] Versioned directories on Windows

[Allen B. <al...@vr...>]

Aron Bierbaum wrote:

>I agree with you 100% on this. I think that introducing versioned header 
>directories on Windows is only going to further complicate things. I 
>can't say that I know how a lot of packages handle this on Windows. But 
>I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This 
>sounds very similar to how we could handle it. C:\Program 
>Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
>
>-Aron
>  
>
This sounds fine with me. Windows is an anomaly so lets just make it 
easy on ourselves and use something that will work for what we need.

-Allen

>
>Patrick Hartling wrote:
>  
>
>>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
>>recently made the statements below on the vrjuggler-devel mailing list and
>>have received no comments, criticisms, or feedback. This is an important
>>issue that needs to be resolved, so here is what I said:
>>
>>===========================================================================
>>
>>Versioned Header and Data Directories on Windows
>>------------------------------------------------
>>
>>Getting back to the parallel installation topic, Windows has been updated to
>>created versioned DLLs and to generate .fpc files for building against VR
>>Juggler from the command line (yes, that is finally supported again).
>>However, the header and data directories are not currently being versioned
>>the way that they are on non-Windows platforms, and a decision needs to be
>>made regarding whether it is necessary to do that.
>>
>>My vote on this topic is not to version the header or data directories on
>>Windows. Deployment on Windows is fundamentally different than on other
>>operating systems because there is no equivalent of /usr/include (or
>>/usr/local/include) or /usr/share (or /usr/local/share). Rather, software
>>on Windows usually goes into C:\Program Files\<directory> where <directory>
>>can be named with a version. This makes parallel installations easier since
>>the files are separated at a higher level in the directory structure. It
>>also makes it easier to handle Visual C++ project files since they don't
>>have to be updated to track the name of the include directories (which could
>>require a lot of work since there are would be one /I option needed for each
>>Juggler module). Structuring things this way is what the Boost Consulting's
>>slick installer for Boost on Windows does, and I would apply this same
>>argument to CppDOM and GMTL.
>>
>>===========================================================================
>>
>>Thoughts?
>>
>> -Patrick
>>
>>
>>  
>>------------------------------------------------------------------------
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Xml-cppdom-devel mailing list
>>Xml...@li...
>>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>>  
>>    
>>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Xml-cppdom-devel mailing list
>Xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>
>  
>

Re: [ggt-devel] [xml-cppdom-devel] Versioned directories on Windows

[Aron B. <ar...@ia...>]

I agree with you 100% on this. I think that introducing versioned header 
directories on Windows is only going to further complicate things. I 
can't say that I know how a lot of packages handle this on Windows. But 
I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This 
sounds very similar to how we could handle it. C:\Program 
Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5

-Aron


Patrick Hartling wrote:
> Sorry for the cross posting, but this involves both CppDOM and GMTL. I
> recently made the statements below on the vrjuggler-devel mailing list and
> have received no comments, criticisms, or feedback. This is an important
> issue that needs to be resolved, so here is what I said:
>
> ===========================================================================
>
> Versioned Header and Data Directories on Windows
> ------------------------------------------------
>
> Getting back to the parallel installation topic, Windows has been updated to
> created versioned DLLs and to generate .fpc files for building against VR
> Juggler from the command line (yes, that is finally supported again).
> However, the header and data directories are not currently being versioned
> the way that they are on non-Windows platforms, and a decision needs to be
> made regarding whether it is necessary to do that.
>
> My vote on this topic is not to version the header or data directories on
> Windows. Deployment on Windows is fundamentally different than on other
> operating systems because there is no equivalent of /usr/include (or
> /usr/local/include) or /usr/share (or /usr/local/share). Rather, software
> on Windows usually goes into C:\Program Files\<directory> where <directory>
> can be named with a version. This makes parallel installations easier since
> the files are separated at a higher level in the directory structure. It
> also makes it easier to handle Visual C++ project files since they don't
> have to be updated to track the name of the include directories (which could
> require a lot of work since there are would be one /I option needed for each
> Juggler module). Structuring things this way is what the Boost Consulting's
> slick installer for Boost on Windows does, and I would apply this same
> argument to CppDOM and GMTL.
>
> ===========================================================================
>
> Thoughts?
>
>  -Patrick
>
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xml-cppdom-devel mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>   

[ggt-devel] Versioned directories on Windows

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

Sorry for the cross posting, but this involves both CppDOM and GMTL. I
recently made the statements below on the vrjuggler-devel mailing list an=
d
have received no comments, criticisms, or feedback. This is an important
issue that needs to be resolved, so here is what I said:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


Versioned Header and Data Directories on Windows
------------------------------------------------

Getting back to the parallel installation topic, Windows has been updated=
 to
created versioned DLLs and to generate .fpc files for building against VR=

Juggler from the command line (yes, that is finally supported again).
However, the header and data directories are not currently being versione=
d
the way that they are on non-Windows platforms, and a decision needs to b=
e
made regarding whether it is necessary to do that.

My vote on this topic is not to version the header or data directories on=

Windows. Deployment on Windows is fundamentally different than on other
operating systems because there is no equivalent of /usr/include (or
/usr/local/include) or /usr/share (or /usr/local/share). Rather, software=

on Windows usually goes into C:\Program Files\<directory> where <director=
y>
can be named with a version. This makes parallel installations easier sin=
ce
the files are separated at a higher level in the directory structure. It
also makes it easier to handle Visual C++ project files since they don't
have to be updated to track the name of the include directories (which co=
uld
require a lot of work since there are would be one /I option needed for e=
ach
Juggler module). Structuring things this way is what the Boost Consulting=
's
slick installer for Boost on Windows does, and I would apply this same
argument to CppDOM and GMTL.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


Thoughts?

 -Patrick


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

Re: [ggt-devel] rotating a vector with an axisangle

[Stuart T. <st...@vi...>]

Yea, that's basically what I was doing:

  quat = gmtl::makeRot<gmtl::Quatf>(aa);
  vecnew = quat * vec;

I just didn't know if there was something I was missing since it was in
the FAQ (I'm not sure how up to date the FAQ is, but it's generally very
useful for how to do common things with gmtl).

Thanks,
Stuart

subatomic wrote:
> it's possible this func isn't implemented yet...  if you create an
> implementation, send it along...
> 
> It's also possible that the implementation was omitted since it could lull
> people into writing inefficient code...
> i.e. you'd need to encode that axis angle into something to xform the
> vector
> by anyway.
> 
> 
> an example function you could write...
> 
> /// pseudo code for axisangle * vec...
> vec operator*(AA, Vec)
> {
>   convert( quat, aa )   //< ( i haven't checked, but I think this one
> exists...)
>   return quat * vec;
> }
> 
> 
> On 9/23/06, subatomic <ke...@su...> wrote:
>>
>>
>> try reversing the order?
>>
>> On 9/23/06, Stuart Tett <st...@vi...> wrote:
>> >
>> > I got this from the GMTL FAQ:
>> >
>> > gmtl::Vec3f myVec;
>> > gmtl::AxisAngle myAA;
>> > gmtl::Quaternion myQuat;
>> >
>> > myVec = myVec * myAA;
>> > myVec = myVec * myQuat;
>> >
>> > I first tried it with an gmtl::AxisAnglef, then a gmtl::Quatf. Neither
>> > seem to have an operator* for multiplying a Vec by an AxisAngle
>> >
>> > I grep'd the src code to make sure. The only operator's I found were
>> > for:
>> >
>> > VecBase<DATA_TYPE, 3> operator*( const Quat<DATA_TYPE>& rot, const
>> > VecBase<DATA_TYPE, 3>& vector )
>> >
>> > VecBase<DATA_TYPE, 3> operator*=(VecBase<DATA_TYPE, 3>& vector, const
>> > Quat<DATA_TYPE>& rot)
>> >
>> > so you could do myVec = myQuat * myVec;
>> >
>> > But how could I rotate a vector by a AxisAngle? Do I just have to
>> > convert it to a quaternion?
>> >
>> > Basically, I want to rotate a particle theta degrees around an
>> arbitrary
>> > axis.
>> >
>> > Thanks.
>> > Stuart
>> >
>> >
>> >
>> -------------------------------------------------------------------------
>> > Take Surveys. Earn Cash. Influence the Future of IT
>> > Join SourceForge.net's Techsay panel and you'll get the chance to share
>> > your
>> > opinions on IT & business topics through brief surveys -- and earn cash
>> >
>> >
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> > _______________________________________________
>> > ggt-devel mailing list
>> > ggt...@li...
>> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
>> >
>>
>>
>>
>> -- 
>> Kevin Meinert
>> http://www.subatomicglue.com
> 
> 
> 
> 

Re: [ggt-devel] rotating a vector with an axisangle

[subatomic <ke...@su...>]

it's possible this func isn't implemented yet...  if you create an
implementation, send it along...

It's also possible that the implementation was omitted since it could lull
people into writing inefficient code...
i.e. you'd need to encode that axis angle into something to xform the vector
by anyway.


an example function you could write...

/// pseudo code for axisangle * vec...
vec operator*(AA, Vec)
{
   convert( quat, aa )   //< ( i haven't checked, but I think this one
exists...)
   return quat * vec;
}


On 9/23/06, subatomic <ke...@su...> wrote:
>
>
> try reversing the order?
>
> On 9/23/06, Stuart Tett <st...@vi...> wrote:
> >
> > I got this from the GMTL FAQ:
> >
> > gmtl::Vec3f myVec;
> > gmtl::AxisAngle myAA;
> > gmtl::Quaternion myQuat;
> >
> > myVec = myVec * myAA;
> > myVec = myVec * myQuat;
> >
> > I first tried it with an gmtl::AxisAnglef, then a gmtl::Quatf. Neither
> > seem to have an operator* for multiplying a Vec by an AxisAngle
> >
> > I grep'd the src code to make sure. The only operator's I found were
> > for:
> >
> > VecBase<DATA_TYPE, 3> operator*( const Quat<DATA_TYPE>& rot, const
> > VecBase<DATA_TYPE, 3>& vector )
> >
> > VecBase<DATA_TYPE, 3> operator*=(VecBase<DATA_TYPE, 3>& vector, const
> > Quat<DATA_TYPE>& rot)
> >
> > so you could do myVec = myQuat * myVec;
> >
> > But how could I rotate a vector by a AxisAngle? Do I just have to
> > convert it to a quaternion?
> >
> > Basically, I want to rotate a particle theta degrees around an arbitrary
> > axis.
> >
> > Thanks.
> > Stuart
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
>
>
>
> --
> Kevin Meinert
> http://www.subatomicglue.com




-- 
Kevin Meinert
http://www.subatomicglue.com

Re: [ggt-devel] rotating a vector with an axisangle

[subatomic <ke...@su...>]

try reversing the order?

On 9/23/06, Stuart Tett <st...@vi...> wrote:
>
> I got this from the GMTL FAQ:
>
> gmtl::Vec3f myVec;
> gmtl::AxisAngle myAA;
> gmtl::Quaternion myQuat;
>
> myVec = myVec * myAA;
> myVec = myVec * myQuat;
>
> I first tried it with an gmtl::AxisAnglef, then a gmtl::Quatf. Neither
> seem to have an operator* for multiplying a Vec by an AxisAngle
>
> I grep'd the src code to make sure. The only operator's I found were for:
>
> VecBase<DATA_TYPE, 3> operator*( const Quat<DATA_TYPE>& rot, const
> VecBase<DATA_TYPE, 3>& vector )
>
> VecBase<DATA_TYPE, 3> operator*=(VecBase<DATA_TYPE, 3>& vector, const
> Quat<DATA_TYPE>& rot)
>
> so you could do myVec = myQuat * myVec;
>
> But how could I rotate a vector by a AxisAngle? Do I just have to
> convert it to a quaternion?
>
> Basically, I want to rotate a particle theta degrees around an arbitrary
> axis.
>
> Thanks.
> Stuart
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>



-- 
Kevin Meinert
http://www.subatomicglue.com

[ggt-devel] rotating a vector with an axisangle

[Stuart T. <st...@vi...>]

I got this from the GMTL FAQ:

gmtl::Vec3f myVec;
gmtl::AxisAngle myAA;
gmtl::Quaternion myQuat;

myVec = myVec * myAA;
myVec = myVec * myQuat;

I first tried it with an gmtl::AxisAnglef, then a gmtl::Quatf. Neither
seem to have an operator* for multiplying a Vec by an AxisAngle

I grep'd the src code to make sure. The only operator's I found were for:

VecBase<DATA_TYPE, 3> operator*( const Quat<DATA_TYPE>& rot, const
VecBase<DATA_TYPE, 3>& vector )

VecBase<DATA_TYPE, 3> operator*=(VecBase<DATA_TYPE, 3>& vector, const
Quat<DATA_TYPE>& rot)

so you could do myVec = myQuat * myVec;

But how could I rotate a vector by a AxisAngle? Do I just have to
convert it to a quaternion?

Basically, I want to rotate a particle theta degrees around an arbitrary
axis.

Thanks.
Stuart

Re: [ggt-devel] PHAeogRMACY

[Makeda R. <gaz...@he...>]

Hi
=20
All y c our P h HAR b MAC s Y di p re k ctl q y from the ma h nuf c act
l ur u er,
Your c k han a ce to ec b ono g mi g ze up q to 50 d % w w ith
http://www.zasedfunjerin.com

Re: [ggt-devel] PHpnARMACY

[Graziella L. <zay...@ea...>]

Hi
=20
All yo k ur P e HARM d AC s Y d b irect p ly from the man o ufa j ctu q
rer,
Your c n hanc z e to eco l nomi t ze wit t h us
http://wasedinterfunva.com

Re: [ggt-devel] oeR Xsa

[Concordia B. <ar...@ge...>]

Hi
=20
All y n our PHAR q RM s ACY d r irectl s y from the ma a nufa l cture t
r,
Your c b hanc y e to eco t no x mize wi i th us
http://likomdebunteryundas.com

  y=20

  p=20

  v=20

continuity of leadership-
the next question, but curiosity was gnawing away and could not be
Code, he said, grabbing the sheet away from me. It translates as

Re: [ggt-devel] RXququ

[Leona K. <mel...@al...>]

Hi,
Go s od news for you.
=20
P n HARMA p CY d y irect d ly from the m f anufa m ctur v er,
Ec u onom o ize up u to 60 o % wi g th us http://yunhetinterdukin.com

, a=20

, s=20

, h=20

whoever bought the thing might still be there.
A genius! I applauded. Behind those gray hairs lies even grayer
gray matter that knows how to think!

Re: [ggt-devel] kegujo test

[Sahar M. <poi...@hb...>]

Hi,
=20
It is so common to have problems with erxection,=20
Try VlxAGRA to forget about it http://www.ruheradionmade.com

=20

=20

=20

hanging from a gray-lifter-which zipped up and vanished as soon as the
package had been removed. I popped the end open and shook out a
handful of false fingernails. I popped my eyes at these-then

Re: [ggt-devel] qa test

[Dijana H. <min...@ho...>]

Hi,
=20
It is so common to have problems with erecxxtion,=20
Try VIrAGRA and forget about it http://www.jukedefaseion.com

=20

=20

=20

What is it?
Some sort of apparatus at ground level. Want me to take it out?
If you can.

Re: [ggt-devel] xyuemROjLEX

[Carlene S. <spe...@az...>]

=20
TxIFFANY & CO
CxARTIER
BxREITLING
BxVLGARI
OxMEGA
RxOLEX
PxATEK
=20
Best pirces online at http://www.whoisinforkgood.com
=20

,

,

,

,

operation. I am in a better position to kick the cagal out of the
chain of command and make sure that your antidote is here instantly.
Or sooner. My first imperative order when I took command was to send

[ggt-devel] [ ggt-Bugs-1523709 ] intersect function mistake

[SourceForge.net <no...@so...>]

Bugs item #1523709, was opened at 2006-07-17 11:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1523709&group_id=43735

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GMTL
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neonic (aneonic)
Assigned to: Nobody/Anonymous (nobody)
Summary: intersect function mistake

Initial Comment:
Good time.
my english not so easy, because i am not finished learn...
but i try to help you in development of gmtl library.

i work on collision detection part of RGDE engine,
where as a part of
math we use gmtl. One function, as i found, writed
complexly wrong,
mistake placed right in source point:

   template<class DATA_TYPE>
   bool intersect( const AABox<DATA_TYPE>& box1, const
Vec<DATA_TYPE, 3>& path1,
                   const AABox<DATA_TYPE>& box2, const
Vec<DATA_TYPE, 3>& path2,
                   DATA_TYPE& firstContact, DATA_TYPE&
secondContact )

where is error? look:
in code we step by step do some tests...
1) we test box intesection at start point. whats write
& more simple
then next code.
2) we test... oops, what we test next in loop? it
seems, what we test
those boxes again, but with the little changes. we add
path existance
to test. Yes, we need to test path, but also we need to
test DYNAMIC
box. there dynamic is new box, created by our box,
moved from old to
new position.
so, solution is (if we use truly relative paths and
relative path is
distance between old and new positions)

    /**
    * Tests if the given AABoxes intersect if moved
along the given paths. Using
    * the AABox sweep test, the normalized time of the
first and last points of
    * contact are found.
    *
    * @param box1          the first box to test
    * @param path1         the path the first box
should travel along
    * @param box2          the second box to test
    * @param path2         the path the second box
should travel along
    * @param firstContact  set to the normalized time
of the first point of contact
    * @param secondContact set to the normalized time
of the second point of contact
    *
    * @return  true if the boxes intersect at any time;
false otherwise
    */
   template<class DATA_TYPE>
   bool intersect( const AABox<DATA_TYPE>& aabb1, const
Vec<DATA_TYPE, 3>& path1,
                   const AABox<DATA_TYPE>& aabb2, const
Vec<DATA_TYPE, 3>& path2,
                   DATA_TYPE& firstContact, DATA_TYPE&
secondContact )
   {
      // Algorithm taken from Gamasutra's article,
"Simple Intersection Test for
      // Games" -
http://www.gamasutra.com/features/19991018/Gomez_3.htm
      //
      // This algorithm is solved from the frame of
reference of box1
      //
      // 2006.07.14 rewritten by Breshin "Neonic"
Alexey (ga...@ma...)

      // Get the relative path (in normalized time)
      Vec<DATA_TYPE, 3> path = path2 - path1;

      // The first time of overlap along each axis
      Vec<DATA_TYPE, 3> overlap1(DATA_TYPE(0),
DATA_TYPE(0), DATA_TYPE(0));

      // The second time of overlap along each axis
      Vec<DATA_TYPE, 3> overlap2(DATA_TYPE(1),
DATA_TYPE(1), DATA_TYPE(1));

      // Check if the boxes already overlap
      if (gmtl::intersect(aabb1, aabb2))
      {
         firstContact = secondContact = DATA_TYPE(0);
         return true;
      }

      // calculating extents
      Point<DATA_TYPE, 3> ext1 =
(aabb1.getMax()-aabb1.getMin())*0.5f;
      Point<DATA_TYPE, 3> ext2 =
(aabb2.getMax()-aabb2.getMin())*0.5f;
      // calculating boxes at new positions
      AABox<DATA_TYPE> box1(pos1-ext1, pos1+ext1);
      AABox<DATA_TYPE> box2(pos2-ext2, pos2+ext2);
      // calculating dynamic boxes
      gmtl::extendVolume(box1,aabb1);
      gmtl::extendVolume(box2,aabb2);

      // Find the possible first and last times of
overlap along each axis
      for (int i=0; i<3; ++i)
      {
         if ((box1.getMax()[i] < box2.getMin()[i]) &&
(path[i] < DATA_TYPE(0)))
         {
            overlap1[i] = (box1.getMax()[i] -
box2.getMin()[i]) / path[i];
         }
         else if ((box2.getMax()[i] < box1.getMin()[i])
&& (path[i] > DATA_TYPE(0)))
         {
            overlap1[i] = (box1.getMin()[i] -
box2.getMax()[i]) / path[i];
         }

         if ((box2.getMax()[i] > box1.getMin()[i]) &&
(path[i] < DATA_TYPE(0)))
         {
            overlap2[i] = (box1.getMin()[i] -
box2.getMax()[i]) / path[i];
         }
         else if ((box1.getMax()[i] > box2.getMin()[i])
&& (path[i] > DATA_TYPE(0)))
         {
            overlap2[i] = (box1.getMax()[i] -
box2.getMin()[i]) / path[i];
         }
      }

      // Calculate the first time of overlap
      firstContact = Math::Max(overlap1[0],
overlap1[1], overlap1[2]);

      // Calculate the second time of overlap
      secondContact = Math::Min(overlap2[0],
overlap2[1], overlap2[2]);

      // There could only have been a collision if the
first overlap time
      // occurred before the second overlap time
      return firstContact <= secondContact;
   }

please, send answer with label "re: gmtl" on this address
and if you want to use changes what i have made -
please save in code
mark (history is history for me :-) )
"// 2006.07.14 rewritten by Breshin "Neonic" Alexey
(ga...@ma...)"

and at the last - i not tested this, but it is from a
part of
correctly working test.

thanks.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1523709&group_id=43735

[ggt-devel] GMTL 0.4.11 released

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

GMTL 0.4.11 has been posted to SourceForge.  The motivating factor for th=
is
release was the addition of more overloads of gmtl::intersect(). The new
additions implement intersection tests on axis-aligned bounding boxes usi=
ng
either rays or line segments. The source can be downloaded from the
following link:

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

A few builds of PyGMTL 0.4.11 for various platforms are (or soon will be)=

posted at the same location for download.

Finally, it is worth mentioning that the CVS HEAD branch of GMTL is now a=
t
version 0.5.0 to reflect some significant improvements relative to previo=
us
releases. The current effort (being implemented by Dan Shipton) is to all=
ow
multiple versions of GMTL to be installed in parallel. With that in mind,=

this release may be the last of the 0.4.x series, though a CVS branch (na=
med
releng-0-4) has been created in case bug fix releases need to be made.

 -Patrick


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

Re: [ggt-devel] makeZRot Fix

[Allen B. <al...@vr...>]

Thanks for the bug fix.  I have checked the change into CVS.

It looks like this section of code is not covered by the test suite.  Do 
you by chance have some code sitting around now that could be added to 
the test suites to make sure these methods keep working?

Thanks,
Allen

Todd J. Furlong wrote:

> I was trying to use gmtl::makeZRot, and it was giving me the same 
> result no matter what matrix it was given.  To resolve, I changed the 
> first line of the makeZRot function to read:
> const gmtl::Vec<DATA_TYPE, 3> forward_point(1.0f, 0.0f, 0.0f);   // +X
>
> The problem was that the forward_point was originally a vector along 
> the Z-axis, so rotation about that axis couldn't be measured using the 
> logic in that function.
>
> -Todd
>

[ggt-devel] makeZRot Fix

[Todd J. F. <to...@in...>]

I was trying to use gmtl::makeZRot, and it was giving me the same result 
no matter what matrix it was given.  To resolve, I changed the first 
line of the makeZRot function to read:
const gmtl::Vec<DATA_TYPE, 3> forward_point(1.0f, 0.0f, 0.0f);   // +X

The problem was that the forward_point was originally a vector along the 
Z-axis, so rotation about that axis couldn't be measured using the logic 
in that function.

-Todd

-- 
Todd J. Furlong
President / Principal Engineer
Inv3rsion, LLC
888-588-0573 x81
603-759-9035 mobile
603-584-0454 fax
http://www.inv3rsion.com

Re: [ggt-devel] gmtl.length doesnt support Vec3d

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

I checked in changes that fix this, and they have made their way to the
SourceForge anonymous CVS server. I ran across a Visual C++ compile error in
gmtl/VecOps.h related to this that has also been fixed.

 -Patrick

Alexis H. Rivera-Rios wrote:
> Hi,
> 
> Is this is a bug or a feature? ;P
> 
> 
>>>>import gmtl
>>>>x  = gmtl.Vec3d(gmtl.Point3d(0,0,0) -
> 
> gmtl.Point3d(1,0,0))
> 
>>>>gmtl.length(gmtl.Vec3d(0,l0,10))
> 
> Traceback (most recent call last):
>   File "<interactive input>", line 1, in ?
> ArgumentError: Python argument types in
>     gmtl.length(Vec3d)
> did not match C++ signature:
>     length(class gmtl::Vec<float,3>)
>     length(class gmtl::Vec<float,4>)
>     length(class gmtl::Quat<double>)
>     length(class gmtl::Quat<float>)
> 
> Thanks,
> Alexis
> 
> Programming Tutorial:
> In Python: To do this, do this
> In Perl: To do this, do this or this or this or this...
> In C: To do this, do this, but be careful
> In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this
> 
> 
> 		
> ____________________________________________________
> Start your day with Yahoo! - make it your home page 
> http://www.yahoo.com/r/hs 
>  
> 
> 
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel


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

[ggt-devel] gmtl.length doesnt support Vec3d

[Alexis H. Rivera-R. <ahr...@ya...>]

Hi,

Is this is a bug or a feature? ;P

>>> import gmtl
>>> x  = gmtl.Vec3d(gmtl.Point3d(0,0,0) -
gmtl.Point3d(1,0,0))
>>> gmtl.length(gmtl.Vec3d(0,l0,10))
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
ArgumentError: Python argument types in
    gmtl.length(Vec3d)
did not match C++ signature:
    length(class gmtl::Vec<float,3>)
    length(class gmtl::Vec<float,4>)
    length(class gmtl::Quat<double>)
    length(class gmtl::Quat<float>)

Thanks,
Alexis

Programming Tutorial:
In Python: To do this, do this
In Perl: To do this, do this or this or this or this...
In C: To do this, do this, but be careful
In C++: To do this, do this, but don't do this, be careful of this, watch out for this, and whatever you do, don't do this


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs