Is Carmack working on a ray tracing based game engine?

At least that's what his tweets (http://twitter.com/id_aa_carmack) seem to suggest:

# There has GOT to be a better way to exactly test triangle-in-AABB than what I am currently doing.

# Idea: dynamically rewrite tree structures based on branch history to linearize the access patterns. Not thread safe…

# The valuation strategy behind the Surface Area Heuristic (SAH) used in ray tracing is also adaptable for rasterization engines.

# It is often better to use a global spherical sampling pattern and discard samples behind a plane instead of local hemispheres.

# @Wudan07 equal area but not shape. Got a better non iterative one? Poisson disc for higher quality.

# To uniformly sample a sphere, pick sample points on the enclosing cylinder and project inwards. Archimedes FTW!

# I need to decide if I am going to spend some quality time with CUDA or Android. Supercomputing and cell phones, about equally interesting…

# @castano triangle intersection is 33% of the wall clock time and a trace averages 12 triangle tests, so gather SIMD tests could win some.

# Doing precise triangle tests instead of just bounds tests when building KD trees makes a large difference with our datasets.

# For our datasets, my scalar KD tree trace code turned out faster than the SSE BVH tracer. Denser traces would help SSE.

If Carmack's pioneering work still has the same impact and influence on the game industry as it had in the 90's, ray traced games could become the standard "soon" (which in id terms means about 5-8 years :-).

