On unrelated note, this is truly web 2.0, now with all post titles linking to itself. I considered going even further, but this single static html file design already scales fantastically. See how bandwidth grows exponentially (go internets go) while page size grows linearly (I'm not robots).

Update: AMD drivers are also already available to selected developers. AMD expects public release in "second half of 2009".

Update 2009-05-28: Another closed beta release from Nvidia. It's good, one of two features I miss was added.

Update: Must.. resist.. temptation.. rewrite.. everything.. for.. 3.1.
I'm weak, already rewriting.

First, there was smallPT, GI in 99 lines of C++, fantastic piece of code that renders Cornell box like scene made only of spheres. It's very slow, but Thierry Berger-Perrin ported it to CUDA and added new scenes and controls for realtime manipulation, The Once Known as SmallPT was born. Magnificent. Beware, requires Nvidia card. Source code included.

Scenes are made of roughly 10 spheres. It makes me wonder in good sense, we coders love limits and intros show we can do lots in 256 bytes... can we make good gameplay with renderer limited to 10 spheres? I guess building games on Thierry's commented source code would be piece of cake. Any demo organizer here?

Update: this slide at hardware.fr shows Nvidia plan: final runtime/driver is expected in the middle of 2009.

I reported it to MS, but before fix is available (and before OpenOffice releases 3.0 with .pptx support), users will google for solution. Let's attract them. Viewer says PowerPoint Viewer cannot open the file "Shedding Indirect Light on Global Illumination for Games.pptx".. Error in event log is Faulting application PPCNVCOM.EXE, version 12.0.6211.1000, time stamp 0x46ce621f, faulting module oartconv.dll, version 12.0.6214.1000, time stamp 0x47029c72, exception code 0xc0000005, fault offset 0x0022d94b, process id 0x3b78, application start time 0x01c912bcf5abd300.

BTW, every child knows that when writing new GI article, it's important to keep first two sentences in standard form
1. "GI is extremely critical stuff"
2. explain why
Gameplayer levels up the scheme by adding strong third sentence
3. "If you don't believe us, go back and fire up the original Doom."

For me, no surprises inside.
Design looks like it could work on Cell too, although with terribly expensive random access to big data structures in global memory. Still, OpenCL would be good for Cell in PS3 development, because one would be able to test on PC and have roaring PS3 jet-engines turned off.

As far as I'm concerned, I welcome even this smaller step, because driver bugs are no longer problem, I became pretty skilled in avoiding them.
Thinking more about Khronos, I hope OpenCL will start soon. Because when we have generic compute shader platform with simple memory management, OpenGL and Direct3D are just unimpressive high level APIs built around hw rasterization, sentenced to slow death. AMD dropped CTM in favour of OpenCL. Nvidia will drop CUDA for the same reason 10 years later. The only two questions are, will Intel manage to add serious OpenGL support before everyone else drops it (in 25 years)? Of course, serious = runs Lightsmark. And will Microsoft manage to prevent OpenCL implementations on next Xbox?

Update:
- That thing about CAD companies, repeated on all forums, originates from Carmack.
- I don't think that death of 'new API' is sooo big disaster for driver developers. Completely new API in addition to the old one, maintained for compatibility is a lots of additional work, while current deprecation model forces them only to add some #ifdefs and compile twice. If they want, they can create separated 'clean' GL3 codebase at any time.

Update2: AMD is not dropping CTM, sorry. Plans are to layer OpenCL on top of CAL that evolved from CTM. However effect is the same, mainstream app developers won't use proprietary API if they get portable one.

Update: users report scores over 700 fps.

Finally, id gets it too. Carmack explained that he found some of the complaints of Doom 3's brand of horror to be "completely valid," saying that the "contrived nature of monsters hiding in a closet" and the extreme darkness were two things that caused the company to cancel its game Darkness and begin production of Rage.

I really like this effort, it's 100x more important for realtime raytracing than Intel's marketing dollars. On the other hand, people should not confuse this with realistic lighting. With zero or constant ambient, it looks less realistically than an average game. Of course there are ways how to improve lighting and even without looking into Arauna, I'm sure Jacco has something in development.

Update: Gotchas solved, but still no luck. With disabled Adblock, download page finally opens. Download link shot down Firefox, right click to save is necessary. Game started, but image was distorted, then it stopped responding and silently disappeared. Demo displayed single static image. Maybe Vista x64 still too exotic?

Update: Demo starts after hitting space, thanks Dhatz. Very nice scene! Scene and lights are static, but it's still the best realtime raytracing demo ever. Looking for improved realism, majority of pixels have only direct lighting + const ambient, so it resembles late 20th century. Exceptions are pixels with specular reflection, refraction and some strange noise.
One extremely important point I forgot to mention: source code of Outbound engine, Arauna, is available too.

Update: problem disappeared after several changes in rendering code. I haven't tried to track it down to one-line change, but changes were related to display lists.

Update at the end of summer: It seems Aaron reached rougly 50% of his goals. Still I think it's an excellent result.

Somehow I think there's not enough realism yet, even with truecolor added to VESA BIOS some time ago. Realtime global illumination is not pixel perfect. How do I quantize in 500000-dimensional space, quickly?
What, NP hard? Starting assembler...

Direct3D defines approx 10 fixed levels of shader length/complexity/whatever (e.g. SM4.0), you must always pick one of them. If you can fit your shaders into these levels, everything is fine, simply look at level supported by graphics card and use appropriate shader from your collection.

OpenGL is simpler and more general, it doesn't specify length/complexity/whatever, you simply compile your shader and driver says OK. Or Sorry, too many interpolators/whatever used, we'll screw you by running it in software. Now you have several shaders and you want to pick the most complex one supported. The only question is, do you test bottom up or top down?

I started with top down: when most complex shader failed to compile/link, I went to second most complex and so on, until I found first supported one. It worked fine except that every card behaved differently, I had strange things reported. I had to buy 5 graphics cards for testing and write several workarounds, based on vendor and model string (ouch!) to prevent broken rendering and crashes inside driver when requested to compile valid GLSL shader. Behaviour often changed with graphics card driver version. It wasn't getting better.

I switched to bottom up: when the simplest shader compiled/linked, I went to second most simple and so on, until next one failed. Number of revealed driver bugs fell down significantly, only one card family continued to crash in driver or render incorrectly.

Conclusion? OpenGL is superior in design, but inferior in practical use, due to insufficient driver testing. Search for the most complex shader won't make you happy.

Try search for the most complex 5-state Turing machine instead. It's like writing really good intro in 5 instructions. Ready?...go! After 45 years of pure research without drivers, problem is still open. Nice intro article. It's about beavers too.

Back when only video was released, I speculated that it's copy of our technique from 2000 (used in RealtimeRadiosity 2 demo) where per-vertex layers of lighting are precomputed for sampled positions of light / objects. When light / objects move, closest samples and their layers of precomputed lighting are selected and per-vertex lighting is reconstructed as weighted average.

Back to reality. CryTek's technique is much simpler and less correct. Only scalar ambient occlusion value per texel is precomputed. The rest is magic expression in shader (not specified precisely) that combines distance attenuation, normal divergence and ambient occlusion. It doesn't simulate light paths, so it would probably look bad in scenes with mostly indirect light, but it probably looks great in mostly open scenes / no big blockers. They added support for portals... I think it was absolutely necessary to avoid light freely leaking through walls.

Conclusion: In mainstream realtime rendering, indoors, it will be first big improvement over aging constant ambient. It's rough estimate rather than light simulation, so it needs lots of additional infrastructure (portals) and work from artists to look good/avoid artifacts. It also means it's viable only for gaming industry and even there, adoption won't be fast. However it's very inexpensive for end user (gamer), so chances are good that it will be adopted by several other engines before fully automated physically based RTGI techniques take lead.

It's still nice to use gcc. It has the best warnings of all compilers, it always finds some error that was completely ignored by other compilers.

It seems only remotely related to rendering, however it has some importance for me as my code is heavily templated and new language features may simplify it.

Ok, it's still too hot area to set one standard now. Land changes quickly with AMD's Fusion plan to integrate GPU and CPU, optimal APIs for 3d graphics evolve as never before. So let's live with several APIs for next few years.

But that reminds me, hacking chaotic VGA registers was fun, because it was simple and nearly bug free; on the other hand using well designed VESA BIOS Extensions (VBE) was pain, because there were bugs in ROM and no chance to fix them without buying new graphics card, so we had to live with bugs. I wrote this list of approx 20 bugs and workarounds for VESA BIOS implementations. With this list, I was able to run on buggy cards, while others displayed random pixels or crashed.
Using GPGPU APIs could be fun again, because they are not set in stone (in ROM), and users can fix bugs by simple driver/library update, we don't have to gather workarounds.
The only thing that makes me worry is closed nature of those APIs. In comparison of APIs created by one company and multiple companies, those multi- look clearly better; see eg. how well specified is OpenGL in comparison to DirectX. DirectX must be rewritten each 2 years to catch up with OpenGL ;)

You can see many papers with precomputed global illumination. They offer very fast rendering of precomputed data and it's not always clearly visible that it must be precomputed, it could be hiden deep inside the article. So some of them are misinterpreted by massmedia as a final solution of the old problem with global illumination. However those hours of precomputations and those limitations coming from precomputed data (eg. you can't move any object) should not be forgotten.

Imagine architectural modeling. Architect or user interactively manipulates geometry of the building. He wants to see it nicely lit. Existing papers offer him for example relighting (Direct-to-Indirect Transfer for Cinematic Relighting by M.Hasan) - once building is modeled, you can run expensive precomputation and when it's done, manipulate light in realtime. But don't touch the geometry. And don't touch the camera. It's both fixed. Well.. can we have more interaction?

Now let's go for games. Games create strong pressure for technological progress, together with sex, however I'll stick to games. While previous generation had static buildings and precomputed illumination fits for such scenarios, current trend is to make everything destructible, even walls. Soon game developers will start looking around for fast global illumination in dynamic scenes.