ggt-devel — Development discussion list

[ggt-devel] [ ggt-Feature Requests-3102319 ] Add pkg-config support

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

Feature Requests item #3102319, was opened at 2010-11-03 17:39
Message generated for change (Tracker Item Submitted) made by isilmendil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437250&aid=3102319&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 pkg-config support

Initial Comment:
Since flagpoll is rather exotic compared to pkg-config it would be nice to have support for pkg-config as well.
The simplest way to achieve this would be to use the .fpc file and simply install it as .pc file. Only minor modifications to the .fpc are necessary (setting the prefix, not using the "fp_file_cwd" variable).

The attached patch makes the neccessary changes to gmtl.fpc.in and adds a gmtl.pc install target to the Sconscript...

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

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

[ggt-devel] [ ggt-Bugs-3084335 ] The original author should be kept in the header files.

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

Bugs item #3084335, was opened at 2010-10-09 12:06
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3084335&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Patrick Hartling (patrickh)
Summary: The original author should be kept in the header files.

Initial Comment:
You removed the Original Author from the files Frunstum.h and FrustumOps.h. The current copyright notice is misguiding as it appears to sugest that "Allen Bierbaum" ist the author of this source-code - which is not the case. The original Author of those two files is "Benjamin Schulz", who really would appreciate to be mentioned as those ;o) 

best regards
Benjamin Schulz

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

>Comment By: Patrick Hartling (patrickh)
Date: 2010-10-10 10:05

Message:
This was fixed by r1261. I apologize for the error.

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

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

[ggt-devel] [ ggt-Bugs-3084335 ] The original author should be kept in the header files.

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

Bugs item #3084335, was opened at 2010-10-09 17:06
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3084335&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: Nobody/Anonymous (nobody)
Summary: The original author should be kept in the header files.

Initial Comment:
You removed the Original Author from the files Frunstum.h and FrustumOps.h. The current copyright notice is misguiding as it appears to sugest that "Allen Bierbaum" ist the author of this source-code - which is not the case. The original Author of those two files is "Benjamin Schulz", who really would appreciate to be mentioned as those ;o) 

best regards
Benjamin Schulz

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

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

Re: [ggt-devel] Updating the FAQ page

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

Hey Patrick,

Attached is a patch the corrects:

1. The notation used for transforming a vector.
2. Making a matrix from a Point. I do not believe the make function is  
implemented for those data types. The makeTrans function works fine  
though.

Doug

On Sep 17, 2010, at 8:39 AM, Patrick Hartling wrote:

> On Sep 17, 2010, at 8:37 AM, Doug McCorkle wrote:
>
>> Hello,
>>
>> I have some corrections for the information posted on the FAQ page.
>> How are those supposed to be passed along?
>
> The FAQ is a Doxygen document under docs/faq in the source tree. If  
> you have patches to that, just send them to this list.
>
> -Patrick

Re: [ggt-devel] Updating the FAQ page

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

On Sep 17, 2010, at 8:37 AM, Doug McCorkle wrote:

> Hello,
> 
> I have some corrections for the information posted on the FAQ page.
> How are those supposed to be passed along?

The FAQ is a Doxygen document under docs/faq in the source tree. If you have patches to that, just send them to this list.

 -Patrick


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

[ggt-devel] Updating the FAQ page

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

Hello,

I have some corrections for the information posted on the FAQ page.
How are those supposed to be passed along?

Doug

[ggt-devel] Patch to resolve boost namespace collisions

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

Hello,

I have attached a patch that resolves a namespace collision on windows  
when trying to use GMLT MatrixConvert with application code that  
utilizes boost::bind. It appears that boost::bind and  
boost::lamda::bind will conflict if not explicitly used.

Doug

Re: [ggt-devel] Repository migrated to Subversion

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

Those are actually good news, since merging with CVS was a real PITA.
I'm looking forward to send in some more fixes and my adaptors to 
boost::serialization and hashing if anyone is still interested.

