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.
On Wednesday, September 21, 2016 at 10:16:33 PM UTC+1, xiio...@gmail.com
> 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
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.