Stuck on Chapter 11: Reflection and Refraction

Hi!

I have been away from my raytracer for a while (it's an ongoing backup project to make something extensible and fun - helps with my linear algebra too!), but I read your post and decided to load up my raytracer and see what happened. It's been so long (well over a year) since I dealt with the actual chapter 11, and I genuinely expected my invocation of the same test to fail, as since I've moved on from the chapter work, my refraction code seems to have become broken, no longer showing contained objects inside a (partially-)transparent outer object. To my surprise and pleasure, I got the correct results from the test ({
"r": 0,
"g": 0.9988745506795582,
"b": 0.04721898034382347
})

So, I am currently tracing my internal values on invocation of refracted_color(...)....

I have all the same internal values you listed, and your code has the same semantics/effective syntax as mine (albeit my raytracer is currently implemented in js), the only difference I see is that because my color object is derived from the same 'tuple' function object (if you know how js works) as vector and point, thus whereas you use two seperate functions to multiply a vector by a scalar ('vMult'), and a color by a scalar ('scale'), I use the same function {as it goes, it's called multiplyScalar(scalar, tuple)}. As all your previous tests are passing, including obviously test #6 etc, there is no obvious indication of what is going wrong, unless the 2 functions 'scale' and 'vMult' are not essentially identical.

The only thing I can think of is that 'matTransparency' should be 1. Check, because perhaps 'scale' is multiplying the returned value of 'colorAt' by a number higher than 1, and if the 'scale' function clamps values greater than 1.0, perhaps that is what is happening.

Straightforward test:

calc result of 'colorAt' BEFORE you pass it to 'scale', and see if it's return value is correct, i.e. it contains the color object above (the expected output), if so, then I imagine if you were to peek at matTransparency it would be > 1, but it shouldn't be.

Let me know if this is helpful, or if I'm an idiot.

Looking into my 'colorAt' function, the bug has to either be in the selection of the intersection, in the 'shadeHit' function, or in preparing the computation incorrectly for the selected intersection. Here's what I have for the list of intersections generated by 'World.intersect' for the same refractRay from the test:

Yeah, I just checked the intersect_world() return array of intersections, and all the t values are correct, but the 4th intersection, the one with t=~0.5 should be the sphere with scaling 1, not the inner sphere.

Not gonna lie, your TU structure leads me to be confused as to where exactly your ch11 test #7 actually is... its okay i found it, but clearly, its *very weird* that you should get the correct t-value, somehow assigned to the wrong object/shape (from one sphere to the completely other sphere). Reading your code (i am a multi-syntax guy, don't know haskell but I do 'get' the general idea, it's functional programming), I believe so far that the problem is either in the 'toIntersections' function (defined in Types.hs), called specifically from your test, which is called "testRefractedColorRefraction" in 'WorldTest.hs' (line 163), because there is a subtle difference(?) between Intersection and [Intersection] (i don't actually know that for a fact), or "intersect" on line #43 of 'World.hs' is scrambling the intersection array - is there a bug with mconcat or map, that trashes the object references??

To clarify the intersection code a little bit: I have an 'Intersection' type which contains the t value and the intersected shape. Then there is the 'Intersections' type which is a 'SortedList' of 'Intersection', which just enforces the precondition that the list of intersections must be sorted at the type level. The 'toIntersections' function just converts from [Intersection] (unsorted list) to the SortedList type 'Intersections'.

Wow, okay. I fixed the issue. Kind of disappointing, the issue was actually in the test. I tracked down the issue to the fact that the surface color returned by shadeHit after the refraction was just white, rather than the point of intersection as it would be if testPattern was working.

It turns out I didn't think through testPattern and the lighting of objects that do not have a pattern. The issue was it was treating testPattern as if the material did not have a pattern, so it was just returning the color of the sphere, which is white, rather than the point of intersection.

So now I changed the type of Material to be a record with Maybe Pattern, to represent that a material may or may not have a pattern. Then I can represent this behavior correctly in 'lighting' and voila, issue resolved and all tests passing.

Thanks for the help again!

Right, I needed to just sit down and very concretely think through the exact set of steps involved, and once I did that it became clear what the issue was, when before I was just browsing my code looking for an error and it seemed intractable. A good lesson in debugging for sure.