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 >
//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
.. 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.