Viewing Tree Depth

This version of my program partitions a unit cube and places them in a BVH tree. It renders the resulting bounding boxes (cubes) whose nodes have the desired tree depth.

I used this for timing. When generating and rendering a tree with a total depth of 6, it took ~14 - 20 seconds (for rendering boxes of depth one vs. depth six). A total depth of three took about 2-3 seconds, regardless of how many boxes I rendered. It seems strange that it should take so long.

I believe the ability to view by layer will help me debug my code as I develop an algorithm to group geometric shapes.

Silly Errors Along the way:

• Swapping min and max corners when declaring boxes
• Not overloading operators (like = )
• Not returning anything for a non-void function.

Operator Overload

October 12, 2011

I was receiving the EX_BAD_ACCESS error because I had not defined the = operator for BoundingBoxes.

I discussed the possibility of using pointers to bounding boxes instead of the actual thing, but the easiest solution at present seems to be overloading the = operator.

This site proved helpful in explaining the process.

Edit/Update


Rather than overloading the operator, I set the elements individually equal to each other (setting minCorner and maxCorner manually.) This was an easy option because so few elements make up a bounding box. For larger complex objects, = or pointers would be more ideal.

Preparing for BVH

Step One : Hit a Box Square


Silly Error # 0: Not checking all necessary boundaries:

I forget what caused the speckled/noisy consistency. I think I was making normal t values negative, which later caused me to disregard them...

Success:

The slight distortion is correct because the eye is at (0,5,2). +Z is up.

Step Two: Hit a Box

Silly Error # 1: Checking wrong Axes-

Silly Error # 2: Adding negative signs to t value for the...fun of it.

Finally successful:

I chose to shade according to axis. Faces with a normal parallel to X got red, Y got green, and Z got blue.

I was worried that I was missing the sides, so I changed the eye position to (3,5,2). This verified I was getting all sides.

Debugging Recursion, Reflections, and Shadows

Attempt #[BIG_NUM_HERE] at Reflections and Shadows: 
Using four bounces:

Using Two Bounces: 

Things that don't seem right to me:

• They look exactly the same, regardless of bounce number. (Time to dig up Image Magick's compare functions...)
• Vibrantly red speck on green sphere
• Speckles on plane

I wanted to see what it looks like without Shadows, so I disable them and get a "EXC_BAD_ACCESS" error unless I am at two bounces or less... In which case I get: 

Smeared color. I'm not sure what to make of this yet... and how do you visually debug in the midst of recursion?

Debugging and Visualizing

Color as function of reflected view direction: 

Responsible code (found in sphere's shade function)

#ifdef DEBUGGING
{
vec3f normal = hr.hitNormal;
normal.normalize();
vec3f viewDir = hr.startPt-hr.hitPoint;
vec3f refvDir = reflectVector(hr.hitNormal, viewDir);         
                                refvDir.normalize();
viewDir.normalize();
vec3f unitvec = refvDir;

shadeRec.color = (unitvec + vec3f(1.f)) * .5;
return shadeRec;
}
#endif

This makes sense, considering the axis to color correspondence: Red- X, Green - Y, Blue - Z. Replacing "unitvec" with other variables gives different debugging images. For instance, substituting hr.hitNormals gives: 

 

Color as function of Hit Normals: