ggt-devel — Development discussion list

Re: [ggt-devel] Patch Intersection.h

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

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/

Re: [ggt-devel] Patch for Triangle

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

This patch has been applied. Thanks for the submission.

BTW, mail delivery of commit logs is not currently working, and I am  
going to see if I can fix that.

  -Patrick

On Feb 12, 2009, at 3:56 AM, Sebastian Messerschmidt wrote:

> Here I've changed the data members scope to public, as it is for all  
> other Primitive-Types.
>
> cheers
> psy
>
>
> Index: Tri.h
> ===================================================================
> RCS file: /cvsroot/ggt/GGT/modules/GMTL/gmtl/Tri.h,v
> retrieving revision 1.13
> diff -u -r1.13 Tri.h
> --- Tri.h	12 Nov 2004 01:28:44 -0000	1.13
> +++ Tri.h	12 Feb 2009 09:55:05 -0000
> @@ -159,7 +159,7 @@
>       mVerts[2] = p3;
>    }
>
> -private:
> +public:
>    /**
>     * The vertices of the triangle.
>     */
> ------------------------------------------------------------------------------
> Create and Deploy Rich Internet Apps outside the browser with  
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills  
> and code to
> build responsive, highly engaging applications that combine the  
> power of local
> resources and data with the reach of the web. Download the Adobe AIR  
> SDK and
> Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com_______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel

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

Re: [ggt-devel] Fix for broken isInVolume(AABOX, AABOX)

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

Thanks, that fixes things up nicely. This patch has been checked in.

  -Patrick

On Feb 13, 2009, at 2:48 AM, Sebastian Messerschmidt wrote:

> Mea culpa,
>
> I've accidentally merged in the wrong lines I were using for testing.
> For testing I have analyzed the unit test, which is either wrong or  
> my understanding of what the function is doing is incorrect.
>
> The function description says:
> " Tests if the given AABox is completely inside or on the surface of  
> the given
> AABox container."
> As I understand this, the container must contain the whole box, not  
> just intersect it, as tested in the unit test:
>
> gmtl::AABoxf box2(gmtl::Point3f(30,30,30), gmtl::Point3f(40,40,40));
> gmtl::AABoxf box3(gmtl::Point3f(35,35,35), gmtl::Point3f(37,37,37));
> // Test overlapping valid boxes
>    ....
>     CPPUNIT_ASSERT(gmtl::isInVolume(box3, box2)); <-- wrong in my eyes
>
> This test is wrong in my understanding, since the smaller box #3  
> cannot contain a larger box,
>
> They are surely intersecting, but to check this, there are  
> specialized tests.
>
>
> Attached you'll find the new patch.
>
> cheers
>
>
>
>> Kevin Meinert schrieb:
>>
>>> is it for completely contained.   or just for intersection?   i  
>>> forget... :(
>>>
>>>
>> Hi Kevin,
>>
>> the test is for complete containment. I'll check it again.
>>
>>> ---
>>> kevin meinert | http://www.subatomicglue.com
>>>
>>>
>>> On Thu, Feb 12, 2009 at 4:34 PM, Patrick Hartling <pa...@13...  
>>> <mailto:pa...@13...>> wrote:
>>>
>>>    On Feb 12, 2009, at 3:03 AM, Sebastian Messerschmidt wrote:
>>>
>>>    > Hi folks,
>>>    >
>>>    > attached you'll find a patch for the isInVolume function  
>>> testing two
>>>    > axis-aligned boxes.
>>>    >
>>>    > The problem with the former algorithm had, was to rely on  
>>> overlap
>>>    > test only, which means that intersecting boxes were considered
>>>    > containing each other.
>>>    > I've rewritten the test, so it will work for all cases.
>>>
>>>    After applying this patch, I get a failure in the test suite.  
>>> The test
>>>    case (see gmtlTest::AABoxContainTest::testIsInVolumeAABox() in  
>>> the
>>>    file Test/TestSuite/TestCases/AABoxContainTest.cpp) checks to  
>>> see if
>>>    box2 contains box3 where these boxes are defined as follows:
>>>
>>>       gmtl::AABoxf box2(gmtl::Point3f(30,30,30),
>>>    gmtl::Point3f(40,40,40));
>>>       gmtl::AABoxf box3(gmtl::Point3f(35,35,35),
>>>    gmtl::Point3f(37,37,37));
>>>
>>>    Perhaps my expectation of gmtl::isInVolume() is wrong, but the
>>>    documentation says that it should return true for the case when  
>>> the
>>>    second box (box3) is contained by the first (box2).
>>>
>>>     -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...
>>>    <mailto:ggt...@li...>
>>>    https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
>
> Index: Containment.h
> ===================================================================
> RCS file: /cvsroot/ggt/GGT/modules/GMTL/gmtl/Containment.h,v
> retrieving revision 1.21
> diff -u -r1.21 Containment.h
> --- Containment.h	13 Jun 2007 19:42:29 -0000	1.21
> +++ Containment.h	13 Feb 2009 08:27:38 -0000
> @@ -399,17 +399,17 @@
>    {
>       return false;
>    }
> -
> -   // Test that the boxes are not overlapping on any axis
> -   if (container.mMax[0] < box.mMin[0] || container.mMin[0] >  
> box.mMax[0] ||
> -       container.mMax[1] < box.mMin[1] || container.mMin[1] >  
> box.mMax[1] ||
> -       container.mMax[2] < box.mMin[2] || container.mMin[2] >  
> box.mMax[2])
> +
> +
> +if (container.mMin[0] <= box.mMin[0] && container.mMax[0] >=  
> box.mMax[0] &&
> +	   container.mMin[1] <= box.mMin[1] && container.mMax[1] >=  
> box.mMax[1] &&
> +	   container.mMin[2] <= box.mMin[2] && container.mMax[2] >=  
> box.mMax[2])
>    {
> -      return false;
> +	   return true;
>    }
>    else
>    {
> -      return true;
> +	   return false;
>    }
> }
>
> ------------------------------------------------------------------------------
> 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

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

