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

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

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

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

and a specialization with DATA_TYPE = int.

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


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

cheers
Sebastian