|
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
|