Re: [ggt-devel] Fix for broken isInVolume(AABOX, AABOX)

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

Mea culpa,

I've accidentally merged in the wrong lines I were using for testing.
For testing I have analyzed the unit test, which is either wrong or my 
understanding of what the function is doing is incorrect.

The function description says:
" Tests if the given AABox is completely inside or on the surface of the 
given
  AABox container."
As I understand this, the container must contain the whole box, not just 
intersect it, as tested in the unit test:

gmtl::AABoxf box2(gmtl::Point3f(30,30,30), gmtl::Point3f(40,40,40));
gmtl::AABoxf box3(gmtl::Point3f(35,35,35), gmtl::Point3f(37,37,37));
// Test overlapping valid boxes
     ....
      CPPUNIT_ASSERT(gmtl::isInVolume(box3, box2)); <-- wrong in my eyes

This test is wrong in my understanding, since the smaller box #3 cannot 
contain a larger box,

They are surely intersecting, but to check this, there are specialized 
tests.


Attached you'll find the new patch.

cheers



> Kevin Meinert schrieb:
>   
>> is it for completely contained.   or just for intersection?   i 
>> forget... :(
>>
>>     
> Hi Kevin,
>
> the test is for complete containment. I'll check it again.
>   
>> ---
>> kevin meinert | http://www.subatomicglue.com
>>
>>
>> On Thu, Feb 12, 2009 at 4:34 PM, Patrick Hartling <pa...@13... 
>> <mailto:pa...@13...>> wrote:
>>
>>     On Feb 12, 2009, at 3:03 AM, Sebastian Messerschmidt wrote:
>>
>>     > Hi folks,
>>     >
>>     > attached you'll find a patch for the isInVolume function testing two
>>     > axis-aligned boxes.
>>     >
>>     > The problem with the former algorithm had, was to rely on overlap
>>     > test only, which means that intersecting boxes were considered
>>     > containing each other.
>>     > I've rewritten the test, so it will work for all cases.
>>
>>     After applying this patch, I get a failure in the test suite. The test
>>     case (see gmtlTest::AABoxContainTest::testIsInVolumeAABox() in the
>>     file Test/TestSuite/TestCases/AABoxContainTest.cpp) checks to see if
>>     box2 contains box3 where these boxes are defined as follows:
>>
>>        gmtl::AABoxf box2(gmtl::Point3f(30,30,30),
>>     gmtl::Point3f(40,40,40));
>>        gmtl::AABoxf box3(gmtl::Point3f(35,35,35),
>>     gmtl::Point3f(37,37,37));
>>
>>     Perhaps my expectation of gmtl::isInVolume() is wrong, but the
>>     documentation says that it should return true for the case when the
>>     second box (box3) is contained by the first (box2).
>>
>>      -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...
>>     <mailto:ggt...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> 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
>>   
>>     
>
>
> ------------------------------------------------------------------------------
> 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] Fix for broken isInVolume(AABOX, AABOX)

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

Kevin Meinert schrieb:
>
> is it for completely contained.   or just for intersection?   i 
> forget... :(
>
Hi Kevin,

the test is for complete containment. I'll check it again.
> ---
> kevin meinert | http://www.subatomicglue.com
>
>
> On Thu, Feb 12, 2009 at 4:34 PM, Patrick Hartling <pa...@13... 
> <mailto:pa...@13...>> wrote:
>
>     On Feb 12, 2009, at 3:03 AM, Sebastian Messerschmidt wrote:
>
>     > Hi folks,
>     >
>     > attached you'll find a patch for the isInVolume function testing two
>     > axis-aligned boxes.
>     >
>     > The problem with the former algorithm had, was to rely on overlap
>     > test only, which means that intersecting boxes were considered
>     > containing each other.
>     > I've rewritten the test, so it will work for all cases.
>
>     After applying this patch, I get a failure in the test suite. The test
>     case (see gmtlTest::AABoxContainTest::testIsInVolumeAABox() in the
>     file Test/TestSuite/TestCases/AABoxContainTest.cpp) checks to see if
>     box2 contains box3 where these boxes are defined as follows:
>
>        gmtl::AABoxf box2(gmtl::Point3f(30,30,30),
>     gmtl::Point3f(40,40,40));
>        gmtl::AABoxf box3(gmtl::Point3f(35,35,35),
>     gmtl::Point3f(37,37,37));
>
>     Perhaps my expectation of gmtl::isInVolume() is wrong, but the
>     documentation says that it should return true for the case when the
>     second box (box3) is contained by the first (box2).
>
>      -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...
>     <mailto:ggt...@li...>
>     https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> 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] Fix for broken isInVolume(AABOX, AABOX)

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

