ggt-devel — Development discussion list

Re: [ggt-devel] Sphere emptiness

[Sebastian M. <seb...@gm...>]

Kevin,

> Got it.
>
> Perhaps a better term would be mExists, or mPositionless, or mUndefined.
>
> Empty implies volume, which 0 could be mistaken for emptiness.
mEmpty was the term that was used in the box, so I'd vote for sticking 
to it for the sake of readability.
Of course it doesn't make much sense, as there is no such thing as an 
empty volume.
>
> I also would look at the higher level sub system expanding volumes and
> ask why uninitialized ones are even in the list. Leads to the question
> whether it might be more appropriate to do that bookkeeping outside of
> the math system
That is right. But in order to do so, It really helps to have the member ;-)
>
> Doing conditional checks tends to slow down processing, I always prefer
> keeping a list of what needs work, and blasting through that list (or
> memory coherent array preferably) without any conditionals. My
> preference would be for math code that blazes (avoiding branches) and
> keep conditionals to the higher level...
Looking at the code, there are no checks inside the gmtl functions that 
use the mEmpty property directly. So no harm done just adding the member.
I totally agree that runtime checking should be done outside the core 
functionality. The only arguable option might be an ASSERT, since 
merging an "empty" sphere is not valid operation.


cheers
Sebastian
>
> Sent from my Phone
> From: Paul Martz
> Sent: 10/24/2012 1:31 PM
> To: ggt...@li...
> Subject: Re: [ggt-devel] Sphere emptiness
>
>
> On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote:
>> Hello Kevin,
>>> What does it mean to have an empty sphere? Or aabox for that matter. Is
>>> it same as sphere volume == 0. Or is it a flag to signify something
>>> else (I.e. No objects contained in).
>>>
>>> if vol == 0 then why not set the size to 0... If it is so you can
>>> remember previous size, why distinguish 0 volume, why not and an N
>>> volume switch... Why a switch at all...
>>>
>>> Excuse me for not knowing/remembering the purpose of mEmpty...
>> Imagine you have BoundingVolume (Doesn't matter if it is a box or
>> sphere) that is default initialized.
>> Now if you use this object to extend an existing volume it will expand
>> it in a wrong way.
>> Since an empty sphere (i.e. radius == 0.0) still has an position it will
>> expand the volume to be extended incorrectly.
>> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty
>> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of
>> pos(5.5,0,0) radius = 6, which is wrong)
>> The main purposes of the empty flag is to ignore those primitives and to
>> check if it was initialized.
> Good summary. Also, an mEmpty member variable will differentiate between a
> sphere that contains nothing (uninitialized), and a sphere that
> contains exactly
> one point. Radius == 0 alone doesn't provide this functionality.
>
> As I mentioned previously, I could use a negative radius to indicate an empty
> sphere. But, we could also have AABox use mMax < mMin to indicate an empty box,
> and we don't -- instead we have AABox::mEmpty, and code to respect the setting
> of that variable in Containment.h. I think, for consistency, Sphere should be
> the same way.
>
> I'll proceed with the code change, if no one objects.
>      -Paul
>
>> Your approach testing the volume might work in this case, but it is
>> surely not a general solution.
>> So I vote for Paul's approach.
>>
>> cheers
>> Sebastian
>>
>> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>>> Thanks,
>>>
>>> Sent from my Phone
>>> From: Paul Martz
>>> Sent: 10/23/2012 5:15 PM
>>> To: ggt...@li...
>>> Subject: [ggt-devel] Sphere emptiness
>>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
>>> bounding volumes.
>>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
>>> present in AABox. Is there a reason for this? If not, I'd like to add it.
>>>
>>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
>>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
>>> add new extendVolume() functions to extend Sphere around an AABox and
>>> vice versa.
>>>
>>> Just wanted to see if there was a logical reason for the current
>>> design before I
>>> embarked on changing the code. I know that I can emulate the desired behavior
>>> with a negative radius, but it seems to me it would be desirable to have this
>>> functionality in gmtl rather than only in my project.
>>>
>>> Thanks,
>>>        -Paul
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

Re: [ggt-devel] Sphere emptiness

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

Got it.

Perhaps a better term would be mExists, or mPositionless, or mUndefined.

Empty implies volume, which 0 could be mistaken for emptiness.

