CBox Unbiased Truck

I've modified the scene in the Kajiya path tracer a bit more: it now consists of a Cornell Box out of axis aligned boxes with the (in)famous truck from Unbiased Truck Soccer:

Color bleeding from the red and green wall:

The screenshots were rendered with 8600M GT (6 fps default view). On a GTS 450, the demo runs at 70 fps in default view. It should run at >200 fps on a GTX 580 with 8 samples per pixel. This new path tracer is just incredible fun, I can't stop messing with it.

Executable and source code at http://code.google.com/p/tokap-the-once-known-as-pong/downloads/list

UPDATE: a more challenging lighting set up with an open box only illuminated by the sky:

The truck seen from behind, indirectly lit by skylight bounced off the back and side walls. As expected with standard path tracing, the noise is a lot worse in this scenario. Bidirectional path tracing should converge faster using fewer samples.

Arnold Render impressions from FMX 2011

http://www.3dworldmag.com/2011/05/04/sony-pictures-imageworks-unbiased-raytracing-in-feature-films-now-viable/

More details by Marcos Fajardo: http://www.cgchannel.com/2011/05/fmx-2011-tuesdays-highlights/:

Having showed a 400-million-polygon asset from G-Force as proof that even the heaviest scenes can be raytraced in production, Fajardo singled out volumetrics as a particular area of benefit.

“[With a traditional hybrid Reyes renderer] you’re losing the interaction of the raytrace effects with the volumes so even simple things like shadows become a problem,” he said. “[With Arnold] it just works. There’s no ‘gotcha’.”

The move to fully ray traced rendering in the movie industry (f.e. Sony Pictures Imageworks and Blue Sky) has started and it's happening really fast. Now it's up to the game industry to do the same.

Real-time path traced Unbiased Truck Soccer moved to Kajiya-engine

It has been a while since the last update on Unbiased Truck Soccer, the real-time path traced game featuring a truck made of spheres. Two major changes happened since last time: I've upgraded from my laptop with 8600M GT to a desktop with GTS 450, not a high end card but a fair bit better than the ultra-low end 8600M GT (I'm still using the latter for developing and testing new ideas, because if it looks and runs OK on crappy hardware, you can be sure that it will look great on a real GPU). I've also started porting the Unbiased Truck game to the brand new and recently released Kajiya scene path tracer from Jacco Bikker and Jeroen van Schijndel. This decision was made for several reasons:

- when comparing path tracing performance on the 8600M GT and the GTS450, TOKAP runs only 5x faster while the Kajiya path tracer runs 11x faster. It's also optimized for Fermi cards and uses CUDA 3.2, while tokaspt (TOKAP's framework) was developed for CUDA 2.0 and pre-Fermi cards. The path tracing performance of tokaspt was already extremely fast, but this new path tracer is just in a league of its own.

- it's going to be fairly easy to port this to OpenCL, since the CUDA-specific code is very small and there's also an OpenCL port of the Kajiya demo available at http://code.google.com/p/kajiya-gpu/ Still waiting for working OpenCL 1.1 drivers from Nvidia.

- more primitives to choose from: not only spheres (as in Tokap), but also cubes (axis aligned bounding boxes actually) and ellipsoids, so there will be less restrictions on game ideas. An example of a physics game: drive the truck into a building made of boxes and make the whole structure collapse like in this video. This would require additional support for oriented bounding boxes.

- the Kajiya path tracer uses "hitboxes", a kind of acceleration structure, improving performance. Tokaspt doesn't have built-in acceleration structures, hence the path tracing performance went down very quickly when adding more spheres (or a second truck).

- proper support for skydome and sunlight with much better looking shadows and much reduced noise levels

Some pictures and videos (screenshots rendered with 8600M GT, videos with GTS450):

The next two images show all the advantages of rendering with path tracing: reflection, refraction, soft shadows, ambient occlusion and colour bleeding. Surpassing Pixar quality graphics in real-time! :D

Nice refraction + color bleeding and gradual light fall-off on the car's rear:


An "overcast" sky (no sunlight):



Night scene, only illuminated with a spotlight. Notice the indirect light bounced from the floor onto the cuboids:

Convergence in this simple scene is extremely fast. While moving, frames are displayed at 8 spp and the scene runs with great quality at 50-60 fps (512x512 resolution) on my GTS 450. When the camera is stationary, 32 spp are accumulated.

I hope I will soon be able to animate the truck and incorporate some CPU physics.

Download executable (Win32) and source code at http://code.google.com/p/tokap-the-once-known-as-pong/downloads/list

-

Minecraft rendered with Octane

After the impressive and awe-inspiring videos of Minecraft rendered in real-time with the Brigade path tracer (1, 2, 3 and 4), here's a pretty neat day/night cycle animation of a Minecraft level rendered with Octane, which looks completely real and kind of resembles a LEGO world: http://www.youtube.com/watch?v=vCC6Bczi2x0

With a couple of ultrahigh-end GPUs, I think the daylight parts in this animation can be path traced in real-time with very good quality, even though all surfaces are glossy, because almost all of the lighting comes from a skylight. The following video demonstrates the extreme speed with which a completely glossy benchmark scene (the Death Star trench from Star Wars) converges in Octane on 2x GTX 460 under different lighting conditions: http://www.youtube.com/watch?v=uHY90epFf2g. After having messed around with the Brigade path tracer for countless hours on a laptop with 8600M GT and still getting pretty good results in real-time, I'm convinced that Minecraft levels will soon be playable in photoreal quality on high-end hardware. Once that goal is reached, it's pretty easy to imagine what's going to come next.

Cycles, a new unbiased CPU/GPU renderer for Blender

The GPU path tracing virus keeps spreading at an incredible rate: Blender is soon going to have a fully integrated physically based renderer, codenamed 'Cycles', which can use the CPU or the GPU for rendering (GPU path tracing starts at 1:18).

http://code.blender.org/index.php/2011/04/modernizing-shading-and-rendering/

Changing materials, moving objects around and adding/deleting new objects can be done in real-time and the Cycles rendering engine can also rebuild the acceleration structure of the Suzanne model at lightning fast speeds. The source code will be available in about two weeks! It's going to be really cool when you can modify your model and immediately see the changes rendered in real-time in photoreal quality. Speaking of real-time editing and rendering, one of Luxrender's developers has made an utterly amazing video showing live editing of a physics simulation inside Blender and rendering it in real-time with Luxrender's PathGPU2 (a 100% OpenCL path tracer and part of SmallLuxGPU v1.8 with a heavy focus on animation rendering):

http://www.youtube.com/watch?v=bSQoJW9ajmU (real-time part starts at 1:23)

The video was rendered on a Core i7 920 + 2x ATI HD4890's, certainly not a bad system, but the HD4000 series was not exactly conceived with OpenCL computing in mind. I would love to see a GTX580 rendering this scene though. According to the graph below from Anandtech depicting the performance of SmallLuxGPU 1.7, I can imagine that card would just fly in this scene and make the video that much more awesome!

Update: SmallLuxGPU 1.8beta (which incorporates Metropolis light transport in OpenCL) is now available for download from the Luxrender forum

Update2: A lot of useful information and implementation details on the Cycles renderer can be found on http://wiki.blender.org/index.php/Dev:2.5/Source/Cycles under the header "Design"

Incredible real-time GPU path tracer using WebGL

Yesterday I came across another awesome GPU renderer (made by Evan Wallace), it's a very neat and extremely fast path tracer using GLSL shaders running in the browser:

http://madebyevan.com/webgl-path-tracing/

A WebGL-enabled browser is required to run this (I highly recommend the latest Chrome build from http://www.khronos.org/webg/wiki/Getting_a_WebGL_Implementation#Chrome.2FChromium (the Chrome Canary build works great if you're on Windows, Firefox 4.0 crashes and other Chrome versions didn't work for me, it just keeps loading).

It's great fun to edit the scene: move the light or objects and see soft shadows being cast in real-time (60 fps) on the walls and other objects. You can also change materials and add extra objects. It renders blazingly fast even on very low end GPUs. Very impressive!

Source code for the path tracer:

view-source:http://madebyevan.com/webgl-path-tracing/

There's also a GLSL version (Mac OS X):

http://www.madebyevan.com/glsl-path-tracing/

With this technology, a path traced physics simulation like the one in this video is perfectly possible in real-time on a current GPU. Or maybe a real-time path traced version of Tetris ;)

CentiLeo: a brand new interactive out-of-core CUDA path tracer for massive models

Wow, the real-time GPU path tracing goodness just keeps on coming! I've barely recovered from the fantastic real-time path traced Kajiya scene by Jacco Bikker and Jeroen van Schijndel, and now I stumbled upon another hugely impressive interactive GPU path tracer, called CentiLeo, which is able to render massive models (such as a stripped down Boeing 777 model containing 370 million polygons) interactively with global illumination on just 1 GTX 480 using out-of-core GPU path tracing (3-10 frames per second at 1024x768, 1 sample per pixel with 1 GI bounce from an HDR image).

A twelve-minute video in HD of this amazing renderer in action:

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

Some screengrabs of the video with more info:

The planned features sound extremely exciting and seem to be aimed at production rendering with among other things bidirectional path tracing, Metropolis light transport, hair and displacement mapping:

All these features will be CUDA based according to the author of the video (see youtube comments):

"the target is CUDA implementation because it is fast and flexible enough. BDPT, MLT, tesselation, displacement mapping, hair/fur, texture filtering - sure, will be CUDA-based.

