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.

Reply via email to