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.
