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: Kevin M. <ke...@su...> - 2016-08-09 07:24:01
|
Fine by me if you fork into a modern source control like github, keep the same license, etc... You might want to first check with the maintainers of vrjuggler, in case maybe they feel like they own/maintain the gmtl stuff now. They may want to control the fork onto github, control who has access, etc... To get vrjuggler to switch to the newer gmtl will be a separate discussion. Maybe check their mailing list. I have been out of gmtl dev for a while, so not sure I want to be the one to greenlight this. But generally forks of LGPL stuff is pretty easy... In theory, I like the idea of github, it can even start as a proposal for these new changes - pull requests make that super easy to collab on new proposals - https://help.github.com/articles/creating-a-pull-request/. I'm on github as https://github.com/subatomicglue . - Kevin --- kevin meinert | http://www.subatomiclabs.com On Mon, Aug 8, 2016 at 1:48 PM, Sebastian Messerschmidt < seb...@gm...> wrote: > > > Am 08.08.2016 um 19:57 schrieb Kevin Meinert: > > Hi I am an original author of gmtl. Forks of course you're always free to > do. For including it in juggler, to reduce users of gmtl, you'd want to > get one of the current maintainers of juggler to weigh in on that (not sure > at the moment who that is) > > I'd like to see it moved to github or any other "modern" version control. > A > > > What types of breaking changes to gmtl do you want? Got a list? > > Basically the changes are "minimal" but breaking existing code. > A small mind dump: > - unify parameters for intersection to match the input type > (e.g. Rayd intersection using float for t0,t1 intersection point) > - template-version of epsilons (currently all epsilons are float) > - gmtl::make for precision casts (e.g . > - namespace collision with boost::static_assert (not gmtl's problem) > - meta-programming optimizations > > The main point however is to have a bit more flexibility in terms of > driving development. But this requires at least someone to maintain the > trunk and managing releases/pull requests. I could spare some extra cycles > to do at least the trunk maintenance as long as I can synchronize with the > main users (juggler). > > > > Personally I use the bullet physics math library (Sony vector math lib) > these days... Nice SSE support > > That's a thing (the SSE) better left to the compiler in my experience. Due > to the clean meta-programming friendly structure GMTL is really efficient > when compiled with AVX. Most assignments are collapsed to mov ops and even > matrix initializations (filling with zeros and filling the diagonal with 1 > is collapsed to a single constant load. I was really surprised how fast it > is. I've compared this with some handwritten code, and usually the > gmtl-based code won the compiler/optimizer race. Anyways, thanks for the > advice, but I like gmtl because it supports bounding volumes and generic > NxM math. > > Cheers > Sebastian > > > > > Kevin > > On Monday, August 8, 2016, Sebastian Messerschmidt < > seb...@gm...> wrote: > >> Hi Todd, >> >> We use it, and VR Juggler heavily depends on it. Would it make sense to >> bring it under the VR Juggler umbrella on GitHub? >> https://github.com/vrjuggler >> >> >> That might be an option. As long as we can create a fork and possibly >> improve it. >> If i understand this correctly, VRJuggler was one of the main drivers for >> GMTL's development, so it makes sense. >> Are you in contact with the original authors? >> >> Cheers >> Sebastian >> >> >> -Todd >> >> On Mon, Aug 8, 2016 at 4:39 AM, Sebastian Messerschmidt < >> seb...@gm...> wrote: >> >>> Hi folks, >>> >>> Just wanted to know if there is still some people actively using gmtl in >>> their day to day coding? >>> >>> We've contributed some changes/bugfixes in the past and like to present >>> some new ones. >>> Some of them will however break existing code (due to renaming and use >>> of different types etc.) and the community doesn't seem very active :-( >>> >>> So basically the question which came to my mind if there are any >>> inclinations is to create a fork on github where we could maintain a new >>> set of gmtl-features, changes and fixes. >>> >>> Who is the current project lead and who could sign off a fork, so we >>> don't infringe any copyright etc. >>> >>> >>> Cheers >>> >>> Sebastian >>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> _______________________________________________ >>> ggt-devel mailing list >>> ggt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ggt-devel >>> >> >> >> >> >> ------------------------------------------------------------------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic >> patterns at an interface-level. Reveals which users, apps, and protocols are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports. http://sdm.link/zohodev2dev >> >> _______________________________________________ >> ggt-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/ggt-devel >> >> -- Sent from Gmail Mobile > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > > _______________________________________________ > ggt-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/ggt-devel > > > ------------------------------------------------------------ > ------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and > traffic > patterns at an interface-level. Reveals which users, apps, and protocols > are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > > |
|
From: Sebastian M. <seb...@gm...> - 2016-08-08 18:47:56
|
Am 08.08.2016 um 19:57 schrieb Kevin Meinert: > Hi I am an original author of gmtl. Forks of course you're always > free to do. For including it in juggler, to reduce users of gmtl, > you'd want to get one of the current maintainers of juggler to weigh > in on that (not sure at the moment who that is) I'd like to see it moved to github or any other "modern" version control. A > > What types of breaking changes to gmtl do you want? Got a list? Basically the changes are "minimal" but breaking existing code. A small mind dump: - unify parameters for intersection to match the input type (e.g. Rayd intersection using float for t0,t1 intersection point) - template-version of epsilons (currently all epsilons are float) - gmtl::make for precision casts (e.g . - namespace collision with boost::static_assert (not gmtl's problem) - meta-programming optimizations The main point however is to have a bit more flexibility in terms of driving development. But this requires at least someone to maintain the trunk and managing releases/pull requests. I could spare some extra cycles to do at least the trunk maintenance as long as I can synchronize with the main users (juggler). > > Personally I use the bullet physics math library (Sony vector math > lib) these days... Nice SSE support That's a thing (the SSE) better left to the compiler in my experience. Due to the clean meta-programming friendly structure GMTL is really efficient when compiled with AVX. Most assignments are collapsed to mov ops and even matrix initializations (filling with zeros and filling the diagonal with 1 is collapsed to a single constant load. I was really surprised how fast it is. I've compared this with some handwritten code, and usually the gmtl-based code won the compiler/optimizer race. Anyways, thanks for the advice, but I like gmtl because it supports bounding volumes and generic NxM math. Cheers Sebastian > > Kevin > > On Monday, August 8, 2016, Sebastian Messerschmidt > <seb...@gm... > <mailto:seb...@gm...>> wrote: > > Hi Todd, >> We use it, and VR Juggler heavily depends on it. Would it make >> sense to bring it under the VR Juggler umbrella on GitHub? >> https://github.com/vrjuggler > > That might be an option. As long as we can create a fork and > possibly improve it. > If i understand this correctly, VRJuggler was one of the main > drivers for GMTL's development, so it makes sense. > Are you in contact with the original authors? > > Cheers > Sebastian >> >> -Todd >> >> On Mon, Aug 8, 2016 at 4:39 AM, Sebastian Messerschmidt >> <seb...@gm... >> <javascript:_e(%7B%7D,'cvml','seb...@gm...');>> >> wrote: >> >> Hi folks, >> >> Just wanted to know if there is still some people actively >> using gmtl in >> their day to day coding? >> >> We've contributed some changes/bugfixes in the past and like >> to present >> some new ones. >> Some of them will however break existing code (due to >> renaming and use >> of different types etc.) and the community doesn't seem very >> active :-( >> >> So basically the question which came to my mind if there are any >> inclinations is to create a fork on github where we could >> maintain a new >> set of gmtl-features, changes and fixes. >> >> Who is the current project lead and who could sign off a >> fork, so we >> don't infringe any copyright etc. >> >> >> Cheers >> >> Sebastian >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> ggt-devel mailing list >> ggt...@li... >> <javascript:_e(%7B%7D,'cvml','ggt...@li...');> >> https://lists.sourceforge.net/lists/listinfo/ggt-devel >> <https://lists.sourceforge.net/lists/listinfo/ggt-devel> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic >> patterns at an interface-level. Reveals which users, apps, and protocols are >> consuming the most bandwidth. Provides multi-vendor support for NetFlow, >> J-Flow, sFlow and other flows. Make informed decisions using capacity >> planning reports.http://sdm.link/zohodev2dev >> >> _______________________________________________ >> ggt-devel mailing list >> ggt...@li... >> <javascript:_e(%7B%7D,'cvml','ggt...@li...');> >> https://lists.sourceforge.net/lists/listinfo/ggt-devel >> <https://lists.sourceforge.net/lists/listinfo/ggt-devel> > > -- Sent from Gmail Mobile > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel |
|
From: Kevin M. <ke...@su...> - 2016-08-08 18:28:29
|
Hi I am an original author of gmtl. Forks of course you're always free to do. For including it in juggler, to reduce users of gmtl, you'd want to get one of the current maintainers of juggler to weigh in on that (not sure at the moment who that is) What types of breaking changes to gmtl do you want? Got a list? Personally I use the bullet physics math library (Sony vector math lib) these days... Nice SSE support Kevin On Monday, August 8, 2016, Sebastian Messerschmidt < seb...@gm...> wrote: > Hi Todd, > > We use it, and VR Juggler heavily depends on it. Would it make sense to > bring it under the VR Juggler umbrella on GitHub? > https://github.com/vrjuggler > > > That might be an option. As long as we can create a fork and possibly > improve it. > If i understand this correctly, VRJuggler was one of the main drivers for > GMTL's development, so it makes sense. > Are you in contact with the original authors? > > Cheers > Sebastian > > > -Todd > > On Mon, Aug 8, 2016 at 4:39 AM, Sebastian Messerschmidt < > seb...@gm... > <javascript:_e(%7B%7D,'cvml','seb...@gm...');>> wrote: > >> Hi folks, >> >> Just wanted to know if there is still some people actively using gmtl in >> their day to day coding? >> >> We've contributed some changes/bugfixes in the past and like to present >> some new ones. >> Some of them will however break existing code (due to renaming and use >> of different types etc.) and the community doesn't seem very active :-( >> >> So basically the question which came to my mind if there are any >> inclinations is to create a fork on github where we could maintain a new >> set of gmtl-features, changes and fixes. >> >> Who is the current project lead and who could sign off a fork, so we >> don't infringe any copyright etc. >> >> >> Cheers >> >> Sebastian >> >> >> ------------------------------------------------------------ >> ------------------ >> _______________________________________________ >> ggt-devel mailing list >> ggt...@li... >> <javascript:_e(%7B%7D,'cvml','ggt...@li...');> >> https://lists.sourceforge.net/lists/listinfo/ggt-devel >> > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > > > > _______________________________________________ > ggt-devel mailing lis...@li... <javascript:_e(%7B%7D,'cvml','ggt...@li...');>https://lists.sourceforge.net/lists/listinfo/ggt-devel > > > -- Sent from Gmail Mobile |
|
From: Sebastian M. <seb...@gm...> - 2016-08-08 17:40:32
|
Hi Todd, > We use it, and VR Juggler heavily depends on it. Would it make sense > to bring it under the VR Juggler umbrella on GitHub? > https://github.com/vrjuggler That might be an option. As long as we can create a fork and possibly improve it. If i understand this correctly, VRJuggler was one of the main drivers for GMTL's development, so it makes sense. Are you in contact with the original authors? Cheers Sebastian > > -Todd > > On Mon, Aug 8, 2016 at 4:39 AM, Sebastian Messerschmidt > <seb...@gm... > <mailto:seb...@gm...>> wrote: > > Hi folks, > > Just wanted to know if there is still some people actively using > gmtl in > their day to day coding? > > We've contributed some changes/bugfixes in the past and like to > present > some new ones. > Some of them will however break existing code (due to renaming and use > of different types etc.) and the community doesn't seem very > active :-( > > So basically the question which came to my mind if there are any > inclinations is to create a fork on github where we could maintain > a new > set of gmtl-features, changes and fixes. > > Who is the current project lead and who could sign off a fork, so we > don't infringe any copyright etc. > > > Cheers > > Sebastian > > > ------------------------------------------------------------------------------ > _______________________________________________ > ggt-devel mailing list > ggt...@li... > <mailto:ggt...@li...> > https://lists.sourceforge.net/lists/listinfo/ggt-devel > <https://lists.sourceforge.net/lists/listinfo/ggt-devel> > > > > > > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. http://sdm.link/zohodev2dev > > > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel |
|
From: Todd F. <to...@in...> - 2016-08-08 16:28:51
|
We use it, and VR Juggler heavily depends on it. Would it make sense to bring it under the VR Juggler umbrella on GitHub? https://github.com/vrjuggler -Todd On Mon, Aug 8, 2016 at 4:39 AM, Sebastian Messerschmidt < seb...@gm...> wrote: > Hi folks, > > Just wanted to know if there is still some people actively using gmtl in > their day to day coding? > > We've contributed some changes/bugfixes in the past and like to present > some new ones. > Some of them will however break existing code (due to renaming and use > of different types etc.) and the community doesn't seem very active :-( > > So basically the question which came to my mind if there are any > inclinations is to create a fork on github where we could maintain a new > set of gmtl-features, changes and fixes. > > Who is the current project lead and who could sign off a fork, so we > don't infringe any copyright etc. > > > Cheers > > Sebastian > > > ------------------------------------------------------------ > ------------------ > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > |
|
From: Sebastian M. <seb...@gm...> - 2016-08-08 08:39:54
|
Hi folks, Just wanted to know if there is still some people actively using gmtl in their day to day coding? We've contributed some changes/bugfixes in the past and like to present some new ones. Some of them will however break existing code (due to renaming and use of different types etc.) and the community doesn't seem very active :-( So basically the question which came to my mind if there are any inclinations is to create a fork on github where we could maintain a new set of gmtl-features, changes and fixes. Who is the current project lead and who could sign off a fork, so we don't infringe any copyright etc. Cheers Sebastian |
|
From: Patrick H. <pat...@gm...> - 2013-10-13 20:12:12
|
I just checked in this change to trunk. I apologize for the delay. Time gets away from me in my old age. :) Thanks for the submission! -Patrick On Aug 17, 2013, at 4:10 PM, Doug McCorkle <dou...@gm...> wrote: > Hello, > > The attached patch prevents .svn files and directories from being installed and corrects how the pc file is installed. The pc file creation is copied from the SCons build process. > > Doug > > <cmake_svn_pc_file.patch> > > ------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk_______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel -- Patrick L. Hartling iOS Library Developer, Banno http://www.banno.com/ |
|
From: Doug M. <dou...@gm...> - 2013-09-13 13:20:23
|
Hello,
Currently when this file:
gmtl/QuatOps.h
is included warnings are generated like this:
In file included from /stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/Generate.h:16:
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:463:33: warning: unused parameter 'result' [-Wunused-parameter]
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:463:51: warning: unused parameter 't' [-Wunused-parameter]
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:463:77: warning: unused parameter 'q1' [-Wunused-parameter]
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:463:104: warning: unused parameter 'q2' [-Wunused-parameter]
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:463:131: warning: unused parameter 'a' [-Wunused-parameter]
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:463:157: warning: unused parameter 'b' [-Wunused-parameter]
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:470:39: warning: unused parameter 'result' [-Wunused-parameter]
void meanTangent( Quat<DATA_TYPE>& result, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& q3 )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:470:70: warning: unused parameter 'q1' [-Wunused-parameter]
void meanTangent( Quat<DATA_TYPE>& result, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& q3 )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:470:97: warning: unused parameter 'q2' [-Wunused-parameter]
void meanTangent( Quat<DATA_TYPE>& result, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& q3 )
^
/stuff/data/VE_Suite_Deps/auto_deps/gmtl-0.6.1/install-64-bit/include/gmtl-0.6.1/gmtl/QuatOps.h:470:124: warning: unused parameter 'q3' [-Wunused-parameter]
void meanTangent( Quat<DATA_TYPE>& result, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& q3 )
Can these methods:
/** WARNING: not implemented (do not use) */
template <typename DATA_TYPE>
void squad( Quat<DATA_TYPE>& result, DATA_TYPE t, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& a, const Quat<DATA_TYPE>& b )
/** WARNING: not implemented (do not use) */
template <typename DATA_TYPE>
void meanTangent( Quat<DATA_TYPE>& result, const Quat<DATA_TYPE>& q1, const Quat<DATA_TYPE>& q2, const Quat<DATA_TYPE>& q3 )
be commented out since it does not appear they are being used or are going to be implemented? Thanks.
Doug
|
|
From: Doug M. <dou...@gm...> - 2013-08-17 21:11:00
|
Hello, The attached patch prevents .svn files and directories from being installed and corrects how the pc file is installed. The pc file creation is copied from the SCons build process. Doug |
|
From: Patrick H. <pat...@gm...> - 2013-08-17 12:59:06
|
I committed your patch. Thanks for the submission. -Patrick On Aug 14, 2013, at 1:42 PM, Paul Martz <ske...@gm...> wrote: > Hi Patrick -- in r1284, my code change normalized the frustum plane eq normals. However, I now realize that this change was incomplete. The change should have included modifying the plane offsets by the unnormalized lengths. My apologies. Please see attached for a fix. > > -- > Paul Martz > Skew Matrix Software LLC > <Frustum.h.patch>------------------------------------------------------------------------------ > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk_______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel -- Patrick L. Hartling iOS Library Developer, Banno http://www.banno.com/ |
|
From: Doug M. <dou...@gm...> - 2013-07-29 03:16:39
|
Hello, Here is a link that builds gmtl: https://www.dropbox.com/s/lgoot24dr9jjb3d/gmtl_cmake.zip with cmake. Everything is installed except for the python wrappers. Let me know what you think. Doug |
|
From: Doug M. <dou...@gm...> - 2013-07-20 21:25:43
|
Hello, Here is a link to CMake build files for GMTL: https://www.dropbox.com/s/9al9g1mcqkyc1s5/gmtl.zip For testing they just need dropped into the root GMTL directory. Right now they do not support compiling the tests or PyGMTL. I am sure both of those features could be added in the future. The current build files get the basics into the project. Let me know of any issues you run into. Doug |
|
From: Patrick H. <pat...@gm...> - 2013-07-05 21:17:28
|
On Jul 5, 2013, at 2:12 PM, Doug McCorkle <dou...@gm...> wrote: > Hello, > > Could one of the committers review the patches posted here: > > http://sourceforge.net/p/ggt/patches/ > > Thanks! I committed the patches to the SVN trunk. -Patrick -- Patrick L. Hartling iOS Library Developer, Banno http://www.banno.com/ |
|
From: Doug M. <dou...@gm...> - 2013-07-05 19:12:34
|
Hello, Could one of the committers review the patches posted here: http://sourceforge.net/p/ggt/patches/ Thanks! Doug |
|
From: Paul M. <ske...@gm...> - 2013-06-29 21:20:59
|
I notice that Containment.h isInVolume(Frustum,...) appears to assume that the Frustum plane normals are normalized, and indeed produces incorrect containment results because they aren't normalized. Should Frustum::extractPlanes() be modified to normalize the plane normals? Would this break any other code? -- Paul Martz Skew Matrix Software LLC |
|
From: SourceForge.net <no...@so...> - 2012-12-06 21:54:08
|
Bugs item #3593340, was opened at 2012-12-06 13:54 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3593340&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: 0.1.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: invert (c, transpose (b, a)) Initial Comment: Given an AFFINE Matrix44f with translation components in column [3], this sequence gives an incorrect result: Matrix44f a, b, c; // Set matrix a with non-zero translation and a.mState = AFFINE invert (c, transpose (b, a)); The problem is that transpose merely copies the mState (AFFINE), so invert calls invertAffine, which contains this: // handle matrices with translation if (COLS == 4) { // The right column vector of the matrix should always be [ 0 0 0 s ] // this represents some shear values result[3][0] = result[3][1] = result[3][2] = 0; There are two work-arounds: * Reverse the order of operations (which is mathematically equivalent and avoids the bug): // invert (c, transpose (b, a)); // transpose fails to change mState, invert makes bad assumption transpose (c, invert (b, a)); // avoid the bug * Force mState to FULL before invert: transpose (b, a); b.mState = FULL; invert (c, b); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=437247&aid=3593340&group_id=43735 |
|
From: Kevin M. <ke...@su...> - 2012-10-29 20:53:42
|
Yep. That's a good one. --- kevin meinert | http://www.subatomiclabs.com On Fri, Oct 26, 2012 at 10:00 AM, Paul Martz <pm...@sk...> wrote: > Seems like the VecOps.h length() function will almost always incur a > sqrt(). I think we can avoid calling length() from the > isInVolume(Sphere,Point) test with the attached patch, which makes > isInVolume() compare the squared length to the squared radius. This trades > a sqrt() for a single multiply operation. > > Submitting this as a separate patch as it is completely orthogonal to my > other work. > -Paul > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > > |
|
From: Patrick H. <pat...@gm...> - 2012-10-26 21:25:49
|
Paul, Kevin reviewed your patch, and I just committed it. Thanks! -Patrick On Oct 26, 2012, at 11:25 AM, Paul Martz <pm...@sk...> wrote: > Sorry, looks like I managed to reply directly to Kevin rather than the list. Here's the patch submission. > -Paul > > > > Kevin / Sebastian -- This code change has lots of parts, so I want to make the changes incrementally so that you can review the code changes and commit them (if they're acceptable) as I go. > > Attached please find the first patch. It's as I described below for #1 and #2, except I went with "mInitialized" and "isInitialized()" for readability. Note that this is the opposite sense of the deprecated "mEmpty", so much of the patch is devoted to swapping true and false, and adding/removing "!" operators, for the existing Box code. > > Let me know if this flies (I expect it well, as it's the most trivial of the changes), then I'll proceed with the other mods. Thanks! > -Paul > <gmtl0.patch>------------------------------------------------------------------------------ > The Windows 8 Center > In partnership with Sourceforge > Your idea - your app - 30 days. Get started! > http://windows8center.sourceforge.net/ > what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/_______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel -- Patrick L. Hartling iOS Library Developer, Banno http://www.banno.com/ |
|
From: Paul M. <pm...@sk...> - 2012-10-26 16:26:03
|
Sorry, looks like I managed to reply directly to Kevin rather than the list.
Here's the patch submission.
-Paul
Kevin / Sebastian -- This code change has lots of parts, so I want to make the
changes incrementally so that you can review the code changes and commit them
(if they're acceptable) as I go.
Attached please find the first patch. It's as I described below for #1 and #2,
except I went with "mInitialized" and "isInitialized()" for readability. Note
that this is the opposite sense of the deprecated "mEmpty", so much of the patch
is devoted to swapping true and false, and adding/removing "!" operators, for
the existing Box code.
Let me know if this flies (I expect it well, as it's the most trivial of the
changes), then I'll proceed with the other mods. Thanks!
-Paul
|
|
From: Kevin M. <ke...@su...> - 2012-10-26 15:34:10
|
Looks reasonable, clean code, I see no reason not to commit this one... --- kevin meinert | http://www.subatomiclabs.com On Thu, Oct 25, 2012 at 5:02 PM, Paul Martz <pm...@sk...> wrote: > Kevin / Sebastian -- This code change has lots of parts, so I want to make > the changes incrementally so that you can review the code changes and > commit them (if they're acceptable) as I go. > > Attached please find the first patch. It's as I described below for #1 and > #2, except I went with "mInitialized" and "isInitialized()" for > readability. Note that this is the opposite sense of the deprecated > "mEmpty", so much of the patch is devoted to swapping true and false, and > adding/removing "!" operators, for the existing Box code. > > Let me know if this flies (I expect it well, as it's the most trivial of > the changes), then I'll proceed with the other mods. Thanks! > -Paul > > > > > On 10/25/2012 11:30 AM, Kevin Meinert wrote: > >> For 3, I would leave out conditional and document function that vector >> must contain initialized volumes only, for performance to avoid >> conditional check per element (can make suggestion that user of >> function manage list to not include unititialized) >> >> >> >> Sent from my Phone >> From: Paul Martz >> Sent: 10/25/2012 11:23 AM >> To: ggt...@li...urceforge.**net <ggt...@li...> >> Subject: Re: [ggt-devel] Sphere emptiness >> (AABox::isEmpty(), yes, as per Sebastian's email.) >> >> Suggestions to make this change work for everyone: >> >> 1. Change mEmpty to mUninitialized in Box, and add mUninitialized to >> Sphere. Add >> an isInitialized() function to both Sphere and Box, but also keep >> isEmpty(). >> This give us a better name and also maintains backwards compatibility. >> >> 2. For the extendVolume() variants that extend a Sphere by a single Point >> or a >> single other volume, add the initialization checks to make Sphere work >> like box. >> >> 3. For performance, add extendVolume() functions that take a std::vector >> of >> Points. This would also have the initialization check, but would amortize >> the >> cost of the check over all the data. Similar code already exists in the >> makeVolume() functions in Containment.h. >> >> Does this sound good? >> -Paul >> >> >> >> On 10/25/2012 9:27 AM, Kevin Meinert wrote: >> >>> If no gmtl uses mEmpty, >>> Then, I question why include it in gmtl. >>> >>> If for bookkeeping for higher level subsystems... Then you could easily >>> extend that class yourself to include that data member, through >>> inheritance. >>> >>> there are no checks inside the gmtl functions that use the mEmpty >>>>> >>>> property directly >>> >>> Didn't Paul say below that extendVolume does use mEmpty? >>> >>> Sent from my Phone >>> From: Sebastian Messerschmidt >>> Sent: 10/25/2012 1:30 AM >>> To: ggt...@li...urceforge.**net <ggt...@li...> >>> Subject: Re: [ggt-devel] Sphere emptiness >>> Kevin, >>> >>> Got it. >>>> >>>> Perhaps a better term would be mExists, or mPositionless, or mUndefined. >>>> >>>> Empty implies volume, which 0 could be mistaken for emptiness. >>>> >>> mEmpty was the term that was used in the box, so I'd vote for sticking >>> to it for the sake of readability. >>> Of course it doesn't make much sense, as there is no such thing as an >>> empty volume. >>> >>>> >>>> I also would look at the higher level sub system expanding volumes and >>>> ask why uninitialized ones are even in the list. Leads to the question >>>> whether it might be more appropriate to do that bookkeeping outside of >>>> the math system >>>> >>> That is right. But in order to do so, It really helps to have the member >>> ;-) >>> >>>> >>>> Doing conditional checks tends to slow down processing, I always prefer >>>> keeping a list of what needs work, and blasting through that list (or >>>> memory coherent array preferably) without any conditionals. My >>>> preference would be for math code that blazes (avoiding branches) and >>>> keep conditionals to the higher level... >>>> >>> Looking at the code, there are no checks inside the gmtl functions that >>> use the mEmpty property directly. So no harm done just adding the member. >>> I totally agree that runtime checking should be done outside the core >>> functionality. The only arguable option might be an ASSERT, since >>> merging an "empty" sphere is not valid operation. >>> >>> >>> cheers >>> Sebastian >>> >>>> >>>> Sent from my Phone >>>> From: Paul Martz >>>> Sent: 10/24/2012 1:31 PM >>>> To: ggt...@li...urceforge.**net <ggt...@li...> >>>> Subject: Re: [ggt-devel] Sphere emptiness >>>> >>>> >>>> On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote: >>>> >>>>> Hello Kevin, >>>>> >>>>>> What does it mean to have an empty sphere? Or aabox for that matter. >>>>>> Is >>>>>> it same as sphere volume == 0. Or is it a flag to signify something >>>>>> else (I.e. No objects contained in). >>>>>> >>>>>> if vol == 0 then why not set the size to 0... If it is so you can >>>>>> remember previous size, why distinguish 0 volume, why not and an N >>>>>> volume switch... Why a switch at all... >>>>>> >>>>>> Excuse me for not knowing/remembering the purpose of mEmpty... >>>>>> >>>>> Imagine you have BoundingVolume (Doesn't matter if it is a box or >>>>> sphere) that is default initialized. >>>>> Now if you use this object to extend an existing volume it will expand >>>>> it in a wrong way. >>>>> Since an empty sphere (i.e. radius == 0.0) still has an position it >>>>> will >>>>> expand the volume to be extended incorrectly. >>>>> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty >>>>> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere >>>>> of >>>>> pos(5.5,0,0) radius = 6, which is wrong) >>>>> The main purposes of the empty flag is to ignore those primitives and >>>>> to >>>>> check if it was initialized. >>>>> >>>> Good summary. Also, an mEmpty member variable will differentiate >>>> between a >>>> sphere that contains nothing (uninitialized), and a sphere that >>>> contains exactly >>>> one point. Radius == 0 alone doesn't provide this functionality. >>>> >>>> As I mentioned previously, I could use a negative radius to indicate an >>>> empty >>>> sphere. But, we could also have AABox use mMax< mMin to indicate an >>>> empty box, >>>> and we don't -- instead we have AABox::mEmpty, and code to respect the >>>> setting >>>> of that variable in Containment.h. I think, for consistency, Sphere >>>> should be >>>> the same way. >>>> >>>> I'll proceed with the code change, if no one objects. >>>> -Paul >>>> >>>> Your approach testing the volume might work in this case, but it is >>>>> surely not a general solution. >>>>> So I vote for Paul's approach. >>>>> >>>>> cheers >>>>> Sebastian >>>>> >>>>> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-) >>>>> >>>>>> Thanks, >>>>>> >>>>>> Sent from my Phone >>>>>> From: Paul Martz >>>>>> Sent: 10/23/2012 5:15 PM >>>>>> To: ggt...@li...urceforge.**net<ggt...@li...> >>>>>> Subject: [ggt-devel] Sphere emptiness >>>>>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as >>>>>> bounding volumes. >>>>>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable >>>>>> that is >>>>>> present in AABox. Is there a reason for this? If not, I'd like to add >>>>>> it. >>>>>> >>>>>> I would also modify Containment.h's extendVolume(Sphere&,...) to >>>>>> respect that >>>>>> variable (as is already done for extendVolume(AABox&,...) ). Finally, >>>>>> I'd also >>>>>> add new extendVolume() functions to extend Sphere around an AABox and >>>>>> vice versa. >>>>>> >>>>>> Just wanted to see if there was a logical reason for the current >>>>>> design before I >>>>>> embarked on changing the code. I know that I can emulate the desired >>>>>> behavior >>>>>> with a negative radius, but it seems to me it would be desirable to >>>>>> have this >>>>>> functionality in gmtl rather than only in my project. >>>>>> >>>>>> Thanks, >>>>>> -Paul >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------**------------------------------** >>>>>> ------------------ >>>>>> Everyone hates slow websites. So do we. >>>>>> Make your web apps faster with AppDynamics >>>>>> Download AppDynamics Lite for free today: >>>>>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>>>>> ______________________________**_________________ >>>>>> ggt-devel mailing list >>>>>> ggt...@li...urceforge.**net <ggt...@li...> >>>>>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>>>>> >>>>>> ------------------------------**------------------------------** >>>>>> ------------------ >>>>>> Everyone hates slow websites. So do we. >>>>>> Make your web apps faster with AppDynamics >>>>>> Download AppDynamics Lite for free today: >>>>>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>>>>> ______________________________**_________________ >>>>>> ggt-devel mailing list >>>>>> ggt...@li...urceforge.**net <ggt...@li...> >>>>>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>>> ------------------ >>>>> Everyone hates slow websites. So do we. >>>>> Make your web apps faster with AppDynamics >>>>> Download AppDynamics Lite for free today: >>>>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>>>> ______________________________**_________________ >>>>> ggt-devel mailing list >>>>> ggt...@li...urceforge.**net <ggt...@li...> >>>>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>>>> >>>>> >>>>> ------------------------------**------------------------------** >>>> ------------------ >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>>> ______________________________**_________________ >>>> ggt-devel mailing list >>>> ggt...@li...urceforge.**net <ggt...@li...> >>>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>>> >>>> ------------------------------**------------------------------** >>>> ------------------ >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>>> ______________________________**_________________ >>>> ggt-devel mailing list >>>> ggt...@li...urceforge.**net <ggt...@li...> >>>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>>> >>> >>> >>> ------------------------------**------------------------------** >>> ------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>> ______________________________**_________________ >>> ggt-devel mailing list >>> ggt...@li...urceforge.**net <ggt...@li...> >>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>> >>> ------------------------------**------------------------------** >>> ------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >>> ______________________________**_________________ >>> ggt-devel mailing list >>> ggt...@li...urceforge.**net <ggt...@li...> >>> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >>> >>> >>> >> ------------------------------**------------------------------** >> ------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_**sfd2d_oct<http://p.sf.net/sfu/appdyn_sfd2d_oct> >> ______________________________**_________________ >> ggt-devel mailing list >> ggt...@li...urceforge.**net <ggt...@li...> >> https://lists.sourceforge.net/**lists/listinfo/ggt-devel<https://lists.sourceforge.net/lists/listinfo/ggt-devel> >> >> >> |
|
From: Paul M. <pm...@sk...> - 2012-10-26 15:00:34
|
Seems like the VecOps.h length() function will almost always incur a sqrt(). I
think we can avoid calling length() from the isInVolume(Sphere,Point) test with
the attached patch, which makes isInVolume() compare the squared length to the
squared radius. This trades a sqrt() for a single multiply operation.
Submitting this as a separate patch as it is completely orthogonal to my other work.
-Paul
|
|
From: Kevin M. <ke...@su...> - 2012-10-25 17:30:49
|
For 3, I would leave out conditional and document function that vector
must contain initialized volumes only, for performance to avoid
conditional check per element (can make suggestion that user of
function manage list to not include unititialized)
Sent from my Phone
From: Paul Martz
Sent: 10/25/2012 11:23 AM
To: ggt...@li...
Subject: Re: [ggt-devel] Sphere emptiness
(AABox::isEmpty(), yes, as per Sebastian's email.)
Suggestions to make this change work for everyone:
1. Change mEmpty to mUninitialized in Box, and add mUninitialized to
Sphere. Add
an isInitialized() function to both Sphere and Box, but also keep isEmpty().
This give us a better name and also maintains backwards compatibility.
2. For the extendVolume() variants that extend a Sphere by a single Point or a
single other volume, add the initialization checks to make Sphere work like box.
3. For performance, add extendVolume() functions that take a std::vector of
Points. This would also have the initialization check, but would amortize the
cost of the check over all the data. Similar code already exists in the
makeVolume() functions in Containment.h.
Does this sound good?
-Paul
On 10/25/2012 9:27 AM, Kevin Meinert wrote:
> If no gmtl uses mEmpty,
> Then, I question why include it in gmtl.
>
> If for bookkeeping for higher level subsystems... Then you could easily
> extend that class yourself to include that data member, through
> inheritance.
>
>>> there are no checks inside the gmtl functions that use the mEmpty
> property directly
>
> Didn't Paul say below that extendVolume does use mEmpty?
>
> Sent from my Phone
> From: Sebastian Messerschmidt
> Sent: 10/25/2012 1:30 AM
> To: ggt...@li...
> Subject: Re: [ggt-devel] Sphere emptiness
> Kevin,
>
>> Got it.
>>
>> Perhaps a better term would be mExists, or mPositionless, or mUndefined.
>>
>> Empty implies volume, which 0 could be mistaken for emptiness.
> mEmpty was the term that was used in the box, so I'd vote for sticking
> to it for the sake of readability.
> Of course it doesn't make much sense, as there is no such thing as an
> empty volume.
>>
>> I also would look at the higher level sub system expanding volumes and
>> ask why uninitialized ones are even in the list. Leads to the question
>> whether it might be more appropriate to do that bookkeeping outside of
>> the math system
> That is right. But in order to do so, It really helps to have the member ;-)
>>
>> Doing conditional checks tends to slow down processing, I always prefer
>> keeping a list of what needs work, and blasting through that list (or
>> memory coherent array preferably) without any conditionals. My
>> preference would be for math code that blazes (avoiding branches) and
>> keep conditionals to the higher level...
> Looking at the code, there are no checks inside the gmtl functions that
> use the mEmpty property directly. So no harm done just adding the member.
> I totally agree that runtime checking should be done outside the core
> functionality. The only arguable option might be an ASSERT, since
> merging an "empty" sphere is not valid operation.
>
>
> cheers
> Sebastian
>>
>> Sent from my Phone
>> From: Paul Martz
>> Sent: 10/24/2012 1:31 PM
>> To: ggt...@li...
>> Subject: Re: [ggt-devel] Sphere emptiness
>>
>>
>> On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote:
>>> Hello Kevin,
>>>> What does it mean to have an empty sphere? Or aabox for that matter. Is
>>>> it same as sphere volume == 0. Or is it a flag to signify something
>>>> else (I.e. No objects contained in).
>>>>
>>>> if vol == 0 then why not set the size to 0... If it is so you can
>>>> remember previous size, why distinguish 0 volume, why not and an N
>>>> volume switch... Why a switch at all...
>>>>
>>>> Excuse me for not knowing/remembering the purpose of mEmpty...
>>> Imagine you have BoundingVolume (Doesn't matter if it is a box or
>>> sphere) that is default initialized.
>>> Now if you use this object to extend an existing volume it will expand
>>> it in a wrong way.
>>> Since an empty sphere (i.e. radius == 0.0) still has an position it will
>>> expand the volume to be extended incorrectly.
>>> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty
>>> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of
>>> pos(5.5,0,0) radius = 6, which is wrong)
>>> The main purposes of the empty flag is to ignore those primitives and to
>>> check if it was initialized.
>> Good summary. Also, an mEmpty member variable will differentiate between a
>> sphere that contains nothing (uninitialized), and a sphere that
>> contains exactly
>> one point. Radius == 0 alone doesn't provide this functionality.
>>
>> As I mentioned previously, I could use a negative radius to indicate an empty
>> sphere. But, we could also have AABox use mMax< mMin to indicate an empty box,
>> and we don't -- instead we have AABox::mEmpty, and code to respect the setting
>> of that variable in Containment.h. I think, for consistency, Sphere should be
>> the same way.
>>
>> I'll proceed with the code change, if no one objects.
>> -Paul
>>
>>> Your approach testing the volume might work in this case, but it is
>>> surely not a general solution.
>>> So I vote for Paul's approach.
>>>
>>> cheers
>>> Sebastian
>>>
>>> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>>>> Thanks,
>>>>
>>>> Sent from my Phone
>>>> From: Paul Martz
>>>> Sent: 10/23/2012 5:15 PM
>>>> To: ggt...@li...
>>>> Subject: [ggt-devel] Sphere emptiness
>>>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
>>>> bounding volumes.
>>>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
>>>> present in AABox. Is there a reason for this? If not, I'd like to add it.
>>>>
>>>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
>>>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
>>>> add new extendVolume() functions to extend Sphere around an AABox and
>>>> vice versa.
>>>>
>>>> Just wanted to see if there was a logical reason for the current
>>>> design before I
>>>> embarked on changing the code. I know that I can emulate the desired behavior
>>>> with a negative radius, but it seems to me it would be desirable to have this
>>>> functionality in gmtl rather than only in my project.
>>>>
>>>> Thanks,
>>>> -Paul
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
ggt-devel mailing list
ggt...@li...
https://lists.sourceforge.net/lists/listinfo/ggt-devel
|
|
From: Paul M. <pm...@sk...> - 2012-10-25 16:23:06
|
(AABox::isEmpty(), yes, as per Sebastian's email.)
Suggestions to make this change work for everyone:
1. Change mEmpty to mUninitialized in Box, and add mUninitialized to Sphere. Add
an isInitialized() function to both Sphere and Box, but also keep isEmpty().
This give us a better name and also maintains backwards compatibility.
2. For the extendVolume() variants that extend a Sphere by a single Point or a
single other volume, add the initialization checks to make Sphere work like box.
3. For performance, add extendVolume() functions that take a std::vector of
Points. This would also have the initialization check, but would amortize the
cost of the check over all the data. Similar code already exists in the
makeVolume() functions in Containment.h.
Does this sound good?
-Paul
On 10/25/2012 9:27 AM, Kevin Meinert wrote:
> If no gmtl uses mEmpty,
> Then, I question why include it in gmtl.
>
> If for bookkeeping for higher level subsystems... Then you could easily
> extend that class yourself to include that data member, through
> inheritance.
>
>>> there are no checks inside the gmtl functions that use the mEmpty
> property directly
>
> Didn't Paul say below that extendVolume does use mEmpty?
>
> Sent from my Phone
> From: Sebastian Messerschmidt
> Sent: 10/25/2012 1:30 AM
> To: ggt...@li...
> Subject: Re: [ggt-devel] Sphere emptiness
> Kevin,
>
>> Got it.
>>
>> Perhaps a better term would be mExists, or mPositionless, or mUndefined.
>>
>> Empty implies volume, which 0 could be mistaken for emptiness.
> mEmpty was the term that was used in the box, so I'd vote for sticking
> to it for the sake of readability.
> Of course it doesn't make much sense, as there is no such thing as an
> empty volume.
>>
>> I also would look at the higher level sub system expanding volumes and
>> ask why uninitialized ones are even in the list. Leads to the question
>> whether it might be more appropriate to do that bookkeeping outside of
>> the math system
> That is right. But in order to do so, It really helps to have the member ;-)
>>
>> Doing conditional checks tends to slow down processing, I always prefer
>> keeping a list of what needs work, and blasting through that list (or
>> memory coherent array preferably) without any conditionals. My
>> preference would be for math code that blazes (avoiding branches) and
>> keep conditionals to the higher level...
> Looking at the code, there are no checks inside the gmtl functions that
> use the mEmpty property directly. So no harm done just adding the member.
> I totally agree that runtime checking should be done outside the core
> functionality. The only arguable option might be an ASSERT, since
> merging an "empty" sphere is not valid operation.
>
>
> cheers
> Sebastian
>>
>> Sent from my Phone
>> From: Paul Martz
>> Sent: 10/24/2012 1:31 PM
>> To: ggt...@li...
>> Subject: Re: [ggt-devel] Sphere emptiness
>>
>>
>> On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote:
>>> Hello Kevin,
>>>> What does it mean to have an empty sphere? Or aabox for that matter. Is
>>>> it same as sphere volume == 0. Or is it a flag to signify something
>>>> else (I.e. No objects contained in).
>>>>
>>>> if vol == 0 then why not set the size to 0... If it is so you can
>>>> remember previous size, why distinguish 0 volume, why not and an N
>>>> volume switch... Why a switch at all...
>>>>
>>>> Excuse me for not knowing/remembering the purpose of mEmpty...
>>> Imagine you have BoundingVolume (Doesn't matter if it is a box or
>>> sphere) that is default initialized.
>>> Now if you use this object to extend an existing volume it will expand
>>> it in a wrong way.
>>> Since an empty sphere (i.e. radius == 0.0) still has an position it will
>>> expand the volume to be extended incorrectly.
>>> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty
>>> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of
>>> pos(5.5,0,0) radius = 6, which is wrong)
>>> The main purposes of the empty flag is to ignore those primitives and to
>>> check if it was initialized.
>> Good summary. Also, an mEmpty member variable will differentiate between a
>> sphere that contains nothing (uninitialized), and a sphere that
>> contains exactly
>> one point. Radius == 0 alone doesn't provide this functionality.
>>
>> As I mentioned previously, I could use a negative radius to indicate an empty
>> sphere. But, we could also have AABox use mMax< mMin to indicate an empty box,
>> and we don't -- instead we have AABox::mEmpty, and code to respect the setting
>> of that variable in Containment.h. I think, for consistency, Sphere should be
>> the same way.
>>
>> I'll proceed with the code change, if no one objects.
>> -Paul
>>
>>> Your approach testing the volume might work in this case, but it is
>>> surely not a general solution.
>>> So I vote for Paul's approach.
>>>
>>> cheers
>>> Sebastian
>>>
>>> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>>>> Thanks,
>>>>
>>>> Sent from my Phone
>>>> From: Paul Martz
>>>> Sent: 10/23/2012 5:15 PM
>>>> To: ggt...@li...
>>>> Subject: [ggt-devel] Sphere emptiness
>>>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
>>>> bounding volumes.
>>>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
>>>> present in AABox. Is there a reason for this? If not, I'd like to add it.
>>>>
>>>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
>>>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
>>>> add new extendVolume() functions to extend Sphere around an AABox and
>>>> vice versa.
>>>>
>>>> Just wanted to see if there was a logical reason for the current
>>>> design before I
>>>> embarked on changing the code. I know that I can emulate the desired behavior
>>>> with a negative radius, but it seems to me it would be desirable to have this
>>>> functionality in gmtl rather than only in my project.
>>>>
>>>> Thanks,
>>>> -Paul
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
>
|
|
From: Sebastian M. <seb...@gm...> - 2012-10-25 16:05:45
|
Am 25.10.2012 17:27, schrieb Kevin Meinert:
> If no gmtl uses mEmpty,
> Then, I question why include it in gmtl.
Sorry, I grep'd for mEmpty only, not for the isEmpty function which is
indeed used in the containment. Mea culpa
Anyways it is a valid property.
In the AABox it is set to true for the standard constructor.
Functions modifying the box set it to true.
I think there are two things:
1. I really advocate for adding the member for two reasons:
1.1. The box has it, so the sphere should have it too. Simply for
reasons of same interface
1.2. The "empty"/"uninitialized" property is not derivable from the
position/radius in a definite way (A sphere with 0,{0,0,0} might still
be considered valid), which makes it impossible to check the
return/reference value from a function.
2. Adding the check to the extend volume.
There is branching to check the isEmpty() for the box. I would add it
for the sphere as well, so the functions behave the same.
I guess this is not a show-stopper performance-wise. Branch prediction
will simply kick in for well formed data sets.
>
> If for bookkeeping for higher level subsystems... Then you could easily
> extend that class yourself to include that data member, through
> inheritance.
I disagree that deriving is a good idea. Might be personal opinion, but
I simple consider deriving basic data structures an overhead.
>
>>> there are no checks inside the gmtl functions that use the mEmpty
> property directly
>
> Didn't Paul say below that extendVolume does use mEmpty?
See above.
>
> Sent from my Phone
> From: Sebastian Messerschmidt
> Sent: 10/25/2012 1:30 AM
> To: ggt...@li...
> Subject: Re: [ggt-devel] Sphere emptiness
> Kevin,
>
>> Got it.
>>
>> Perhaps a better term would be mExists, or mPositionless, or mUndefined.
>>
>> Empty implies volume, which 0 could be mistaken for emptiness.
> mEmpty was the term that was used in the box, so I'd vote for sticking
> to it for the sake of readability.
> Of course it doesn't make much sense, as there is no such thing as an
> empty volume.
>> I also would look at the higher level sub system expanding volumes and
>> ask why uninitialized ones are even in the list. Leads to the question
>> whether it might be more appropriate to do that bookkeeping outside of
>> the math system
> That is right. But in order to do so, It really helps to have the member ;-)
>> Doing conditional checks tends to slow down processing, I always prefer
>> keeping a list of what needs work, and blasting through that list (or
>> memory coherent array preferably) without any conditionals. My
>> preference would be for math code that blazes (avoiding branches) and
>> keep conditionals to the higher level...
> Looking at the code, there are no checks inside the gmtl functions that
> use the mEmpty property directly. So no harm done just adding the member.
> I totally agree that runtime checking should be done outside the core
> functionality. The only arguable option might be an ASSERT, since
> merging an "empty" sphere is not valid operation.
>
>
> cheers
> Sebastian
>> Sent from my Phone
>> From: Paul Martz
>> Sent: 10/24/2012 1:31 PM
>> To: ggt...@li...
>> Subject: Re: [ggt-devel] Sphere emptiness
>>
>>
>> On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote:
>>> Hello Kevin,
>>>> What does it mean to have an empty sphere? Or aabox for that matter. Is
>>>> it same as sphere volume == 0. Or is it a flag to signify something
>>>> else (I.e. No objects contained in).
>>>>
>>>> if vol == 0 then why not set the size to 0... If it is so you can
>>>> remember previous size, why distinguish 0 volume, why not and an N
>>>> volume switch... Why a switch at all...
>>>>
>>>> Excuse me for not knowing/remembering the purpose of mEmpty...
>>> Imagine you have BoundingVolume (Doesn't matter if it is a box or
>>> sphere) that is default initialized.
>>> Now if you use this object to extend an existing volume it will expand
>>> it in a wrong way.
>>> Since an empty sphere (i.e. radius == 0.0) still has an position it will
>>> expand the volume to be extended incorrectly.
>>> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty
>>> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of
>>> pos(5.5,0,0) radius = 6, which is wrong)
>>> The main purposes of the empty flag is to ignore those primitives and to
>>> check if it was initialized.
>> Good summary. Also, an mEmpty member variable will differentiate between a
>> sphere that contains nothing (uninitialized), and a sphere that
>> contains exactly
>> one point. Radius == 0 alone doesn't provide this functionality.
>>
>> As I mentioned previously, I could use a negative radius to indicate an empty
>> sphere. But, we could also have AABox use mMax < mMin to indicate an empty box,
>> and we don't -- instead we have AABox::mEmpty, and code to respect the setting
>> of that variable in Containment.h. I think, for consistency, Sphere should be
>> the same way.
>>
>> I'll proceed with the code change, if no one objects.
>> -Paul
>>
>>> Your approach testing the volume might work in this case, but it is
>>> surely not a general solution.
>>> So I vote for Paul's approach.
>>>
>>> cheers
>>> Sebastian
>>>
>>> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-)
>>>> Thanks,
>>>>
>>>> Sent from my Phone
>>>> From: Paul Martz
>>>> Sent: 10/23/2012 5:15 PM
>>>> To: ggt...@li...
>>>> Subject: [ggt-devel] Sphere emptiness
>>>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as
>>>> bounding volumes.
>>>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is
>>>> present in AABox. Is there a reason for this? If not, I'd like to add it.
>>>>
>>>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that
>>>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also
>>>> add new extendVolume() functions to extend Sphere around an AABox and
>>>> vice versa.
>>>>
>>>> Just wanted to see if there was a logical reason for the current
>>>> design before I
>>>> embarked on changing the code. I know that I can emulate the desired behavior
>>>> with a negative radius, but it seems to me it would be desirable to have this
>>>> functionality in gmtl rather than only in my project.
>>>>
>>>> Thanks,
>>>> -Paul
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Everyone hates slow websites. So do we.
>>>> Make your web apps faster with AppDynamics
>>>> Download AppDynamics Lite for free today:
>>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>>> _______________________________________________
>>>> ggt-devel mailing list
>>>> ggt...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>> ------------------------------------------------------------------------------
>>> Everyone hates slow websites. So do we.
>>> Make your web apps faster with AppDynamics
>>> Download AppDynamics Lite for free today:
>>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>>> _______________________________________________
>>> ggt-devel mailing list
>>> ggt...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>>
>>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> ggt-devel mailing list
>> ggt...@li...
>> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
|
|
From: Kevin M. <ke...@su...> - 2012-10-25 15:27:19
|
If no gmtl uses mEmpty, Then, I question why include it in gmtl. If for bookkeeping for higher level subsystems... Then you could easily extend that class yourself to include that data member, through inheritance. >> there are no checks inside the gmtl functions that use the mEmpty property directly Didn't Paul say below that extendVolume does use mEmpty? Sent from my Phone From: Sebastian Messerschmidt Sent: 10/25/2012 1:30 AM To: ggt...@li... Subject: Re: [ggt-devel] Sphere emptiness Kevin, > Got it. > > Perhaps a better term would be mExists, or mPositionless, or mUndefined. > > Empty implies volume, which 0 could be mistaken for emptiness. mEmpty was the term that was used in the box, so I'd vote for sticking to it for the sake of readability. Of course it doesn't make much sense, as there is no such thing as an empty volume. > > I also would look at the higher level sub system expanding volumes and > ask why uninitialized ones are even in the list. Leads to the question > whether it might be more appropriate to do that bookkeeping outside of > the math system That is right. But in order to do so, It really helps to have the member ;-) > > Doing conditional checks tends to slow down processing, I always prefer > keeping a list of what needs work, and blasting through that list (or > memory coherent array preferably) without any conditionals. My > preference would be for math code that blazes (avoiding branches) and > keep conditionals to the higher level... Looking at the code, there are no checks inside the gmtl functions that use the mEmpty property directly. So no harm done just adding the member. I totally agree that runtime checking should be done outside the core functionality. The only arguable option might be an ASSERT, since merging an "empty" sphere is not valid operation. cheers Sebastian > > Sent from my Phone > From: Paul Martz > Sent: 10/24/2012 1:31 PM > To: ggt...@li... > Subject: Re: [ggt-devel] Sphere emptiness > > > On 10/24/2012 10:46 AM, Sebastian Messerschmidt wrote: >> Hello Kevin, >>> What does it mean to have an empty sphere? Or aabox for that matter. Is >>> it same as sphere volume == 0. Or is it a flag to signify something >>> else (I.e. No objects contained in). >>> >>> if vol == 0 then why not set the size to 0... If it is so you can >>> remember previous size, why distinguish 0 volume, why not and an N >>> volume switch... Why a switch at all... >>> >>> Excuse me for not knowing/remembering the purpose of mEmpty... >> Imagine you have BoundingVolume (Doesn't matter if it is a box or >> sphere) that is default initialized. >> Now if you use this object to extend an existing volume it will expand >> it in a wrong way. >> Since an empty sphere (i.e. radius == 0.0) still has an position it will >> expand the volume to be extended incorrectly. >> (For example you have sphere1 with pos(10,0,0) and r = 1 and an empty >> sphere (pos(0,0,0), radius=0). The extendVolume will produce a sphere of >> pos(5.5,0,0) radius = 6, which is wrong) >> The main purposes of the empty flag is to ignore those primitives and to >> check if it was initialized. > Good summary. Also, an mEmpty member variable will differentiate between a > sphere that contains nothing (uninitialized), and a sphere that > contains exactly > one point. Radius == 0 alone doesn't provide this functionality. > > As I mentioned previously, I could use a negative radius to indicate an empty > sphere. But, we could also have AABox use mMax < mMin to indicate an empty box, > and we don't -- instead we have AABox::mEmpty, and code to respect the setting > of that variable in Containment.h. I think, for consistency, Sphere should be > the same way. > > I'll proceed with the code change, if no one objects. > -Paul > >> Your approach testing the volume might work in this case, but it is >> surely not a general solution. >> So I vote for Paul's approach. >> >> cheers >> Sebastian >> >> P.S. Hi Paul, nice to see you outside the OSG mailing list ;-) >>> Thanks, >>> >>> Sent from my Phone >>> From: Paul Martz >>> Sent: 10/23/2012 5:15 PM >>> To: ggt...@li... >>> Subject: [ggt-devel] Sphere emptiness >>> Hi all -- My project uses both gmtl::Sphere and gmtl::AABox as >>> bounding volumes. >>> But I've noticed that Sphere lacks the 'bool mEmpty' member variable that is >>> present in AABox. Is there a reason for this? If not, I'd like to add it. >>> >>> I would also modify Containment.h's extendVolume(Sphere&,...) to respect that >>> variable (as is already done for extendVolume(AABox&,...) ). Finally, I'd also >>> add new extendVolume() functions to extend Sphere around an AABox and >>> vice versa. >>> >>> Just wanted to see if there was a logical reason for the current >>> design before I >>> embarked on changing the code. I know that I can emulate the desired behavior >>> with a negative radius, but it seems to me it would be desirable to have this >>> functionality in gmtl rather than only in my project. >>> >>> Thanks, >>> -Paul >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_sfd2d_oct >>> _______________________________________________ >>> ggt-devel mailing list >>> ggt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ggt-devel >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_sfd2d_oct >>> _______________________________________________ >>> ggt-devel mailing list >>> ggt...@li... >>> https://lists.sourceforge.net/lists/listinfo/ggt-devel >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_sfd2d_oct >> _______________________________________________ >> ggt-devel mailing list >> ggt...@li... >> https://lists.sourceforge.net/lists/listinfo/ggt-devel >> >> > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > ggt-devel mailing list > ggt...@li... > https://lists.sourceforge.net/lists/listinfo/ggt-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ ggt-devel mailing list ggt...@li... https://lists.sourceforge.net/lists/listinfo/ggt-devel |
49 messages has been excluded from this view by a project administrator.