I also would look at the higher level sub system expanding volumes and
ask why uninitialized ones are even in the list. Leads to the question
whether it might be more appropriate to do that bookkeeping outside of
the math system

Doing conditional checks tends to slow down processing, I always prefer
keeping a list of what needs work, and blasting through that list (or
memory coherent array preferably) without any conditionals. My
preference would be for math code that blazes (avoiding branches) and
keep conditionals to the higher level...

Sent from my Phone
From: Paul Martz
Sent: 10/24/2012 1:31 PM
To: ggt...@li...
Subject: Re: [ggt-devel] Sphere emptiness


On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote:
> Hello Kevin,
>> What does it mean to have an empty sphere? Or aabox for that matter. Is
>> it same as sphere volume == 0. Or is it a flag to signify something
>> else (I.e. No objects contained in).
>>
>> if vol == 0 then why not set the size to 0... If it is so you can
>> remember previous size, why distinguish 0 volume, why not and an N
>> volume switch... Why a switch at all...
>>
>> Excuse me for not knowing/remembering the purpose of mEmpty...
>
> Imagine you have BoundingVolume (Doesn't matter if it is a box or
> sphere) that is default initialized.
> Now if you use this object to extend an existing volume it will expand
> it in a wrong way.
> Since an empty sphere (i.e. radius == 0.0) still has an position it will
> expand the volume to be extended incorrectly.
> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty
> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of
> pos(5.5,0,0) radius = 6, which is wrong)
> The main purposes of the empty flag is to ignore those primitives and to
> check if it was initialized.

Good summary. Also, an mEmpty member variable will differentiate between a
sphere that contains nothing (uninitialized), and a sphere that
contains exactly
one point. Radius == 0 alone doesn't provide this functionality.

As I mentioned previously, I could use a negative radius to indicate an empty
sphere. But, we could also have AABox use mMax < mMin to indicate an empty box,
and we don't -- instead we have AABox::mEmpty, and code to respect the setting
of that variable in Containment.h. I think, for consistency, Sphere should be
the same way.

I'll proceed with the code change, if no one objects.
    -Paul

>
> Your approach testing the volume might work in this case, but it is
> surely not a general solution.
> So I vote for Paul's approach.
>
> cheers
> Sebastian
>
> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>>
>> Thanks,
>>
>> Sent from my Phone
>> From: Paul Martz
>> Sent: 10/23/2012 5:15 PM
>> To: ggt...@li...
>> Subject: [ggt-devel] Sphere emptiness
>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
>> bounding volumes.
>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
>> present in AABox. Is there a reason for this? If not, I'd like to add it.
>>
>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
>> add new extendVolume() functions to extend Sphere around an AABox and
>> vice versa.
>>
>> Just wanted to see if there was a logical reason for the current
>> design before I
>> embarked on changing the code. I know that I can emulate the desired behavior
>> with a negative radius, but it seems to me it would be desirable to have this
>> functionality in gmtl rather than only in my project.
>>
>> Thanks,
>>       -Paul
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
ggt-devel mailing list
ggt...@li...
https://lists.sourceforge.net/lists/listinfo/ggt-devel

Re: [ggt-devel] Sphere emptiness

[Paul M. <pm...@sk...>]

On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote:
> Hello Kevin,
>> What does it mean to have an empty sphere? Or aabox for that matter. Is
>> it same as sphere volume == 0. Or is it a flag to signify something
>> else (I.e. No objects contained in).
>>
>> if vol == 0 then why not set the size to 0... If it is so you can
>> remember previous size, why distinguish 0 volume, why not and an N
>> volume switch... Why a switch at all...
>>
>> Excuse me for not knowing/remembering the purpose of mEmpty...
>
> Imagine you have BoundingVolume (Doesn't matter if it is a box or
> sphere) that is default initialized.
> Now if you use this object to extend an existing volume it will expand
> it in a wrong way.
> Since an empty sphere (i.e. radius == 0.0) still has an position it will
> expand the volume to be extended incorrectly.
> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty
> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of
> pos(5.5,0,0) radius = 6, which is wrong)
> The main purposes of the empty flag is to ignore those primitives and to
> check if it was initialized.

Good summary. Also, an mEmpty member variable will differentiate between a 
sphere that contains nothing (uninitialized), and a sphere that contains exactly 
one point. Radius == 0 alone doesn't provide this functionality.

