On Thursday, 22 September 2016 19:43:35 UTC+1, Jamie Clarkson wrote: > > Sure, as you say for your use case it might be best for you, and you might > need different information from the test anyway. Usually in a fast ray > tracer you'd pre-calculate the inverse of the direction components and > store them (since you do LOTS of ray-bbox intersections for each ray while > traversing the bounding hierarchies) then the slab test is pure > multiplication and adds. The branchless version then replaces all branch > tests with min/max operations. I'd be interested if your div free version > is faster and doesn't need the precalculation/storage costs. > > Cheers, > > Jamie > > I'm currently fiddling with the "no-division" version - it's not optimised. It doesn't actually avoid the division, unless all that is needed is a true/false (intersects) return - for a function that also returns the scalar along the ray the division is still needed, but it's not in the boundary check

## Advertising

Easier to show : Original code (in my first post) front_n = (x_front - s.X) / v.X ripY = s.Y + front_n*v.Y ripZ = s.Z + front_n*v.Z if (front_n > 0) && (ymin <= ripY && ripY <= ymax) && (zmin <= ripZ && ripZ <= zmax) { ..etc .. becomes (completely non-optimized) front_n_d = (x_front - s.X) // non-divided version positive = (v.X > 0) if (front_n_d > ) == positive && ((ymin-s.Y)*v.X <= front_n_d*v.Y)==positive && (front_n_d*v.Y <= (ymax-s.Y)*v.X)==positive && ((zmin-s.Z)*v.X <= front_n_d*v.Z)==positive && (front_n_d*v.Z <= (zmax-s.Z)*v.X))==positive { ..etc.. (terms such as ymin-s.Y are reused many times .. I haven't remove them here as it obscures the math.) the obvious alternative is to add an extra if positive .. else .. to simplify all those ==positive out of the condition.. *either way I'm not expecting it to be faste*r, but the *numerical errors should be much less*, since each side has only 1 multiply and 1 add/subtract, whereas the original form had all the math on one side of the boundary condition - consisting of a subtract followed by a divide ie (x_front - s.X) / v.X (or a multiplication by a reciprocal which adds more potential numerical error), compounded into an additional multiplication and add ie s.Y + front_n*v.Y - so in terms of numerical accuracy the non-multiply version should be much better. however if the condition is true the divide is still required to get the scalar if needed : front_n = front_n_d / v.X So for multiple rays the pre-store of the reciprocal of v.X, v.Y, v.Z still make sense. For the usual raytracing bounding boxes a few errors, or slightly oversized bounding boxes are fine, but in my case the ray-box intersection is used to generate indexes for a 3d voxel array - so errors here can throw an index out of range (about 1 in 1 million rays, but still a run time panic for me) -- 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.