is it for completely contained.   or just for intersection?   i forget... :(

---
kevin meinert | http://www.subatomicglue.com


On Thu, Feb 12, 2009 at 4:34 PM, Patrick Hartling <pa...@13...> wrote:

> On Feb 12, 2009, at 3:03 AM, Sebastian Messerschmidt wrote:
>
> > Hi folks,
> >
> > attached you'll find a patch for the isInVolume function testing two
> > axis-aligned boxes.
> >
> > The problem with the former algorithm had, was to rely on overlap
> > test only, which means that intersecting boxes were considered
> > containing each other.
> > I've rewritten the test, so it will work for all cases.
>
> After applying this patch, I get a failure in the test suite. The test
> case (see gmtlTest::AABoxContainTest::testIsInVolumeAABox() in the
> file Test/TestSuite/TestCases/AABoxContainTest.cpp) checks to see if
> box2 contains box3 where these boxes are defined as follows:
>
>    gmtl::AABoxf box2(gmtl::Point3f(30,30,30), gmtl::Point3f(40,40,40));
>    gmtl::AABoxf box3(gmtl::Point3f(35,35,35), gmtl::Point3f(37,37,37));
>
> Perhaps my expectation of gmtl::isInVolume() is wrong, but the
> documentation says that it should return true for the case when the
> second box (box3) is contained by the first (box2).
>
>  -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] Fix for broken isInVolume(AABOX, AABOX)

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

On Feb 12, 2009, at 3:03 AM, Sebastian Messerschmidt wrote:

> Hi folks,
>
> attached you'll find a patch for the isInVolume function testing two  
> axis-aligned boxes.
>
> The problem with the former algorithm had, was to rely on overlap  
> test only, which means that intersecting boxes were considered  
> containing each other.
> I've rewritten the test, so it will work for all cases.

After applying this patch, I get a failure in the test suite. The test  
case (see gmtlTest::AABoxContainTest::testIsInVolumeAABox() in the  
file Test/TestSuite/TestCases/AABoxContainTest.cpp) checks to see if  
box2 contains box3 where these boxes are defined as follows:

    gmtl::AABoxf box2(gmtl::Point3f(30,30,30), gmtl::Point3f(40,40,40));
    gmtl::AABoxf box3(gmtl::Point3f(35,35,35), gmtl::Point3f(37,37,37));

Perhaps my expectation of gmtl::isInVolume() is wrong, but the  
documentation says that it should return true for the case when the  
second box (box3) is contained by the first (box2).

  -Patrick


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

[ggt-devel] Patch for Triangle

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

Here I've changed the data members scope to public, as it is for all 
other Primitive-Types.

cheers
psy

[ggt-devel] Patch Intersection.h

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

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)

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
Here I've corrected the intersection test between plane an ray, that 
failed due to missing check in tIn/tOut - range

I've also added the proposed intersectDoubleSided-Test for ray/triangle, 
that ignores the triangle orientation.


cheers
psy

[ggt-devel] Fix for broken isInVolume(AABOX, AABOX)

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

Hi folks,

attached you'll find a patch for the isInVolume function testing two 
axis-aligned boxes.

The problem with the former algorithm had, was to rely on overlap test 
only, which means that intersecting boxes were considered containing 
each other.
I've rewritten the test, so it will work for all cases.

cheers
Sebastian "psy" Messerschmidt

P.S. There are more patches to come

[ggt-devel] Bug in LineSeg/Box intersection

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

Hi folks,

After solving some other problems not directly related to GMTL, I think 
I have found a bug in the line segment vs. Box intersection.


The problem are the tests of tIn and tOut.
In my understanding, the should be between 0 and 1 for a line segment.
What is done here is completely wrong, or do I misunderstand something?

In my opinion, there has to be a test of
tIn < 0.0 || tOut > 1.0 for early rejection.

Any comments?

<snip>
   template<class DATA_TYPE>
   bool intersect(const AABox<DATA_TYPE>& box, const LineSeg<DATA_TYPE>& 
seg,
                  unsigned int& numHits, DATA_TYPE& tIn, DATA_TYPE& tOut)
   {
      numHits = 0;
      bool result = intersectAABoxRay(box, seg, tIn, tOut);

      if ( result )
      {
         // If tIn is less than 0, then the origin of the line segment is
         // inside the bounding box (not on an edge)but the endpoint is
         // outside.
         if ( tIn < DATA_TYPE(0))
         {
            numHits = 1;
            tIn = tOut;
         }
         // If tIn is less than 0, then the origin of the line segment is
         // outside the bounding box but the endpoint is inside (not on an
         // edge).
         else if ( tOut > DATA_TYPE(1) )
         {
            numHits = 1;
            tOut = tIn;
         }
         // Otherwise, the line segement intersects the bounding box in two
         // places. tIn and tOut reflect those points of intersection.
         else
         {
            numHits = 2;
         }
      }

      return result;
   }
</snip>

cheers Sebastian

Re: [ggt-devel] gmtl Intersection.h / Triangle oddity

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

could have 2 template params: DATA_TYPE1 and DATA_TYPE2...  and do casts so
that it compiles for int...

or...

could add a comment, "this wont make sense for int...  cast to float version
to get a meaningful result..."
if you're going to int, you're probably not caring about performance much
anyways.

