(Almost) Real-Time Path Tracing

[LesPaul75]

I just discovered that modern GPUs can essentially do ray-tracing in real time.

Here are some examples from an engine under development: http://igad.nhtv.nl/~bikker
And, possibly even more mind-blowing, path tracing running in an interactive applet on a web page: http://madebyevan.com/webgl-path-tracing/

I'm only just beginning to research the subject, but apparently, it handles indirect lighting, soft shadows, ambient occlusion, reflection, and even transparency with refraction. No more need for lightmaps!

However, even fast GPUs are only barely able to handle this at a reasonable frame rate, so you'll immediately notice the grainy look that shows up while the lighting is being calculated. This will steadily improve as GPUs get faster. And that grainy look might even be acceptable in some games. Another possibility is offering the user a trade-off between screen resolution, frame rate, and graininess. For example, at 640x480, with the frame rate limited to say 10 FPS, you might eliminate that graininess entirely.

Anyway, just thought I'd mention this here, in the hopes that it might make it into Irrlicht. I know most developers would find that grainy look unacceptable, but I think I could actually make it work in my current project.

[LesPaul75]

Oh, it also handles depth-of-field blur. A good example of that in this video, towards the middle: http://www.youtube.com/watch?v=yzE4auqSCi4

[Mel]

Raytracing has been there for a long time already This is from 2000 or so and ran perfectly on a 350MHz machine without acceleration at all

http://www.youtube.com/watch?v=rNqpD3Mg9hY

The only real drawback for the raytracing is the scene traversing. While with simple and few primitives, it is posible to iterate through all of them, with complex meshes, it becomes more and more complex since you can't, at first, know which is the primitive you are aiming at on each pixel.

[LesPaul75]

That's a cool video of a demo, Mel. I used to be an avid follower of the "demo scene," even back in the early 90s. In fact, I remember a demo called "1993" that was released in 1993 and the whole thing was exactly 1993 bytes in size, but somehow managed to do some 3D rendering entirely in software (no one I knew had a 3D card in 1993).

That video you posted makes me nostalgic for those days -- the hard-edged shadows, the perfect spheres with 100% perfect mirror reflections... cool.

Anyway, yes, there are lots of examples of highly specialized software renderers that go beyond what is considered "the norm" in desktop graphics. But we all know that demos almost never translate into something that can be used in an actual game or game engine.

But the point of my original post is that real-time path tracing is actually becoming "the norm." It can now be done in a single shader, in fact. Even WebGL is powerful enough to do it. So I think it's reasonable to assume that it's time for this technique to make its way into game engines. And since I happen to be partial to Irrlicht as my engine of choice, I'm hoping path tracing becomes an option there.

Like I said, though, that grainy look isn't for everyone. I think it looks cool, and it almost starts to feel natural when I play around with the handful of demos that are available.

[LesPaul75]

The only real drawback for the raytracing is the scene traversing. While with simple and few primitives, it is posible to iterate through all of them, with complex meshes, it becomes more and more complex since you can't, at first, know which is the primitive you are aiming at on each pixel.

Yes, good point, but apparently, that problem has now been solved well enough. Here's an example of a scene as complex as you'd see in any modern game rendered using real-time path tracing: http://www.youtube.com/watch?v=OyY9pQEJkSk

[Mel]

Impressive indeed,

If they solve the noise problem, they have a solid product to sell for the next gen of gaming. In fact, it can be said it is already solved, using large memory buffers it is posible to store a scene like that, and traverse it using a BSP/octree acceleration technique. then the samples are interpolated in lower resolution, and to get a final image, it blends those samples... not bad

[BlindSide]

Hi guys,

I actually developed a realtime ray tracer driver for Irrlicht a few years ago but I didn't do anything with it (It was pure software and used all CPU cores and SSE2 SIMD vector instructions + BVH tree structure). It's sitting collecting dust on an old laptop of mine

Here is a screenshot of it running at (I think 60 fps on my old quadcore):


I had a demo you can run online somewhere but I misplaced it

[BlindSide]

There were some interesting things about it for example if I loaded a model > 1 mil polys or so at a low resolution it would run faster than the software rasterizer because the rasterizer has to loop over all the triangles while the raytracer only has to trace each pixel

[Cube_]

Blindside, that is because raytraces get exponentially less slow as scene complexity increases vs a rasterizer that gets slower in a linear fashion as scene complexity increases

describes this phenomenon just fine
for each subdivision:
x*2 for a rasterizer, this is nice in a low poly scene
log(x) is slower at lower poly counts than a rasterizer but at six hundred and eighty four million triangles the performance difference is extreme

[BlindSide]

I know haha, I was explaining it in laymen's terms.

[Cube_]

We're all programmers here, aren't we? *besides even a layman should be able to see why x*y is inferior to log(x) in the long run (I just woke up but x*y should describe a rasterizer properly)

[BlindSide]

It really depends on your acceleration data structure, a strict KD Tree might offer a slightly different curve than a BVH. I was actually just pointing out how it was faster than the rasterizer in some cases, it's great that you already knew that, I can get a medal made if you want

[Cube_]

^^; I sense sarcasm in your comment, please don't get me wrong but when someone describes things in laymans terms I assume that they don't know what they're talking about which is why I linked that pretty little graph (Oh and I just woke up, I can't recall if x*2 or x^2 describes the graph better)

[Mel]

The point now is that, besides the raytracing, now they use path tracing.

It is similar to a raytracing done many times per pixel to calculate diffuse illumination (i.e. global lighting) The point is that pathtracing traces the lighting not from the light source, like the raytracing, but from the screen point to be calculated. From there, several rays are shot, and it is seen what happens. If the rays hit another surface, those points are stored as a path (and stored so they can be further accessed if any other ray hits them, this is what causes that after some time, the noise of the image is reduced), and another ray is shot from there, until the system either runs out of iterations or finds a light source which is not occluded. When a light is found, the contributions to the lighting of each point found in the path are calculated taking into consideration the diffuse, reflective and media properties of the materials, and thus, the pixel is physically correct lit (including even half transparent and refractive objects).

The good thing is that this lighting model includes in itself ALL of the other lighting models. It calculates correct ambient ligth, correct soft shadows, without the need of shadowmapping at all, it scales in screen space, not in world space, so it is more costly whenever the resolution is larger, and using subpixel sampling, it may calculate an antialiasing on its own.

[dorrax]

So if we tolerate a low resolution ( I like 320 by 240 ) this should run fast. I've seen minecraft run "ok" as low as 10FPS, so if we could get a path tracer running at 320x240 in the 15 to 20 FPS range it might be practical? I'm too noob to know how though.