"Grainy" mirror.ppm

[ginkxo]

Getting a very peculiar issue at the moment. With every other image working perfectly, this is my mirror.ppm:

This is 100% due to my code for reflection. I've straightforwardly followed the textbook and the reflection code itself is a very short addition (just the extra recursive calls with the call to reflect, etc).

Interestingly, when I set the recursive raycolor's "min_t" to not just the given epsilon but "min_t + epsilon" it works fine:

However, using "min_t + epsilon" then messes up some of the subtle reflections in the bunny.ppm:

before:

after:

as an aside I've made sure that d is normalized in the reflection calculation (n is also normalized by default). I am wondering if this "graininess" is some self-reflection bugginess that is happening somewhere. Because raycolor only outputs a boolean of whether or not it hits along with an rgb vector, I'm not super certain what I might be able to check or compare here to adjust and remove this phenomenon due to what might be self intersection somewhere.

[darren-moore]

The graininess indeed seems to be due to self-intersection in reflection. It's not clear to me what exactly you are passing to the recursive call for min_t. It sounds like you're passing a reference to min_t. Consider what the initial value of min_t coming from the camera is, and what value should be passed in a recursive call.

[ginkxo]

The graininess is for when I just only passed in the epsilon in the min_t argument of the recursive call. It cleared up when I passed in initial min_t+epsilon, but with the resulting changes to the bunny.ppm image we don't want.

I can think that we start with min_t in the first call from the camera, and the first_hit in the raycolor gives us a resultant t that is used in the parametric equation for the viewing ray to find the intersection point. Besides these I'm a bit uncertain how the initial min_t or t might be able to work in conjunction with the epsilon to be the "new" min_t argument for the recursive call. For the reflect ray, I use t to calculate the intersection point q, and its direction is calculated from the reflection equation. But as far as I understand since this reflection ray would define a new parametric line equation q + tr I can't fathom why min_t in the next recursive call might be anything besides just epsilon as an initial?

[ginkxo]

do we need to loop through all the lights? I was initially calculating reflection based off of the view direction "d" as in the textbook, but now I'm thinking that the method in the slides might be the way to go -- but since we have multiple light sources, does this mean we will need to call individual recursive raycast calls for each light in the loop and superimpose them all up?

[darren-moore]

I can't fathom why min_t in the next recursive call might be anything besides just epsilon as an initial?

That's exactly right, which is why your issue is so mysterious... Are you considering self-intersections for shadowing as well?

I wonder if you're initializing the reflected vector correctly? To zero, before passing reference and recursing: Eigen::Vector3d blah(0,0,0);.

does this mean we will need to call individual recursive raycast calls for each light in the loop and superimpose them all up?

No, remember that rays are coming from the camera in our model, not from lights.

[ginkxo]

(disregard, need to check something)

edit: figured it out! the problem was some typing all along, always check your types folks