As I mentioned previously, I could use a negative radius to indicate an empty 
sphere. But, we could also have AABox use mMax < mMin to indicate an empty box, 
and we don't -- instead we have AABox::mEmpty, and code to respect the setting 
of that variable in Containment.h. I think, for consistency, Sphere should be 
the same way.

I'll proceed with the code change, if no one objects.
    -Paul

>
> Your approach testing the volume might work in this case, but it is
> surely not a general solution.
> So I vote for Paul's approach.
>
> cheers
> Sebastian
>
> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>>
>> Thanks,
>>
>> Sent from my Phone
>> From: Paul Martz
>> Sent: 10/23/2012 5:15 PM
>> To: ggt...@li...
>> Subject: [ggt-devel] Sphere emptiness
>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
>> bounding volumes.
>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
>> present in AABox. Is there a reason for this? If not, I'd like to add it.
>>
>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
>> add new extendVolume() functions to extend Sphere around an AABox and
>> vice versa.
>>
>> Just wanted to see if there was a logical reason for the current
>> design before I
>> embarked on changing the code. I know that I can emulate the desired behavior
>> with a negative radius, but it seems to me it would be desirable to have this
>> functionality in gmtl rather than only in my project.
>>
>> Thanks,
>>       -Paul
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>

Re: [ggt-devel] Sphere emptiness

[Sebastian M. <seb...@gm...>]

Hello Kevin,
> What does it mean to have an empty sphere? Or aabox for that matter. Is
> it same as sphere volume == 0. Or is it a flag to signify something
> else (I.e. No objects contained in).
>
> if vol == 0 then why not set the size to 0... If it is so you can
> remember previous size, why distinguish 0 volume, why not and an N
> volume switch... Why a switch at all...
>
> Excuse me for not knowing/remembering the purpose of mEmpty...

Imagine you have BoundingVolume (Doesn't matter if it is a box or 
sphere) that is default initialized.
Now if you use this object to extend an existing volume it will expand 
it in a wrong way.
Since an empty sphere (i.e. radius == 0.0) still has an position it will 
expand the volume to be extended incorrectly.
(For example you have sphere1 with pos(10,0,0) and r = 1 and an empty 
sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of 
pos(5.5,0,0) radius = 6, which is wrong)
The main purposes of the empty flag is to ignore those primitives and to 
check if it was initialized.

Your approach testing the volume might work in this case, but it is 
surely not a general solution.
So I vote for Paul's approach.

cheers
Sebastian

P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>
> Thanks,
>
> Sent from my Phone
> From: Paul Martz
> Sent: 10/23/2012 5:15 PM
> To: ggt...@li...
> Subject: [ggt-devel] Sphere emptiness
> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
> bounding volumes.
> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
> present in AABox. Is there a reason for this? If not, I'd like to add it.
>
> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
> add new extendVolume() functions to extend Sphere around an AABox and
> vice versa.
>
> Just wanted to see if there was a logical reason for the current
> design before I
> embarked on changing the code. I know that I can emulate the desired behavior
> with a negative radius, but it seems to me it would be desirable to have this
> functionality in gmtl rather than only in my project.
>
> Thanks,
>      -Paul
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

Re: [ggt-devel] Sphere emptiness

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

What does it mean to have an empty sphere? Or aabox for that matter. Is
it same as sphere volume == 0. Or is it a flag to signify something
else (I.e. No objects contained in).

if vol == 0 then why not set the size to 0... If it is so you can
remember previous size, why distinguish 0 volume, why not and an N
volume switch... Why a switch at all...

Excuse me for not knowing/remembering the purpose of mEmpty...

Thanks,

Sent from my Phone
From: Paul Martz
Sent: 10/23/2012 5:15 PM
To: ggt...@li...
Subject: [ggt-devel] Sphere emptiness
Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
bounding volumes.
But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
present in AABox. Is there a reason for this? If not, I'd like to add it.

I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
add new extendVolume() functions to extend Sphere around an AABox and
vice versa.

Just wanted to see if there was a logical reason for the current
design before I
embarked on changing the code. I know that I can emulate the desired behavior
with a negative radius, but it seems to me it would be desirable to have this
functionality in gmtl rather than only in my project.

Thanks,
    -Paul




------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
ggt-devel mailing list
ggt...@li...
https://lists.sourceforge.net/lists/listinfo/ggt-devel

[ggt-devel] Sphere emptiness

[Paul M. <pm...@sk...>]

Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as bounding volumes. 
But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is 
present in AABox. Is there a reason for this? If not, I'd like to add it.

I would also modify Containment.h's extendVolume(Sphere&,...) to respect that 
variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also 
add new extendVolume() functions to extend Sphere around an AABox and vice versa.

Just wanted to see if there was a logical reason for the current design before I 
embarked on changing the code. I know that I can emulate the desired behavior 
with a negative radius, but it seems to me it would be desirable to have this 
functionality in gmtl rather than only in my project.

Thanks,
    -Paul

Re: [ggt-devel] Support for OpenGL uniform types

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

Test reply. Please ignore.

Doug

On Sep 14, 2012, at 2:26 PM, Paul Martz wrote:

> Hi -- I've been working on a project with a GMTL-based wrapper for OpenGL uniforms. Attached, please find a patch that adds some new Point and Matrix typedefs that make GMTL types more closely match OpenGL uniform types. Thanks!
> 
> 
> -- 
>  -Paul Martz      Skew Matrix Software
>                   http://www.skew-matrix.com/
> <uniformsupport.patch>------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html_______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

[ggt-devel] Patch for makeTrans() in Generate.h

[Kevin G. <go...@gm...>]

Hello.

I've attached a patch for Generate.h.  The makeTrans() function is
being called (from setLookAt(), line 753) before it is defined (line
1389).

This patch just moves the definition of makeTrans() above the
definition of setLookAt().

--Kevin Godby

[ggt-devel] Support for OpenGL uniform types

[Paul M. <pm...@sk...>]

Hi -- I've been working on a project with a GMTL-based wrapper for OpenGL 
uniforms. Attached, please find a patch that adds some new Point and Matrix 
typedefs that make GMTL types more closely match OpenGL uniform types. Thanks!


-- 
   -Paul Martz      Skew Matrix Software
                    http://www.skew-matrix.com/

[ggt-devel] Test, please ignore

[Paul M. <pm...@sk...>]

Sorry.

[ggt-devel] GMTL enhancements

[Paul M. <pm...@sk...>]

Hi -- I'm submitting a patch with two enhancements:

  * a new setLookAt() function in Generate.h (implements gluLookAt())
  * a new binary operator^() for Vec3 cross product in VecOps.h

Note that setLookAt() makes use of the new cross product interface. This change 
is based on svn trunk r1277.

Thanks,
    -Paul

[ggt-devel] Request for comments - Interface changes

[Sebastian M. <seb...@gm...>]

Hello,

A while ago (around March 2011) I proposed some controversial changes to 
some of the gmtl functions.
Unfortunately there has been no response to the main issues, so I will 
re-state  my ideas here again:
1.

Issues with the epsilon values used inside some of the functions e.g.
template<typename DEST_TYPE, typename DATA_TYPE>
     inline DEST_TYPE&  setRot( DEST_TYPE&  result, const Vec<DATA_TYPE,
3>&  from, const Vec<DATA_TYPE, 3>&  to )

I've had to change the epsilon here, else the from and to vectors were
considered to be close enough for long distance camera aiming.
To solve this problem in general, I also have proposed a generalized fix
on the bug list. It involves templated type dependent epsilon usage
See Bug id: 3199376



Are there any objections against this approach?


2.

There are still issues with inconsistent interfaces for some of the
intersect functions, some taking an int, some an unsigned int for the numhits:

E.g.

   inline bool intersect( const Sphere<T>&  sphere, const Ray<T>&  ray,
int&  numhits, T&  t0, T&  t1 )

     inline bool intersectVolume( const Sphere<T>&  sphere, const
LineSeg<T>&  ray, int&  numhits, T&  t0, T&  t1 )

     inline bool intersectVolume( const Sphere<T>&  sphere, const Ray<T>&
ray,  int&  numhits, T&  t0, T&  t1 )

     inline bool intersectVolume( const Sphere<T>&  sphere, const Ray<T>&
ray,  int&  numhits, T&  t0, T&  t1 )

Those functions are all taking integers for the numhits ref. Other
intersect functions take unsigned int. I think this is fairly
inconsistent, and bugs me.
The reason I would rather set them all to unsigned int is simple: I have
some template functions that unify and wrap those functions. Right now I
cannot use them for all intersect functions on the trunk-rev,
since type inference will not allow for int/unsigned int mixtures.

