Realtime radiosity?

http://www.geomerics.com/products.htm

Nice. But how?

A really smart coworker of mine noticed that some pillars in the demo where being lighted as a whole, like with a per-object coefficient, as the light changed. Plus, reading their technology page and how the system integrates with direct lighting... Mhm.

They seem to precompute visibility at given points around the scene (linked to objects? to vertices? to uniquely mapped textures? probably the latter is true). Then they take all the direct illumination plus shadows from a big lightmap of the entire level (how do they get an unwrap of the whole scene? is that computed dynamically based on the objects you see? like packing lightmaps of various visible objects into a big one? dunno, but you have to bake your direct illumination, even if it's dynamic into lightmaps, it seems for this to work). So probably, they're computing the amout of lighting for each sample point by gathering visible light texels from the lightmaps (so are they expressing visibility directly in the lightmap uv space? are they limited only to one bounce? probably).

I'm just guessing. I could be completelly wrong. But still I'm curious. If they're doing something like that, do they have a lod on the number of sample points? How much memory does each point require to store the precomputed visibility? Are they able to gather more than a single bounce? As they talk of precomputed visibility, surely they're not going to handle dynamic worlds... Still it's kinda nice.

Shame that you have to bake your dynamic lighting into lightmaps, that sounds expensive, even because you can't limit that to visibile surfaces (as the ATI skin subsurface scattering demo does for example, by a neat use of the early-z rejection) but you have to do that for each object/surface that could influence the scene lighting...

development stories

Me: "help, mouse does not work on my ps3 devkit"
Other: "do you have a keyboard plugged in?"
Me: "yes"
Other: "tried with another mouse"
Me: "yessir"
Other: "is your kit flashed with the latest update?"
Me: "all version correct"
Other: "do you have the second keyboard plugged in?"
Me: "!?!?"

P.S. even with the second keyboard it did not work, I had to reboot randomly swapping usb ports, now it works but the GPU debugger seems to crash. It's not funny. In the end, I gave up and debugged the shader blindly, by just iterating edit-compile-run cycles a few times.

Raytracing vs Rasterization

Is a really hot topic nowdays. Intel has been pushing realtime raytracing a lot lately, and this has spawned a number of discussions both in the realtime raytracing community and in the rasterization rendering one.

For now, I'll just link a post from Tom Forsyth on the topic. His summary is nice, but I wanted to point out a couple of things:

• He says that rasterization has a simple way to discard stuff in its inner loop, i.e. pixels. That's only partially true. It's simple when you don't deal with depth, i.e. discarding stuff to avoid overdraw. If you have to account for depth, then you need a zbuffer, a zbuffer pyramid, and checking fragments against the pyramid, the rasterizer itself becomes more complex etc. It's really not easy and the GPUs are really optimized nowdays to do that, as overdraw was becoming a major problem. If you account all those techniques that are needed to properly cull triangles in a rasterization renderer, a KD-Tree raytracer does not seem to be any harder. In my opinion, usually, raytracers tend to be easier to write than rasterizers.
  
• REYES is used only by a couple of offline renderers. Most notably, by Photorealisic Renderman. PRMan has a huge success, but it's only one product, and I doubt that its success is any more linked to REYES. I guess that it's so used in high end productions due to its proven stability, robustness and scalability in first place. And both PRMan and Mental Ray are hybrid, they use some form of rasterization only for the "first hit" (first visible surfaces) and then they raytrace the other hits. Rasterizing the first hit is nice not only for the speed, but also to compute antialiasing, gradients etc...
  
• When complex stuff is thrown into, rasterizer complexity tend to grow faster than raytracers. I.E. reflections, shadows etc. That could be a nice reason alone to experiment with RTRT in nextgen GPUs. Raytracing is kinda suited to parallel execution, expecially modern memory-coherent ones. Dunno if it is THE future, but I won't discard it so easily.

UPDATE: I've moved the second part of this post in a newer one

How to properly LOD pixel shaders?

I've said in a previous post that pixel shaders have automatic LOD, in the sense that far away/small objects usually fill a small part of the screen, so there is an implicit LOD, done by the perspective projection. And this is true.

The problem is that small, far away objects, due to the same perspective projection, tend to be the vast majority of the objects we draw. If we have many different shading techniques, this also means that they cause the vast majority of state changes - pipeline stalls. And that's bad.

How to solve that? Replace shading of far away objects with a "maximum common denominator" technique, so all those objects can be grouped togheter and do not issue state/shader changes.

Next-gen, realism and detail.

Is next-gen about realism? In most cases, yes it is. Is realism about detail? In my opinion, no. Or at least, not about fine-scale details. It's strange but I see in many games that to be "nextgen" a lot of effort has been placed on such details, completelly overlooking other, more important things. Nailing the exact shape of grass blades is completelly irrelevant, if you don't nail the exact colors of the grass.

Do this test. Take a good photo and blur it. It's still good. You lost details, but the general apparence is the same (*). Do the same with games, and see how many pass this test. Assassin Creed? Gears of War? What about Gran Turismo HD? Crysis? Nba Street Homecourt? Half Life 2? Some titles have a quality that trascend fine detail, some others are so detailed that they are almost noise, when you filter them, you'll see how flat they really are.

Again, painter's technique is a great ispiration. Nail the general volumes, colors, apparence first. Then add details. Gran Turismo HD/5 has a lot of errors in the details. Missing transitions, obviously tiled textures, you can even see trees that are still made with two textured, alpha-keyed planes. But it is incredibly realistic. And the previous titles, on the Playstation 2, had the same extraordinary level of quality.

Color, shadows, light, those are the details that matter, and they are hard to get right too. Gather referece, use referece a LOT.

In-game visual quality checking systems also help. It's really nice to have the ability to load and display reference side-by-side with the rendered frame for example. Or to be able to turn off textures, and check only the lighting, diffuse only or with specular, with specularmaps, with normalmaps etc. A surface blurring shader could be nice too, maybe just biasing the mipmap lookups to get a very blurred mipmap level.

And this is not only true for realistic games. It's the key for achieving any kind of look.

(*) That's also why technical details in expensive photo equipment matter only for huge prints, mostly in commercial photography, and in most cases are useless, the only thing that matter is your view, the situation, and how comfortable you are with your equipment (tools!).