cheers
Sebastian
> The GGT repository has finally been changed over to Subversion. The full CVS revision history has been preserved, but the trunk, branches, and tags reflect the fact that this project is really about GMTL. The SGA code and all other unmaintained, unfinished aspects of the GGT source tree have been removed from the trunk. These can always be retrieved from the repository if necessary.
>
> More information is available here:
>
>    http://sourceforge.net/projects/ggt/develop
>
>  -Patrick
>
>
> --
> Patrick L. Hartling
> Senior Software Engineer, Priority 5
> http://www.priority5.com/
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>   

[ggt-devel] Repository migrated to Subversion

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

The GGT repository has finally been changed over to Subversion. The full CVS revision history has been preserved, but the trunk, branches, and tags reflect the fact that this project is really about GMTL. The SGA code and all other unmaintained, unfinished aspects of the GGT source tree have been removed from the trunk. These can always be retrieved from the repository if necessary.

More information is available here:

   http://sourceforge.net/projects/ggt/develop

 -Patrick


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

[ggt-devel] [ ggt-Bugs-2828090 ] error in PlaneOps.h

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

Bugs item #2828090, was opened at 2009-07-27 21:58
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=2828090&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in PlaneOps.h

Initial Comment:
In whichSide with eps 
PlaneSide whichSide ( const Plane<DATA_TYPE>& plane, const Point<DATA_TYPE, 3>& pt, const DATA_TYPE& eps )

instead of    
if ( dist < eps ) return NEG_SIDE;

should be 
if ( dist < -eps ) return NEG_SIDE;

because in this case we have right situation: NEG_SIDE for (-infinity, -eps), ON_PLANE for (-eps, +eps) and POS_SIDE for (+eps, +infinity)

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

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

[ggt-devel] GMTL 0.6.0 released

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

GMTL 0.6.0 has been released. This is primarily a bug fix release relative 
to version 0.5.4. Additionally, the SCons build has been updated to work 
with the latest versions of SCons (up through 1.2.0) and Boost.Python (up 
through 1.38). The source can be downloaded from the following link:

https://sourceforge.net/project/showfiles.php?group_id=43735&package_id=50702&release_id=667228

  -Patrick


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

Re: [ggt-devel] Pending patches

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

On Mar 5, 2009, at 8:50 AM, Sebastian Messerschmidt wrote:

> Patrick Hartling schrieb:
>> Are there any pending GMTL patches remaining to be committed? If  
>> not, then I
>> am going to tag the current code base as GMTL 0.6.0 and make a  
>> release.
>>
>>  -Patrick
>>
>>
>>
> Sorry for the late response, but regarding my patch on the
> Intersection.h, I've introduced some oddity:
>
> in Intersection.h
> <snip>
>   template<typename T>
>   inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray,
> unsigned int& numhits, T& t0, T& t1 )
> </snip>
> around line 550
>
> the numhits = -1 should state numhits = 0
>
> to avoid compilers to barf at higher warning levels.

In the most current version of Intersection.h, that overload of  
intersect has numhits declared as a signed integer rather than as an  
unsigned. Initializing it to -1 is safe in that case.

  -Patrick


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

Re: [ggt-devel] Pending patches

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

Patrick Hartling schrieb:
> Are there any pending GMTL patches remaining to be committed? If not, then I 
> am going to tag the current code base as GMTL 0.6.0 and make a release.
>
>   -Patrick
>
>
>   
Sorry for the late response, but regarding my patch on the 
Intersection.h, I've introduced some oddity:

in Intersection.h
<snip>
   template<typename T>
   inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray, 
unsigned int& numhits, T& t0, T& t1 )
</snip>
around line 550

the numhits = -1 should state numhits = 0

to avoid compilers to barf at higher warning levels.

cheers
Sebastian

[ggt-devel] Pending patches

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

Are there any pending GMTL patches remaining to be committed? If not, then I 
am going to tag the current code base as GMTL 0.6.0 and make a release.

  -Patrick


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

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

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

Bugs item #1523709, was opened at 2006-07-17 02:56
Message generated for change (Comment added) made by patrickh
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: Patrick Hartling (patrickh)
Date: 2009-02-13 14: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-1151637 ] some operator* tweaking

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

Bugs item #1151637, was opened at 2005-02-25 04:00
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1151637&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: trigras (trigras)
>Assigned to: Patrick Hartling (patrickh)
Summary: some operator* tweaking

