ggt-devel — Development discussion list

[ggt-devel] Re: adding GetColumn to ggt Matrix?

[Ben S. <bs...@ga...>]

While it could be considered an unneeded function because you can achieve
the same functionality on your own, I have often wanted the ability to get
a column from a matrix as vector - especially when getting the forward
vector for entities or doing billboarding. It's a relatively simple
function that will bloat the API but not the user's code unless they use
it. I figure that GMTL is hard enough for most people to grok because of
the templates that anything we can do to help them use it and like it is
good.

I guess if Allen agrees with you and doesn't want it in the library I'll
concede and just send Eric the patch rather than commit it.

cheers,
-Ben

>
>
> I'm not sure it was an ambiguity, rather it was an effort not to bloat the
> code with unneeded functions.
>
> for example, you can easily write your own GetColumn using the element
> accessor operator (  mat[row][col]  ).
>
> I see it as unneeded, but I'll defer the descision to allen or ben since I
> don't feel too strongly about it.
>
> kevin
>
>
> On Mon, 22 Sep 2003, Eric Maslowski wrote:
>
>> Ben said he was going to take a look into adding GetColumn() routine to
>> the
>> library to simplify this ambiguity. Thanks for the response.
>>
>> cheers
>>
>> E.
>>
>> At 15:13 09/22/2003 -0500, you wrote:
>>
>> >mats are column ordered, so that helps.  you should be able to index
>> one
>> >element and dereference it to get the column.
>> >
>> >I think (float*)&mat.mData[0] would be the first column, which if you
>> init
>> >a Vec with it:
>> >
>> >gmtl::Vec4f col;
>> >col.set( (float*)&mat.mData[0] );
>> >
>> >
>> >second column (example):
>> >
>> >    col.set( (float*)&mat(0,1) );
>> >
>> >
>> >4th column (translation component):
>> >
>> >    col.set( (float*)&mat[0][3] );
>> >
>> >
>> >
>> >-kevin
>> >
>> >
>> >
>> >On Mon, 22 Sep 2003, Eric Maslowski wrote:
>> >
>> > > How this is the right list: What is the recommended method for
>> grabbing an
>> > > entire column?
>> > >
>> > > Can't seem to find a general GetColumn() routine in the Matrix
>> definition.
>> > > I can't seem to even grab the components and throw them in a vector
>> when
>> > > the Matrix44f is a pointer.
>> > >
>> > > Matrix44f* mat = entity->GetTransform(); // GetTransform() returns
>> > Matrix44f*
>> > > Vec3f out_vec(mat[2][0],mat[2][1],mat[2][2]);
>> > >
>> > > yields:
>> > >
>> > > error C2664: 'gmtl::Vec<DATA_TYPE,SIZE>::Vec(const DATA_TYPE &,const
>> > > DATA_TYPE &,const DATA_TYPE &)' : cannot convert parameter 1 from
>> > > 'gmtl::Matrix<DATA_TYPE,ROWS,COLS>::RowAccessor *' to 'const float
>> &'
>> > >
>> > > Any help would be greatly appreciated.
>> > >
>> > > cheers
>> > >
>> > > E.
>> > >
>> > >
>> > >
>> > > -------------------------------------------------------
>> > > This sf.net email is sponsored by:ThinkGeek
>> > > Welcome to geek heaven.
>> > > http://thinkgeek.com/sf
>> > > _______________________________________________
>> > > ggt-devel mailing list
>> > > ggt...@li...
>> > > https://lists.sourceforge.net/lists/listinfo/ggt-devel
>> > >
>> >
>> >--
>> >*--*---*---*----*-----*------*------*-----*----*---*---*--*
>> >Kevin Meinert                         /_/
>> >home - http://www.vrsource.org/~kevin           \        /
>> >music - http://www.subatomicglue.com           \/  __    \/
>> >                                                    \__
>> >                                             \_\
>>
>>
>
> --
> *--*---*---*----*-----*------*------*-----*----*---*---*--*
> Kevin Meinert                         /_/
> home - http://www.vrsource.org/~kevin           \        /
> music - http://www.subatomicglue.com           \/  __    \/
>                                                    \__
>                                             \_\
>
>

Re: [ggt-devel] Best way to grab an entire column (Matrix44f)

[Kevin M. <ke...@vr...>]

what Ben says works too, and avoids depending on internal memory ordering 
though you can depend on it because it will not change (because opengl's 
memory format is that way).

ben's code reads a little better though since the operations are more 
apparent.
kevin



On Mon, 22 Sep 2003, Ben Scott wrote:

> You need to dereference your matrix pointer before accessing it like an
> array. Try the following code:
> 
> const Matrix44f& mat = *entity->GetTransform();
> Vec3f out_vec(mat[2][0], mat[2][1], mat[2][2]);
> 
> cheers,
> -Ben
> 
> > How this is the right list: What is the recommended method for grabbing an
> > entire column?
> >
> > Can't seem to find a general GetColumn() routine in the Matrix definition.
> > I can't seem to even grab the components and throw them in a vector when
> > the Matrix44f is a pointer.
> >
> > Matrix44f* mat = entity->GetTransform(); // GetTransform() returns
> > Matrix44f*
> > Vec3f out_vec(mat[2][0],mat[2][1],mat[2][2]);
> >
> > yields:
> >
> > error C2664: 'gmtl::Vec<DATA_TYPE,SIZE>::Vec(const DATA_TYPE &,const
> > DATA_TYPE &,const DATA_TYPE &)' : cannot convert parameter 1 from
> > 'gmtl::Matrix<DATA_TYPE,ROWS,COLS>::RowAccessor *' to 'const float &'
> >
> > Any help would be greatly appreciated.
> >
> > cheers
> >
> > E.
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] Best way to grab an entire column (Matrix44f)

