Raytracer Assignment 2

So I got the ray tracing working for at least non-recursive color picking the other day. Been waiting to put this up until I cleaned it up a bit. I've learned a lot on this assignment aside from how to implement the ray tracer itself:

1. 90% of the time, if the algorithm is showing anything at all, you're 99% correct and one little bug is holding you back.


2. Never assume you know math by heart. I've taken and easily aced all levels of calculus, differential equations, matrix algebra and multi-variable calculus; yet the source of almost a solid day's worth of frustration on this assignment this weekend was the result of me misplacing parenthesis in the quadratic formula.


3. These things are slow. When I first got everything rendering this weekend, I was looking at an average of 7 seconds per frame. That skyrocketed to over half a minute for a simple 2x2 multi-sampling technique, with an exponential increase as the complexity rose. I've profiled my C++ code using a fantastic utility called Very Sleepy which picks up on the debugging symbols that visual studio embeds in my program and can profile individual lines of code with up-to-date source code every time. This helped me narrow down the problematic aspects of my renderer and get that 7 seconds per frame down to a more tolerable 2 seconds. More on this later.

So anyways yeah, it works and it renders the scene as it's supposed to:

From CG2 - Week 2

Once I could stand the wait time for multi-sampled renderings to process, I snapped one of those too at 4x4 = 16 samples per pixel:

From CG2 - Week 2

The results of the 16x multi-sampling look good, but the ray algorithm performs really slowly. I could probably improve it a bit, but I don't think it's worth my time at the moment, and it's probably not the largest bottleneck in the system still.



In fact, this is another important thing I learned during this. I strove for an object-oriented approach to this whole thing, and unfortunately it turns out that all of that overhead that the C-fans rant about actually matters with something as CPU intensive as a ray tracer. I actually believe this is the source of much if not all of my low-performance problems. Multiple levels of data abstraction and hierarchical class design make some operations much slower than they could be. In my efforts to get this down to where it's at now time-wise, I already reduced my Ray3D class to a simple struct with public members. I also dropped STL iterator functionality from the scene's intersection code as well, since Very Sleepy claimed that iterator incrementing was huge. That was probably the biggest boost in speed that I got over all.



Anyways, I'm a little early on this assignment, I think I've got roughly a week until it's due. I plan to work on my project a bit during that time, but if that's looking good by later in the week I just might go back and re-implement parts of mRay's pipeline in straight C. Another possibility I'm entertaining is OpenCL. I'm gonna do a bit of research on that, since if I'm using straight C I might as well do something cool with it. We'll see.