Initial Comment:
there is a bunch of operator*
maybe they can be replaced with somethink like:

template <typename T, typename DATA_TYPE, unsigned
ROWS, unsigned COLS>
inline T operator*( const Matrix<DATA_TYPE, ROWS,
COLS>& matrix, const T& in)
{
   T temporary;
   return xform( temporary, matrix, in);
}

or even:

template <typename T, typename M>
inline T operator*( const M& matrix, const T& in )
{
   T temporary;
   return xform( temporary, matrix, in );
}


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

>Comment By: Patrick Hartling (patrickh)
Date: 2009-02-13 14:38

Message:
I think that this is worth pursuing, but it will not be as simple as what
you have proposed. The issue is that there are overloads of operator* where
a fundamental type is passed as an argument (such as scalar multiplication
of a vector). Perhaps the solution is to make gmtl::xform() more general
first so that all operator* uses end up getting handed off to an overload
of gmtl::xform(). That is the first thing that comes to mind anyway.

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

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

[ggt-devel] [ ggt-Bugs-1539595 ] error in LineSegOps.h

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

Bugs item #1539595, was opened at 2006-08-13 11:03
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1539595&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: Closed
>Resolution: Fixed
Priority: 9
Private: No
Submitted By: michaln (overeater)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in LineSegOps.h

Initial Comment:
File: gmtl-0.4.11/gmtl/LineSegOps.h

51 template< class DATA_TYPE >
52 Point<DATA_TYPE, 3> findNearestPt( const
LineSeg<DATA_TYPE>& lineseg,
53                                    const
Point<DATA_TYPE, 3>& pt )
54 {
55    // result = origin + dir * dot((pt-origin), dir)
56    return ( lineseg.mOrigin + lineseg.mDir *
57             dot(pt - lineseg.mOrigin, lineseg.mDir) );
58 }

This formula holds only for LineSeg of unit length...
...should be:

56    return ( lineseg.mOrigin + lineseg.mDir *
57             ( dot(pt - lineseg.mOrigin,
lineseg.mDir) / lengthSquared(lineseg.mDir) ) );

Keep up Your good work :)


Michal Nociar, Slovakia

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

>Comment By: Patrick Hartling (patrickh)
Date: 2009-02-13 14:14

Message:
Your change has been applied. Thanks for the bug report!

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

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

Re: [ggt-devel] Patch Intersection.h

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

On Feb 13, 2009, at 10:31 AM, Sebastian Messerschmidt wrote:

> Patrick Hartling schrieb:
>> On Feb 12, 2009, at 3:54 AM, Sebastian Messerschmidt wrote:
>>
>>
>>> Hi,
>>>
>>> as I've written some weeks ago, I've fixed some float/double/
>>> DATA_TYPE issues and  corrected some intersection functions, that
>>> were return false positives.
>>>
>>> The changes in detail:
>>>
>>> Line 318:
>>> Fixed the box / lineseg intersection, which was missing an early out
>>> for the case were the ray hit the box. but the line didn't (some
>>> simple early out test by checking tin,tout between 0 and 1)
>>>
>>
>> This change breaks one of the tests (see
>> gmtlTest::IntersectionTest::testIntersectAABoxLineSeg() at line 199  
>> of
>> Test/TestSuite/TestCases/IntersectionTest.cpp). As far as I can tell,
>> the expectation of the test is correct. Specifically, there is a line
>> segment that starts within the axis-aligned bounding box and ends
>> outside the box. In this case, tIn has a value of -0.5, and tOut is
>> 0.5. Should the test be a logical AND instead of an OR?
>>
>>
> Okay, after rethinking it my intention got obvious again.
> Consider the following setup:
> {
>        // Unit box centered at the origin.
>        gmtl::AABoxf box(gmtl::Point3f(-0.5f, -0.5f, -0.5f),
>            gmtl::Point3f(0.5f, 0.5f, 0.5f));
>        // Unit line segment with its origin on the front edge of the  
> box
>        // and its endpoint on the back edge of the box.
>        gmtl::LineSegf seg(gmtl::Point3f(0.0f, 0.0f, 0.0f),
>            gmtl::Point3f(0.1f, 0.0f, -0.0f));
>        unsigned int num_hits;
>        float t_in, t_out;
>       CPPUNIT_ASSERT(!gmtl::intersect(box, seg, num_hits, t_in,  
> t_out));
>
> }
>
> With the old function, this caused a hit because the segment was  
> inside
> the box with tIn = tOut = 5,
> which in my opinion is wrong, because the line segment never enters or
> leaves the box.
> Do you agree?
> If so, just take the logical AND instead of or, which will do the  
> trick ;-)

