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 

.. 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 
For more options, visit

Reply via email to