[Kevin M. <ke...@vr...>]

mats are column ordered, so that helps.  you should be able to index one 
element and dereference it to get the column.

I think (float*)&mat.mData[0] would be the first column, which if you init 
a Vec with it:

gmtl::Vec4f col;
col.set( (float*)&mat.mData[0] );


second column (example):

   col.set( (float*)&mat(0,1) );


4th column (translation component):

   col.set( (float*)&mat[0][3] );



-kevin



On Mon, 22 Sep 2003, Eric Maslowski wrote:

> How this is the right list: What is the recommended method for grabbing an 
> entire column?
> 
> Can't seem to find a general GetColumn() routine in the Matrix definition. 
> I can't seem to even grab the components and throw them in a vector when 
> the Matrix44f is a pointer.
> 
> Matrix44f* mat = entity->GetTransform(); // GetTransform() returns Matrix44f*
> Vec3f out_vec(mat[2][0],mat[2][1],mat[2][2]);
> 
> yields:
> 
> error C2664: 'gmtl::Vec<DATA_TYPE,SIZE>::Vec(const DATA_TYPE &,const 
> DATA_TYPE &,const DATA_TYPE &)' : cannot convert parameter 1 from 
> 'gmtl::Matrix<DATA_TYPE,ROWS,COLS>::RowAccessor *' to 'const float &'
> 
> Any help would be greatly appreciated.
> 
> cheers
> 
> E.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] Best way to grab an entire column (Matrix44f)

[Ben S. <bs...@ga...>]

You need to dereference your matrix pointer before accessing it like an
array. Try the following code:

const Matrix44f& mat = *entity->GetTransform();
Vec3f out_vec(mat[2][0], mat[2][1], mat[2][2]);

cheers,
-Ben

> How this is the right list: What is the recommended method for grabbing an
> entire column?
>
> Can't seem to find a general GetColumn() routine in the Matrix definition.
> I can't seem to even grab the components and throw them in a vector when
> the Matrix44f is a pointer.
>
> Matrix44f* mat = entity->GetTransform(); // GetTransform() returns
> Matrix44f*
> Vec3f out_vec(mat[2][0],mat[2][1],mat[2][2]);
>
> yields:
>
> error C2664: 'gmtl::Vec<DATA_TYPE,SIZE>::Vec(const DATA_TYPE &,const
> DATA_TYPE &,const DATA_TYPE &)' : cannot convert parameter 1 from
> 'gmtl::Matrix<DATA_TYPE,ROWS,COLS>::RowAccessor *' to 'const float &'
>
> Any help would be greatly appreciated.
>
> cheers
>
> E.
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>

[ggt-devel] Best way to grab an entire column (Matrix44f)

[Eric M. <ema...@um...>]

How this is the right list: What is the recommended method for grabbing an 
entire column?

Can't seem to find a general GetColumn() routine in the Matrix definition. 
I can't seem to even grab the components and throw them in a vector when 
the Matrix44f is a pointer.

Matrix44f* mat = entity->GetTransform(); // GetTransform() returns Matrix44f*
Vec3f out_vec(mat[2][0],mat[2][1],mat[2][2]);

yields:

error C2664: 'gmtl::Vec<DATA_TYPE,SIZE>::Vec(const DATA_TYPE &,const 
DATA_TYPE &,const DATA_TYPE &)' : cannot convert parameter 1 from 
'gmtl::Matrix<DATA_TYPE,ROWS,COLS>::RowAccessor *' to 'const float &'

Any help would be greatly appreciated.

cheers

E.

Re: [ggt-devel] Bug in matrix state code

[Kevin M. <ke...@vr...>]

I was thinking of the re-orthonormalization too, and wondering if the guy 
just needs to do that.  I don't know enough about what he's doing though 
to say much more...

I'm guessing it is going out of affine, because the 3x3 isn't orthonormal 
and with drift quickly gets crappy because the invert affine somehow 
doesn't account for it.

it would be good to get some sample data and try to run it through to see 
where it falls apart.  (i.e. is it a bad scale, is it truely error drift, 
something else?)


kevin


On Mon, 8 Sep 2003, Allen Bierbaum wrote:

> Kevin Meinert wrote:
> > using matrices to accumulate might be error prone, make sure the guy is 
> > accomodating for drift...  make sure he is actually inverting an affine 
> > matrix (if he's setting values manually, he'll need to set the state to 
> > full manually).
> 
> Does GMTL provide facilities for either of these things: accomodating 
> for drift or even checking if the matrix is affine?
> 
> Another helpful method may be something to correct a slightly drifted 
> matrix to "re-affine" it.  I know I have seen libraries that implement 
> re-orthogonalization, but I am not sure about affine.
> 
> -Allen
> 
> > 
> > what part of the matrix is going to crap?  and what is the matrix being 
> > used for?  i.e. what sort of accumulative operation is being done...
> > 
> > kevin
> > 
> > On Sun, 7 Sep 2003, Patrick Hartling wrote:
> > 
> > 
> >>Well, unsurprisingly, I misdiagnosed this problem.  The data flow is 
> >>rather difficult to explain.  There are a lot of matrices in this code, 
> >>and I got confused tracing through how they all work together.  The 
> >>matrix I mentioned in the previous message is not the one causing the 
> >>problem, though it is being used every frame in the calculation of the 
> >>matrix that is causing problems.
> >>
> >>After further testing, I am convinced that there is a problem of some 
> >>form in gmtl::invertAffine() that causes an error to accumulate over 
> >>time.  If I comment out the use of gmtl::invertAffine() in 
> >>gmtl::invert() (lines 564-566 in MatrixOps.h), the bug goes away.  This 
> >>behavior is repeatable in a super simple test case, but the epsilon 
> >>value used for an equality test has to be quite small.  The values in 
> >>the matrices also have to be floating point--the current tests use integers.
> >>
> >>I'm still not sure why the error accumulates so quickly in my code 
> >>(within 30 frames, the matrices turn to junk), though it could be the 
> >>cumulative effect of many matrix operations per frame.  A more 
> >>complicated test case may cause the problem to be exhibited more 
> >>effectively.
> >>
> >>For the time being, I am inclined to comment out the use of 
> >>gmtl::invertAffine().  This seems like a pretty serious problem since 
> >>gmtl::invert() is a common operation.
> >>
> >>  -Patrick
> >>
> >>Patrick Hartling wrote:
> >>
> >>>I think that there is a bug in the code that does optimizations for 
> >>>matrix operations based on the matrix state.  Unfortunately, I don't 
> >>>know the GMTL code (or math in general) well enough to track down the 
> >>>bug.  I can describe the symptoms, however, with the hope that someone 
> >>>can give me a suggestion on how to do further debugging.
> >>>
> >>>Basically, what happens is the values of an affine matrix approach zero 
> >>>after it is inverted.  Eventually, they reach zero, and my application 
> >>>crashes.  (The application was not written by me, and the math in it is 
> >>>way beyond me.)  What is particularly vexing is that the single 
> >>>inversion appears to be the only place in the code where the matrix is 
> >>>modified, but somehow its values change constantly after that point.  I 
> >>>must be missing something--I just haven't figured out what.
> >>>
> >>>In any event, if I back out the only changes to Generate.h, Matrix.h, 
> >>>and MatrixOps.h to remove the state tracking optimizations, the code 
> >>>starts working again without any problems.  I'm guessing that the 
> >>>problem is in gmtl::invertAffine() since it was added as part of the 
> >>>optimization code.  Perhaps there is something in that function that 
> >>>causes additive round-off errors?
> >>>
> >>>The specific revisions in question are the following:
> >>>
> >>>   Generate.h: 1.73
> >>>   Matrix.h: 1.28
> >>>   MatrixOps.h: 1.31
> >>>
> >>>I would appreciate any suggestions on how to track down this problem or 
> >>>any suggested fixes (short of backing out the optimizations altogether).
> >>>
> >>> -Patrick
> >>>
> >>>
> >>
> >>
> >>
> > 
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] Bug in matrix state code

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

Kevin Meinert wrote:
> using matrices to accumulate might be error prone, make sure the guy is 
> accomodating for drift...  make sure he is actually inverting an affine 
> matrix (if he's setting values manually, he'll need to set the state to 
> full manually).

Does GMTL provide facilities for either of these things: accomodating 
for drift or even checking if the matrix is affine?

Another helpful method may be something to correct a slightly drifted 
matrix to "re-affine" it.  I know I have seen libraries that implement 
re-orthogonalization, but I am not sure about affine.

-Allen

