[ggt-devel] Request for comments - Interface changes

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

Hello,

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

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

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



Are there any objections against this approach?


2.

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

E.g.

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

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

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

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

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

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


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

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

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


cheers
Sebastian