Menu
▾
▴
ggt-devel — Development discussion list
You can subscribe to this list here.
| 2002 |
Jan
(15) |
Feb
|
Mar
|
Apr
(8) |
May
(21) |
Jun
(7) |
Jul
(13) |
Aug
|
Sep
(5) |
Oct
(3) |
Nov
(2) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(9) |
Mar
(20) |
Apr
(13) |
May
(8) |
Jun
(6) |
Jul
|
Aug
|
Sep
(20) |
Oct
|
Nov
(2) |
Dec
|
| 2004 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(11) |
Aug
(3) |
Sep
(15) |
Oct
(3) |
Nov
(17) |
Dec
(1) |
| 2005 |
Jan
(1) |
Feb
(3) |
Mar
(5) |
Apr
(7) |
May
|
Jun
(14) |
Jul
(5) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(4) |
Sep
(12) |
Oct
(1) |
Nov
(3) |
Dec
(6) |
| 2007 |
Jan
(4) |
Feb
(18) |
Mar
(6) |
Apr
|
May
|
Jun
(36) |
Jul
(1) |
Aug
(9) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(12) |
Jul
(3) |
Aug
(6) |
Sep
(9) |
Oct
(9) |
Nov
(25) |
Dec
(5) |
| 2009 |
Jan
(7) |
Feb
(22) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
(2) |
Nov
(7) |
Dec
|
| 2011 |
Jan
|
Feb
(1) |
Mar
(19) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(2) |
Jun
|
Jul
|
Aug
(2) |
Sep
(2) |
Oct
(16) |
Nov
|
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
(3) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2011-03-27 18:32:33
|
Bugs item #3234230, was opened at 2011-03-22 03:12 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GMTL Group: HEAD Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Patrick Hartling (patrickh) Summary: AABox/AABox sweep intersection problem Initial Comment: Version: GMTL 0.5.2-1 deb The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2011-03-27 13:32 Message: Ignore my question. I didn't realize that the bug tracker showed comments in reverse chronological order. I now understand that the proposed change was incorrect. ---------------------------------------------------------------------- Comment By: Patrick Hartling (patrickh) Date: 2011-03-27 13:31 Message: The proposed patch causes a test case in the test suite to fail. Specifically, it breaks gmtlTest::IntersectionTest::testIntersectAABoxSweep() (see Test/TestSuite/TestCases/IntersectionTest.cpp). Does that mean that that test is incorrect or that the patch is incorrect? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-23 03:24 Message: Eek! I just looked at the patch I added and it is _wrong_. Really wrong. Sorry for the noise. If I come up with a better patch, I'll post it later. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-22 22:57 Message: Here's the patch that I am using to correct this problem. Sorry about the formatting -- I don't have a Sourceforge account, so I can't attach files. *** Intersection.h.orig 2011-03-22 20:54:30.198177237 -0700 --- /usr/include/gmtl-0.5.2/gmtl/Intersection.h 2011-03-22 20:54:36.771836476 -0700 *************** *** 152,157 **** --- 152,161 ---- { overlap1[i] = (box1.getMin()[i] - box2.getMax()[i]) / path[i]; } + else + { + return false; + } if ((box2.getMax()[i] > box1.getMin()[i]) && (path[i] < DATA_TYPE(0))) { *************** *** 161,166 **** --- 165,174 ---- { overlap2[i] = (box1.getMax()[i] - box2.getMin()[i]) / path[i]; } + else + { + return false; + } } // Calculate the first time of overlap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2011-03-27 18:31:25
|
Bugs item #3234230, was opened at 2011-03-22 03:12 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GMTL Group: HEAD Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Patrick Hartling (patrickh) Summary: AABox/AABox sweep intersection problem Initial Comment: Version: GMTL 0.5.2-1 deb The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2011-03-27 13:31 Message: The proposed patch causes a test case in the test suite to fail. Specifically, it breaks gmtlTest::IntersectionTest::testIntersectAABoxSweep() (see Test/TestSuite/TestCases/IntersectionTest.cpp). Does that mean that that test is incorrect or that the patch is incorrect? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-23 03:24 Message: Eek! I just looked at the patch I added and it is _wrong_. Really wrong. Sorry for the noise. If I come up with a better patch, I'll post it later. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-22 22:57 Message: Here's the patch that I am using to correct this problem. Sorry about the formatting -- I don't have a Sourceforge account, so I can't attach files. *** Intersection.h.orig 2011-03-22 20:54:30.198177237 -0700 --- /usr/include/gmtl-0.5.2/gmtl/Intersection.h 2011-03-22 20:54:36.771836476 -0700 *************** *** 152,157 **** --- 152,161 ---- { overlap1[i] = (box1.getMin()[i] - box2.getMax()[i]) / path[i]; } + else + { + return false; + } if ((box2.getMax()[i] > box1.getMin()[i]) && (path[i] < DATA_TYPE(0))) { *************** *** 161,166 **** --- 165,174 ---- { overlap2[i] = (box1.getMax()[i] - box2.getMin()[i]) / path[i]; } + else + { + return false; + } } // Calculate the first time of overlap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 |
|
From: Patrick H. <pat...@gm...> - 2011-03-27 17:12:48
|
On Mar 11, 2011, at 3:05 AM, Sebastian Messerschmidt wrote: > Hi, > > the current trunk includes the cppunittest library. Unfortunately it > doesn't state which version is used. > After trying a few of the newer versions, I still didn't manage to get > the TestSuite running, as there are files that don't seem to be coming > with cppunittest originally. > Can someone provide me some info where to find, or send me the > cppunittest lib used for testing? > > I'd rather like to test my changes extensively against the unit tests > before committing ;-) Try the version from the VR Juggler SVN repository: http://code.google.com/p/vrjuggler/source/browse/#svn%2Fvendor%2Fcppunit%2F1.12.0 -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: SourceForge.net <no...@so...> - 2011-03-25 13:35:33
|
Bugs item #3234230, was opened at 2011-03-22 03:12 Message generated for change (Settings changed) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GMTL >Group: HEAD Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) >Assigned to: Patrick Hartling (patrickh) Summary: AABox/AABox sweep intersection problem Initial Comment: Version: GMTL 0.5.2-1 deb The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-23 03:24 Message: Eek! I just looked at the patch I added and it is _wrong_. Really wrong. Sorry for the noise. If I come up with a better patch, I'll post it later. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-22 22:57 Message: Here's the patch that I am using to correct this problem. Sorry about the formatting -- I don't have a Sourceforge account, so I can't attach files. *** Intersection.h.orig 2011-03-22 20:54:30.198177237 -0700 --- /usr/include/gmtl-0.5.2/gmtl/Intersection.h 2011-03-22 20:54:36.771836476 -0700 *************** *** 152,157 **** --- 152,161 ---- { overlap1[i] = (box1.getMin()[i] - box2.getMax()[i]) / path[i]; } + else + { + return false; + } if ((box2.getMax()[i] > box1.getMin()[i]) && (path[i] < DATA_TYPE(0))) { *************** *** 161,166 **** --- 165,174 ---- { overlap2[i] = (box1.getMax()[i] - box2.getMin()[i]) / path[i]; } + else + { + return false; + } } // Calculate the first time of overlap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2011-03-23 08:24:38
|
Bugs item #3234230, was opened at 2011-03-22 08:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GMTL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: AABox/AABox sweep intersection problem Initial Comment: Version: GMTL 0.5.2-1 deb The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-23 08:24 Message: Eek! I just looked at the patch I added and it is _wrong_. Really wrong. Sorry for the noise. If I come up with a better patch, I'll post it later. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-23 03:57 Message: Here's the patch that I am using to correct this problem. Sorry about the formatting -- I don't have a Sourceforge account, so I can't attach files. *** Intersection.h.orig 2011-03-22 20:54:30.198177237 -0700 --- /usr/include/gmtl-0.5.2/gmtl/Intersection.h 2011-03-22 20:54:36.771836476 -0700 *************** *** 152,157 **** --- 152,161 ---- { overlap1[i] = (box1.getMin()[i] - box2.getMax()[i]) / path[i]; } + else + { + return false; + } if ((box2.getMax()[i] > box1.getMin()[i]) && (path[i] < DATA_TYPE(0))) { *************** *** 161,166 **** --- 165,174 ---- { overlap2[i] = (box1.getMax()[i] - box2.getMin()[i]) / path[i]; } + else + { + return false; + } } // Calculate the first time of overlap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2011-03-23 03:57:00
|
Bugs item #3234230, was opened at 2011-03-22 08:12 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GMTL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: AABox/AABox sweep intersection problem Initial Comment: Version: GMTL 0.5.2-1 deb The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2011-03-23 03:57 Message: Here's the patch that I am using to correct this problem. Sorry about the formatting -- I don't have a Sourceforge account, so I can't attach files. *** Intersection.h.orig 2011-03-22 20:54:30.198177237 -0700 --- /usr/include/gmtl-0.5.2/gmtl/Intersection.h 2011-03-22 20:54:36.771836476 -0700 *************** *** 152,157 **** --- 152,161 ---- { overlap1[i] = (box1.getMin()[i] - box2.getMax()[i]) / path[i]; } + else + { + return false; + } if ((box2.getMax()[i] > box1.getMin()[i]) && (path[i] < DATA_TYPE(0))) { *************** *** 161,166 **** --- 165,174 ---- { overlap2[i] = (box1.getMax()[i] - box2.getMin()[i]) / path[i]; } + else + { + return false; + } } // Calculate the first time of overlap ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2011-03-22 08:12:39
|
Bugs item #3234230, was opened at 2011-03-22 08:12 Message generated for change (Tracker Item Submitted) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: GMTL Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: AABox/AABox sweep intersection problem Initial Comment: Version: GMTL 0.5.2-1 deb The attached file demonstrates that the AABox/AABox sweep intersection test returns a false positive if any component of the relative velocity of the two boxes is zero. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3234230&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2011-03-12 13:56:37
|
Bugs item #3172856, was opened at 2011-02-04 11:33 Message generated for change (Settings changed) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3172856&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: Ryan Pavlik () >Assigned to: Patrick Hartling (patrickh) Summary: Mac OS X: Build error if Python isn't in a framework Initial Comment: If the active python version isn't in a framework, even if the python bindings are not being built, the scons file crashes because it assumes the regex will be matched. Patch attached that does not change behavior on systems where the existing build works, and prevents crashing on other systems. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2011-03-12 07:56 Message: Fixed by r1266. Thanks for the patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3172856&group_id=43735 |
|
From: Sebastian M. <seb...@gm...> - 2011-03-11 10:06:52
|
Hi, attached you'll find a diff against the trunk revision containing a new function for determining the closest point on triangle to a given point cheers Sebastian |
|
From: Sebastian M. <seb...@gm...> - 2011-03-11 09:57:26
|
Hi, attached you'll find a diff against the trunk revision containing them missing function for Tri vs LineSeg intersection which ignores the triangle winding (i.e. double sided intersection) I've made this patch against the original, instead of applying it to the previous patch i've sent. I hope this okay. cheers Sebastian |
|
From: Sebastian M. <seb...@gm...> - 2011-03-11 09:38:27
|
Hi, attached you'll find a diff against the trunk revision containing a new function for Sphere vs Sphere intersection. cheers Sebastian |
|
From: Sebastian M. <seb...@gm...> - 2011-03-11 09:05:45
|
Hi, the current trunk includes the cppunittest library. Unfortunately it doesn't state which version is used. After trying a few of the newer versions, I still didn't manage to get the TestSuite running, as there are files that don't seem to be coming with cppunittest originally. Can someone provide me some info where to find, or send me the cppunittest lib used for testing? I'd rather like to test my changes extensively against the unit tests before committing ;-) cheers Sebastian |
|
From: Patrick H. <pat...@gm...> - 2011-03-11 01:49:45
|
On Mar 10, 2011, at 9:23 AM, Sebastian Messerschmidt wrote: > Am 10.03.2011 16:12, schrieb Patrick Hartling: >> On Mar 10, 2011, at 8:27 AM, Sebastian Messerschmidt wrote: >> >>> Todd, >>>> Sebastian, >>>> >>>> I'm interested in seeing GMTL maintained& updated as well, and it >>>> sounds like you have some valuable additions. I'll let the project >>>> admins chime in as to how you can submit patches. >>>> >>>> I don't think the boost-related code should be part of GMTL, but it >>>> sounds like you have the foundation for maybe a gmtl-boost header library? >>> There is already boost related code in the Misc/MatrixConvert.h . IIRC >>> it is invoked only if you include certain header files explicitly. >>> For my includes you would have to include the gmtl_serializers.h only if >>> you need to serialize via boost. >>> I think that'd be a viable solution, because gmtl is header only, so it >>> won't harm to deploy a number of extra headers which not mandatory to use. >> I agree. >> >>>> 10/2011 5:25 AM, Sebastian Messerschmidt wrote: >>>>> Hi, >>>>> >>>>> it's been a while since I've heard anything from this list. >>>>> If it is still active I'd have to requests/questions. >>>>> >>>>> 1. I've extended some of stuff in the gmtl library, and like to submit >>>>> them for a review. >>>>> Namely I've added some new functions: >>>>> >>>>> 1.1 A trivial sphere sphere intersection test (I didn't find one) >>>>> >>>>> bool intersect(const Sphere<DATA_TYPE>& sphere1, const >>>>> Sphere<DATA_TYPE>& sphere2) >>>>> >>>>> 1.2 double sided intersection function for Triangles and LineSegments >>>>> (my last contribution only contained the ray intersection) >>>>> >>>>> template<class DATA_TYPE> >>>>> bool intersectDoubleSided( const Tri<DATA_TYPE>& tri, const >>>>> LineSeg<DATA_TYPE>& lineseg, >>>>> DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t ) >>>>> >>>>> 1.3 TriOps: Closest point to triangle >>>>> >>>>> template< class DATA_TYPE> >>>>> Point<DATA_TYPE, 3> findNearestPt( const Tri<DATA_TYPE>& tri, >>>>> const Point<DATA_TYPE, 3>& pt ) >>>>> >>>>> >>>>> >>>>> 2. Furthermore I'd like to discuss some topics, that might be beneficial >>>>> to the gmtl library. >>>>> >>>>> 2.1 Issues with the epsilon values used inside some of the functions e.g. >>>>> template<typename DEST_TYPE, typename DATA_TYPE> >>>>> inline DEST_TYPE& setRot( DEST_TYPE& result, const Vec<DATA_TYPE, >>>>> 3>& from, const Vec<DATA_TYPE, 3>& to ) >>>>> >>>>> I've had to change the epsilon here, else the from and to vectors where >>>>> considered to be close enough for long distance camera aiming. >>>>> To solve this problem in general, I also have proposed a generalized fix >>>>> on the bug list. It involves templated type dependent epsilon usage >>>>> >>>>> 2.2 There are still issues with inconsistent interfaces for some of the >>>>> intersect functions: >>>>> >>>>> E.g. >>>>> >>>>> inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray, >>>>> int& numhits, T& t0, T& t1 ) >>>>> >>>>> inline bool intersectVolume( const Sphere<T>& sphere, const >>>>> LineSeg<T>& ray, int& numhits, T& t0, T& t1 ) >>>>> >>>>> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >>>>> ray, int& numhits, T& t0, T& t1 ) >>>>> >>>>> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >>>>> ray, int& numhits, T& t0, T& t1 ) >>>>> >>>>> Those functions are all taking integers for the numhits ref. Other >>>>> intersect functions take unsigned int. I think this is fairly >>>>> inconsistent, and bugs me. >>>>> The reason I would rather set them all to unsigned int is simple: I have >>>>> some template functions that unify and wrap those functions. Right now I >>>>> cannot use them for all intersect functions on the trunk-rev, >>>>> since type inference will not allow for int/unsigned int mixtures. >>>>> >>>>> 2.3. There has been a submission of mine ( like ages ago) concerning the >>>>> Box/LineSeg intersection test. >>>>> In my eyes, the early out test should be different to encompass >>>>> LineSegments completely behind the box: >>>>> >>>>> Instead of: >>>>> if (tIn< 0.0&& tOut> 1.0) >>>>> I'd rather advocate for: >>>>> if (tIn< 0.0&& tOut> DATA_TYPE(1)|| tIn> DATA_TYPE(1)&& tOut> >>>>> DATA_TYPE(1)) >>>>> >>>>> >>>>> 2.4. I had to add private assignment operators in the VecBase and >>>>> VecBinaryExpr classes to satisfy my compiler. These are trivial changes, >>>>> but I'd like to see them reviewed and added. >>>>> >>>>> >>>>> 2.5 I've experimented with Metaprogramming for Vector, Matrix >>>>> constructors (eliminating the nested loop in the matrix and get it >>>>> replaced to "fload"). >>>>> >>>>> 2.6. I've implemented non-intrusive boost::serialization functions for >>>>> VecBase, Tri, Matrix, Quat, AABox and Sphere. If anyone is interested. >>>>> >>>>> 2.7 boost::hash based hash functions for some gmtl types (Matrix and >>>>> VecBase) >>>>> >>>>> So how do I submit my proposals? Splitting this stuff up into smaller >>>>> chunks shouldn't be a problem. >>>>> I'd be happy to hear your opinions. >> These all sound like great improvements. If you could break things up into multiple patches, that would help me review them. The GMTL issue tracker is pretty far off my radar, so if you have submitted patches through it that have gone unnoticed, I apologize for that. Submitting them through this mailing list makes it easier for me to keep track of things. > Okay, the remaining question is the format of the patches. Do you want > diffs, complete files, svn patches? Unified or context diffs work best for me. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Sebastian M. <seb...@gm...> - 2011-03-10 15:23:15
|
Am 10.03.2011 16:12, schrieb Patrick Hartling: > On Mar 10, 2011, at 8:27 AM, Sebastian Messerschmidt wrote: > >> Todd, >>> Sebastian, >>> >>> I'm interested in seeing GMTL maintained& updated as well, and it >>> sounds like you have some valuable additions. I'll let the project >>> admins chime in as to how you can submit patches. >>> >>> I don't think the boost-related code should be part of GMTL, but it >>> sounds like you have the foundation for maybe a gmtl-boost header library? >> There is already boost related code in the Misc/MatrixConvert.h . IIRC >> it is invoked only if you include certain header files explicitly. >> For my includes you would have to include the gmtl_serializers.h only if >> you need to serialize via boost. >> I think that'd be a viable solution, because gmtl is header only, so it >> won't harm to deploy a number of extra headers which not mandatory to use. > I agree. > >>> 10/2011 5:25 AM, Sebastian Messerschmidt wrote: >>>> Hi, >>>> >>>> it's been a while since I've heard anything from this list. >>>> If it is still active I'd have to requests/questions. >>>> >>>> 1. I've extended some of stuff in the gmtl library, and like to submit >>>> them for a review. >>>> Namely I've added some new functions: >>>> >>>> 1.1 A trivial sphere sphere intersection test (I didn't find one) >>>> >>>> bool intersect(const Sphere<DATA_TYPE>& sphere1, const >>>> Sphere<DATA_TYPE>& sphere2) >>>> >>>> 1.2 double sided intersection function for Triangles and LineSegments >>>> (my last contribution only contained the ray intersection) >>>> >>>> template<class DATA_TYPE> >>>> bool intersectDoubleSided( const Tri<DATA_TYPE>& tri, const >>>> LineSeg<DATA_TYPE>& lineseg, >>>> DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t ) >>>> >>>> 1.3 TriOps: Closest point to triangle >>>> >>>> template< class DATA_TYPE> >>>> Point<DATA_TYPE, 3> findNearestPt( const Tri<DATA_TYPE>& tri, >>>> const Point<DATA_TYPE, 3>& pt ) >>>> >>>> >>>> >>>> 2. Furthermore I'd like to discuss some topics, that might be beneficial >>>> to the gmtl library. >>>> >>>> 2.1 Issues with the epsilon values used inside some of the functions e.g. >>>> template<typename DEST_TYPE, typename DATA_TYPE> >>>> inline DEST_TYPE& setRot( DEST_TYPE& result, const Vec<DATA_TYPE, >>>> 3>& from, const Vec<DATA_TYPE, 3>& to ) >>>> >>>> I've had to change the epsilon here, else the from and to vectors where >>>> considered to be close enough for long distance camera aiming. >>>> To solve this problem in general, I also have proposed a generalized fix >>>> on the bug list. It involves templated type dependent epsilon usage >>>> >>>> 2.2 There are still issues with inconsistent interfaces for some of the >>>> intersect functions: >>>> >>>> E.g. >>>> >>>> inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray, >>>> int& numhits, T& t0, T& t1 ) >>>> >>>> inline bool intersectVolume( const Sphere<T>& sphere, const >>>> LineSeg<T>& ray, int& numhits, T& t0, T& t1 ) >>>> >>>> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >>>> ray, int& numhits, T& t0, T& t1 ) >>>> >>>> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >>>> ray, int& numhits, T& t0, T& t1 ) >>>> >>>> Those functions are all taking integers for the numhits ref. Other >>>> intersect functions take unsigned int. I think this is fairly >>>> inconsistent, and bugs me. >>>> The reason I would rather set them all to unsigned int is simple: I have >>>> some template functions that unify and wrap those functions. Right now I >>>> cannot use them for all intersect functions on the trunk-rev, >>>> since type inference will not allow for int/unsigned int mixtures. >>>> >>>> 2.3. There has been a submission of mine ( like ages ago) concerning the >>>> Box/LineSeg intersection test. >>>> In my eyes, the early out test should be different to encompass >>>> LineSegments completely behind the box: >>>> >>>> Instead of: >>>> if (tIn< 0.0&& tOut> 1.0) >>>> I'd rather advocate for: >>>> if (tIn< 0.0&& tOut> DATA_TYPE(1)|| tIn> DATA_TYPE(1)&& tOut> >>>> DATA_TYPE(1)) >>>> >>>> >>>> 2.4. I had to add private assignment operators in the VecBase and >>>> VecBinaryExpr classes to satisfy my compiler. These are trivial changes, >>>> but I'd like to see them reviewed and added. >>>> >>>> >>>> 2.5 I've experimented with Metaprogramming for Vector, Matrix >>>> constructors (eliminating the nested loop in the matrix and get it >>>> replaced to "fload"). >>>> >>>> 2.6. I've implemented non-intrusive boost::serialization functions for >>>> VecBase, Tri, Matrix, Quat, AABox and Sphere. If anyone is interested. >>>> >>>> 2.7 boost::hash based hash functions for some gmtl types (Matrix and >>>> VecBase) >>>> >>>> So how do I submit my proposals? Splitting this stuff up into smaller >>>> chunks shouldn't be a problem. >>>> I'd be happy to hear your opinions. > These all sound like great improvements. If you could break things up into multiple patches, that would help me review them. The GMTL issue tracker is pretty far off my radar, so if you have submitted patches through it that have gone unnoticed, I apologize for that. Submitting them through this mailing list makes it easier for me to keep track of things. Okay, the remaining question is the format of the patches. Do you want diffs, complete files, svn patches? > -Patrick > > > -- > Patrick L. Hartling > Senior Software Engineer, Priority 5 > http://www.priority5.com/ > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > > |
|
From: Patrick H. <pat...@gm...> - 2011-03-10 15:12:42
|
On Mar 10, 2011, at 8:27 AM, Sebastian Messerschmidt wrote: > Todd, >> Sebastian, >> >> I'm interested in seeing GMTL maintained& updated as well, and it >> sounds like you have some valuable additions. I'll let the project >> admins chime in as to how you can submit patches. >> >> I don't think the boost-related code should be part of GMTL, but it >> sounds like you have the foundation for maybe a gmtl-boost header library? > There is already boost related code in the Misc/MatrixConvert.h . IIRC > it is invoked only if you include certain header files explicitly. > For my includes you would have to include the gmtl_serializers.h only if > you need to serialize via boost. > I think that'd be a viable solution, because gmtl is header only, so it > won't harm to deploy a number of extra headers which not mandatory to use. I agree. >> 10/2011 5:25 AM, Sebastian Messerschmidt wrote: >>> Hi, >>> >>> it's been a while since I've heard anything from this list. >>> If it is still active I'd have to requests/questions. >>> >>> 1. I've extended some of stuff in the gmtl library, and like to submit >>> them for a review. >>> Namely I've added some new functions: >>> >>> 1.1 A trivial sphere sphere intersection test (I didn't find one) >>> >>> bool intersect(const Sphere<DATA_TYPE>& sphere1, const >>> Sphere<DATA_TYPE>& sphere2) >>> >>> 1.2 double sided intersection function for Triangles and LineSegments >>> (my last contribution only contained the ray intersection) >>> >>> template<class DATA_TYPE> >>> bool intersectDoubleSided( const Tri<DATA_TYPE>& tri, const >>> LineSeg<DATA_TYPE>& lineseg, >>> DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t ) >>> >>> 1.3 TriOps: Closest point to triangle >>> >>> template< class DATA_TYPE> >>> Point<DATA_TYPE, 3> findNearestPt( const Tri<DATA_TYPE>& tri, >>> const Point<DATA_TYPE, 3>& pt ) >>> >>> >>> >>> 2. Furthermore I'd like to discuss some topics, that might be beneficial >>> to the gmtl library. >>> >>> 2.1 Issues with the epsilon values used inside some of the functions e.g. >>> template<typename DEST_TYPE, typename DATA_TYPE> >>> inline DEST_TYPE& setRot( DEST_TYPE& result, const Vec<DATA_TYPE, >>> 3>& from, const Vec<DATA_TYPE, 3>& to ) >>> >>> I've had to change the epsilon here, else the from and to vectors where >>> considered to be close enough for long distance camera aiming. >>> To solve this problem in general, I also have proposed a generalized fix >>> on the bug list. It involves templated type dependent epsilon usage >>> >>> 2.2 There are still issues with inconsistent interfaces for some of the >>> intersect functions: >>> >>> E.g. >>> >>> inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray, >>> int& numhits, T& t0, T& t1 ) >>> >>> inline bool intersectVolume( const Sphere<T>& sphere, const >>> LineSeg<T>& ray, int& numhits, T& t0, T& t1 ) >>> >>> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >>> ray, int& numhits, T& t0, T& t1 ) >>> >>> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >>> ray, int& numhits, T& t0, T& t1 ) >>> >>> Those functions are all taking integers for the numhits ref. Other >>> intersect functions take unsigned int. I think this is fairly >>> inconsistent, and bugs me. >>> The reason I would rather set them all to unsigned int is simple: I have >>> some template functions that unify and wrap those functions. Right now I >>> cannot use them for all intersect functions on the trunk-rev, >>> since type inference will not allow for int/unsigned int mixtures. >>> >>> 2.3. There has been a submission of mine ( like ages ago) concerning the >>> Box/LineSeg intersection test. >>> In my eyes, the early out test should be different to encompass >>> LineSegments completely behind the box: >>> >>> Instead of: >>> if (tIn< 0.0&& tOut> 1.0) >>> I'd rather advocate for: >>> if (tIn< 0.0&& tOut> DATA_TYPE(1)|| tIn> DATA_TYPE(1)&& tOut> >>> DATA_TYPE(1)) >>> >>> >>> 2.4. I had to add private assignment operators in the VecBase and >>> VecBinaryExpr classes to satisfy my compiler. These are trivial changes, >>> but I'd like to see them reviewed and added. >>> >>> >>> 2.5 I've experimented with Metaprogramming for Vector, Matrix >>> constructors (eliminating the nested loop in the matrix and get it >>> replaced to "fload"). >>> >>> 2.6. I've implemented non-intrusive boost::serialization functions for >>> VecBase, Tri, Matrix, Quat, AABox and Sphere. If anyone is interested. >>> >>> 2.7 boost::hash based hash functions for some gmtl types (Matrix and >>> VecBase) >>> >>> So how do I submit my proposals? Splitting this stuff up into smaller >>> chunks shouldn't be a problem. >>> I'd be happy to hear your opinions. These all sound like great improvements. If you could break things up into multiple patches, that would help me review them. The GMTL issue tracker is pretty far off my radar, so if you have submitted patches through it that have gone unnoticed, I apologize for that. Submitting them through this mailing list makes it easier for me to keep track of things. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Sebastian M. <seb...@gm...> - 2011-03-10 14:27:04
|
Todd, > Sebastian, > > I'm interested in seeing GMTL maintained& updated as well, and it > sounds like you have some valuable additions. I'll let the project > admins chime in as to how you can submit patches. > > I don't think the boost-related code should be part of GMTL, but it > sounds like you have the foundation for maybe a gmtl-boost header library? There is already boost related code in the Misc/MatrixConvert.h . IIRC it is invoked only if you include certain header files explicitly. For my includes you would have to include the gmtl_serializers.h only if you need to serialize via boost. I think that'd be a viable solution, because gmtl is header only, so it won't harm to deploy a number of extra headers which not mandatory to use. cheers Sebastian > Regards, > Todd > > On 3/10/2011 5:25 AM, Sebastian Messerschmidt wrote: >> Hi, >> >> it's been a while since I've heard anything from this list. >> If it is still active I'd have to requests/questions. >> >> 1. I've extended some of stuff in the gmtl library, and like to submit >> them for a review. >> Namely I've added some new functions: >> >> 1.1 A trivial sphere sphere intersection test (I didn't find one) >> >> bool intersect(const Sphere<DATA_TYPE>& sphere1, const >> Sphere<DATA_TYPE>& sphere2) >> >> 1.2 double sided intersection function for Triangles and LineSegments >> (my last contribution only contained the ray intersection) >> >> template<class DATA_TYPE> >> bool intersectDoubleSided( const Tri<DATA_TYPE>& tri, const >> LineSeg<DATA_TYPE>& lineseg, >> DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t ) >> >> 1.3 TriOps: Closest point to triangle >> >> template< class DATA_TYPE> >> Point<DATA_TYPE, 3> findNearestPt( const Tri<DATA_TYPE>& tri, >> const Point<DATA_TYPE, 3>& pt ) >> >> >> >> 2. Furthermore I'd like to discuss some topics, that might be beneficial >> to the gmtl library. >> >> 2.1 Issues with the epsilon values used inside some of the functions e.g. >> template<typename DEST_TYPE, typename DATA_TYPE> >> inline DEST_TYPE& setRot( DEST_TYPE& result, const Vec<DATA_TYPE, >> 3>& from, const Vec<DATA_TYPE, 3>& to ) >> >> I've had to change the epsilon here, else the from and to vectors where >> considered to be close enough for long distance camera aiming. >> To solve this problem in general, I also have proposed a generalized fix >> on the bug list. It involves templated type dependent epsilon usage >> >> 2.2 There are still issues with inconsistent interfaces for some of the >> intersect functions: >> >> E.g. >> >> inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray, >> int& numhits, T& t0, T& t1 ) >> >> inline bool intersectVolume( const Sphere<T>& sphere, const >> LineSeg<T>& ray, int& numhits, T& t0, T& t1 ) >> >> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >> ray, int& numhits, T& t0, T& t1 ) >> >> inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& >> ray, int& numhits, T& t0, T& t1 ) >> >> Those functions are all taking integers for the numhits ref. Other >> intersect functions take unsigned int. I think this is fairly >> inconsistent, and bugs me. >> The reason I would rather set them all to unsigned int is simple: I have >> some template functions that unify and wrap those functions. Right now I >> cannot use them for all intersect functions on the trunk-rev, >> since type inference will not allow for int/unsigned int mixtures. >> >> 2.3. There has been a submission of mine ( like ages ago) concerning the >> Box/LineSeg intersection test. >> In my eyes, the early out test should be different to encompass >> LineSegments completely behind the box: >> >> Instead of: >> if (tIn< 0.0&& tOut> 1.0) >> I'd rather advocate for: >> if (tIn< 0.0&& tOut> DATA_TYPE(1)|| tIn> DATA_TYPE(1)&& tOut> >> DATA_TYPE(1)) >> >> >> 2.4. I had to add private assignment operators in the VecBase and >> VecBinaryExpr classes to satisfy my compiler. These are trivial changes, >> but I'd like to see them reviewed and added. >> >> >> 2.5 I've experimented with Metaprogramming for Vector, Matrix >> constructors (eliminating the nested loop in the matrix and get it >> replaced to "fload"). >> >> 2.6. I've implemented non-intrusive boost::serialization functions for >> VecBase, Tri, Matrix, Quat, AABox and Sphere. If anyone is interested. >> >> 2.7 boost::hash based hash functions for some gmtl types (Matrix and >> VecBase) >> >> So how do I submit my proposals? Splitting this stuff up into smaller >> chunks shouldn't be a problem. >> I'd be happy to hear your opinions. >> >> >> cheers >> Sebastian >> >> >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> ggt-devel mailing list >> ggt...@li... >> https://lists.sourceforge.net/lists/listinfo/ggt-devel > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > |
|
From: Todd J. F. <to...@in...> - 2011-03-10 14:16:37
|
Sebastian, I'm interested in seeing GMTL maintained & updated as well, and it sounds like you have some valuable additions. I'll let the project admins chime in as to how you can submit patches. I don't think the boost-related code should be part of GMTL, but it sounds like you have the foundation for maybe a gmtl-boost header library? Regards, Todd On 3/10/2011 5:25 AM, Sebastian Messerschmidt wrote: > Hi, > > it's been a while since I've heard anything from this list. > If it is still active I'd have to requests/questions. > > 1. I've extended some of stuff in the gmtl library, and like to submit > them for a review. > Namely I've added some new functions: > > 1.1 A trivial sphere sphere intersection test (I didn't find one) > > bool intersect(const Sphere<DATA_TYPE>& sphere1, const > Sphere<DATA_TYPE>& sphere2) > > 1.2 double sided intersection function for Triangles and LineSegments > (my last contribution only contained the ray intersection) > > template<class DATA_TYPE> > bool intersectDoubleSided( const Tri<DATA_TYPE>& tri, const > LineSeg<DATA_TYPE>& lineseg, > DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t ) > > 1.3 TriOps: Closest point to triangle > > template< class DATA_TYPE> > Point<DATA_TYPE, 3> findNearestPt( const Tri<DATA_TYPE>& tri, > const Point<DATA_TYPE, 3>& pt ) > > > > 2. Furthermore I'd like to discuss some topics, that might be beneficial > to the gmtl library. > > 2.1 Issues with the epsilon values used inside some of the functions e.g. > template<typename DEST_TYPE, typename DATA_TYPE> > inline DEST_TYPE& setRot( DEST_TYPE& result, const Vec<DATA_TYPE, > 3>& from, const Vec<DATA_TYPE, 3>& to ) > > I've had to change the epsilon here, else the from and to vectors where > considered to be close enough for long distance camera aiming. > To solve this problem in general, I also have proposed a generalized fix > on the bug list. It involves templated type dependent epsilon usage > > 2.2 There are still issues with inconsistent interfaces for some of the > intersect functions: > > E.g. > > inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray, > int& numhits, T& t0, T& t1 ) > > inline bool intersectVolume( const Sphere<T>& sphere, const > LineSeg<T>& ray, int& numhits, T& t0, T& t1 ) > > inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& > ray, int& numhits, T& t0, T& t1 ) > > inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>& > ray, int& numhits, T& t0, T& t1 ) > > Those functions are all taking integers for the numhits ref. Other > intersect functions take unsigned int. I think this is fairly > inconsistent, and bugs me. > The reason I would rather set them all to unsigned int is simple: I have > some template functions that unify and wrap those functions. Right now I > cannot use them for all intersect functions on the trunk-rev, > since type inference will not allow for int/unsigned int mixtures. > > 2.3. There has been a submission of mine ( like ages ago) concerning the > Box/LineSeg intersection test. > In my eyes, the early out test should be different to encompass > LineSegments completely behind the box: > > Instead of: > if (tIn< 0.0&& tOut> 1.0) > I'd rather advocate for: > if (tIn< 0.0&& tOut> DATA_TYPE(1)|| tIn> DATA_TYPE(1)&& tOut> > DATA_TYPE(1)) > > > 2.4. I had to add private assignment operators in the VecBase and > VecBinaryExpr classes to satisfy my compiler. These are trivial changes, > but I'd like to see them reviewed and added. > > > 2.5 I've experimented with Metaprogramming for Vector, Matrix > constructors (eliminating the nested loop in the matrix and get it > replaced to "fload"). > > 2.6. I've implemented non-intrusive boost::serialization functions for > VecBase, Tri, Matrix, Quat, AABox and Sphere. If anyone is interested. > > 2.7 boost::hash based hash functions for some gmtl types (Matrix and > VecBase) > > So how do I submit my proposals? Splitting this stuff up into smaller > chunks shouldn't be a problem. > I'd be happy to hear your opinions. > > > cheers > Sebastian > > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel |
|
From: Sebastian M. <seb...@gm...> - 2011-03-10 10:25:41
|
Hi,
it's been a while since I've heard anything from this list.
If it is still active I'd have to requests/questions.
1. I've extended some of stuff in the gmtl library, and like to submit
them for a review.
Namely I've added some new functions:
1.1 A trivial sphere sphere intersection test (I didn't find one)
bool intersect(const Sphere<DATA_TYPE>& sphere1, const
Sphere<DATA_TYPE>& sphere2)
1.2 double sided intersection function for Triangles and LineSegments
(my last contribution only contained the ray intersection)
template<class DATA_TYPE>
bool intersectDoubleSided( const Tri<DATA_TYPE>& tri, const
LineSeg<DATA_TYPE>& lineseg,
DATA_TYPE& u, DATA_TYPE& v, DATA_TYPE& t )
1.3 TriOps: Closest point to triangle
template< class DATA_TYPE >
Point<DATA_TYPE, 3> findNearestPt( const Tri<DATA_TYPE>& tri,
const Point<DATA_TYPE, 3>& pt )
2. Furthermore I'd like to discuss some topics, that might be beneficial
to the gmtl library.
2.1 Issues with the epsilon values used inside some of the functions e.g.
template <typename DEST_TYPE, typename DATA_TYPE>
inline DEST_TYPE& setRot( DEST_TYPE& result, const Vec<DATA_TYPE,
3>& from, const Vec<DATA_TYPE, 3>& to )
I've had to change the epsilon here, else the from and to vectors where
considered to be close enough for long distance camera aiming.
To solve this problem in general, I also have proposed a generalized fix
on the bug list. It involves templated type dependent epsilon usage
2.2 There are still issues with inconsistent interfaces for some of the
intersect functions:
E.g.
inline bool intersect( const Sphere<T>& sphere, const Ray<T>& ray,
int& numhits, T& t0, T& t1 )
inline bool intersectVolume( const Sphere<T>& sphere, const
LineSeg<T>& ray, int& numhits, T& t0, T& t1 )
inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>&
ray, int& numhits, T& t0, T& t1 )
inline bool intersectVolume( const Sphere<T>& sphere, const Ray<T>&
ray, int& numhits, T& t0, T& t1 )
Those functions are all taking integers for the numhits ref. Other
intersect functions take unsigned int. I think this is fairly
inconsistent, and bugs me.
The reason I would rather set them all to unsigned int is simple: I have
some template functions that unify and wrap those functions. Right now I
cannot use them for all intersect functions on the trunk-rev,
since type inference will not allow for int/unsigned int mixtures.
2.3. There has been a submission of mine ( like ages ago) concerning the
Box/LineSeg intersection test.
In my eyes, the early out test should be different to encompass
LineSegments completely behind the box:
Instead of:
if (tIn < 0.0 && tOut > 1.0)
I'd rather advocate for:
if (tIn < 0.0 && tOut > DATA_TYPE(1)|| tIn > DATA_TYPE(1) && tOut >
DATA_TYPE(1))
2.4. I had to add private assignment operators in the VecBase and
VecBinaryExpr classes to satisfy my compiler. These are trivial changes,
but I'd like to see them reviewed and added.
2.5 I've experimented with Metaprogramming for Vector, Matrix
constructors (eliminating the nested loop in the matrix and get it
replaced to "fload").
2.6. I've implemented non-intrusive boost::serialization functions for
VecBase, Tri, Matrix, Quat, AABox and Sphere. If anyone is interested.
2.7 boost::hash based hash functions for some gmtl types (Matrix and
VecBase)
So how do I submit my proposals? Splitting this stuff up into smaller
chunks shouldn't be a problem.
I'd be happy to hear your opinions.
cheers
Sebastian
|
|
From: SourceForge.net <no...@so...> - 2011-02-04 17:33:35
|
Bugs item #3172856, was opened at 2011-02-04 17:33 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3172856&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: Ryan Pavlik () Assigned to: Nobody/Anonymous (nobody) Summary: Mac OS X: Build error if Python isn't in a framework Initial Comment: If the active python version isn't in a framework, even if the python bindings are not being built, the scons file crashes because it assumes the regex will be matched. Patch attached that does not change behavior on systems where the existing build works, and prevents crashing on other systems. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3172856&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2010-11-21 18:05:41
|
Feature Requests item #3102319, was opened at 2010-11-03 11:39 Message generated for change (Comment added) made by patrickh 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: Closed >Resolution: Fixed 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... ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-11-21 12:05 Message: Your patch was applied in r1264 Thanks for the submission. ---------------------------------------------------------------------- Comment By: Patrick Hartling (patrickh) Date: 2010-11-21 11:59 Message: Backing out part of r1188 will probably take care of most of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437250&aid=3102319&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2010-11-21 17:59:51
|
Feature Requests item #3102319, was opened at 2010-11-03 11:39 Message generated for change (Comment added) made by patrickh 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... ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-11-21 11:59 Message: Backing out part of r1188 will probably take care of most of this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437250&aid=3102319&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2010-11-21 17:58:00
|
Bugs item #3103753, was opened at 2010-11-05 12:56 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103753&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: Johannes Zarl (isilmendil) >Assigned to: Patrick Hartling (patrickh) Summary: gmtl/Sphere.h: extra ';' Initial Comment: g++ 4.4.5 warns about an extra semicolon in Sphere.h: gmtl-0.6.1/gmtl/Sphere.h:109: warning: extra ‘;’ ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-11-21 11:58 Message: This bug has been fixed by r1262. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103753&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2010-11-21 17:57:26
|
Bugs item #3103757, was opened at 2010-11-05 13:04 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103757&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: Johannes Zarl (isilmendil) >Assigned to: Patrick Hartling (patrickh) Summary: gmtl/Numerics/Eigen.h references non-existing include file Initial Comment: gmtl/Numerics/Eigen.h includes the file <gmtl/gmtlConfig.h>, which apparently was removed a while ago (2002-05-20). ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-11-21 11:57 Message: This bug has been fixed by r1263. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103757&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2010-11-05 18:04:27
|
Bugs item #3103757, was opened at 2010-11-05 19:04 Message generated for change (Tracker Item Submitted) made by isilmendil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103757&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: Johannes Zarl (isilmendil) Assigned to: Nobody/Anonymous (nobody) Summary: gmtl/Numerics/Eigen.h references non-existing include file Initial Comment: gmtl/Numerics/Eigen.h includes the file <gmtl/gmtlConfig.h>, which apparently was removed a while ago (2002-05-20). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103757&group_id=43735 |
|
From: SourceForge.net <no...@so...> - 2010-11-05 17:56:50
|
Bugs item #3103753, was opened at 2010-11-05 18:56 Message generated for change (Tracker Item Submitted) made by isilmendil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103753&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: Johannes Zarl (isilmendil) Assigned to: Nobody/Anonymous (nobody) Summary: gmtl/Sphere.h: extra ';' Initial Comment: g++ 4.4.5 warns about an extra semicolon in Sphere.h: gmtl-0.6.1/gmtl/Sphere.h:109: warning: extra ‘;’ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3103753&group_id=43735 |
49 messages has been excluded from this view by a project administrator.
