Path tracing in the viewport

[Chris_TC]

Before I even start, HUGE credit goes to Paul Smith. If you don't know his tutorials, watch them now on his Vimeo:
http://vimeo.com/user4895541/videos

I took his idea of an "ICE camera" and attempted to make it path trace. Rays are shot out of the camera grid, bounce around in the scene, return a color value and write it to a color at vertex map. Right now I can control:
- Camera resolution (512x288 in the example image)
- Camera field of view
- Trace depth (2 in the example image)
- Samples per pixel (512 in the example image)
- Diffuse color or texture map is assigned to objects via an ICE set data compound
- Emission color (for area lights) is assigned to objects via an ICE set data compound

Since I'm quite clueless about renderers, I have no idea whether the result is even correct. I may easily have messed up the math somewhere. But it looks kind of right. Oh, and don't get confused by the render time. Mental ray renders it quickly once the color at vertex map is calculated. But calculating that map takes a long time. It's path tracing after all (I think), not magic.

[Pooby]

That looks great! I'd love to know more about it. How does it work. Is it based on a similar system to mine? Have you tried a sequence? its funny that you say you don't know about renderers. I didn't either at all when I did my ray cam thing. But you have done a great job with the multiple bounce thing. How long is the calculation time?

I'd love to see a day when xsi is developed to the point when it would be feasible to render properly in ICE.
Imagine an "open source" ICE renderer that you could customise yourself. It'd be awesome!
Thanks for the credit btw.

[Chris_TC]

It's similar to yours, yes. You raycast into the scene and sample the object color where it hits. From this hit location you shoot another ray in a random direction. Wherever that ray hits, the color is multiplied with what you had previously. You repeat doing this until the specified ray depth is reached.

In order to reduce the amount of noise, you then repeat the above loop a certain number of times. Since each time the rays will bounce around differently (the seed of the randomized direction is changed every time), you can brute force all illumination in the scene. At least that's how I understood it. I used the Wikipedia article on path tracing, which has some pseudo code explaining it.
http://en.wikipedia.org/wiki/Path_tracing

I can share the pathtrace camera soon. I want to make it a bit more user friendly. For navigational purposes, there needs to be a simple direct light mode because pathtrace mode is too slow to be interactive. The calculation time for the example image was about 10 minutes I think. The papers on how to optimize it (bi-directional tracing and Metropolis light transport) have too many weird equations in them for me to understand, I need Wikipedia pseudo code

P.S.: Calculation time of course depends on the number of samples. I used 512 in the example image. But even with only 2 samples you can see an image, albeit a very noisy one. The more samples, the less noise, the longer it takes to calculate.

[Ramon]

Good job! Interesttind where and for what things you can apply this ttechnique?

[Chris_TC]

Good job! Interesttind where and for what things you can apply this ttechnique?

For the most part it's pretty useless because there are infinitely better professional path tracers with Softimage connections (like Maxwell Render), and I think mental ray itself even has a simple path material. I just find it amazing that you can do all this with ICE. I'm not a programmer, I didn't type one line of code, no <<stamp("../copy1", "xyz", 3)>> nothing. Just nodes, and not even very many.

It's a great learning exercise really. Paul's original raytrace camera is more useful because it makes great images and is quite responsive. If you parent the camera grid to an actual camera and make it fill the screen, you can even navigate the viewport like you normally would.