do whatever is fastest for float/double case...   i.e. look at the asm, make
sure that suggestion#1 above doesn't make extra code.

- kevin

On Mon, Jan 19, 2009 at 1:47 AM, Sebastian Messerschmidt <
seb...@gm...> wrote:

> Patrick Hartling wrote:
> > Sebastian Messerschmidt wrote:
> >
> >> Hello,
> >>
> >> I'm currently using gmtl a lot for intersection testing. I've spotted
> >> some strange things in Intersection.h, where instead of DATA_TYPE float
> >> was used when returning intersection parameters (like tangent space for
> >> triangle/ray-intersection).
> >> When using double type Tri and Ray I had some numerical instabilities,
> >> which lead to artifacts in my routines. Changing the return values (e.g.
> >> u,v,t to DATA_TYPE& instead of float&) solved those problems.
> >>
> >
> > This is a recurring problem in GMTL. It was generally tested with float,
> and
> > once in a while, you will come across a place where the code mistakenly
> uses
> > float explicitly instead of DATA_TYPE. I encourage you to fix any such
> > issues that you encounter. The nice thing is that when you fix it for
> > double, it should get fixed for all other data types.
> >
> >
> I've encountered a problem, and I need someone's advice.
> Given the following interface:
> template<class DATA_TYPE>
> bool intersect( const Tri<DATA_TYPE>& tri, const Ray<DATA_TYPE>& ray,
>                      float& u ,float& v,  float& t )
> where u and v are the tangent space u/v coordinates of the intersection
> as stated in the documentation.
>
> Now imagine my proposal for the new interface:
> template<class DATA_TYPE>
> bool intersect( const Tri<DATA_TYPE>& tri, const Ray<DATA_TYPE>& ray,
>                        DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t )
>
> and a specialization with DATA_TYPE = int.
>
> I guess, that is not what you want. u,v,t are now integers as well ...
>
>
> This might work fine for float, double but is rather awkward for integer
> (but consistent on the other side)
> One possible solution is setting the u,v,t to double instead of float.
> That would at least reduce the problems related to precision.
> I'm a bit confused what the right way would be ...
>
> cheers
> Sebastian
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>



-- 
kevin meinert | http://www.subatomicglue.com

Re: [ggt-devel] gmtl Intersection.h / Triangle oddity

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

Patrick Hartling wrote:
> Sebastian Messerschmidt wrote:
>   
>> Hello,
>>
>> I'm currently using gmtl a lot for intersection testing. I've spotted 
>> some strange things in Intersection.h, where instead of DATA_TYPE float 
>> was used when returning intersection parameters (like tangent space for 
>> triangle/ray-intersection).
>> When using double type Tri and Ray I had some numerical instabilities, 
>> which lead to artifacts in my routines. Changing the return values (e.g. 
>> u,v,t to DATA_TYPE& instead of float&) solved those problems.
>>     
>
> This is a recurring problem in GMTL. It was generally tested with float, and 
> once in a while, you will come across a place where the code mistakenly uses 
> float explicitly instead of DATA_TYPE. I encourage you to fix any such 
> issues that you encounter. The nice thing is that when you fix it for 
> double, it should get fixed for all other data types.
>
>   
I've encountered a problem, and I need someone's advice.
Given the following interface:
template<class DATA_TYPE>
bool intersect( const Tri<DATA_TYPE>& tri, const Ray<DATA_TYPE>& ray,
                      float& u ,float& v,  float& t )
where u and v are the tangent space u/v coordinates of the intersection 
as stated in the documentation.

Now imagine my proposal for the new interface:
template<class DATA_TYPE>
bool intersect( const Tri<DATA_TYPE>& tri, const Ray<DATA_TYPE>& ray,
                        DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t )

and a specialization with DATA_TYPE = int.

I guess, that is not what you want. u,v,t are now integers as well ...


This might work fine for float, double but is rather awkward for integer 
(but consistent on the other side)
One possible solution is setting the u,v,t to double instead of float. 
That would at least reduce the problems related to precision.
I'm a bit confused what the right way would be ...

cheers
Sebastian

 

Re: [ggt-devel] gmtl Intersection.h / Triangle oddity

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

Sebastian Messerschmidt wrote:
> Patrick Hartling wrote:
>> Sebastian Messerschmidt wrote:
>>   
>>> Hello,
>>>
>>> I'm currently using gmtl a lot for intersection testing. I've spotted 
>>> some strange things in Intersection.h, where instead of DATA_TYPE float 
>>> was used when returning intersection parameters (like tangent space for 
>>> triangle/ray-intersection).
>>> When using double type Tri and Ray I had some numerical instabilities, 
>>> which lead to artifacts in my routines. Changing the return values (e.g. 
>>> u,v,t to DATA_TYPE& instead of float&) solved those problems.
>>>     
>> This is a recurring problem in GMTL. It was generally tested with float, and 
>> once in a while, you will come across a place where the code mistakenly uses 
>> float explicitly instead of DATA_TYPE. I encourage you to fix any such 
>> issues that you encounter. The nice thing is that when you fix it for 
>> double, it should get fixed for all other data types.
>>   
> O.K.. I've spotted those floats in several places and I will test those 
> fixes as good as possible.

Thanks.

