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...

We have fully completed the creation of the BVH tree using the top-down approach described in [Kay/Kajiya 1986]. The results look very convincing after testing with many simpler cases. The above shows our Stanford bunny with correctly applied axis aligned bounding volumes. We now will start the part of the project where we transfer the BVH tree via texture to the GPU. We are excited.

[Kay/Kajiya 1986] Timothy L. Kay, James T. Kajiya: Ray Tracing Complex Scenes, ACM Computer Graphics, Volume 20, Issue 4, p. 269-278, 1986, ACM Press, New York, USA

BVH Problems

We have finally fixed our problem with our normals. It turns out our PLY point indexing was incorrect, thereby causing our normals calculation to output faulty results. We laboriously traced our indices of our simple bunny in order to find the error.

We conducted research on different implementations of BVH trees and have created a root bounding box that works. We are currently unsure as to which is the most effective way to perform the subdivision of geometry. We will therefore continue with our research on possible approaches. We will look into surface area heuristics as recommended by Mr. Luebke from NVidia.

PLY Loaders specifics

The PLY loader we wrote currently only reads in files in ascii format. There are tools out there to convert the binary PLY files into ascii ones, but they're the type of tools that are ill-documented and consist of a lot of source files you have to put together yourself, so integrating those is a back-burner step.
The stanford bunny comes in ascii PLY at varying degrees of fidelity, so he's our current test object.

Debug Applet Initiated

We have been able to merge the PLY loader with the OpenGL output window. Currently the shaders are simply spitting out the input data, but at least we are getting objects rendered. Our next step will be to finalize the ray tracing algorithm and apply to the debug app.

Project Update

We are currently making progress towards our alpha build of the project. We have thoroughly researched the background information involved in creation of the ray tracer and the bvh trees. The PLY loader is fully implemented, although the further details of its implementation will be revealed later. The OpenGL debug window has also been completed more or less. We will meet in the near future to combine the two modules. We will also revise our schedule based on advice provided to us by a previous student who worked on a similar project.

Project Abstract

Ray tracing is the rendering technique of shooting multiple rays into a scene from the point of view of the camera. In a modest view port this involves hundreds of thousands of rays shooting and even reflecting off surfaces. Each ray then needs to be tested against every object (or object component) in the scene for an intersection to find the closest intersection to the ray.

Our project suggests a speed up of this technique by shooting the rays in parallel, and instead of testing all the rays against each triangle in the scene; we propose that the geometry is ordered in a bounding volume hierarchy (BVH) as described in “A Comparison of Acceleration Structures for GPU Assisted Ray Tracing” by Niels Thrane and Lars Ole Simonsen.

The BVH will be composed of geometry enclosed in axis aligned bounding boxes (AABB) that will be constructed in a top down approach from the scene input. The BVH Tree will be represented as a texture, and each ray as well as the BVH Texture will be passed to the GPU for processing. The result will be the intersection for each ray, which will be processed by the main program and rendered in OpenGL to be a realistic scene.

*Photo from "Ray Tracing on a Stream Processor" Purcell, T. Standford : 2004

Blog Launch

This is the blog for our CIS665 GPU Programming and Architecture final project. The project consists of creating a GPU-based ray tracing application which incorporates a bounding volume hierarchy to further improve rendering efficiency. In future posts, we will provide updates on our progress with the project.