UPDATE: I wasted a couple of hours and transcribed the part of Carmack's keynote at Quakecon 2010, where he's specifically talking about raytracing (from http://www.youtube.com/watch?v=LOdfox80VDU&feature=related time 3:17 ) English is not my mother tongue so there are some gaps here and there, this part is not about real-time raytracing, but about precomputing the lightmaps and megatextures with raytracing instead of rasterization:

"We were still having precision issues with shadow buffers and all this and that, and finally I just sort of bit the bullet and said “Alright, we’re on the software side, let’s just stop rasterizing, let’s just raytrace everything. I’m gonna do a little bit of rasterizing for where I have to, but just throw lots and lots of rays." And it was really striking from my experience how much better a lot of things got. There are a lot of things that we live with for rasterization as we do in games with making shadows, trying to get shadow buffers working right, finding shadow acné vs Peter Pan effect on here and this balance that never quite get as things move around. Dealing with having to vastly oversize this trying to use environment maps for ambient lighting. And these are the things that people just live and breathe in games, you just accept it, this is the way things are, these are the issues and things will always be like this just getting higher and higher resolution. But it was pretty neat to see a lot of these things just vanish with ray tracing, where the shadows are just, the samples are right. We don’t have to worry about the orientation of some of these things relative to the other things. The radiosity gets done in a much better way and there are far less artifacts. And as we start thinking about things in those terms, we can start thinking about better ways to create all of these different things. So that experience has probably raised in my estimation a little bit the benefit of raytracing in the future of games. Again, there’s no way it’s happening in this coming generation, the current platforms can’t support it. It’s an open question about whether it’s possible in the generation after that, but I would say that it’s almost a foregone conclusion that a lot of things in the generation after that will wind up being raytraced, because it does look like it’s going to be performance reasonable on there and it makes the development process easier, because a lot of problems that you fight with just aren’t there. There’s a lot of things that, yeah, it’s still you could go ahead and render five times or ten times as many pixels, but we’re gonna reach this point where our ten times as many pixels or fragment samples going to give us that much more benefit or would we really like to have all the local shadows done really really right and have better indirect ambient occlusion. Or you can just have the reflections and highlights go where they’re supposed to, instead of just having a crummy environment map that reflects on the shiny surfaces there. So, I can chalk that up as one of those things where I definitely learned some things in the last six months about this and it modified some of my opinions there and the funny coming back around about that is, so I’m going through a couple of stages of optimizing our internal raytracer, this is making things faster and the interesting thing about the processing was, what we found was, it’s still a fair estimate that the gpu’s are going to be five times faster at some task than the cpu’s. But now everybody has 8 core systems and we’re finding that a lot of the stuff running software on this system turned out to be faster than running the gpu version on the same system. And that winds up being because we get killed by Amdahl’s law there where you’re throwing the very latest and greatest gpu and your kernel amount (?) goes ten times faster. The scalability there is still incredibly great, but all of this other stuff that you’re dealing with of virtualizing of textures and managing all of that did not get that much faster, so we found that the 8 core systems were great and now we’re looking at 24 thread systems where you’ve got dual thread six core dual socket systems (?) it’s an incredible amount of computing power and that comes around another important topic where pc scalability is really back now where we have, we went through sort of a ..."

Arnold is back!

During the last Siggraph, a lot of presentations were centered around Arnold, the production renderer which is going to kick Renderman's and mental ray's collective asses. The VFX industry is slowly discovering this marvel, which is doing Monte Carlo path tracing at incredible speeds. It eats huge complex scenes with motion blur and DOF for breakfast.

The argument that ray tracing is only used sparingly in the movie industry no longer holds, as almost all big film companies are shifting towards more and more (and sometimes full) raytracing as the method of choice. I'm sure this industry wide shift will trickle down to the game industry as well

Some interviews and presentations:

interview Marcos Fajardo: http://tog.acm.org/resources/RTNews/html/rtnv23n1.html#art3

HPG2009 Larry Gritz talking about Arnold: http://www.larrygritz.com/docs/HPG2009-Gritz-Keynote-clean.pdf

more on Larry Gritz' talk: http://www.realtimerendering.com/blog/hpg-2009-report/

interesting interview wiht Larry Gritz about the decision to move to Arnold: http://news.cnet.com/8301-13512_3-10306215-23.html

basic features of Arnold: http://www.graphics.cornell.edu/~jaroslav/gicourse2010/giai2010-02-marcos_fajardo-slides.pdf

many details on Arnold (don't miss this one): http://renderwonk.com/publications/s2010-shading-course/martinez/s2010_course_notes.pdf

Carmack loves ray tracing

Some excerpts from his QuakeCon keynote (different live blogs):

"There are a lot of things we live with as rasterization in games...Ray tracing was the better way to go. The shadows and samples were right.. the radiosity gets done in a much better way."

http://kotaku.com/5611429/quakecon-2010-keynote-liveblog-aka-man-i-hope-they-mention-doom-4

Ray Tracing definitely not coming in this generation, but it's definitely the future of gaming once the technology becomes performance reasonable. Will make development easier. A lot of his opinions on ray tracing has changed in the past six months. Now that multicore CPUs are mainstream they're starting to catch back up to rendering performance compared to GPUs.

http://ve3d.ign.com/articles/news/56520/John-Carmack-Quakecon-Live-Feed-Coverage

and from Carmack's own twitter:

"Reading Realistic Ray Tracing 2nd Ed. I discourage the use of .x .y .z style members and favor arrays. Many bugs due to copy-paste."

http://twitter.com/id_aa_carmack

Faster raytraced global illumination by LOD tracing

Just read this Siggraph presentation about PantaRay, a GPU-accelerated raytracer to compute occlusion, which was used in Avatar and developed by Nvidia and Weta: http://bps10.idav.ucdavis.edu/talks/13-fascionePantaleoni_PantaRay_BPS_SIGGRAPH2010.pdf

The idea is simple and elegant: use the full res geometry for tracing primary rays and use lower LOD geometry for tracing secondary rays. The amount of triangles to test intersection with is significantly reduced, which speeds up the GI computation considerably.

These papers use the same principle:

"R-LODs: Fast LOD based raytracing for massive models" by Yoon
"Two-Level Ray Tracing with Reordering for Highly Complex Scenes" by Hanika, Keller and Lensch

The idea is similar to Lightcuts and point based color bleeding (which both use a hierarchy to cluster sets of lights or points to reduce the computational cost of tracing) but is used for geometry instead of lights. It is also being used by Dreamworks:



Picture from Siggraph presentation by Tabellion (PDI Dreamworks)

From http://www.graphics.cornell.edu/~jaroslav/gicourse2010/giai2010-04-eric_tabellion-notes.pdf:

We describe here one of the main ways in which we deal with geometric complexity. When rays are cast, we do not attempt to intersect the geometry that is finely tessellated down to pixel-size micropolygons - this would be very expensive and use a lot of memory. Instead we tessellate geometry using a coarser simplified resolution and the raytracing engine only needs to deal with a much smaller set of polygons. This greatly increases the complexity of the scenes that can be rendered with a given memory footprint, and also helps increase ray-tracing efficiency. To avoid artifacts due to the offset between the two geometries, we use a “smart bias” algorithm described in the next slides.

Since rays originate from positions on the micropolygon tessellation of the surface and can potentially intersect a coarser tessellation of the same surface, self intersection problems can happen.

The image above illustrates cross-section examples of a surface tessellated both into micropolygons and into a coarse set of polygons. It also shows a few rays that originate from a micropolygon whith directions distributed over the hemisphere. To prevent self intersection problems to happen, we use a ray origin offsetting algorithm. In this algorithm, we adjust the ray origin to the closest intersection before / after the ray origin along the direction of the ray, within a user-specified distance. The ray intersection returned as a result of the ray intersection query is the first intersection that follows the adjusted ray origin. The full algorithm is described in [Tabellion and Lamorlette 2004].

Here is a comparison between a reference image that was rendered while raytracing the micropolygons micropolygons. The image in the center was rendered with our technique while raytracing the coarser polygon tessellation illustrated in the image on the right.

It has been shown in [Christensen 2003] that it is possible to use even coarser and coarser tessellations of the geometry to intersect rays with larger ray footprints. This approach is also based on using only coarser tessellation and is not able to provide very coarse tessellations with much fewer polygons than there are primitives (fur, foliage, many small overlapping surfaces, etc.), which would be ideal for large ray footprints. This problem is one of the main limitations of ray-tracing based GI in very complex scenes and is addressed by the clustering approach used in point-based GI, as discussed in later slides.

With this technique, you could have a 1 million polygon scene to trace primary rays, while secondary rays are traced against a 100K or a 50K polygon LOD version of the scene. When using voxels, this becomes a walk in the park, since LOD is automatically generated (see http://voxelium.wordpress.com/2010/07/25/shadows-and-global-illumination/ for an awesome example)

CUDA 3.1 out

Just read that cuda 3.1 toolkit is available (has been for some time in fact)

http://www.theregister.co.uk/2010/07/22/nvidia_cuda_parallel_nsight/

As you can see from the release notes, CUDA 3.1 also gives 16-way kernel concurrency, allowing for up to 16 different kernels to run at the same time on Fermi GPUs. Banks said a bunch of needed C++ features were added, such as support for function pointers and recursion to allow for more C++ apps to run on GPUs as well as a unified Visual Profiler that supports CUDA C/C++ as well as OpenCL. The math libraries in the CUDA 3.1 SDK were also goosed, with some having up to 25 per cent performance improvements, according to Banks.

The support for recursion and concurrent kernels should be great for CUDA path tracers running on Fermi and I'm curious to see the performance gains. Maybe the initial claims that Fermi will have 4x the path tracing performance of GT200 class GPUs could become true after all.

OnLive + Mova vs OTOY + LightStage

I've just read Joystiq's review of OnLive, which is very positive regarding the lag issue: there is none...

As it stands right now, the service is -- perhaps shockingly -- running as intended. OnLive still requires a faster than normal connection (regardless of what the folks from OnLive might tell you), and it requires a wired one at that, but it absolutely, unbelievably works. Notice I haven't mentioned issues with button lag? That's because I never encountered them. Not during a single game (even UE3).

A related recent Joystiq article about OnLive mentions Mova, a sister company of OnLive developing Contour, a motion capture technology using a curved wall of camera's, very reminiscent of OTOY's LightStage (although the LightStage dome is bigger and can capture the actor from 360 degrees at once). The photorealistic CG characters and objects that it produces are the real advantage of cloud gaming (as was being hinted at when the Lightstaged Ruby from the latest Ruby demo was presented at the Radeon HD 5800 launch):

What he stressed most, though, was Perlman's other company, Mova, working in tandem with OnLive to create impressive new visual experiences in games. "This face here," Bentley began, as he motioned toward a life-like image that had been projected on a screen before us, "is computer generated -- 100,000 polygons. It's the same thing we used in Benjamin Button to capture Brad Pitt's face. Right here, this is an actress. You can't render this in real time on a standard console. So this is the reason OnLive really exists." Bentley claims that Mova is a big part of the reason that a lot of folks originally got involved with OnLive. "We were mind-boggled," he exclaimed. And mind-boggling can be a tremendous motivator, it would seem -- spurring Bentley to leave a successful startup for a still nascent, unknown company working on the fringes of the game industry.

In fairness, what we saw of Mova was terrifyingly impressive, seemingly crossing the uncanny valley into "Holy crap! Are those human beings or computer games?" territory. Luckily for us, someone, somewhere is working with Mova for games. Though Bentley couldn't say much, when we pushed him on the subject, he laughed and responded, "Uhhhh ... ummm ... there's some people working on it." And though we may not see those games for quite some time, when we do, we'll be seeing the future.

Just like OTOY, I bet that OnLive is developing some voxel ray tracing tech as well, which is a perfect fit for server side rendering due to it's massive memory requirements. Now let's see what OTOY and OnLive with their respective cloud servers and capturing technologies will come up with :-)

Real-time Energy Redistribution Path Tracing in Brigade!

A lot of posts about Brigade lately, but that's because the pace of development is going at break neck speeds and the intermediate updates are very exciting. Jacco Bikker and Dietger van Antwerpen, the coding brains behind the Brigade path tracer, seem unstoppable. The latest contribution to the Brigade path tracer is the implementation of ERPT or Energy Redistribution Path Tracing. ERPT was presented at Siggraph 2005 and is an unbiased extension of regular path tracing which combines Monte Carlo path tracing and Metropolis Light Transport path mutation to obtain lower frequency noise and converge faster in general. Caustics benefit greatly as well as scenes which are predominantly lit by indirect lighting. The original ERPT paper can be found at http://rivit.cs.byu.edu/a3dg/publications/erPathTracing.pdf and offers a very in-depth and understandable insight into the technique. A practical implementation of ERPT can be found in the paper "Implementing Energy Redistribution Path Tracing" (http://www.cs.ubc.ca/~batty/projects/ERPT-report.pdf).

The algorithm seems to be superior than (bidirectional) path tracing and MLT in most cases, while retaining it's unbiased character. And they made it work on the GPU! You could say that algorithm-wise, the addition of ERPT makes Brigade currently more advanced than the other GPU renderers (Octane, Arion, LuxRays, OptiX, V-Ray RT, iray, SHOT, Indigo GPU, ...) which rely on "plain" path tracing.

The following video compares path tracing to ERPT in Brigade at a resolution of 1280x720(!) on a GTX 470: http://www.youtube.com/watch?v=d9X_PhFIL1o&feature=channel

This image directly compares path tracing on the left with ERPT on the right (the smeary pixel artefacts in the ERPT image are mostly due to the youtube video + JPEG screengrab compression, but I presume that there are also some noise filters applied as described in the ERPT paper):
ERPT seems to be a little bit darker than regular path tracing in this image, which seems to be a by product of the noise filters according to http://pages.cs.wisc.edu/~yu-chi/research/pmc-er/PMCER_files/pmc-er-egsr.pdf.

On a side note, the Sponza scene in the video renders very fast for the given resolution and hardware. When comparing this with the video of Sponza rendering in the first version of SmallLuxGPU on a HD 4870 (which I thought looked amazing at the time), it's clear that GPU rendering has made enormous advancements in just a few months thanks to more powerful GPU's and optimizations of the path tracing code. I can hardly contain my excitement to see what Brigade is going to bring next! Maybe Population Monte Carlo energy redistribution for even faster convergence? ;)

Sparse voxel octree and path tracing: a perfect combination?

I have been wondering for some time if SVO and path tracing would be a perfect solution for realtime GI in games. Cyril Crassin has shown in his paper "Beyond triangles: Gigavoxels effects in videogames" that secondary ray effects such as shadows can be computed very inexpensively by tracing a coarse voxel resolution mipmap without tracing all the way down to the finest voxel resolution, something that is a magic intrinsic property of SVO's and which is to my knowledge not possible when tracing triangles (unless there are multiple LOD levels), where all rays have to be traced to the final leaf containing the triangle, which is of course very expensive. A great example of different SVO resolution levels can be seen in the video "Efficient sparse voxel octrees" by Samuli Laine and Tero Karras (on http://code.google.com/p/efficient-sparse-voxel-octrees/ , video link at the right, a demo and source code for CUDA cards is also available).

I think that this LOD "trick" could work with all kinds of secondary ray effects, not just shadows. Particularly ambient occlusion and indirect lighting could be efficiently calculated in this manner, even on glossy materials. One limitation could be high frequency content, because every voxel is an average of the eight smaller voxels that it's constituted of, but in such a case the voxels could be adaptively subdivided to a higher res (same for perfectly specular reflections). For diffuse materials, the cost of computing indirect lighting could be drastically reduced.

Another idea is to compute primary rays and first bounce secondary rays at full resolution, and all subsequent bounces at lower voxel LODs with some edge-adaptive sampling, since the 2nd, 3rd, 4th, ... indirect bounces contribute relatively little to the final pixel color compared to direct + 1st indirect bounce. Not sure if this idea is possible or how to make it work.

Voxelstein3d has already implemented the idea of pathtracing SVOs for global illumination (http://raytracey.blogspot.com/2010/03/svo-and-path-tracing-update.html) with some nice results. Once a demo is released, it's going to be interesting to see if the above is true and doesn't break down with non-diffuse materials in the scene.

UPDATE: VoxLOD actually has done this for diffuse global illumination and it seems to work nicely:
http://voxelium.wordpress.com/2010/07/25/shadows-and-global-illumination/

Tokaspt, an excellent real-time path tracing app

Just stumbled upon this very impressive CUDA based path tracer: http://code.google.com/p/tokaspt/ for exe and source (The app itself has been available since January 2009)

Although the scenes are quite simple (spheres and planes only), it's extremely fast and it converges literally in a matter of milliseconds to a high quality image. Navigation is as close to real-time as it gets. There are 4 different scenes to choose from (load scene with F9) and they can be modified at will: parameters are sphere size, color, emitting properties, 3 material BRDFs (diffuse (matte), specular (mirror) and refractive (glass)) and sphere position. Path trace depth and spppp (samples per pixel per pass) can also be altered on the fly thanks to the very convenient GUI with sliders. When moving around and ghosting artefacts appear, press the "reset acc" button to clear the accumulation buffer and get a clean image. Definitely worth messing around with!

New version of Brigade path tracer

Follow the link in this post to download. There's some new features + performance increase. Rename cudart.dll to cudart32_31_9.dll to make it work.

The next image demonstrates some of the exceptional strenghts of using path tracing:

- indirect lighting with color bleeding: notice that every surface facing down (yellow arrows) picks up a slightly greenish glow from the floor plane, due to indirect light bouncing off (this picture uses path trace depth 6)
- soft shadows
- indirect shadows
- contact shadows (ambient occlusion)
- superb anti-aliasing
- depth of field
- natural looking light with gradual changes

all of these contribute to the photorealistic look and it's all interactive (on high end cpu+gpu)!

Crayon Physics Deluxe

This has to be one of the coolest games ever. Media Molecule should hire these guys:

http://vimeo.com/1849263

http://vimeo.com/2739375

Demo here

Brigade path tracer comparison

The following screenshots are taken from the Brigade real-time path tracer demo, available at http://igad.nhtv.nl/~bikker/
Rendered with CPU only at resolution 832x512
Images with 100 and 800 spp were taken without frame averaging (only 1 iteration)
Images with 2, 8, 16, 32 spp taken with frame averaging (averaging samples of several frames)

2 spp


8 spp


16 spp


32 spp


100 spp


800 spp



To top it off, one big image comparing 800, 8, 16 and 32 spp. It amazes me that the quality of just 8 samples is already great and with some filtering it could rival the quality of the 800 spp image:

Gaikai's cloud bussiness model: play games for free in your browser

Interview with Gaikai's Dave Perry on Joystiq:
http://www.joystiq.com/2010/06/30/dave-perry-on-the-innovation-of-gaikai/

Gaikai focuses on delivering game demo's, not complete games: you see an advertisement of a game on a website (could be Gamespot, EA.com, Eurogamer) or read a game review, and with just one click you can play a demo of that game in your browser without paying a cent. The game publisher pays for your playing time, 1 cent per minute per user.
This approach is economically safer, more practical and more retail/publisher/gamer friendly than what OnLive is doing. With the current network infrastructure of the internet and its bandwidth limitations, this is probably the most successful route for cloud gaming. Gaikai has already signed EA (http://games.venturebeat.com/2010/06/17/gaikai-signs-ea-as-digital-distribution-partner/), so I think cloud gaming is gonna get big pretty soon.

UPDATE: another video of OnLive, showing mouse latency in F.E.A.R. 2 behind a router: http://www.youtube.com/watch?v=Edf5xsqST90

Crytek aims for the cloud, sparse voxel octrees and sparse surfel octrees

Crytek's HPG 2010 presentation is available at http://www.crytek.com/fileadmin/user_upload/inside/presentations/2010_HPG_Keynotes/Notes.ppt According to the slides, Crytek is already using sparse voxel octree in the game asset pipeline. Because they are Crytek, they are also researching a variation on SVO, called the sparse surfel octree (I vaguely remember surfels from Michael Bunnell's point based ambient occlusion and indirect lighting technique in GPU Gems 2). I wonder what that is going to look like.

There are a few slides on server side rendering, which could "drastically change the direction" of the real-time rendering pipeline.

Other interesting tidbits:
- a configurable hardware scheduler which could make raytracing much faster
- Larrabee 2 still in the race for next-gen consoles?
- DX11 Compute Shaders suck
- Perception-driven graphics are the key to more efficient use of rendering resources (this is a very interesting future direction)

DysKinect

This one made me LOL:

Tom's Hardware review of OnLive

Tom's Hardware review: OnLive Cloud-Based Gaming: Is This the End of High-End PCs?

Interesting review, but the assumption in the article's title is already fundamentally flawed: high end PC gaming is already nearing it's end and it has nothing to do with cloud gaming, but everything with consoles. The article's conclusion is that OnLive doesn't come close to displace a high-end PC in gaming, but what the author seems to forget is that game publishers - not PC gamers - will ultimately decide if cloud gaming will succeed and they also have the power to kill off high-end PC gaming in no time (as they have been doing for the last 5 years).

Gone are the days when I was eagerly anticipating cutting-edge PC games like Doom III (before the name change to Doom 3), Half-Life 2 and Unreal 2. That was about 8 years ago. The last PC game worthy of being called cutting-edge was Crysis and that came out 3 years ago. Consoles have become the main focus of id Software, Epic games and now also Crytek. For a graphics enthusiast like myself, this is a very unfortunate trend, all dictated by economical laws.

So in essence, high-end PC gaming is already dead. Crysis still beats every other PC game (ported from consoles) in advanced effects. Cranking up resolution, AA, and AF settings in Modern Warfare 2 will not change the poor lighting and shadowing. I can't wait until the consoles, aka the high-end PC gaming killers, will be made obsolete themselves by cloud gaming. Considering the enthusiasm of game publishers and developers for the cloud (e.g. Crytek is a big proponent of server side rendering cfr. Yerli's presentation at HPG 2010), this might happen much sooner than thought, just like stereoscopic 3D is taking console gaming by storm.

UPDATE: CNET also has an excellent review of OnLive up, with an analysis of the benefits of cloud gaming for all actors in the playing field http://news.cnet.com/8301-17938_105-20009033-1.html

iray officially in the open with Bunkspeed Shot

Bunkspeed Shot (final version) was officially released last week. More importantly, it also means that the long awaited iray, which is powering SHOT, is finally available for everyone (it should have been here much earlier with 3ds max 2011, but was not integrated for some obscure reason).

Bunkspeed SHOT press release

You can download a 30-day trial demo at http://bunkspeed.com/shot/demo/index.html (Don't bother if you don't have a CUDA enabled card with at least 1GB of VRAM, else the software defaults to CPU only, totally retarded limitation if you ask me).

Funny enough, the press release makes it look like you'll need a Quadro or Tesla to run the software, but a Geforce should do fine and is probably faster. The amount of GPU memory will be the real decisive factor and Octane has shown that you can do a lot within a 1GB VRAM budget (it even has procedural textures now, which take up almost no memory).

Waiting for V-Ray GPU... hopefully another "Siggraph surprise" :-D

Demo of Brigade real-time path tracer out!

Available at http://igad.nhtv.nl/~bikker/

Anyone (remotely) interested in real-time raytracing, owning a CUDA enabled GPU or a powerful CPU, must definitely try this excellent demo! It works with Geforce 8000 cards and upwards, but can also use the CPU only if you don't have a CUDA card. (UPDATE: some people on XP machines cannot run the program because of a msvcrt.dll error. Removing opengl32.dll from the Brigade folder seems to solve the problem). There are 4 different scenes to choose from, some are animated with "planes" flying around. You can simply edit "scene.txt" to change scene, resolution, samples per pixel and so on. This is a video of one of the scenes: http://www.youtube.com/watch?v=qC2zKIqttzk

It's an amazing piece of software with huge potential. Afaik, the CPU uses bidirectional path tracing while divergent rays are path traced on the GPU. Scenes and materials are very simple, but nevertheless I am still stunned that real-time path tracing with animated objects is possible today. (Bidirectional) path tracing solves most limitations encountered by other real-time GI methods which rely on image space techniques or can only be used in diffuse and semi-glossy scenes. Speed is the only limit. I can't wait to see Brigade run on a cluster of PC's each containing multiple Fermi's (as is suggested in the readme file). Looking very forward to the games that the Dutchies will produce with this technology ;-)