Yes, I agree with that. I have added the test you presented and made  
that change. Thanks!

  -Patrick


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

Re: [ggt-devel] Patch Intersection.h

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

Patrick Hartling schrieb:
> On Feb 12, 2009, at 3:54 AM, Sebastian Messerschmidt wrote:
>
>   
>> Hi,
>>
>> as I've written some weeks ago, I've fixed some float/double/  
>> DATA_TYPE issues and  corrected some intersection functions, that  
>> were return false positives.
>>
>> The changes in detail:
>>
>> Line 318:
>> Fixed the box / lineseg intersection, which was missing an early out  
>> for the case were the ray hit the box. but the line didn't (some  
>> simple early out test by checking tin,tout between 0 and 1)
>>     
>
> This change breaks one of the tests (see  
> gmtlTest::IntersectionTest::testIntersectAABoxLineSeg() at line 199 of  
> Test/TestSuite/TestCases/IntersectionTest.cpp). As far as I can tell,  
> the expectation of the test is correct. Specifically, there is a line  
> segment that starts within the axis-aligned bounding box and ends  
> outside the box. In this case, tIn has a value of -0.5, and tOut is  
> 0.5. Should the test be a logical AND instead of an OR?
>
>   
>> Lines 584, 616, 649, 706:
>>
>> changed the declaration of tIN and tOUT parameters consitently to  
>> DATA_TYPE instead of fixed float.
>> addiditionally the numHits were mixed int/unsigned int which I've  
>> corrected to unsigned int everywhere
>>
>> Line 745:
>> Same as above, double/float DATA_TYPE corrections
>>     
>
> These changes have been committed. Thanks very much.
>
>   
>> Here I've corrected the intersection test between plane an ray, that  
>> failed due to missing check in tIn/tOut - range
>>     
>
> This change breaks another test in Test/TestSuite/TestCases/ 
> IntersectionTest.cpp. This one is at line 874 where a plane is  
> constructed with a ray pointing down through it. The test expects that  
> t will be 5. Is the expectation of the test invalid?
>
>   
You're right. As i don't use the function anymore, just skip this for 
now. Seems to be bogus.
But I recall there was a case in which the test failed. If I encounter 
it again, I'll post a patch that complies with the unit tests.

So long ..

>> I've also added the proposed intersectDoubleSided-Test for ray/ 
>> triangle, that ignores the triangle orientation.
>>     
>
>
> This has been committed. Thanks!
>
>   -Patrick
>
>
> --
> Patrick L. Hartling
> Senior Software Engineer, Priority 5
> http://www.priority5.com/
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>   

[ggt-devel] [ ggt-Bugs-1077554 ] gmtl-0.4.5 - conversion from 'const double' to 'float'

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

Bugs item #1077554, was opened at 2004-12-02 06:57
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=1077554&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: trigras (trigras)
Assigned to: Nobody/Anonymous (nobody)
Summary: gmtl-0.4.5 - conversion from 'const double' to 'float'

Initial Comment:
I think there somehow should be introduced DATA_TYPE:

include\gmtl\VecOpsMeta.h(70) : warning C4244: 'return'
: conversion from 'const double' to 'float', possible
loss of data

include\gmtl\VecOpsMeta.h(78) : warning C4244: 'return' : 
conversion from 'const double' to 'float', possible
loss of data

compiler - VC7.1

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

>Comment By: Patrick Hartling (patrickh)
Date: 2009-02-13 10:49

Message:
This was fixed a while ago in Revision 1.3 of gmtl/VecOpsMeta.h.

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

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

[ggt-devel] [ ggt-Bugs-2596445 ] "scons install" fails

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

Bugs item #2596445, was opened at 2009-02-13 10:32
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=2596445&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: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: "scons install" fails