Programmable materials can be done in CUDA. But an additional idea would be to port some existing CPU/C++ material shaders to work with our GPU compute building blocks. Voxels are not yet planned. But they can be potentially implemented.

Our goal is to finish the TODO feature list by September 2011. The concepts are pretty simple, but all the devil is in details. The future work is engineering. Almost all research was already done.

The website will be created this or next week. This demo shows what we can do now."

The holy grail for game graphics:

This tech would be an ideal fit for rendering huge voxel data sets stored in a sparse voxel octree at interactive rates with high-quality global illumination. Definitely something to keep an eye on in the future.

Scene from Kajiya's paper 'The rendering equation' can now be path traced in real-time on the GPU! UPDATE: exe available

This is just incredible, another milestone in the history of rendering! Jacco Bikker, the main developer behind the real-time path tracer Brigade, and Jeroen van Schijndel, an IGAD research assistant, have made a new simple but superb path tracer (similar to tokaspt) which can render the classic path tracing scene from the 1986 paper "The rendering equation" by Jim Kajiya in real-time on just one GTX 470! There is very little noise overall, there's just some in the glass spheres and in the shadowed caustics.

Youtube video: http://www.youtube.com/watch?v=OHWxsUUataw

Some stats:

- 512x512 rendering resolution

- 8 bounces

- 64 samples per pixel

- 12 frames/second on 1 GTX470

The amazing path tracing speed is partly due to the fact that there are no triangle meshes but only geometric primitives (spheres and boxes) in this scene, which are computationally much cheaper to intersect than triangles. The scene in the video is not 100 % identical to the original one (the structure consisting of the revolved parabola with the oblate spheroid, 'mushroom' for short ;-), is missing), but they're working on it (UPDATE 2: the mushroom is finished, see link at the end of this post). This is the original scene from the 1986 paper:

The above is an off-screen photograph (published in the paper). This is the direct feed image:

It's really mind-boggling when you realize that Kajiya needed 1221 minutes (20.35 hours) to render this image on a supercomputer from 1986 (an IBM 3081 mainframe) and 25 years later it can be computed at the same resolution in 36 milliseconds on a GTX580! A speed up of 2 million times!! Sounds like a great 25th anniversary :D !

(gotta love that '80ies font :-)

I would love to see some animation in this scene, for example an animated light casting moving shadows or a collapse of the pile of green spheres, which would greatly accentuate the "real-timeness" of the path tracing.

UPDATE: Executable and source code for this demo are now available at the links in this thread on the ompf forum. It's awesome, I'm getting a frametime of 1900ms in the 64 spp version on my poor 8600M GT, which is 49x slower than a GTX580 in this demo (kajiya-perf, default view at 64 spp/frame needs 1759 ms/frame on my 8600M GT and only 36 ms/frame on a GTX580)! Time to upgrade :)

UPDATE 2: Like Jacco Bikker has promised in the comments, the mushroom-like structure is now done! Visit http://ompf.org/forum/viewtopic.php?f=6&t=3174 for a screenshot of the updated scene and for more info on this project.

GPU Metropolis light transport with OpenCL in LuxRender!

This is very neat: after Dietger van Antwerpen successfully implemented Metropolis light transport (MLT) on the GPU using CUDA and the Brigade path tracer framework, one of the LuxRender developers now has succeeded at making MLT work on the GPU with OpenCL.

http://www.luxrender.net/forum/viewtopic.php?f=34&t=5795 (registration required)

Unlike Luxrender's SmallLuxGPU, which is a hybrid CPU+GPU renderer that only uses the GPU for ray intersections, this MLT algorithm is running entirely on the GPU using OpenCL, offering a vast speed boost over the hybrid approach. Fireflies (bright pixels produced by caustics) are sampled away much more efficiently than when using the standard path tracing integrator. Very complex lighting situations (e.g. light passing through a keyhole) should benefit as well.

It's great to see a smart and efficient rendering algorithm like MLT (which many believed to be impossible on current GPUs) is now popping up in several GPU renderers. Hopefully bidirectional path tracing running entirely on the GPU (with MLT on top, something that has already been done by Dietger van Antwerpen) will become widespread soon as well.

720p video of Unbiased Truck Soccer Sunny Sky with caustics!

HD video: http://www.youtube.com/watch?v=ymo57ElhHvY

Rendered with my 8600M GT, it's still doing a pretty good job despite its age :) The caustics from the glass sphere are not reflected in the mirror ball because max path length is set to 3 for performance reasons. Setting max path length to 4 will show the reflection of the caustic light pattern.

Download executable: http://code.google.com/p/tokap-the-once-known-as-pong/downloads/list



Increasing the emission values (RGB) of the "sun" to 4, 4, 2 makes the caustics more obvious:

Unbiased Truck Soccer: Sunny sky with only a few traces of rayn!

Another test in the quest for faster convergence speed, this time using a skydome and sun.