> 
> what part of the matrix is going to crap?  and what is the matrix being 
> used for?  i.e. what sort of accumulative operation is being done...
> 
> kevin
> 
> On Sun, 7 Sep 2003, Patrick Hartling wrote:
> 
> 
>>Well, unsurprisingly, I misdiagnosed this problem.  The data flow is 
>>rather difficult to explain.  There are a lot of matrices in this code, 
>>and I got confused tracing through how they all work together.  The 
>>matrix I mentioned in the previous message is not the one causing the 
>>problem, though it is being used every frame in the calculation of the 
>>matrix that is causing problems.
>>
>>After further testing, I am convinced that there is a problem of some 
>>form in gmtl::invertAffine() that causes an error to accumulate over 
>>time.  If I comment out the use of gmtl::invertAffine() in 
>>gmtl::invert() (lines 564-566 in MatrixOps.h), the bug goes away.  This 
>>behavior is repeatable in a super simple test case, but the epsilon 
>>value used for an equality test has to be quite small.  The values in 
>>the matrices also have to be floating point--the current tests use integers.
>>
>>I'm still not sure why the error accumulates so quickly in my code 
>>(within 30 frames, the matrices turn to junk), though it could be the 
>>cumulative effect of many matrix operations per frame.  A more 
>>complicated test case may cause the problem to be exhibited more 
>>effectively.
>>
>>For the time being, I am inclined to comment out the use of 
>>gmtl::invertAffine().  This seems like a pretty serious problem since 
>>gmtl::invert() is a common operation.
>>
>>  -Patrick
>>
>>Patrick Hartling wrote:
>>
>>>I think that there is a bug in the code that does optimizations for 
>>>matrix operations based on the matrix state.  Unfortunately, I don't 
>>>know the GMTL code (or math in general) well enough to track down the 
>>>bug.  I can describe the symptoms, however, with the hope that someone 
>>>can give me a suggestion on how to do further debugging.
>>>
>>>Basically, what happens is the values of an affine matrix approach zero 
>>>after it is inverted.  Eventually, they reach zero, and my application 
>>>crashes.  (The application was not written by me, and the math in it is 
>>>way beyond me.)  What is particularly vexing is that the single 
>>>inversion appears to be the only place in the code where the matrix is 
>>>modified, but somehow its values change constantly after that point.  I 
>>>must be missing something--I just haven't figured out what.
>>>
>>>In any event, if I back out the only changes to Generate.h, Matrix.h, 
>>>and MatrixOps.h to remove the state tracking optimizations, the code 
>>>starts working again without any problems.  I'm guessing that the 
>>>problem is in gmtl::invertAffine() since it was added as part of the 
>>>optimization code.  Perhaps there is something in that function that 
>>>causes additive round-off errors?
>>>
>>>The specific revisions in question are the following:
>>>
>>>   Generate.h: 1.73
>>>   Matrix.h: 1.28
>>>   MatrixOps.h: 1.31
>>>
>>>I would appreciate any suggestions on how to track down this problem or 
>>>any suggested fixes (short of backing out the optimizations altogether).
>>>
>>> -Patrick
>>>
>>>
>>
>>
>>
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

Re: [ggt-devel] Bug in matrix state code

[Kevin M. <ke...@vr...>]

using matrices to accumulate might be error prone, make sure the guy is 
accomodating for drift...  make sure he is actually inverting an affine 
matrix (if he's setting values manually, he'll need to set the state to 
full manually).

what part of the matrix is going to crap?  and what is the matrix being 
used for?  i.e. what sort of accumulative operation is being done...

kevin

On Sun, 7 Sep 2003, Patrick Hartling wrote:

> Well, unsurprisingly, I misdiagnosed this problem.  The data flow is 
> rather difficult to explain.  There are a lot of matrices in this code, 
> and I got confused tracing through how they all work together.  The 
> matrix I mentioned in the previous message is not the one causing the 
> problem, though it is being used every frame in the calculation of the 
> matrix that is causing problems.
> 
> After further testing, I am convinced that there is a problem of some 
> form in gmtl::invertAffine() that causes an error to accumulate over 
> time.  If I comment out the use of gmtl::invertAffine() in 
> gmtl::invert() (lines 564-566 in MatrixOps.h), the bug goes away.  This 
> behavior is repeatable in a super simple test case, but the epsilon 
> value used for an equality test has to be quite small.  The values in 
> the matrices also have to be floating point--the current tests use integers.
> 
> I'm still not sure why the error accumulates so quickly in my code 
> (within 30 frames, the matrices turn to junk), though it could be the 
> cumulative effect of many matrix operations per frame.  A more 
> complicated test case may cause the problem to be exhibited more 
> effectively.
> 
> For the time being, I am inclined to comment out the use of 
> gmtl::invertAffine().  This seems like a pretty serious problem since 
> gmtl::invert() is a common operation.
> 
>   -Patrick
> 
> Patrick Hartling wrote:
> > I think that there is a bug in the code that does optimizations for 
> > matrix operations based on the matrix state.  Unfortunately, I don't 
> > know the GMTL code (or math in general) well enough to track down the 
> > bug.  I can describe the symptoms, however, with the hope that someone 
> > can give me a suggestion on how to do further debugging.
> > 
> > Basically, what happens is the values of an affine matrix approach zero 
> > after it is inverted.  Eventually, they reach zero, and my application 
> > crashes.  (The application was not written by me, and the math in it is 
> > way beyond me.)  What is particularly vexing is that the single 
> > inversion appears to be the only place in the code where the matrix is 
> > modified, but somehow its values change constantly after that point.  I 
> > must be missing something--I just haven't figured out what.
> > 
> > In any event, if I back out the only changes to Generate.h, Matrix.h, 
> > and MatrixOps.h to remove the state tracking optimizations, the code 
> > starts working again without any problems.  I'm guessing that the 
> > problem is in gmtl::invertAffine() since it was added as part of the 
> > optimization code.  Perhaps there is something in that function that 
> > causes additive round-off errors?
> > 
> > The specific revisions in question are the following:
> > 
> >    Generate.h: 1.73
> >    Matrix.h: 1.28
> >    MatrixOps.h: 1.31
> > 
> > I would appreciate any suggestions on how to track down this problem or 
> > any suggested fixes (short of backing out the optimizations altogether).
> > 
> >  -Patrick
> > 
> > 
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] CPPUNIT_ASSERT() vs. assert()

[Kevin M. <ke...@vr...>]

I know that sometimes when migrating my tests from a main.cpp I forget to 
change them, just cut-n-paste syndrome...


