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 On Wednesday, September 21, 2016 at 10:16:33 PM UTC+1, xiio...@gmail.com wrote: > > Thanks for those links - I started using a something similar to what is > described as Smit's algorithm (Slab method) in the Amy Williams paper. My > code us subtly different to that usually given because I check the "back > face" intersection first -for an early terminate ; this basically involves > swapping x_plane_min and x_plane_max early if v.X<0 .. then looking > explicitly for the back plane intersection points first.. as well as being > slightly more verbose it seems to have the side effect of avoiding the > divide by -0 problem described in the paper. (misses ray parallel to plane, > catches adjoining edges) I think my version is sub-optimal but not a > priority right now. > > I've noticed that the divides in all the "slab" methods could be > multiplied out - this which inverts the boundary condition if the divisor > was negative, but can be caught using > > if (multiplied_x < undivided_boundary_value) ==(divisor>0) > > > instead of the vanilla. > > if (x < boundary_value) > > > not only does this avoid any division (hurray!), but also reduces the > cumulative float errors - the number of operations on both sides of the > condition of is roughly equal, rather than being unbalanced with most on > one side in the un-premultuplied version.. It's a little more complicated, > but divides are, afaik, still slow even on modern hardware, which is > something I suspect may be a bottleneck within the function.. I need to > bench this.. It may mitigate but doesn't solve the float precision problem. > > The second link is a nice optimisation for simd too. Optimisation for this > function isn't a big priority for me because I'm primarily using it it get > the intersection point for a bounding volume for a "3d texture" (or > 'non-sparse voxel array' in other words) - my main routine steps through > the voxel grid front to back using a different algorithm. > > PBRT looks good - wasn't aware of it - found the pre-publication chapter > section 3.9.2 "CONSERVATIVE RAY–BOUNDS INTERSECTIONS" - though I didn't > proof read it it looks like it covers using calculated expected errors > (deltas) well. > -- 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.