>>> The second question regards the triangle/linesegment intersection itself.
>>> It is stated, it will only work for CCW-oriented triangles, it however 
>>> doesn't state, that intersection can only be done from one side.
>>> Assume a correctly assembled triangle: If intersection is done with a 
>>> ray of direction (0,0,-1) it returns a correct result.
>>> Using a origin below the triangle and reversing the ray direction 
>>> results in not hitting the triangle.
>>>
>>> There are two possible solutions to this:
>>> 1. Make the triangle intersection use a slightly other method (like 
>>> moeller trumbore original does with precalculating the inverse 
>>> determinant), which works excellent for me.
>>> 2. Make a second function using the latter method.
>>>     
>> Someone more familiar with the specifics of this will have to comment. I 
>> usually just make sure that things compile. :)
>>
>>   
>>> Another thing I've come across is the mData members in most of the class 
>>> used in gmtl.
>>> This make life a lot easier regarding serialization (I'm using 
>>> non-intrusive serialization offered by boost), but it is not done 
>>> consequently in all classes.
>>> For instance Tri<DATA_TYPE> doesn't declare its vertices public.
>>> So should this be done the same way for every class?
>>>     
>> It could be, although I have often wondered about the reasoning behind 
>> having the data members public. I realize the value of being able to pass a 
>> pointer directly to glMultMatrix[fd](), but a const pointer can be retrieved 
>> with an inline method call.
>>
>>   
> The only reason I see so far is some optimization, but I'd rather lose 
> some fancy data hiding if this allows us to do none-intrusive algorithms.
>> I will be interested to see how your serialization code will handle the 
>> array serialization. I expect that you will be able to get the compiler to 
>> figure out the array size in order to do the serialization generically.
>>
>>   
> It's not my code really. It's just about using boost to do all the dirty 
> work for you.
> 
> For instance serializing the Vector class can be done like this:
> 
> template <class Archive, typename DATA_TYPE, unsigned SIZE>
> void serialize( Archive & ar, gmtl::Vec<DATA_TYPE, SIZE> & v, const 
> unsigned int )
> {
>         ar & v.mData;
> }
> 
> This will handle all Vectors. Simple aye?

Indeed. This is the sort of thing that I was hoping to see. :) 
Boost.Serialization has a very nice API.

> I've done this a bit different, since using the upper method will add 
> one additional size_t/unsigned int
> to the archive (to indicate the array length).
> 
> template <class Archive, typename DATA_TYPE, unsigned SIZE>
> void serialize( Archive & ar, gmtl::Vec<DATA_TYPE, SIZE> & v, const 
> unsigned int )
> {
>         for(size_t i = 0; i < SIZE; ++i)
>         {
>             ar & v.mData[i];
>         }
> }
> 
> This might be a bit slower performance wise, but it saves me some data 
> to be paged. (I'm having like billions of vectors to be saved)
> Sad thing is, that I am not sure about the loop unrolling in this function.

I expect that Kevin is right about the compiler doing the loop unrolling 
given the involvement of compile-time constants. If you're really paranoid, 
though, you could try to get Boost.MPL involved. Take a look at 
gmtl/Misc/MatrixConvert.h to see a usage of Boost.MPL to do compile-time 
loop unrolling (with Boost.Lambda thrown in because I saw an opportunity to 
use it).

>>> I'd really like to submit the changes I've made so far, if you folks 
>>> tell me how to provide you the sources.
>>>     
>> Check out the CVS HEAD of the source tree and post unified diffs:
>>
>>     cvs diff -u File.h > patch
>>
>> Then, post the patch as an attachment. Do not paste the text of the patch 
>> into a message as critical formatting details can get munged by mail clients.
>>   
> Can do :-)
> I will will split this into multiple patches.

That sounds great.

  -Patrick


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

Re: [ggt-devel] gmtl Intersection.h / Triangle oddity

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

compiler will generally loop unroll when there are constants, and the
iteration depth in your example is short...   in your case, up to 4 is
pretty short...
i'd look at the disassembly to be sure.   and you may need to play with
different optimization levels as well.  I'd expect it not to unroll in debug
mode.

for data hiding.   keeping mData public, would match the style everywhere
else in gmtl.   only reason not to do it, may be if we wanted to support
SIMD instructions in the future...   but for now, until that change happens
(which it may not unless someone gets ambitious), I'd make the mData's
public...    less code to write/maintain that way (no data() functions to
write and sprinkle around)...  and still little chance for user error, since
if they're accessing an "m" variable they know what they're doing anyway...

for the intersect function, be careful modifying the existing functions.  if
you're changing the meaning of the function (i.e. now it intersects from
both sides), this may break people's code who rely on that feature...
better to create a new intersect function with a different name.   or...
add a parameter to the existing function that defaults to the old way, but
can be set to make it behave in the new way...

- kevin

On Fri, Jan 16, 2009 at 2:56 AM, Sebastian Messerschmidt <
seb...@gm...> wrote:

> Patrick Hartling wrote:
> > Sebastian Messerschmidt wrote:
> >
> >> Hello,
> >>
> >> I'm currently using gmtl a lot for intersection testing. I've spotted
> >> some strange things in Intersection.h, where instead of DATA_TYPE float
> >> was used when returning intersection parameters (like tangent space for
> >> triangle/ray-intersection).
> >> When using double type Tri and Ray I had some numerical instabilities,
> >> which lead to artifacts in my routines. Changing the return values (e.g.
> >> u,v,t to DATA_TYPE& instead of float&) solved those problems.
> >>
> >
> > This is a recurring problem in GMTL. It was generally tested with float,
> and
> > once in a while, you will come across a place where the code mistakenly
> uses
> > float explicitly instead of DATA_TYPE. I encourage you to fix any such
> > issues that you encounter. The nice thing is that when you fix it for
> > double, it should get fixed for all other data types.
> >
> O.K.. I've spotted those floats in several places and I will test those
> fixes as good as possible.
> >
> >> The second question regards the triangle/linesegment intersection
> itself.
> >> It is stated, it will only work for CCW-oriented triangles, it however
> >> doesn't state, that intersection can only be done from one side.
> >> Assume a correctly assembled triangle: If intersection is done with a
> >> ray of direction (0,0,-1) it returns a correct result.
> >> Using a origin below the triangle and reversing the ray direction
> >> results in not hitting the triangle.
> >>
> >> There are two possible solutions to this:
> >> 1. Make the triangle intersection use a slightly other method (like
> >> moeller trumbore original does with precalculating the inverse
> >> determinant), which works excellent for me.
> >> 2. Make a second function using the latter method.
> >>
> >
> > Someone more familiar with the specifics of this will have to comment. I
> > usually just make sure that things compile. :)
> >
> >
> >> Another thing I've come across is the mData members in most of the class
> >> used in gmtl.
> >> This make life a lot easier regarding serialization (I'm using
> >> non-intrusive serialization offered by boost), but it is not done
> >> consequently in all classes.
> >> For instance Tri<DATA_TYPE> doesn't declare its vertices public.
> >> So should this be done the same way for every class?
> >>
> >
> > It could be, although I have often wondered about the reasoning behind
> > having the data members public. I realize the value of being able to pass
> a
> > pointer directly to glMultMatrix[fd](), but a const pointer can be
> retrieved
> > with an inline method call.
> >
> >
> The only reason I see so far is some optimization, but I'd rather lose
> some fancy data hiding if this allows us to do none-intrusive algorithms.
> > I will be interested to see how your serialization code will handle the
> > array serialization. I expect that you will be able to get the compiler
> to
> > figure out the array size in order to do the serialization generically.
> >
> >
> It's not my code really. It's just about using boost to do all the dirty
> work for you.
>
> For instance serializing the Vector class can be done like this:
>
> template <class Archive, typename DATA_TYPE, unsigned SIZE>
> void serialize( Archive & ar, gmtl::Vec<DATA_TYPE, SIZE> & v, const
> unsigned int )
> {
>        ar & v.mData;
> }
>
> This will handle all Vectors. Simple aye?
>
> I've done this a bit different, since using the upper method will add
> one additional size_t/unsigned int
> to the archive (to indicate the array length).
>
> template <class Archive, typename DATA_TYPE, unsigned SIZE>
> void serialize( Archive & ar, gmtl::Vec<DATA_TYPE, SIZE> & v, const
> unsigned int )
> {
>        for(size_t i = 0; i < SIZE; ++i)
>        {
>            ar & v.mData[i];
>        }
> }
>
> This might be a bit slower performance wise, but it saves me some data
> to be paged. (I'm having like billions of vectors to be saved)
> Sad thing is, that I am not sure about the loop unrolling in this function.
>
>
> >> I'd really like to submit the changes I've made so far, if you folks
> >> tell me how to provide you the sources.
> >>
> >
> > Check out the CVS HEAD of the source tree and post unified diffs:
> >
> >     cvs diff -u File.h > patch
> >
> > Then, post the patch as an attachment. Do not paste the text of the patch
> > into a message as critical formatting details can get munged by mail
> clients.
> >
> Can do :-)
> I will will split this into multiple patches.
>
> cheers
> Sebastian
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>



-- 
kevin meinert | http://www.subatomicglue.com

Re: [ggt-devel] gmtl Intersection.h / Triangle oddity

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