So my proposal is to consistently report them via unsigned int.
This might break some code using gmtl, but it still feels like the correct approach.


3.
There has been a submission of mine ( like ages ago) concerning the
Box/LineSeg intersection test.
In my eyes, the early out test should be different to encompass
LineSegments completely behind the box:

Instead of:
      if (tIn<  0.0&&  tOut>  1.0)
I'd rather advocate for:
      if (tIn<  0.0&&  tOut>  DATA_TYPE(1)|| tIn>  DATA_TYPE(1)&&  tOut>
DATA_TYPE(1))

I have been using this piece of code for more than a year now and never 
experienced a problem.
Should the test be rewritten to use the above changes?


cheers
Sebastian

Re: [ggt-devel] Submissions of patches for the GMTL

[Patrick H. <pat...@gm...>]

Sebastian,

Now would be a good time to start the discussion and post patches. If you want to discuss changes that were already committed, that is fine too.

That said, I can't promise that I will have a lot of good feedback. I maintain GMTL mainly because someone has to, not because I am a math superstar. If you can point me at references supporting your ideas, that would help me.

 -Patrick

On Apr 30, 2012, at 3:19 AM, Sebastian Messerschmidt wrote:

> Hi Patrick, 
> 
> Yes the changes are indeed in the trunk.
> So the things left are the proposals which I didn't directly submit in order to discuss them first. 
> Do you think that we'll find the time soon?
> 
> 
>> Hi Patrick,
>> 
>> I've submitted the patches and some posted some questions and proposals in March 2011. 
>> 
>> No I didn't check the trunk, as there was never a reply to the submissions (and some changes really needed discussion I think).
>> The patches included:
>> - Sphere-Sphere intersection
>> - double sided tri-linesegment intersection
>> - a fix in the lineseg-aabb intersection (which was not evaluating correctly for linesegments inside the box or only leaving it IIRC)
>> - closest point to triangle function
>> 
>> I also proposed changes regarding some important points:
>> - epsilon value clarification in setRot (which was skipping small rotations in case of close vectors). The epsilon value should be dependent on the type)
>> - inconsistent interfaces for intersectXXX functions that should all report "numhits" with a consistent type (in order to allow those values inside own templates)
>> - meta programming matrix initialization (effectively making the NxN matrix intialisation nested loops one SSE operation) 
>> 
>> If you want me to, I can create patches against the trunk version and we might open the discussion about the remaining issues again.
>> I really like to see GMTL improved and made future-proof as I simply didn't find anything on the internet that is fast and supports all primitives I need.
>> 
>> Cheers 
>> Sebastian
>> 
>> 
>>> Sebastian,
>>> 
>>> How long ago did you submit your patches? I was confused and thought that an update made to an old bug report a could of weeks ago was the submission to which you were referring. It looks to me like I was getting ready to release GMTL 0.7.0 with patches that you submitted, but I never finished the release. I have no idea what happened, but GMTL tends to be pretty far off my radar most weeks.
>>> 
>>> Have you looked at the SVN trunk to see if it includes your changes? If so, I will just tag and release GMTL 0.7.0. Note that the SVN trunk requires the use of SCons 2.0 or newer.
>>> 
>>>  -Patrick
>>> 
>>> On Apr 23, 2012, at 3:06 AM, Sebastian Messerschmidt wrote:
>>> 
>>>> Hello,
>>>> 
>>>> I've submitted a bunch of patches a while ago.
>>>> Did anyone have the chance to look into them?
>>>> 
>>>> I'm currently remerging my changes against the 0.6.1 version of GMTL and 
>>>> have a strong interest in some of the changes to be added to GMTL.
>>>> 
>>>> cheers
>>>> Sebastian
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> For Developers, A Lot Can Happen In A Second.
>>>> Boundary is the first to Know...and Tell You.
>>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>> --
>>> Patrick L. Hartling
>>> iOS Library Developer, T8 Webware
>>> http://www.t8webware.com/
>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and 
>>> threat landscape has changed and how IT managers can respond. Discussions 
>>> will include endpoint security, mobile security and the latest in malware 
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> 
>>> 
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and 
>> threat landscape has changed and how IT managers can respond. Discussions 
>> will include endpoint security, mobile security and the latest in malware 
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> 
>> 
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

