## Friday, March 23, 2007

### Rainbows in clouds

When the sun is behind you and you look at some rainstorms, you see a rainbow. Since the droplets in a cloud are (I assume) spherical, why don't we see rainbows in clouds? My hypothesis is that they are there, but they are superimposed on a bright cloud where secondary scattering dominates, so the rainbow is just washed out by contrast. Recently I was on a flight around noon and could see below me the shadow of my plane and when the clouds became thin enough that primary scattering probably dominates, there was a perfect circular rainbow with the dark terrain below it. So why no rainbows from thin clouds when the viewer is not on a plane? My guess is the sky behind it is bright. But I am unsure. Another possibility is that what I saw was not a rainbow. But the ring's angular radius looked about right...

### Getting to Ulm from the US

For those interested in attending RT07 (see previous post), I found that going through Frankfurt was really easy-- the airport has a train station that will take you straight to downtown Ulm. If you do that, be aware that train has a reserved seating system (like an airplane or Amtrak). Hope to see you there!

## Monday, March 19, 2007

### IRT 07

The interactive ray tracing symposium will be in Ulm, Germany this year:

IRT 07 site

SCHEDULE

JUNE 14, 2007 SUBMISSION DEADLINE

JULY 12, 2007 REVIEWS DUE

JULY 19, 2007 AUTHOR NOTIFICATION

AUGUST 2, 2007 CAMERA-READY COPY

SEPTEMBER 10-12, 2007 SYMPOSIUM IN ULM

IRT 07 site

SCHEDULE

JUNE 14, 2007 SUBMISSION DEADLINE

JULY 12, 2007 REVIEWS DUE

JULY 19, 2007 AUTHOR NOTIFICATION

AUGUST 2, 2007 CAMERA-READY COPY

SEPTEMBER 10-12, 2007 SYMPOSIUM IN ULM

## Thursday, March 15, 2007

### Bounding Volume Hierarchy

If I were trapped on a desert island with only one data structure allowed I would bring my trusty BVH. I have been liking the BVH for some time in spite of all the k-d tree advocates (see the SIGGRAPH 05 notes for a discussion before ray packets were integrated) despite them being "slow". One reason is simplicity-- dividing on objects leads to cleaner implementations than dividing space, and leads to O(N) bounded memory use. My basic software rule is

Solomon Boulos and Ingo Wald have done a bunch of nice work to packetize a BVH (a ray packet is a set of rays that are traced together). The first optimization (and a huge one) is to descend the BVH as soon as any of the rays hit a box. Maintaining a "first not dead ray" index makes this more efficient. Another optimization is to use interval arithmetic to test a whole packet against a box for a conservative trivial reject. See Solomon's tech report for details (it is really simple even though it sounds fancy, and has a nice mapping to C++ code). Note that both of these optimizations are algorithmic and are mostly orthogonal to SSE optimizations (the descend if one hits optimization makes SSE less helpful).

Finally, the BVH traversal has a low penalty for false positives on boxes, so conservative boxes like you get for moving objects, and well as the lower intrinsic coherency of secondary packets, are not so bad for the BVH.

An important disclaimer: I have previously (in the early 90s) been an advocate of k-d, and later the grid. So maybe this is just the end of the first cycle in my opinion!

It does help if you use the surface-area heuristic to build (that was what it was first invented for in fact-- the BVH). Nobody has ever justified to my satisfaction why the SAH greedy algorithm works so well.

**KISS rules!**. Another reason is they handle many dynamic models well as has been shown by the collision detection community. It turns out they can also be fast.Solomon Boulos and Ingo Wald have done a bunch of nice work to packetize a BVH (a ray packet is a set of rays that are traced together). The first optimization (and a huge one) is to descend the BVH as soon as any of the rays hit a box. Maintaining a "first not dead ray" index makes this more efficient. Another optimization is to use interval arithmetic to test a whole packet against a box for a conservative trivial reject. See Solomon's tech report for details (it is really simple even though it sounds fancy, and has a nice mapping to C++ code). Note that both of these optimizations are algorithmic and are mostly orthogonal to SSE optimizations (the descend if one hits optimization makes SSE less helpful).

Finally, the BVH traversal has a low penalty for false positives on boxes, so conservative boxes like you get for moving objects, and well as the lower intrinsic coherency of secondary packets, are not so bad for the BVH.

An important disclaimer: I have previously (in the early 90s) been an advocate of k-d, and later the grid. So maybe this is just the end of the first cycle in my opinion!

It does help if you use the surface-area heuristic to build (that was what it was first invented for in fact-- the BVH). Nobody has ever justified to my satisfaction why the SAH greedy algorithm works so well.

## Wednesday, March 14, 2007

### New ray packet paper

Solomon Boulos and friends have shown that ray packets may work for secondary rays. Check out the first paper here. As much as I hate the software engineering implications that arise with ray packets, I do like that they can make things faster.

## Saturday, March 10, 2007

### Environment map formats

As there are no "natural" mappings between the sphere of directions and the square, so there is no standard way to parametrize your environment map. In the Original paper by Blinn and Newell, a cylindrical map was used. There are many such cylindrical maps out there and have been used for map projection . For software renderers these are more intuitive than cube maps or the Disk on square paramerterization. In a physically based renderer, you would like to importance sample the environment map. This is easiest if each texel in the map subtends the same solid angle as every other texel. There is one cylindrical map that does this for a given rectangle. A well-known version of this projection is the Peters Projection.

Here's an example projection. The rectangle has parameters [0.1]^2. Let's take u to the angle phi (longitude): u = phi/(2*pi) = atan2(y,x)/(2*pi) assuming your direction (x,y,z) is a unit vector and z is "up". Now we have v = f(z). The simplest such mapping is v = (z+1)/2. Is there area distortion there? What is the area of a given pixel in the texture map. How about the differential area? Let's say that we have a differential square du*dv in the texture map. The area on the sphere of that will be sin(theta) * dtheta(v) * dphi(u).

dphi(u) = 2*pi*du = constant so we can ignore it.

Since z = cos(theta), the other mapping is

(cos(theta) + 1)/2 = v

so differentiating both sides:

-sin(theta)*dtheta/2 = dv

As the differential area is proportional to sign theta, each pixel does have the same solid angle. So this most simple mapping is also a good one! I am not sure why anybody uses any other in a software renderer.

Here's an example projection. The rectangle has parameters [0.1]^2. Let's take u to the angle phi (longitude): u = phi/(2*pi) = atan2(y,x)/(2*pi) assuming your direction (x,y,z) is a unit vector and z is "up". Now we have v = f(z). The simplest such mapping is v = (z+1)/2. Is there area distortion there? What is the area of a given pixel in the texture map. How about the differential area? Let's say that we have a differential square du*dv in the texture map. The area on the sphere of that will be sin(theta) * dtheta(v) * dphi(u).

dphi(u) = 2*pi*du = constant so we can ignore it.

Since z = cos(theta), the other mapping is

(cos(theta) + 1)/2 = v

so differentiating both sides:

-sin(theta)*dtheta/2 = dv

As the differential area is proportional to sign theta, each pixel does have the same solid angle. So this most simple mapping is also a good one! I am not sure why anybody uses any other in a software renderer.

Subscribe to:
Posts (Atom)