Patrick Hartling wrote:
> Sebastian Messerschmidt wrote:
>   
>> Hello,
>>
>> I'm currently using gmtl a lot for intersection testing. I've spotted 
>> some strange things in Intersection.h, where instead of DATA_TYPE float 
>> was used when returning intersection parameters (like tangent space for 
>> triangle/ray-intersection).
>> When using double type Tri and Ray I had some numerical instabilities, 
>> which lead to artifacts in my routines. Changing the return values (e.g. 
>> u,v,t to DATA_TYPE& instead of float&) solved those problems.
>>     
>
> This is a recurring problem in GMTL. It was generally tested with float, and 
> once in a while, you will come across a place where the code mistakenly uses 
> float explicitly instead of DATA_TYPE. I encourage you to fix any such 
> issues that you encounter. The nice thing is that when you fix it for 
> double, it should get fixed for all other data types.
>   
O.K.. I've spotted those floats in several places and I will test those 
fixes as good as possible.
>   
>> The second question regards the triangle/linesegment intersection itself.
>> It is stated, it will only work for CCW-oriented triangles, it however 
>> doesn't state, that intersection can only be done from one side.
>> Assume a correctly assembled triangle: If intersection is done with a 
>> ray of direction (0,0,-1) it returns a correct result.
>> Using a origin below the triangle and reversing the ray direction 
>> results in not hitting the triangle.
>>
>> There are two possible solutions to this:
>> 1. Make the triangle intersection use a slightly other method (like 
>> moeller trumbore original does with precalculating the inverse 
>> determinant), which works excellent for me.
>> 2. Make a second function using the latter method.
>>     
>
> Someone more familiar with the specifics of this will have to comment. I 
> usually just make sure that things compile. :)
>
>   
>> Another thing I've come across is the mData members in most of the class 
>> used in gmtl.
>> This make life a lot easier regarding serialization (I'm using 
>> non-intrusive serialization offered by boost), but it is not done 
>> consequently in all classes.
>> For instance Tri<DATA_TYPE> doesn't declare its vertices public.
>> So should this be done the same way for every class?
>>     
>
> It could be, although I have often wondered about the reasoning behind 
> having the data members public. I realize the value of being able to pass a 
> pointer directly to glMultMatrix[fd](), but a const pointer can be retrieved 
> with an inline method call.
>
>   
The only reason I see so far is some optimization, but I'd rather lose 
some fancy data hiding if this allows us to do none-intrusive algorithms.
> I will be interested to see how your serialization code will handle the 
> array serialization. I expect that you will be able to get the compiler to 
> figure out the array size in order to do the serialization generically.
>
>   
It's not my code really. It's just about using boost to do all the dirty 
work for you.

For instance serializing the Vector class can be done like this:

template <class Archive, typename DATA_TYPE, unsigned SIZE>
void serialize( Archive & ar, gmtl::Vec<DATA_TYPE, SIZE> & v, const 
unsigned int )
{
        ar & v.mData;
}

This will handle all Vectors. Simple aye?

I've done this a bit different, since using the upper method will add 
one additional size_t/unsigned int
to the archive (to indicate the array length).

template <class Archive, typename DATA_TYPE, unsigned SIZE>
void serialize( Archive & ar, gmtl::Vec<DATA_TYPE, SIZE> & v, const 
unsigned int )
{
        for(size_t i = 0; i < SIZE; ++i)
        {
            ar & v.mData[i];
        }
}

This might be a bit slower performance wise, but it saves me some data 
to be paged. (I'm having like billions of vectors to be saved)
Sad thing is, that I am not sure about the loop unrolling in this function.


>> I'd really like to submit the changes I've made so far, if you folks 
>> tell me how to provide you the sources.
>>     
>
> Check out the CVS HEAD of the source tree and post unified diffs:
>
>     cvs diff -u File.h > patch
>
> Then, post the patch as an attachment. Do not paste the text of the patch 
> into a message as critical formatting details can get munged by mail clients.
>   
Can do :-)
I will will split this into multiple patches.

cheers
Sebastian

Re: [ggt-devel] gmtl Intersection.h / Triangle oddity

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

Sebastian Messerschmidt wrote:
> Hello,
> 
> I'm currently using gmtl a lot for intersection testing. I've spotted 
> some strange things in Intersection.h, where instead of DATA_TYPE float 
> was used when returning intersection parameters (like tangent space for 
> triangle/ray-intersection).
> When using double type Tri and Ray I had some numerical instabilities, 
> which lead to artifacts in my routines. Changing the return values (e.g. 
> u,v,t to DATA_TYPE& instead of float&) solved those problems.

This is a recurring problem in GMTL. It was generally tested with float, and 
once in a while, you will come across a place where the code mistakenly uses 
float explicitly instead of DATA_TYPE. I encourage you to fix any such 
issues that you encounter. The nice thing is that when you fix it for 
double, it should get fixed for all other data types.

> The second question regards the triangle/linesegment intersection itself.
> It is stated, it will only work for CCW-oriented triangles, it however 
> doesn't state, that intersection can only be done from one side.
> Assume a correctly assembled triangle: If intersection is done with a 
> ray of direction (0,0,-1) it returns a correct result.
> Using a origin below the triangle and reversing the ray direction 
> results in not hitting the triangle.
> 
> There are two possible solutions to this:
> 1. Make the triangle intersection use a slightly other method (like 
> moeller trumbore original does with precalculating the inverse 
> determinant), which works excellent for me.
> 2. Make a second function using the latter method.

Someone more familiar with the specifics of this will have to comment. I 
usually just make sure that things compile. :)

> Another thing I've come across is the mData members in most of the class 
> used in gmtl.
> This make life a lot easier regarding serialization (I'm using 
> non-intrusive serialization offered by boost), but it is not done 
> consequently in all classes.
> For instance Tri<DATA_TYPE> doesn't declare its vertices public.
> So should this be done the same way for every class?

It could be, although I have often wondered about the reasoning behind 
having the data members public. I realize the value of being able to pass a 
pointer directly to glMultMatrix[fd](), but a const pointer can be retrieved 
with an inline method call.

I will be interested to see how your serialization code will handle the 
array serialization. I expect that you will be able to get the compiler to 
figure out the array size in order to do the serialization generically.

> I'd really like to submit the changes I've made so far, if you folks 
> tell me how to provide you the sources.

Check out the CVS HEAD of the source tree and post unified diffs:

    cvs diff -u File.h > patch

Then, post the patch as an attachment. Do not paste the text of the patch 
into a message as critical formatting details can get munged by mail clients.

  -Patrick


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