probably ok to change to cppunit assert if it looks like something i've 
touched.

On Sun, 7 Sep 2003, Patrick Hartling wrote:

> Is there any reason that some tests in the GMTL test suite use assert() 
> instead of the CPPUNIT_ASSERT() macro?  The best reason I can think of 
> is to try to force the person running the test to fix the failure.  Is 
> that the case here?
> 
>   -Patrick
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] Bug in matrix state code

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

Well, unsurprisingly, I misdiagnosed this problem.  The data flow is 
rather difficult to explain.  There are a lot of matrices in this code, 
and I got confused tracing through how they all work together.  The 
matrix I mentioned in the previous message is not the one causing the 
problem, though it is being used every frame in the calculation of the 
matrix that is causing problems.

After further testing, I am convinced that there is a problem of some 
form in gmtl::invertAffine() that causes an error to accumulate over 
time.  If I comment out the use of gmtl::invertAffine() in 
gmtl::invert() (lines 564-566 in MatrixOps.h), the bug goes away.  This 
behavior is repeatable in a super simple test case, but the epsilon 
value used for an equality test has to be quite small.  The values in 
the matrices also have to be floating point--the current tests use integers.

I'm still not sure why the error accumulates so quickly in my code 
(within 30 frames, the matrices turn to junk), though it could be the 
cumulative effect of many matrix operations per frame.  A more 
complicated test case may cause the problem to be exhibited more 
effectively.

For the time being, I am inclined to comment out the use of 
gmtl::invertAffine().  This seems like a pretty serious problem since 
gmtl::invert() is a common operation.

  -Patrick

Patrick Hartling wrote:
> I think that there is a bug in the code that does optimizations for 
> matrix operations based on the matrix state.  Unfortunately, I don't 
> know the GMTL code (or math in general) well enough to track down the 
> bug.  I can describe the symptoms, however, with the hope that someone 
> can give me a suggestion on how to do further debugging.
> 
> Basically, what happens is the values of an affine matrix approach zero 
> after it is inverted.  Eventually, they reach zero, and my application 
> crashes.  (The application was not written by me, and the math in it is 
> way beyond me.)  What is particularly vexing is that the single 
> inversion appears to be the only place in the code where the matrix is 
> modified, but somehow its values change constantly after that point.  I 
> must be missing something--I just haven't figured out what.
> 
> In any event, if I back out the only changes to Generate.h, Matrix.h, 
> and MatrixOps.h to remove the state tracking optimizations, the code 
> starts working again without any problems.  I'm guessing that the 
> problem is in gmtl::invertAffine() since it was added as part of the 
> optimization code.  Perhaps there is something in that function that 
> causes additive round-off errors?
> 
> The specific revisions in question are the following:
> 
>    Generate.h: 1.73
>    Matrix.h: 1.28
>    MatrixOps.h: 1.31
> 
> I would appreciate any suggestions on how to track down this problem or 
> any suggested fixes (short of backing out the optimizations altogether).
> 
>  -Patrick
> 
> 


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

[ggt-devel] CPPUNIT_ASSERT() vs. assert()

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

Is there any reason that some tests in the GMTL test suite use assert() 
instead of the CPPUNIT_ASSERT() macro?  The best reason I can think of 
is to try to force the person running the test to fix the failure.  Is 
that the case here?

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

[ggt-devel] Bug in matrix state code

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

I think that there is a bug in the code that does optimizations for 
matrix operations based on the matrix state.  Unfortunately, I don't 
know the GMTL code (or math in general) well enough to track down the 
bug.  I can describe the symptoms, however, with the hope that someone 
can give me a suggestion on how to do further debugging.

Basically, what happens is the values of an affine matrix approach zero 
after it is inverted.  Eventually, they reach zero, and my application 
crashes.  (The application was not written by me, and the math in it is 
way beyond me.)  What is particularly vexing is that the single 
inversion appears to be the only place in the code where the matrix is 
modified, but somehow its values change constantly after that point.  I 
must be missing something--I just haven't figured out what.

In any event, if I back out the only changes to Generate.h, Matrix.h, 
and MatrixOps.h to remove the state tracking optimizations, the code 
starts working again without any problems.  I'm guessing that the 
problem is in gmtl::invertAffine() since it was added as part of the 
optimization code.  Perhaps there is something in that function that 
causes additive round-off errors?

The specific revisions in question are the following:

    Generate.h: 1.73
    Matrix.h: 1.28
    MatrixOps.h: 1.31

I would appreciate any suggestions on how to track down this problem or 
any suggested fixes (short of backing out the optimizations altogether).

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

Re: [ggt-devel] Platform Specific Optimization of GMTL

[Kevin M. <ke...@vr...>]

you'll want to compare the compiled result to the compiled result of your 
optimized code.  I'm guessing that even with optimizations the gcc 
compiler wouldn't be able to vectorize automatically what is currently in 
gmtl.  you may have to rearrage the calls in gmtl so that gcc can optimize 
for the vector processor - or you may have to write specific platform 
code.

as usual be sure to test for these features before implementing, so that 
you'll be well informed and write good stuff. :)


kevin

On Sun, 29 Jun 2003, Allen Bierbaum wrote:

> Galen Faidley wrote:
> > I was wondering what the best way to perform platform specific 
> > optimization on GMTL was?  Apple provides a vector library for OS X that 
> > will use the G4 and G5's vector units.  It would be nice if GMTL on OS X 
> > was basically just a wrapper around this library.
> > 
> > Thanks
> > Galen
> 
> If you want to contribute some code that can allow for OSX 
> optimizations, we are more then happy to take them.
> 
> That said, we have tried to keep GMTL as platform neutral as possible 
> and we rely upon the compilers to be smart enough to help out when 
> optimizing the code.  So if Apple has contributed optimizers to gcc to 
> help make use of their hardware, you may already be getting the benefit 
> of it.
> 
> -Allen
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] Platform Specific Optimization of GMTL

[Kevin M. <ke...@vr...>]

if you reimplemented parts of gmtl in terms of those vector units, then 
you could put ifdefs for MAC or something in gmtl to include your files 
instead.
you'll know if you have a successful implementation if the test suite 
compiles and runs.

if we get enough impls, then maybe we'd have a directory for each version, 
and reference directory, a mac, an intel, etc...

good luck.  anyone want to do an SSE2 version?  at least unrol the loops?


kevin

On Sun, 29 Jun 2003, Galen Faidley wrote:

> I was wondering what the best way to perform platform specific 
> optimization on GMTL was?  Apple provides a vector library for OS X 
> that will use the G4 and G5's vector units.  It would be nice if GMTL 
> on OS X was basically just a wrapper around this library.
> 
> Thanks
> Galen
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\            

Re: [ggt-devel] Platform Specific Optimization of GMTL

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

Galen Faidley wrote:
> I was wondering what the best way to perform platform specific 
> optimization on GMTL was?  Apple provides a vector library for OS X that 
> will use the G4 and G5's vector units.  It would be nice if GMTL on OS X 
> was basically just a wrapper around this library.
> 
> Thanks
> Galen

If you want to contribute some code that can allow for OSX 
optimizations, we are more then happy to take them.

That said, we have tried to keep GMTL as platform neutral as possible 
and we rely upon the compilers to be smart enough to help out when 
optimizing the code.  So if Apple has contributed optimizers to gcc to 
help make use of their hardware, you may already be getting the benefit 
of it.

-Allen

-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

[ggt-devel] Platform Specific Optimization of GMTL

[Galen F. <gfa...@ia...>]

I was wondering what the best way to perform platform specific 
optimization on GMTL was?  Apple provides a vector library for OS X 
that will use the G4 and G5's vector units.  It would be nice if GMTL 
on OS X was basically just a wrapper around this library.

Thanks
Galen

[ggt-devel] Re: GMTL question about LGPL license

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

Roy Dennington wrote:
> Allen,
> 
> 
>>I believe we should be able to deal with it by adding an addendum to the
>>current license.  Since this is an issue that other libraries have had
>>to deal with, has anyone else seen a modified LGPL that explicitly
>>allows for use of inline code?
> 
> 
> Thanks for a quick reply. Does this mean you and the other
> Authors intend to allow commercial use for software that
> Qualifies as a "Work that Uses the Library"?

I believe that all the developers would agree that we want to allow gmtl 
to be used in commercial applications.

The main reason we used the LGPL is because we are familiar with it and 
it places a copy-left restriction on the code.

I have no problem with people using the code in commercial application, 
but I would like to require anyone using it to contribute changes back 
to the community.

> I cannot find a modified LGPL License that specifically
> addresses a Template-based Library with extensive inlining.
> I was able to find several examples of licenses modifying LGPL
> to allow static linking that loosen the restrictions on binaries.
> 
> The problem with LGPL in this context is that it is
> Impossible to qualify as a "Work that Uses the Library"
> Because of the inlining. Further, it is impossible to
> Comply with Section 6a which requires allowing users
> To re-link with object code. (LGPL works best for libraries
> That can be compiled into separate shared libs.)

Agreed.  This is definitely an area that is not covered well by the 
LGPL.  It becomes very difficult to legally separate what is a derived 
work of the library code and what is the application code.

I will look at the licenses below and see if I can find anything we can use.

One other library I would like to look at is the standard C++ library 
that is included with g++.  It seems like the template libraries in that 
code would suffer from the same issues.

-Allen