--
Patrick Hartling
iOS Library Developer, T8 Webware

Re: [ggt-devel] Submissions of patches for the GMTL

[Sebastian M. <seb...@gm...>]

Hi Patrick,

Yes the changes are indeed in the trunk.
So the things left are the proposals which I didn't directly submit in 
order to discuss them first.
Do you think that we'll find the time soon?


> Hi Patrick,
>
> I've submitted the patches and some posted some questions and 
> proposals in March 2011.
>
> No I didn't check the trunk, as there was never a reply to the 
> submissions (and some changes really needed discussion I think).
> The patches included:
> - Sphere-Sphere intersection
> - double sided tri-linesegment intersection
> - a fix in the lineseg-aabb intersection (which was not evaluating 
> correctly for linesegments inside the box or only leaving it IIRC)
> - closest point to triangle function
>
> I also proposed changes regarding some important points:
> - epsilon value clarification in setRot (which was skipping small 
> rotations in case of close vectors). The epsilon value should be 
> dependent on the type)
> - inconsistent interfaces for intersectXXX functions that should all 
> report "numhits" with a consistent type (in order to allow those 
> values inside own templates)
> - meta programming matrix initialization (effectively making the NxN 
> matrix intialisation nested loops one SSE operation)
>
> If you want me to, I can create patches against the trunk version and 
> we might open the discussion about the remaining issues again.
> I really like to see GMTL improved and made future-proof as I simply 
> didn't find anything on the internet that is fast and supports all 
> primitives I need.
>
> Cheers
> Sebastian
>
>
>> Sebastian,
>>
>> How long ago did you submit your patches? I was confused and thought that an update made to an old bug report a could of weeks ago was the submission to which you were referring. It looks to me like I was getting ready to release GMTL 0.7.0 with patches that you submitted, but I never finished the release. I have no idea what happened, but GMTL tends to be pretty far off my radar most weeks.
>>
>> Have you looked at the SVN trunk to see if it includes your changes? If so, I will just tag and release GMTL 0.7.0. Note that the SVN trunk requires the use of SCons 2.0 or newer.
>>
>>   -Patrick
>>
>> On Apr 23, 2012, at 3:06 AM, Sebastian Messerschmidt wrote:
>>
>>> Hello,
>>>
>>> I've submitted a bunch of patches a while ago.
>>> Did anyone have the chance to look into them?
>>>
>>> I'm currently remerging my changes against the 0.6.1 version of GMTL and
>>> have a strong interest in some of the changes to be added to GMTL.
>>>
>>> cheers
>>> Sebastian
>>>
>>> ------------------------------------------------------------------------------
>>> For Developers, A Lot Can Happen In A Second.
>>> Boundary is the first to Know...and Tell You.
>>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>>> http://p.sf.net/sfu/Boundary-d2dvs2
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>> --
>> Patrick L. Hartling
>> iOS Library Developer, T8 Webware
>> http://www.t8webware.com/
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>
>>
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

Re: [ggt-devel] Submissions of patches for the GMTL

[Sebastian M. <seb...@gm...>]

Hi Patrick,

I've submitted the patches and some posted some questions and proposals 
in March 2011.

No I didn't check the trunk, as there was never a reply to the 
submissions (and some changes really needed discussion I think).
The patches included:
- Sphere-Sphere intersection
- double sided tri-linesegment intersection
- a fix in the lineseg-aabb intersection (which was not evaluating 
correctly for linesegments inside the box or only leaving it IIRC)
- closest point to triangle function

I also proposed changes regarding some important points:
- epsilon value clarification in setRot (which was skipping small 
rotations in case of close vectors). The epsilon value should be 
dependent on the type)
- inconsistent interfaces for intersectXXX functions that should all 
report "numhits" with a consistent type (in order to allow those values 
inside own templates)
- meta programming matrix initialization (effectively making the NxN 
matrix intialisation nested loops one SSE operation)

If you want me to, I can create patches against the trunk version and we 
might open the discussion about the remaining issues again.
I really like to see GMTL improved and made future-proof as I simply 
didn't find anything on the internet that is fast and supports all 
primitives I need.

Cheers
Sebastian