One of the advantages of using a skydome to light the scene is that the difference between 2 and 3 bounces of indirect light is not as large as when using an area light:

max path length 1 (zero bounces)

max path length 2 (1 bounce)


2 bounces


3 bounces

Another advantage is the very fast convergence speed compared to using area lights due to the fact that almost every pixel can 'see' the skydome. Only the pixels that are occluded from the skydome (e.g. the ground patch under the car) clean up slower because they are indirectly lit. Using bidirectional path tracing would greatly increase the convergence speed of these pixels (edit: as pointed out by Iliyan in the comments, bidir path tracing would actually perform worse in this outdoor scene where standard path tracing shines).

An overcast sky can be simulated by using only the skydome for lighting (without an emitting sun sphere):

In this case, the noise clears up very fast with just a few samples. This lighting setup will be used for the Unbiased Truck Soccer game.

Download the executable for this sky test at http://code.google.com/p/tokap-the-once-known-as-pong/downloads/list (package updated with glass sphere for some nice caustics)

To brighten/darken the sun, select the sun sphere by right-clicking it, click the 'emi' button on the top right of the screen and change the values at the bottom of the screen to e.g. 10, 10, 5. Overbrightening the sun will cause the shadows to look sharper and more pronounced, but will also increase the noise to unacceptable levels:

Unbiased Truck Soccer: motion blur tests

I made some tests to determine which amount of motion blur (accomplished by accumulating samples from previous frames) is acceptable for relatively fast moving objects.

The picture below shows a comparison of the scene from 'Unbiased Truck Soccer' with different amounts of motion blur: no motion blur (left), averaging the last 3 frames (middle) and averaging the last 6 frames (right). These images were all rendered on a 8600M GT with a frame rate of barely 5 fps, so the comparison is not representative for more powerful GPUs, but it provides a general idea of the "noise freeness" of parts of the image that are static like the walls, floor and ceiling. The three little rectangles at the bottom of the picture show a close-up comparison of a noisy area of the ceiling which is lit only with indirect lighting.



A low-res video:


The truck is performing a looped animation. The camera can be moved by holding the middle mouse button (dragging in image plane) and Shift + middle mouse button (zooming).

The new test can be downloaded from http://code.google.com/p/tokap-the-once-known-as-pong/downloads/list The package contains three executables, with different amounts of motion blur (none, average of last 3 frames and average of last 6 frames).

On a GTX 580 this demo should run at 60 fps at default settings (768x512 resolution, max path length 4, 4 samples per pixel per pass blurred to 12 (motion blur = 1) or 24 (motion blur = 2) samples per pixel).

OTOY at the Abu Dhabi Media Summit 2011

Last week, AMD held a session about "Content and the Cloud" at the Abu Dhabi Media Summit with OTOY's Jules Urbach as one of the main speakers. A video of the complete session can be found at

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

Some interesting snippets that were shown and talked about:

- Crysis 2 rendered in the cloud at the highest settings and streamed to an iPad using OTOY's tech

- games can be rendered for 16 concurrent users with a single GPU

- (around the 16:00 mark) path tracing!!! A very short clip was shown where Jules manipulates an extremely high detail model from the Transformers movie (created by ILM) on an iPhone in real-time, rendered in the cloud with path tracing and displayed at 60 fps. Path tracing will scale to as many servers as are available. This will really revolutionize the way games and films are made. A blurry picture below:

- Software tools such as Blender will be delivered through the cloud with OTOY

- WebCL! The next logical step after WebGL, which will make the GPU computing power from the cloud accessible through a webbrowser. Very interesting.

- Operating systems, next-gen consoles, Blu-Ray discs will become irrelevant when all apps run in the cloud

- The same assets from the Gaiking movie (to be released next year), will be used in a Gaiking game that can only be played on the cloud due to the massive computing resources it will require for rendering the graphics in real-time. Tantalizing... :-D

Screen from the Gaiking teaser trailer:

Unbiased Truck Soccer: First physics test with Bullet Physics

UPDATE: I've uploaded the executables for the Bullet physics test and the new scene with the soccer playing field at http://code.google.com/p/tokap-the-once-known-as-pong/downloads/list

I've recreated the truck from 'Unbiased Truck Soccer' in the Bullet Physics engine and applied some physical properties to make it behave like a real vehicle like suspension stiffness, damping, rolling and friction.

This is a video of what the gameplay should be like when using the Bullet Physics engine, made with the built-in debug OpenGL renderer of Bullet:

And a Soccer game is not complete without a huge open playing field. The goals will be represented by a blue and a red sphere. Players can score by bumping the soccer ball against the opponent's sphere.

The hardest part is using the output of the Bullet Physics engine to update the position of the trucks and the soccer ball in the real-time path tracer. It should be fairly straightforward though, so I hope to have a working version soon!