Michael is of course correct about floating point but it is possible to 
robustly handle cases like this. I'm not sure on your exact goals but 
you've not already seen there are several papers about robust ray-box 
intersection e.g. An Efficient and Robust Ray-Box Intersection Algorithm by 
Amy Williams et al., and 
https://tavianator.com/fast-branchless-raybounding-box-intersections/ has 
some good information about handling precision, infs and NaNs (Vermeer LT 
implements some of this in Go but mainly in asm unfortunately so it's not 
much use for borrowing :). Also the chapter in PBRT about floating point 
error handling is very handy for understanding the issues (there is a 
preprint PDF floating).



On Wednesday, September 21, 2016 at 2:11:42 PM UTC+1, xiio...@gmail.com 
> Yes thanks. 
> I decided on catching the missed ON (edge/corner) case at the end of the 
> function with an extra if statement when the numerical work returns 
> EXITS_BOX=true, ENTERS_BOX=false - then I do a relatively simple check for 
> the 'ray' outside the box - if Ray.Origin was outside and EXITS_BOX=true 
> then ENTERS_BOX should have been true too - so a contradiction here lets be 
> catch the miss. (There's another reverse case I don't need to catch).
> if s.X < xmin || s.Y < ymin || s.Z < zmin || s.X > xmax || s.Y > ymax || s.Z 
> > zmax {
>               //origin is outside box *but* ray intersected with back plane
>               //      so ray should have intersected with front plane
>               //      probable rounding error at edge/corner intersection
>               return true, true, back_n, back_n, back_p, back_p
>       }
> The float conversion is a little fiddly because of that implicit bit in 
> the mantissa .. if the compiler is working well the catch is only 6 
> compares, and the rounding conversion adds a bit-ops AND, OR and SHIFT.. so 
> I doubt the unsafe will make a huge difference in time.. though I think it 
> could be preferable.
> .. Mainly relieved to here someone say this problem is unavoidable with 
> floats .. I can stop looking for maths work arounds.. Thanks again.

You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to