> Thanks,
> Roy
> 
> Here are a few examples of software that uses modified LGPL:
> 
> http://www.opensource.org/licenses/wxwindows.php
> 
> http://www.fltk.org/COPYING.php
> 
> 
> And,	http://qwt.sourceforge.net
> [I couldn't find the license online]
> 
>                              Qwt License
>                            Version 1.0, January 1, 2003
> 
> The Qwt library and included programs are provided under the terms
> of the GNU LESSER GENERAL PUBLIC LICENSE (LGPL) with the following
> exceptions:
> 
>     1. Widgets that are subclassed from Qwt widgets do not
>        constitute a derivative work.
> 
>     2. Static linking of applications and widgets to the
>        Qwt library does not constitute a derivative work
>        and does not require the author to provide source
>        code for the application or widget, use the shared
>        Qwt libraries, or link their applications or
>        widgets against a user-supplied version of Qwt.
>   
>        If you link the application or widget to a modified
>        version of Qwt, then the changes to Qwt must be 
>        provided under the terms of the LGPL in sections
>        1, 2, and 4.
>   
>     3. You do not have to provide a copy of the Qwt license
>        with programs that are linked to the Qwt library, nor
>        do you have to identify the Qwt license in your
>        program or documentation as required by section 6
>        of the LGPL.
> 
> 
>        However, programs must still identify their use of Qwt.
>        The following example statement can be included in user
>        documentation to satisfy this requirement:
> 
>            [program/widget] is based in part on the work of
>            the Qwt project (http://qwt.sf.net).
> 
> -----------------------------------------------------------------------
> 
> 
> 		  GNU LESSER GENERAL PUBLIC LICENSE
> 		       Version 2.1, February 1999
> 
> [... LGPL text snipped]
> 
> 


-- 
-- Allen Bierbaum                         al...@vr...
-- PhD Candidate             txtmsg - 515...@us...
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu

[ggt-devel] [Task #57262] Track Matrix State, and Optimize code to it.

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

Task #57262 has been updated. 

Project: Generic Graphics Toolkit
Subproject: GMTL
Summary: Track Matrix State, and Optimize code to it.
Complete: 55%
Status: Open
Authority  : subatomic
Assigned to: subatomic, nonchocoboy, jahare, aronb, allenb

Description: We can enable optimizations for matrix operations when the matrix contains some known transform.  This needs to be enabled, implemented to increase the performance of GMTL.

Follow-Ups:

-------------------------------------------------------
Date: 2003-06-01 23:29
By: subatomic

Comment:
it is there, and invert now uses it, 

Next we need to add optimization for op= and perhaps some others.



-------------------------------------------------------
For more info, visit:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=57262&group_id=43735&group_project_id=16299

Re: [ggt-devel] Xforms and HP UX

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

Well, looking at the code, I don't quite see how any compiler is able to 
figure out which instantiation of gmtl::xform() is supposed to be 
used--unless the compilers are relying on the ordering of the function 
declarations.

Is it possible for you to try a newer version of GMTL?  I see on the 
SourceForge project page, version 0.2.1 is the latest download.  It may 
be that this problem was fixed with a newer version.  I know that I did 
some reordering of functions to fix errors with more strict compilers 
(e.g., GCC 3.4).

If trying a different version of GMTL is not an option for you, have you 
tried modifying the code to help out aCC?  It looks as though some manual 
disambiguation is necessary.  My guess is that if you change line 236 of 
Xforms.h to the following:

    return xform<DATA_TYPE, ROWS, COLS>(temporary, matrix, point);

you'll be able to get it to compile with aCC.

  -Patrick

jue...@gm... wrote:
> Hi,
> 
> there was a mistake on my side:
> We're using
>   aCC "HP ANSI C++ B3910B A.03.27" on HP UX, where the Xforms problem
> appears.
> It works fine with
>   "gcc 2.95.2" on Sun
>   "gcc 3.2.2" on Linux
>   "MIPSpro Compiler 7.3.1.2m" on IRIX.
> 
> The gmtl version is 0.1.13.
> 
>   -Juergen
> 



-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

Re: [ggt-devel] Xforms and HP UX

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

Which version of GMTL are you using?  The line numbers don't match your 
description in the latest CVS Xforms.h.  Also, what compilers are you 
using on IRIX and Linux?  I'm rather surprised that GCC 2.95.x can 
handle GMTL at all.

  -Patrick

jue...@gm... wrote:
> Hi everybody,
> 
> I have a problem with using the gmtl on HP UX. The compiler (gcc-2.95.2)
> cannot decide which of the two xform template functions (Xforms.h line 213 and
> line 249) should be used for the xform call (line 236).
> There are no problems compiling the same code on IRIX or LINUX.
> The compiler output is:
> 
> 
>>Error 225: "../../3rdparty/gmtl/include/gmtl/Xforms.h", line 236 #
> 
> Ambiguous overloaded function call;
> 
>>more than one acceptable function found. Two such functions that matched
> 
> were
> 
>>"gmtl::Point<float,(unsigned int)4> &gmtl::xform<float,(unsigned
> 
> int)4,(unsigned
> 
>>int)4>(gmtl::Point<float,(unsigned int)4> &,const
> 
> gmtl::Matrix<float,(unsigned int)4,(unsigned
> 
>>int)4> &,const gmtl::Point<float,(unsigned int)4> &)"
> 
> ["../../3rdparty/gmtl/include/gmtl/Xforms.h", line 213]
> 
>>and
>>"gmtl::Point<float,(unsigned int)4> &gmtl::xform<float,(unsigned
> 
> int)4,(unsigned int)4,(unsigned
> 
>>int)4>(gmtl::Point<float,(unsigned int)4> &,const
> 
> gmtl::Matrix<float,(unsigned int)4,(unsigned
> 
>>int)4> &,const gmtl::Point<float,(unsigned int)4> &)"
> 
> ["../../3rdparty/gmtl/include/gmtl/Xforms.h", line 249].
> 
>>         return xform( temporary, matrix, point );
>>                  ^^^^^
> 
> 
> Thanks,
>   Juergen.
> 


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

[ggt-devel] Xforms and HP UX

[<jue...@gm...>]

Hi everybody,

I have a problem with using the gmtl on HP UX. The compiler (gcc-2.95.2)
cannot decide which of the two xform template functions (Xforms.h line 213 and
line 249) should be used for the xform call (line 236).
There are no problems compiling the same code on IRIX or LINUX.
The compiler output is:

> Error 225: "../../3rdparty/gmtl/include/gmtl/Xforms.h", line 236 #
Ambiguous overloaded function call;
> more than one acceptable function found. Two such functions that matched
were
>
> "gmtl::Point<float,(unsigned int)4> &gmtl::xform<float,(unsigned
int)4,(unsigned
> int)4>(gmtl::Point<float,(unsigned int)4> &,const
gmtl::Matrix<float,(unsigned int)4,(unsigned
> int)4> &,const gmtl::Point<float,(unsigned int)4> &)"
["../../3rdparty/gmtl/include/gmtl/Xforms.h", line 213]
> and
> "gmtl::Point<float,(unsigned int)4> &gmtl::xform<float,(unsigned
int)4,(unsigned int)4,(unsigned
> int)4>(gmtl::Point<float,(unsigned int)4> &,const
gmtl::Matrix<float,(unsigned int)4,(unsigned
> int)4> &,const gmtl::Point<float,(unsigned int)4> &)"
["../../3rdparty/gmtl/include/gmtl/Xforms.h", line 249].
>
>          return xform( temporary, matrix, point );
>                   ^^^^^

