This post is the second update for the GPU Pathtracer project!

Since the last update, Peter and I added an interactive camera to the renderer to allow realtime movement around the scene! We also had our Alpha Review, which went quite well, and Peter implemented a reflection model. Initially the reflection model used was Schlick’s Approximation, but later Peter replaced that with the full Fresnel equations. I also added super-sampled anti-aliasing for a smoother image.

The posts for this update:

1. Interactivity and Moveable Camera: We can move around the scene!
2. Alpha Review Presentation: Slides and other stuff from our Alpha Review
3. Specular Reflection Test: The first test with Shlick’s Approximation
4. Fresnel Reflections: Some details on our reflection model
5. Abstract Art: Some fun buggy renders Peter produced while debugging
6. Anti-Aliasing: Super-sampled anti-aliasing!

A nice image from the last post:

Check the posts for tons of details, images, and even some video!

Here’s the first progress update/blog digest for the MultiFluids project!

Dan and I started by taking our starting framework and tearing it down to its core. We then rebuilt the base code up with our own custom additions, leaving just the core solver intact. From there, we started building some of the basic features our project will require!

Here are the posts for this update:

1. Framework Improvements and Particles with Properties: Tearing the base code down to the ground and rebuilding it better, faster, and with more features
2. Bounding Volumes & Lesson 1: Don’t just assume base code is perfect: Dan discovers some flaws in the base code!
3. Multiple Arbitrary Bounding Volumes: All-important object interaction

A frame from one of our test videos:

Check the posts for details and videos!

Here’s the first progress summary/blog digest for the GPU Pathtracer project!

Over the past few days, Peter and I established our framework, got random number generation working on the GPU, built an accumulator, figured out parallelized camera ray projection, got spherical intersection tests working, and got a basic path-traced image!

Here are the posts for this update:

1. Random Number Generation: Fun with parallelized random number generators and seeding
2. First Rays on the GPU: Parallel raycasting!
3. Accumulating Iterations: The heart of any monte-carlo based renderer
4. We Have Path Tracing: First working renders!

Here’s an image from our very first working render! More soon!

For both MultiFluids and the GPU Pathtracer, we will be making our source code accessibly to all on Github!

Of course commercial coding projects and whatnot have very good reasons for keeping their source code locked down and proprietary, but open source is something I very strongly believe in. Open code allows other people to see what one does and give feedback and suggestions for improvement, and also allows other people interested in similar projects to potentially learn and build off of. Everybody wins!

The MultiFluids repository can be found here: https://github.com/betajippity/MultiFluids

The GPU Pathtracer repository can be found here: https://github.com/peterkutz/GPUPathTracer/

…and of course, the relevant blog posts:

GPU Pathtracer: http://gpupathtracer.blogspot.com/2012/03/github-repository.html

MultiFluids: http://chocolatefudgesyrup.blogspot.com/2012/03/github-and-windowsosx.html

Over the next month and a half, I will be working on a pair of final projects for two of my classes, CIS565 (GPU Programming, taught by Patrick Cozzi), and CIS563 (Physically Based Animation, taught by Joe Kider).

For CIS563, I will be teaming up with my fellow classmate and good friend Dan Knowlton to develop a liquid fluid simulator capable of simulating multiple fluids interacting against each other. Dan is without a doubt one of the best in our class and easily my equal or superior in all things graphics, so working with him should be a lot of fun. Our project is going to be based primarily on the paper Multiple Interacting Fluids by Losasso et. al. and as a starting point we will be using Chris Batty’s Fluid 3D framework.

For CIS565, I will be working with my fellow Pixarian and friend Peter Kutz, who is somewhat of a physically based rendering titan at Penn. Working with Peter should be a very interesting and exciting learning experience. Peter and I will be developing a CUDA based GPU Pathtracer with the goal of generating convincing photorealistic images extremely rapidly. We will be developing our GPU pathtracer from scratch, although we will obviously draw inspiration from both Peter’s Photorealizer project and my own CPU pathtracer project.

For both projects, we will be keeping blogs where we will post development updates, so I won’t post too much about development details to this here personal blog. Instead, I’m thinking about posting a weekly digest of progress on both projects with links to interesting highlights on the project blogs.

Dan and I will be blogging at http://chocolatefudgesyrup.blogspot.com/. We’ve titled our project “Chocolate Syrup” for two reasons: firstly, Dan likes to codename his project with types of confectionaries, and secondly, chocolate syrup is one type of highly viscous fluid we aim for our simulator to be able to handle!

Peter and I will be blogging at http://gpupathtracer.blogspot.com/. For now we have decided to call our project “Peter and Karl’s GPU Pathtracer”, for obvious reasons.

Details for each project can be found in the first post of each blog, which are the project proposals.

Multiple Interacting Fluids Proposal: http://chocolatefudgesyrup.blogspot.com/2012/03/project-proposal.html

GPU Pathtracer Proposal: http://gpupathtracer.blogspot.com/2012/03/project-proposal.html

Both of these projects should be very very cool, and I’ll be posting often to both development blogs!

I have finished my KD-Tree rewrite! My new KD-Tree implements the Surface-Area Heuristic for finding optimal splitting planes, and stops splitting once a node has either reached a certain sufficiently small surface area, or has a sufficiently small number of elements contained within itself. Basically, very standard KD-Tree stuff, but this time, properly implemented. As a result, I can now render meshes much quicker than before.

Here’s a cow in a Cornell Box. Each iteration of the cow took about 3 minutes, which is a huge improvement over my old raytracer, but still leaves a lot of room for improvement:

…and of course, the obligatory Stanford Dragon test. Each iteration took about 4 minutes for both of these images (the second one I let converge for a bit longer than the first one), and I made these renders a bit larger than the cow one:

So! Of course the KD-Tree could still use even more work, but for now it works well enough that I think I’m going to start focusing on other things, such as more interesting BSDFs and other performance enhancements.