Cloud gaming just works

The last couple of days, I have been reading a lot of impressions from gamers who have tried the OnLive service and I must say that I'm surprised at the amount of positive feedback. Many people don't seem to perceive any lag and the ones that do don't mind it too much and it never makes the games unplayable. I am stunned reading that OnLive works so well, I've been hoping that cloud gaming would work great, but this is even better than I had expected. I thought it would initially be plagued by major lag fluctuations, stuttering, connections shutting down when the service launched, but everything seems fine till now.

When cloud gaming really catches on and other services like OTOY and Gaikai will join the battlefield, these game clouds will have the capability to go beyond what consoles and even high-end PCs can offer in terms of graphics processing:

- insane geometrical detail with e.g. sparse voxel octree raycasting/-tracing for environments and characters
- advanced lighting and global illumination through GPU accelerated raytracing
- physics on every dynamic object
- procedural sound
- more human-like A.I. (just hook up the server to Blue Gene ;-))

This will be imo the ultimate argument to drop restricted console architecture in favor of cloud gaming.

Cloud gaming is also a great way for offering time-limited game demo's, which is Gaikai's main focus: play a demo of a soon to be released game right in your browser. How easy and customer friendly can it get? There are many other options beyond gaming, such as a Facebook-ish virtual reality world (LivePlace powered by OTOY), CAD programs, Photoshop, Matlab, anything compute intensive...

