dipityPix app

Wednesday, February 17, 2016

Ray-Object Intersection Repository at RTR

Until Eric H's comment on a previous post, I was somehow unaware of this page.   It really rocks and will be my first stop when I look again at triangles (next week?).   Here is the page.

Sunday, February 14, 2016

New simple ray-box test from Andrew Kensler

Andrew Kensler and Thiago Ize have been helping me tune up my ray-box code trying to find a sweet-spot of fast and simple.   I've updates a few test cases here and added the new method Andrew sent me.   Andrew's new code a super-simple version that on some compilers/machines is very competitive with the Amy Williams method, and you don't have to muck up your ray class.    It's not as fast under clang on my mac (but hard-coding swap helped a little) but it's so simple it will be my go-to method for the time being.

If there are NaN the compare will fail and it returns false.   It handles the inf cases right.    Very clean!

Saturday, February 6, 2016

ray-box intersection and fmin

In working on the code for the next mini-book, I have followed the philosophy of using the simplest code and trusting that it is good enough.   For bounding volume hierarchies I tried making a simpler ray-box test that people usually use.   I was especially impressed with this post by Tavian Barnes.

This is the simplest ray-box test I was able to write:

The overall code seemed pretty slow so I tried some old more complicated code that stores the sign of the ray propagation directions as well as the inverses of the ray direction components:

This was a lot faster in the overall ray tracer so I started digging into it a bit.   I wrote an isolation test that sends lots of rays from near the corner of a box in random directions (so a little less than 1/8 should hit).    It occurred to me that the fmax and fmin might be slower due to their robust NaN handling and that does appear to be the case.    Here is the test I used on my old macbook pro compiled with -O.   Perhaps it gives a little too much amortization advantage to the long code because 100 trials for each ray, but maybe not (think big BVH trees).

The runtimes on my machine are:

traditional code: 4.3 s
using mymin/mymax: 5.4s
using fmin/fmax: 6.9s

As Tavian B points out, the properties of fmax and NaN can be used to programmer advantage, and vectorization might make system max functions a winner.   But the gaps between all three functions were bigger than I expected.

Here is my code.   If you try it on other compilers/machines please let us know what you see.

Monday, February 1, 2016

Motion blur in a ray tracer

I implemented the first change in my ray tracer for my next mini-book.    I had forgotten how easy motion blur is to add to a ray tracer.   For linear motion anyway.    The ray gets a time it exists at, the camera generates a ray at a random time, and the object intersection takes a time in.

For a sphere whose center moves linearly, the change is just to make the center a function of time:

To test it I had the diffuse spheres have a random vertical motion.   This was a rare time my code worked on first run (after many typos on the way to compilation).