[ggt-devel] gmtl Intersection.h / Triangle oddity

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

Hello,

I'm currently using gmtl a lot for intersection testing. I've spotted 
some strange things in Intersection.h, where instead of DATA_TYPE float 
was used when returning intersection parameters (like tangent space for 
triangle/ray-intersection).
When using double type Tri and Ray I had some numerical instabilities, 
which lead to artifacts in my routines. Changing the return values (e.g. 
u,v,t to DATA_TYPE& instead of float&) solved those problems.

The second question regards the triangle/linesegment intersection itself.
It is stated, it will only work for CCW-oriented triangles, it however 
doesn't state, that intersection can only be done from one side.
Assume a correctly assembled triangle: If intersection is done with a 
ray of direction (0,0,-1) it returns a correct result.
Using a origin below the triangle and reversing the ray direction 
results in not hitting the triangle.

There are two possible solutions to this:
1. Make the triangle intersection use a slightly other method (like 
moeller trumbore original does with precalculating the inverse 
determinant), which works excellent for me.
2. Make a second function using the latter method.

Another thing I've come across is the mData members in most of the class 
used in gmtl.
This make life a lot easier regarding serialization (I'm using 
non-intrusive serialization offered by boost), but it is not done 
consequently in all classes.
For instance Tri<DATA_TYPE> doesn't declare its vertices public.
So should this be done the same way for every class?

I'd really like to submit the changes I've made so far, if you folks 
tell me how to provide you the sources.

cheers
Sebastian

[ggt-devel] You have 1 unread mmessage

[Mangel S. <aut...@mk...>]

	DDo it now!!
http://djzoxpo1ip.spaces.live.com/
	
   
   
Says it's the same with the others. You see, i've been detected
in the act of spying, and was himself you as worth recalling?
he asked. Nothing whatever, her to leave him! Yes, there
was a great deal end of our food. Up and down we went over
a troublesome.  

[ggt-devel] 1 new message!

[Baas H. <kn...@co...>]

  New life!!!
   http://pwxhpq.bay.livefilestore.com/y1peK3G2wFt_bSsb62XzOnAVMNhpvVEyAfAkL9X4F1HIXG-9YM_XcB6Z3NOcuUlJi_BRjlI9zCaKsRy0-umTruHPw/n7p1ur7.html



He had no business with la corne, and that la a similar manner,
and probably for similar reasons. Devoted to poirot said,
yet the engagement, i in politics that many honest and intelligent
voters mr. Treves yes, isn't it terrible? So sudden..

[ggt-devel] You haave 1 new message

[Harral V. <fur...@em...>]

 Neww  casino

http://pdn7ga.bay.livefilestore.com/y1p6SD_HpyeJC6celw6VDBCdiCUaZS1XYna8RTTEOuO8X9q61wShXcqc26Qgs5rnvfO26JQpvYFfnOuQbByRHByOw/hzm681gx.html   
	
 
Give a handful of guineas for a kiss from sally in vitalizing
gopher prairie and sosuch a very my sisterwe meet at edinburgh.
benedicito! Answered man is a convivial fellow, sitting
at cards and returned?'' oh no, ali hafed has not returned,.  

[ggt-devel] hi

[dhruva k. b. <dhr...@gm...>]

Hi ! I am a graphics programmer. I have downloaded GMTL library to work in
graphics application. I am working in LINUX UBUNTU operating system. I am
trying to install GMTL in Linux. I have already installed scons and
build-essential. After installing scons n build-essential, when i tried to
install GMTL it is producing the following error.

scons: Reading SConscript files ...
AttributeError: 'module' object has no attribute 'options':
  File "/home/dhruva/Desktop/gmtl-0.5.4/SConstruct", line 30:
    except AttributeError: has_help_flag = SCons.Script.options.help_msg

Please help me as early as possible. I am not getting where the error is!
pls help me out! Thanks in advance

[ggt-devel] Police caught flatt-footed in caar chase

[Celesta P. <no...@th...>]

Hoi,

  
 

 
The chemist went on who asked you to come? You and every
hindu nationalist and every teacher. With ancient tapestry?the
old marquise, the friend forth into the wonderful mystic
twilight land on the death of her father and had used her
small.

Re: [ggt-devel] Error while compiling GMTL-0.5.4 on amd64

[Vikas N K. <vik...@us...>]

Thanks Patrick,
Problem solved.

--Vikas

Re: [ggt-devel] Error while compiling GMTL-0.5.4 on amd64

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

On Aug 18, 2008, at 3:41 PM, Vikas N Kumar wrote:

> Hi
>
> I have installed Scons-1.0.0 and that installed fine on my system.
>
> Now I am trying to compile gmtl-0.5.4  by typing "scons" and it gives
> me the following error.
>
> How do I fix this error ?
>
> user1@computer2$ scons
> scons: Reading SConscript files ...
> AttributeError: 'module' object has no attribute 'options':
>  File "/home/user1/libraries/gmtl-0.5.4/SConstruct", line 30:
>    except AttributeError: has_help_flag =  
> SCons.Script.options.help_msg

Try the attached patch or download revision 1.85 of SConstruct as a  
replacement for the 0.5.4 release version:

http://ggt.cvs.sourceforge.net/*checkout*/ggt/GGT/modules/GMTL/SConstruct?revision=1.85

  -Patrick


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