We understand SS2 is using a brand-new visible surface determination algorithm and you mention using the hardware supported "occlusion query". With recent hardware coming out with ever more pixel culling support, do you think the industry is on the right path, does it needs to devote more effort towards eliminating pixels that aren't visible before going into the shader pipelines, or even should it seek a radical alternative to this problem?

To be quite honest, I haven't thought yet of radical alternative. :) So far - so good. I mean, early-Z rejection can really do wonders. For example, we are sorting our opaque objects from front to back (one more reason why geometry instancing is not-that-good, by the way! :). This way, early per-pixel rejections tends to eliminate lots occluded pixels, and if we reverse the sort order, drop in frame rate will be considerable (something like 30-40%). I guess, this counts as an evidence that we do need optimizations like that in GPUs. :)

Take it one step up in the rendering pipeline and you get occlusion queries - the core feature of our visibility system. Simple explanation would be that we have something like hierarchical occlusion culling system, and it basically works by itself, with a little (optional) help from our level editors. Basically, occlusion of an object is checked in one frame, and result is requested in the next (to avoid GPU stalls). Also, we have so-called visibility-boxes which level designer can lay all over the level, and that boxes will act as checkers for occlusion of all the objects that are inside them. So, we don't need to check each and every object if visibility box turns out to be occluded. (There is a lot more to it, but I don't want to go much deeper here. :)

NVIDIA mentions one of SLI's advantage is giving developers performance of tomorrow today. How has SLI and ATI's Crossfire changed how you develop the renderer? I'm asking because we're becoming ever more CPU-bound. Is giving developers more GPU power really that important?

Click for a bigger version

On the other side, we did need to tweak the code a bit here and there, in two cases to be precise;

• result of occlusion query cannot be read in next frame (because it's different board that the one which did the pixel count for a query), and
• render-to-texture result must be used by the board which did the rendering (of course).

All in all, it's not a big problem to implement. :)

Since SS2 is a TWIMTBP game, should we expect any NVIDIA-only features (like Depth Stencil Texture)?

Even better - HDR! Our HDR is the feature for all hardware that supports FP blending and filtering. So yes, you might say that it's NV-only feature. For the time being. :)

Does your crumb rendering system (vegetation sub-system) utilize geometry instancing?

Nope, not at this point, but we're considering using it. Only for crumbs rendering, though.

The problem with geometry instancing is that.... well, it's a feature that looks very good on paper, but when you start messing with it, it turns out that it's not that easy to implement. There's lots of resorting needs to be done in the engine scene renderer, which tends to break orthogonality big-time. :(

So, no, I don't want end up doing what papers suggest on how to use this feature... how you need to re-sort your surfaces to be "linked" with surfaces from other models - no, no, no... it just won't fit well in the visibility system.

You can look at geometry instancing as a patch-feature while waiting for Longhorn. It's here to improve batching performance, eliminating the need for lots of small batches rendered. And it's pretty radical approach, I must say.

Another way to eliminate small batches issue is - go and talk with your artists. Explain them all the performance issues related to it, make them understand all the consequences, and you'll have the game like Serious Sam 2 - (almost) completely free of small-batches! :)