Initial Comment:
When trying to install gmtl via scons following error occurs:
scons: Reading SConscript files ...
AttributeError: 'module' object has no attribute 'options':
  File "/usr/local/share/gmtl-0.5.4/SConstruct", line 30:
    except AttributeError: has_help_flag = SCons.Script.options.help_msg

GMTL version: 0.5.4
SCons version: v1.0.0.r3266

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

>Comment By: Patrick Hartling (patrickh)
Date: 2009-02-13 10:46

Message:
This has been fixed in the CVS HEAD version (soon to be released as GMTL
0.5.5). The fix can be seen here:

http://ggt.cvs.sourceforge.net/viewvc/ggt/GGT/modules/GMTL/SConstruct?r1=1.84&r2=1.85


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

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

[ggt-devel] [ ggt-Bugs-2596445 ] "scons install" fails

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

Bugs item #2596445, was opened at 2009-02-13 16:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=437247&aid=2596445&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: Nobody/Anonymous (nobody)
Summary: "scons install" fails

Initial Comment:
When trying to install gmtl via scons following error occurs:
scons: Reading SConscript files ...
AttributeError: 'module' object has no attribute 'options':
  File "/usr/local/share/gmtl-0.5.4/SConstruct", line 30:
    except AttributeError: has_help_flag = SCons.Script.options.help_msg

GMTL version: 0.5.4
SCons version: v1.0.0.r3266

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

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

Re: [ggt-devel] Patch Intersection.h

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

Patrick Hartling schrieb:
> On Feb 12, 2009, at 3:54 AM, Sebastian Messerschmidt wrote:
>
>   
>> Hi,
>>
>> as I've written some weeks ago, I've fixed some float/double/  
>> DATA_TYPE issues and  corrected some intersection functions, that  
>> were return false positives.
>>
>> The changes in detail:
>>
>> Line 318:
>> Fixed the box / lineseg intersection, which was missing an early out  
>> for the case were the ray hit the box. but the line didn't (some  
>> simple early out test by checking tin,tout between 0 and 1)
>>     
>
> This change breaks one of the tests (see  
> gmtlTest::IntersectionTest::testIntersectAABoxLineSeg() at line 199 of  
> Test/TestSuite/TestCases/IntersectionTest.cpp). As far as I can tell,  
> the expectation of the test is correct. Specifically, there is a line  
> segment that starts within the axis-aligned bounding box and ends  
> outside the box. In this case, tIn has a value of -0.5, and tOut is  
> 0.5. Should the test be a logical AND instead of an OR?
>
>   
Okay, after rethinking it my intention got obvious again.
Consider the following setup:
{
        // Unit box centered at the origin.
        gmtl::AABoxf box(gmtl::Point3f(-0.5f, -0.5f, -0.5f),
            gmtl::Point3f(0.5f, 0.5f, 0.5f));
        // Unit line segment with its origin on the front edge of the box
        // and its endpoint on the back edge of the box.
        gmtl::LineSegf seg(gmtl::Point3f(0.0f, 0.0f, 0.0f),
            gmtl::Point3f(0.1f, 0.0f, -0.0f));
        unsigned int num_hits;
        float t_in, t_out;
       CPPUNIT_ASSERT(!gmtl::intersect(box, seg, num_hits, t_in, t_out));
      
 }

With the old function, this caused a hit because the segment was inside 
the box with tIn = tOut = 5,
which in my opinion is wrong, because the line segment never enters or 
leaves the box.
Do you agree?
If so, just take the logical AND instead of or, which will do the trick ;-)

cheers
psy

Re: [ggt-devel] Patch Intersection.h

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

Forget my last email,

I've mixed up something and will recheck the broken tests.

cheers


