My path tracer

Show-off, reference material & tools.
chriso
Posts: 7
Joined: Mon Mar 19, 2012 2:10 am

My path tracer

Post by chriso » Mon Mar 19, 2012 2:24 am

I started work on a path tracer around 2 weeks ago, using Caustic's OpenRL to develop it and I thought I'd post a few demo shots!

Image
A cornell box test. I'm not convinced that my refraction code is entirely correct, especially because of the caustic.

And some sponza shots in (roughly) chronological order
Image
Image
Image
Image
The first 3 images are a little off in terms of colour due to the lack of 'proper' gamma correction, and the illuminated lion in the last is deliberate (trying to make materials emissive)

It seems to need around 30spp to look mostly noise free (apart from particularly shady areas), and it takes ~10 seconds per spp per frame to render the images @ 1280x720. I don't handle reflection/specular surfaces at the moment, but I'll get round to adding it soon!

SonKim
Posts: 3
Joined: Sat Mar 03, 2012 3:31 pm

Re: My path tracer

Post by SonKim » Thu Mar 22, 2012 5:15 am

Pretty awesome for 2 weeks worth of work! Are you aiming for real-time path tracing for games?

chriso
Posts: 7
Joined: Mon Mar 19, 2012 2:10 am

Re: My path tracer

Post by chriso » Thu Mar 22, 2012 3:28 pm

Thanks. I'd like to manage real time some day, although OpenRL only runs on CPUs right now, which makes it a little difficult. When Caustic have some hardware on the market it will be a more attainable goal.

ingenious
Posts: 282
Joined: Mon Nov 28, 2011 11:11 pm
Location: London, UK
Contact:

Re: My path tracer

Post by ingenious » Thu Mar 22, 2012 7:20 pm

chriso wrote:When Caustic have some hardware on the market...
Yes, when? :D We haven't touched that subject in the new ompf yet ;)

chriso
Posts: 7
Joined: Mon Mar 19, 2012 2:10 am

Re: My path tracer

Post by chriso » Thu Jul 12, 2012 12:17 pm

I've been working on this a bit more recently.

First off, a 320x180 video of a cornell box at 1spp, 5-10fps:



And some more interesting stuff
Image
Image
Image

Sadly nowhere near real time (about 10 seconds per 1spp frame), but my code is fairly unoptimised at the moment.

spectral
Posts: 382
Joined: Wed Nov 30, 2011 2:27 pm
Contact:

Re: My path tracer

Post by spectral » Fri Jul 13, 2012 9:12 am

Hum,

Maybe it is me... but... it seems slow, on which hardware do you run it ?

chriso
Posts: 7
Joined: Mon Mar 19, 2012 2:10 am

Re: My path tracer

Post by chriso » Fri Jul 13, 2012 9:33 am

It is running on an i7 920, no GPU acceleration at all.

spectral
Posts: 382
Joined: Wed Nov 30, 2011 2:27 pm
Contact:

Re: My path tracer

Post by spectral » Fri Jul 13, 2012 7:35 pm

I see...

I don't know caustic... but I was thinking it use GLSL and was running on the GPU through openGL only :-P

sirpalee
Posts: 22
Joined: Mon Nov 28, 2011 3:23 pm
Location: Madrid

Re: My path tracer

Post by sirpalee » Tue Jul 24, 2012 5:25 pm

What are your experiences with openRL? I always wanted to take a look at their SDK, but never had the time for that.

How easy to use? What about shader networking? Out of core data access?

chriso
Posts: 7
Joined: Mon Mar 19, 2012 2:10 am

Re: My path tracer

Post by chriso » Wed Jul 25, 2012 4:25 pm

sirpalee wrote:What are your experiences with openRL? I always wanted to take a look at their SDK, but never had the time for that.

How easy to use? What about shader networking? Out of core data access?
I've found OpenRL very easy to use. You submit the geometry using a very similar API to OpenGL, define some shaders and make a call to render. You get back a framebuffer (or several).

There are 3 types of shader: Vertex (self explanatory), Frame and Ray.

Frame Shaders are executed once per pixel in the output framebuffer - this is where you generate your eye rays (along with lens effects/ MSAA)
Ray Shaders are executed when a ray hits an object. Each primitive has a ray shader associated with it. The shader is called with information about the intersection point, along with the uniforms for that primitive. From here you can accumulate to the framebuffer for the current pixel and emit more rays in whichever direction you want. I'm not sure how well shader networking maps on to OpenRL - you can write functions to do whatever you want in the shader code, and call different functions in the shader depending on the properties of the primitive the ray hit, which I guess provides the same functionality as the shader network.

As for data access, you just submit the geometry and OpenRL handles all of the memory etc. I haven't tried rendering any truly huge scenes yet - the courtyard scene uses about 1.5GB of RAM on my machine while running.

Post Reply