Question

I’m trying to render the “mount” scene from Eric Haines’ Standard Procedural Database (SPD), but the refraction part just doesn’t want to co-operate. I’ve tried everything I can think of to fix it.

This one is my render (with Watt’s formula):

_{(source: philosoraptor.co.za)}

This is my render using the “normal” formula:

_{(source: philosoraptor.co.za)}

And this one is the correct render:

_{(source: philosoraptor.co.za)}

As you can see, there are only a couple of errors, mostly around the poles of the spheres. This makes me think that refraction, or some precision error is to blame.

Please note that there are actually 4 spheres in the scene, their NFF definitions (s x_coord y_coord z_coord radius) are:

s -0.8 0.8 1.20821 0.17
s -0.661196 0.661196 0.930598 0.17
s -0.749194 0.98961 0.930598 0.17
s -0.98961 0.749194 0.930598 0.17

That is, there is a fourth sphere behind the more obvious three in the foreground. It can be seen in the gap left between these three spheres.

Here is a picture of that fourth sphere alone:

_{(source: philosoraptor.co.za)}

And here is a picture of the first sphere alone:

_{(source: philosoraptor.co.za)}

You’ll notice that many of the oddities present in both my version and the correct version is missing. We can conclude that these effects are the result of interactions between the spheres, the question is which interactions?

What am I doing wrong? Below are some of the potential errors I’ve already considered:

• Refraction vector formula.

As far as I can tell, this is correct. It’s the same formula used by several websites and I verified the derivation personally. Here’s how I calculate it:

double sinI2 = eta * eta * (1.0f - cosI * cosI);

Vector transmit = (v * eta) + (n * (eta * cosI - sqrt(1.0f - sinI2)));

transmit = transmit.normalise();

I found an alternate formula in 3D Computer Graphics, 3rd Ed by Alan Watt. It gives a closer approximation to the correct image:

double etaSq = eta * eta;
double sinI2 = etaSq * (1.0f - cosI * cosI);
Vector transmit = (v * eta) + (n * (eta * cosI - (sqrt(1.0f - sinI2) / etaSq)));
transmit = transmit.normalise();

The only difference is that I’m dividing by eta^2 at the end.

• Total internal reflection.

I tested for this, using the following conditional before the rest of my intersection code:

if (sinI2 <= 1)

• Calculation of eta.

I use a stack-like approach for this problem:

        /* Entering object. */
        if (r.normal.dot(r.dir) < 0)
        {
           double eta1 = r.iorStack.back();
           double eta2 = m.ior;
           eta = eta1 / eta2;

           r.iorStack.push_back(eta2);
        }
        /* Exiting object. */
        else
        {
           double eta1 = r.iorStack.back();
           r.iorStack.pop_back();
           double eta2 = r.iorStack.back();

           eta = eta1 / eta2;
        }

As you can see, this stores the previous objects that contained this ray in a stack. When exiting the code pops the current IOR off the stack and uses that, along with the IOR under it to compute eta. As far as I know this is the most correct way to do it.

This works for nested transmitting objects. However, it breaks down for intersecting transmitting objects. The problem here is that you need to define the IOR for the intersection independently, which the NFF file format does not do. It’s unclear then, what the “correct” course of action is.

• Moving the new ray’s origin.

The new ray’s origin has to be moved slightly along the transmitted path so that it doesn’t intersect at the same point as the previous one.

p = r.intersection + transmit * 0.0001f;

p += transmit * 0.01f;

I’ve tried making this value smaller (0.001f) and (0.0001f) but that makes the spheres appear solid. I guess these values don’t move the rays far enough away from the previous intersection point.

EDIT: The problem here was that the reflection code was doing the same thing. So when an object is reflective as well as refractive then the origin of the ray ends up in completely the wrong place.

• Amount of ray bounces.

I’ve artificially limited the amount of ray bounces to 4. I tested raising this limit to 10, but that didn’t fix the problem.

• Normals.

I’m pretty sure I’m calculating the normals of the spheres correctly. I take the intersection point, subtract the centre of the sphere and divide by the radius.

Answer 1

So after more than I year, I finally figured out what was going on here. Clear minds and all that. I was completely off track with the formula. I’m instead using a formula by Heckbert now, which I am sure is correct because I proved it myself using geometry and discrete math.

Here’s the correct vector calculation:

double c1 = v.dot(n) * -1;
double c1Sq = pow(c1, 2);

/* Heckbert's formula requires eta to be eta2 / eta1, so I have to flip it here. */
eta = 1 / eta;
double etaSq = pow(eta, 2);

if (etaSq + c1Sq >= 1)
{
   Vector transmit = (v / eta) + (n / eta) * (c1 - sqrt(etaSq - 1 + c1Sq));
   transmit = transmit.normalise();
...
}
else
{
   /* Total internal reflection. */
}

In the code above, eta is eta1 (the IOR of the surface from which the ray is coming) over eta2 (the IOR of the destination surface), v is the incident ray and n is the normal.

There was another problem, which confused the problem some more. I had to flip the normal when exiting an object (which is obvious – I missed it because the other errors were obscuring it).

Lastly, my line of sight algorithm (to determine whether a surface is illuminated by a point light source) was not properly passing through transparent surfaces.

So now my images line up properly 🙂