Thanks,
  Juergen.

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

Re: [ggt-devel] Import of Python bindings for GMTL

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

Okay, Ben got a build process in place for the GMTL Python bindings, so I 
have removed all the GMTL-related code from PyJuggler.  I don't know if 
PyGMTL has been tested in its new home, but I presume that will happen 
shortly if it has not already.

Since the use of GMTL from Python has changed from this:

    from PyJuggler import gmtl

to this:

    import gmtl

I incremented the PyJuggler version number to 0.5.0.  I presume that 
PyGMTL will have its own version number now, probably starting at 0.1.0.

In any event, there is no longer a need for the "freeze" on the PyGMTL I 
requested yesterday.  Feel free to hack away.  :)

  -Patrick

Patrick Hartling wrote:
> At Ben's request, I have imported the current version of the Python 
> bindings for GMTL (which I propose to call PyGMTL or "pig metal").  
> These come straight from PyJuggler as of today.  Right now, there is no 
> way to compile the code, but Ben has volunteered to write a build 
> process.  Once that is done, I'll remove all the GMTL-related code from 
> PyJuggler and update its build to depend on an installed version of 
> PyGMTL.  Until that time, however, I would appreciate it if no one made 
> any changes to the code currently in GGT/modules/GMTL/python.  Any 
> commits will take the modified file(s) off the vendor branch.  If that 
> happens and I need to import a newer version of the bindings code from 
> PyJuggler, it will be a pain to do so.
> 
>  -Patrick
> 
> 



-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

[ggt-devel] Import of Python bindings for GMTL

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

At Ben's request, I have imported the current version of the Python 
bindings for GMTL (which I propose to call PyGMTL or "pig metal").  These 
come straight from PyJuggler as of today.  Right now, there is no way to 
compile the code, but Ben has volunteered to write a build process.  Once 
that is done, I'll remove all the GMTL-related code from PyJuggler and 
update its build to depend on an installed version of PyGMTL.  Until that 
time, however, I would appreciate it if no one made any changes to the 
code currently in GGT/modules/GMTL/python.  Any commits will take the 
modified file(s) off the vendor branch.  If that happens and I need to 
import a newer version of the bindings code from PyJuggler, it will be a 
pain to do so.

  -Patrick


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@vr...                | 2624 Howe Hall: 1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/

Re: [ggt-devel] 2 pi

[Ben S. <bs...@ia...>]

Works for me. I'd prefer the TWO_PI option.

cheers,
-ben

Justin Hare wrote:
> Would there be any objections to adding another pi-related constant to 
> gmtl/Math.h? We've got PI, PI_OVER_2, and PI_OVER_4 already. 
> 
> But (2 * PI) comes up quite a bit in calculations and I wanted to add it
> as PI_TIMES_2 or TWO_PI.
> 
> justin
> 
> -----------------------------------------
> Justin Hare  <ja...@vr...>
> Virtual Reality Applications Center
> Iowa State University, Howe Hall
> http://www.vrac.iastate.edu/~jahare
> -----------------------------------------
> 
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

Re: [ggt-devel] 2 pi

[Kevin M. <ke...@vr...>]

sounds good.


On Thu, 15 May 2003, Justin Hare wrote:

> Would there be any objections to adding another pi-related constant to 
> gmtl/Math.h? We've got PI, PI_OVER_2, and PI_OVER_4 already. 
> 
> But (2 * PI) comes up quite a bit in calculations and I wanted to add it
> as PI_TIMES_2 or TWO_PI.
> 
> justin
> 
> -----------------------------------------
> Justin Hare  <ja...@vr...>
> Virtual Reality Applications Center
> Iowa State University, Howe Hall
> http://www.vrac.iastate.edu/~jahare
> -----------------------------------------
> 
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.edu/~kevin           \        / 
music - http://subatomic.vrsource.org          \/  __    \/
                                                   \__     
                                            \_\