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

[Kevin M. <ke...@su...>]

could have 2 template params: DATA_TYPE1 and DATA_TYPE2...  and do casts so
that it compiles for int...

or...

could add a comment, "this wont make sense for int...  cast to float version
to get a meaningful result..."
if you're going to int, you're probably not caring about performance much
anyways.

do whatever is fastest for float/double case...   i.e. look at the asm, make
sure that suggestion#1 above doesn't make extra code.

- kevin

On Mon, Jan 19, 2009 at 1:47 AM, Sebastian Messerschmidt <
seb...@gm...> wrote:

> 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
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>



-- 
kevin meinert | http://www.subatomicglue.com