> Sebastian,
>
> How long ago did you submit your patches? I was confused and thought that an update made to an old bug report a could of weeks ago was the submission to which you were referring. It looks to me like I was getting ready to release GMTL 0.7.0 with patches that you submitted, but I never finished the release. I have no idea what happened, but GMTL tends to be pretty far off my radar most weeks.
>
> Have you looked at the SVN trunk to see if it includes your changes? If so, I will just tag and release GMTL 0.7.0. Note that the SVN trunk requires the use of SCons 2.0 or newer.
>
>   -Patrick
>
> On Apr 23, 2012, at 3:06 AM, Sebastian Messerschmidt wrote:
>
>> Hello,
>>
>> I've submitted a bunch of patches a while ago.
>> Did anyone have the chance to look into them?
>>
>> I'm currently remerging my changes against the 0.6.1 version of GMTL and
>> have a strong interest in some of the changes to be added to GMTL.
>>
>> cheers
>> Sebastian
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
> --
> Patrick L. Hartling
> iOS Library Developer, T8 Webware
> http://www.t8webware.com/
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

Re: [ggt-devel] Submissions of patches for the GMTL

[Patrick H. <pat...@gm...>]

Sebastian,

How long ago did you submit your patches? I was confused and thought that an update made to an old bug report a could of weeks ago was the submission to which you were referring. It looks to me like I was getting ready to release GMTL 0.7.0 with patches that you submitted, but I never finished the release. I have no idea what happened, but GMTL tends to be pretty far off my radar most weeks.

Have you looked at the SVN trunk to see if it includes your changes? If so, I will just tag and release GMTL 0.7.0. Note that the SVN trunk requires the use of SCons 2.0 or newer.

 -Patrick

On Apr 23, 2012, at 3:06 AM, Sebastian Messerschmidt wrote:

> Hello,
> 
> I've submitted a bunch of patches a while ago.
> Did anyone have the chance to look into them?
> 
> I'm currently remerging my changes against the 0.6.1 version of GMTL and 
> have a strong interest in some of the changes to be added to GMTL.
> 
> cheers
> Sebastian
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

--
Patrick L. Hartling
iOS Library Developer, T8 Webware
http://www.t8webware.com/

Re: [ggt-devel] Submissions of patches for the GMTL

[Patrick H. <pat...@gm...>]

Sorry, I haven't had a chance to look at them yet. I will get to it as soon as I can (maybe tonight, definitely before Friday).

 -Patrick

On Apr 23, 2012, at 3:06 AM, Sebastian Messerschmidt wrote:

> Hello,
> 
> I've submitted a bunch of patches a while ago.
> Did anyone have the chance to look into them?
> 
> I'm currently remerging my changes against the 0.6.1 version of GMTL and 
> have a strong interest in some of the changes to be added to GMTL.
> 
> cheers
> Sebastian
> 
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

--
Patrick Hartling
iOS Library Developer, T8 Webware

[ggt-devel] Submissions of patches for the GMTL

[Sebastian M. <seb...@gm...>]

Hello,

I've submitted a bunch of patches a while ago.
Did anyone have the chance to look into them?

I'm currently remerging my changes against the 0.6.1 version of GMTL and 
have a strong interest in some of the changes to be added to GMTL.

cheers
Sebastian

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

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

Bugs item #1523709, was opened at 2006-07-17 00:56
Message generated for change (Comment added) made by nobody
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
Private: No
Submitted By: Neonic (aneonic)
Assigned to: Patrick Hartling (patrickh)
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.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2012-04-03 18:48