> On Feb 12, 2009, at 3:54 AM, Sebastian Messerschmidt wrote:
>
>   
>> Hi,
>>
>> as I've written some weeks ago, I've fixed some float/double/  
>> DATA_TYPE issues and  corrected some intersection functions, that  
>> were return false positives.
>>
>> The changes in detail:
>>
>> Line 318:
>> Fixed the box / lineseg intersection, which was missing an early out  
>> for the case were the ray hit the box. but the line didn't (some  
>> simple early out test by checking tin,tout between 0 and 1)
>>     
>
> This change breaks one of the tests (see  
> gmtlTest::IntersectionTest::testIntersectAABoxLineSeg() at line 199 of  
> Test/TestSuite/TestCases/IntersectionTest.cpp). As far as I can tell,  
> the expectation of the test is correct. Specifically, there is a line  
> segment that starts within the axis-aligned bounding box and ends  
> outside the box. In this case, tIn has a value of -0.5, and tOut is  
> 0.5. Should the test be a logical AND instead of an OR?
>
>   
>> Lines 584, 616, 649, 706:
>>
>> changed the declaration of tIN and tOUT parameters consitently to  
>> DATA_TYPE instead of fixed float.
>> addiditionally the numHits were mixed int/unsigned int which I've  
>> corrected to unsigned int everywhere
>>
>> Line 745:
>> Same as above, double/float DATA_TYPE corrections
>>     
>
> These changes have been committed. Thanks very much.
>
>   
>> Here I've corrected the intersection test between plane an ray, that  
>> failed due to missing check in tIn/tOut - range
>>     
>
> This change breaks another test in Test/TestSuite/TestCases/ 
> IntersectionTest.cpp. This one is at line 874 where a plane is  
> constructed with a ray pointing down through it. The test expects that  
> t will be 5. Is the expectation of the test invalid?
>
>   
>> I've also added the proposed intersectDoubleSided-Test for ray/ 
>> triangle, that ignores the triangle orientation.
>>     
>
>
> This has been committed. Thanks!
>
>   -Patrick
>
>
> --
> Patrick L. Hartling
> Senior Software Engineer, Priority 5
> http://www.priority5.com/
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>   

Re: [ggt-devel] Patch Intersection.h

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

Patrick Hartling schrieb:
> On Feb 12, 2009, at 3:54 AM, Sebastian Messerschmidt wrote:
>
>   
>> Hi,
>>
>> as I've written some weeks ago, I've fixed some float/double/  
>> DATA_TYPE issues and  corrected some intersection functions, that  
>> were return false positives.
>>
>> The changes in detail:
>>
>> Line 318:
>> Fixed the box / lineseg intersection, which was missing an early out  
>> for the case were the ray hit the box. but the line didn't (some  
>> simple early out test by checking tin,tout between 0 and 1)
>>     
>
> This change breaks one of the tests (see  
> gmtlTest::IntersectionTest::testIntersectAABoxLineSeg() at line 199 of  
> Test/TestSuite/TestCases/IntersectionTest.cpp). As far as I can tell,  
> the expectation of the test is correct. Specifically, there is a line  
> segment that starts within the axis-aligned bounding box and ends  
> outside the box. In this case, tIn has a value of -0.5, and tOut is  
> 0.5. Should the test be a logical AND instead of an OR?
>
>   
>> Lines 584, 616, 649, 706:
>>
>> changed the declaration of tIN and tOUT parameters consitently to  
>> DATA_TYPE instead of fixed float.
>> addiditionally the numHits were mixed int/unsigned int which I've  
>> corrected to unsigned int everywhere
>>
>> Line 745:
>> Same as above, double/float DATA_TYPE corrections
>>     
>
> These changes have been committed. Thanks very much.
>
>   
>> Here I've corrected the intersection test between plane an ray, that  
>> failed due to missing check in tIn/tOut - range
>>     
>
> This change breaks another test in Test/TestSuite/TestCases/ 
> IntersectionTest.cpp. This one is at line 874 where a plane is  
> constructed with a ray pointing down through it. The test expects that  
> t will be 5. Is the expectation of the test invalid?
>
>   
Since the test is done against a segment t should never be outside 0 and 
+1 in my expectation ( everything else would describe a ray as far as I 
understand it)
I'll take a deeper look at it over the weekend, but my collision system 
produces false positives if I don't add this test.

>> I've also added the proposed intersectDoubleSided-Test for ray/ 
>> triangle, that ignores the triangle orientation.
>>     
>
>
> This has been committed. Thanks!
>
>   -Patrick
>
>
> --
> Patrick L. Hartling
> Senior Software Engineer, Priority 5
> http://www.priority5.com/
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>