UPDATE: Two interesting short articles on Dave Perry's Gaikai:

http://www.nowgamer.com/news/3548/perry-big-3-will-embrace-cloud-gaming
http://www.nowgamer.com/news/3547/perry-gaikai-demo-surprised-publishers

Video review of OnLive

Cloud gaming, it's finally here: http://www.youtube.com/watch?v=Ir4B0rgta0Y

Two written reviews:

http://gizmodo.com/5567770/onlive-streaming-game-service-tested-at-home-finally

http://blog.wolfire.com/2010/06/Thoughts-on-OnLive

The reviews are surprisingly positive about the lag: some say it's noticeable, others say it isn't, but in either case it's not really an issue during gameplay, not even for "fast twitched" games like Unreal Tournament 3 and Batman Arkham Asylum. I(UPDATE: I have been watching 5 video reviews from casual gamers on YouTube, and every single one says that lag is unnoticeable, which is fuck awesome, I guess this settles anyones doubts about latency!). mage quality is a mixed bag: one reviewer says it looks almost identical to 720p local play, another says it's significantly worse. due to compression. I guess it depends on the bandwidth connection. Image quality is imo definitely not the biggest hurdle for cloud gaming, latency is much more important and apparently it's all very playable. Games are the most challenging software to make work through cloud computing and OnLive has apparently succeeded at this daunting task. OTOY and Gaikai will surely follow. When these services mature and gain popularity, consoles will face a difficult time. Ultimately, when every thinkable piece of software can be run on the cloud, who will still need Windows?

There's no doubt that cloud gaming is the future of games, the killer app for iPad and iPhone, probably sooner than most people think, and a serious problem for next-gen consoles. I think Larrabee/MIC/Knight's Corner might resurface in a cloud game server environment instead of being sold as a stand-alone PC card. I also think that at some point in the future, Nvidia and AMD will make hardware that is specifically aimed at game cloud servers and will be more efficient at memory use and power management in order to serve multiple users with the same hardware resources (like OTOY). A super beefed-up version of AMD Fusion for example.