Message:
DKVlw5  <a href="http://wzexjpkkcymv.com/">wzexjpkkcymv</a>,
[url=http://udjkbedkruig.com/]udjkbedkruig[/url],
[link=http://offodtvzqpwd.com/]offodtvzqpwd[/link],
http://lxfkgigxsjrw.com/

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

Comment By: Patrick Hartling (patrickh)
Date: 2009-02-13 12:39

Message:
If you could write a test case demonstrating that this change works and
that it does not break any existing test cases, then I will be happy to
commit your change.

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

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

[ggt-devel] [ ggt-Bugs-3187564 ] AABox/AABox sweep intersection is broken?

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

Bugs item #3187564, was opened at 2011-02-20 22:32
Message generated for change (Comment added) made by chenz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3187564&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
Private: No
Submitted By: Christian Henz (chenz)
Assigned to: Nobody/Anonymous (nobody)
Summary: AABox/AABox sweep intersection is broken?

Initial Comment:
I think the AABox/AABox sweep intersection test is broken (Intersection.h, line ~90).

For example it is clear to see that the test will always report an intersection if the relative displacement of the boxes is (0,0,0). The implementation on Gamasutra referenced in the comment has the same problem btw!


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

>Comment By: Christian Henz (chenz)
Date: 2011-04-25 23:25

Message:
I posted a second version of the patch that fixes an incorrect interval
overlap test I introduced in the first patch.


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

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

Re: [ggt-devel] Patch to correct scons usage on windows

[Patrick H. <pat...@gm...>]

On Mar 31, 2011, at 9:54 PM, Doug McCorkle wrote:

> Hello,
> 
> I have attached a patch that corrects the usage of scons on windows.

Your patch was applied as r1277. Thanks for the submission.

 -Patrick


--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/

[ggt-devel] [ ggt-Bugs-3234230 ] AABox/AABox sweep intersection problem

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

Bugs item #3234230, was opened at 2011-03-22 09:12
Message generated for change (Comment added) made by chenz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&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: HEAD
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Patrick Hartling (patrickh)
Summary: AABox/AABox sweep intersection problem

Initial Comment:
Version: GMTL 0.5.2-1 deb

The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero.

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

Comment By: Christian Henz (chenz)
Date: 2011-04-23 17:36

Message:
I have posted a possible fix in my bug report.
http://sourceforge.net/tracker/?func=detail&aid=3187564&group_id=43735&atid=437247


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

Comment By: Patrick Hartling (patrickh)
Date: 2011-03-27 20:32

Message:
Ignore my question. I didn't realize that the bug tracker showed comments
in reverse chronological order. I now understand that the proposed change
was incorrect.

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

Comment By: Patrick Hartling (patrickh)
Date: 2011-03-27 20:31

Message:
The proposed patch causes a test case in the test suite to fail.
Specifically, it breaks
gmtlTest::IntersectionTest::testIntersectAABoxSweep() (see
Test/TestSuite/TestCases/IntersectionTest.cpp). Does that mean that that
test is incorrect or that the patch is incorrect?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2011-03-23 09:24

Message:
Eek!  I just looked at the patch I added and it is _wrong_.  Really wrong. 
Sorry for the noise.  If I come up with a better patch, I'll post it later.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2011-03-23 04:57

Message:
Here's the patch that I am using to correct this problem.  Sorry about the
formatting -- I don't have a Sourceforge account, so I can't attach files.

*** Intersection.h.orig 2011-03-22 20:54:30.198177237 -0700
--- /usr/include/gmtl-0.5.2/gmtl/Intersection.h 2011-03-22
20:54:36.771836476 -0700
***************
*** 152,157 ****
--- 152,161 ----
           {
              overlap1[i] = (box1.getMin()[i] - box2.getMax()[i]) /
path[i];
           }
+          else
+          {
+             return false;
+          }
  
           if ((box2.getMax()[i] > box1.getMin()[i]) && (path[i] <
DATA_TYPE(0)))
           {
***************
*** 161,166 ****
--- 165,174 ----
           {
              overlap2[i] = (box1.getMax()[i] - box2.getMin()[i]) /
path[i];
           }
+          else
+          {
+             return false;
+          }
        }
  
        // Calculate the first time of overlap

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

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

[ggt-devel] [ ggt-Patches-3292037 ] Fix README to point to correct cppunit repository

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

Patches item #3292037, was opened at 2011-04-23 17:32
Message generated for change (Tracker Item Submitted) made by chenz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437249&aid=3292037&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Christian Henz (chenz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix README to point to correct cppunit repository

Initial Comment:
The version of cppunit pointed to in README does not work (it does not include MetricRegistry.h etc.). This patch changes README to point to a version of cppunit that works.


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

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

[ggt-devel] Patch to correct scons usage on windows

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

Hello,

I have attached a patch that corrects the usage of scons on windows.

Doug

[ggt-devel] [ ggt-Patches-3252946 ] Add support for CMake find_package

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

Patches item #3252946, was opened at 2011-03-28 17:27
Message generated for change (Tracker Item Submitted) made by isilmendil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437249&aid=3252946&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Johannes Zarl (isilmendil)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add support for CMake find_package

Initial Comment:
The attached patch allows gmtl to be found from cmake scripts using the cmake find_package command.

New files:
gmtl-config.cmake.in
gmtl-config-version.cmake.in

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

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