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).
Cheers,
Jamie
On Wednesday, September 21, 2016 at 2:11:42 PM UTC+1, xiio...@gmail.com
wrote:
>
> 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.
