BVHallelujah

In the previous episode, our BVH traversal still had some issues in which much of the culling was not taking place. This made the traversal very inefficient and resulted in pretty, but slow bunnies. In fact, the high resolution bunny we had would not even load because the computer ran out of steam. After some further work, we were able to fix those issues which turned out to be some stupid logic errors. We are now able to run our high resolution bunny faster than the low resolution bunny ran before (~4 fps).

The Bunny Is In The House

We finally have a ray traced bunny!!!! The red bunny rendered above contains ~16000 polygons and was ray traced in 0.04 seconds.

Profiles, wow

So we just found out about earlier today that we've wasted countless hours dancing around the most inane cg errors all because we were using a very outdated profile (working from the homework 1 code on my laptop). The profile we were using didn't support while or for loops, min/max calls, or even tex2d!!! The only way we finally found out this was the problem was when Gary walked by and we complained to him that we spent most of our time debugging cg line by line with out a complier due to an "cg compile error" crash at runtime.

He told us about the "cgc" command line debugger and now we're finally able to fly through cg code like we should have been doing weeks ago. Now we're working with fp40 and things are going well. Stocked up on Red Bull and candy from WaWa =)

More cg problems

We're still hammering out little cg errors. It's really frustrating to have the concepts for BVH trees and raytracing so solidly planned out, and get continually bogged down by cg compile errors. We're regretting our decisions to implement in cg now. CUDA definitely would have been easier to work with. Unfortunetly we wanted maximum portablity and to be able to follow the paper as best as possible. It doesn't seem worth it anymore. =(

At the moment all our textures seem to be passing okay. There seem to be some problem with simple cg calls our main kernel is making to other cg helper kernels. Specifically our Intersection test. There doesn't seem to be any good reason why it shouldn't work. We'll keep debugging it.

Stuck on some CG stuff

So we've put the CPU side of this project to rest. We've tested our BVH tree to death CPU side, but things aren't synching up on the cg side. We struggled for a couple of days just getting our cg code to compile. Apparently there's a problem having cg that doesn't know the number of loop iteration in a while loop while compiling. Now that that's sorted out we are working on calculating the ray intersections on the GPU side.

Journey to the GPU - Part I of 0

Having finished with most of the CPU aspect of the project, we started work on transfering the BVH and ray data to the GPU via textures. We had to review the necessary steps to convert and pass the data as textures and ran into a few roadblocks in trying to do so. Fortunately, we were able to figure most of the issues out. Currently we believe we have correctly passed the data, but are not really sure how to effectively test it. The next step we will then tackle will be formulating and coding the ray intersection test on the GPU based on the paper [1]. Hopefully this will go smoothly so we can move on to getting the results and outputting them to the screen asap. We are still excited.

[1] “A Comparison of Acceleration Structures for GPU Assisted Ray Tracing” by Niels Thrane and Lars Ole Simonsen.

Bunnys of the world

We've trying to make sure the textures we are sending to the cg program are set up right. They include textures containing data for the bvh tree, the ray origins, the ray directions, and the best hits so far per ray. To test them we map them to bunnies before we send the textures. Some of them seem to work, some seem to pass okay but color the bunny wrong, and some crash program...