Independent Study: Week 4

Slow progress this week because of early midterms and projects in other courses ramping up. I'm still well on track with the tentative schedule I put into the original proposal however, which is a good thing. I plan to make a lot of progress on the material / object systems in the next few days in preparation for the photon mapping which I hope to start implementing this weekend. For now, here's a video that shows that I can successfully integrate my quaternion camera that I developed for a previous project into this project with moderate ease:

I think what I would like to do for photon mapping is get a very basic implementation done initially that uses something like a 1-dimensional (or perhaps 2-dimensional) sorted array for storing the photon map. That way I can get an idea of what kind of performance I have base-line, and then work on optimization. Here's the original projected schedule that I included in my proposal:

Week 1: Final decisions on architectures and hardware to be used are made.
Weeks 2-3: Basic OpenCL / CUDA Ray-Caster implemented (trivial, no bouncing)
Weeks 4-6: OpenCL / CUDA photon-map computation is implemented
Weeks 7-8: Benchmarking and Profiling, bottlenecks are identified and addressed
Weeks 9-10: Finishing touches. Final project completed.
Week 11: Formal Writeup / Final Paper completed.



It's currently week 4, so as I said I'm still well on track. I've also left myself an additional 2 weeks to get this part done, but more importantly is the 2 weeks I've allocated for optimization following that. At the latest, that is when I hope to implement an acceleration structure such as a kd-tree so that I can get some high frame rates. One of the cool things about this approach is that while performance will be decreased by the photon mapping itself, it's overall limited by the ray-tracer's resolution during final gathering. That means that  my "real-time" photon mapper may not be real-time at 1280x720, but dropping it down to 640x480 or lower could still yield decent frame rates. That's sort of cheating however, and I'd rather just get an awesome implementation that runs well :).

Also, caustics are (temporarily) off the table on this project until I get a better idea of the performance boundaries I'm dealing with. I'd love to implement the technique if I have time and I can keep the speed up.




Update: 4/7/2012


...for loops...


Tried adding multiple lights to my scene, a single light that I illuminate with phong shading gets me around 200 FPS at 1280x720 resolution. I up that to two hard-coded lights: 160 FPS...not bad at all. I keep the same two lights, but write the code with a for-loop so that I can handle an arbitrary number of lights: 100 FPS! Just the loop iteration is significantly reducing my frame-rates. I'm not really shocked, but it still sucks. I tried manually unwinding the loop in code and the speed actually went down, so I'm guessing OpenCL already takes care of that to some extent during compilation. Oh well, seeing as everything about this project is supposed to be about indirect lighting, I shouldn't technically need more than one light in the scene anyway. I've resorted to a preprocessor flag, USE_MULTIPLE_LIGHTS that when defined makes the code use a for loop, otherwise it just uses the first light in the scene. I might come back to this later on and see if I can find a faster way to get these going but I just don't see how at the moment...