level of detail

As of last month, I’ve been at Firaxis Games for a year. That time just flew right past. The transition to game development has been challenging and rewarding (and frustrating). Every aspect of creating “pretty pictures” becomes much more difficult when working on a game. I imagine more than a few of you reading this to be internally commenting “No Shit, Sherlock”, but it cracks me up when I think about some of the things that I always took for granted when making demos at ATI/AMD. Things like shadowing, translucency, etc. are easily handled when you are making one-off demo apps over the course of a few weeks/months. Usually those apps have controlled camera angles, small scenes, a very specific technical goal and the privilege  of supporting a limited range of hardware. It’s certainly changed my perspective on what is impressive as far as real-time graphics goes.

I’ve joined a few friends and former schoolmates at Firaxis. Actually, my graduate school adviser, Marc Olano, has been here for the last year on sabbatical. Some of his work on filtering specular highlights from normal maps for ocean rendering in Civilization V was published at I3D 2010 under the title LEAN Mapping. Speaking of, he’s been posting a number of graphics tricks over at the UMBC Games and Interactive Media blog. Trick 1 reformulates the computation of a normal from a heightfield and Trick 2 deals with calculating the size of a mip chain via closed form equations. He’ll be posting a few more in the future, so add the RSS feed and check back in a week or so.

Many of the blogs I used to read on the regular have either gone silent or their authors have primarily moved to Twitter. I read a few people’s tweets but mostly I just haven’t made (or plan to make) that transition. I find it hard enough to post anything here without over-analyzing whether or not its even worth reading, let alone posting 8 times a day. And frankly as a reader I find the signal:noise ratio difficult to manage. A few of the good old fashioned web blogs I’ve been reading lately are Miles Macklin’s blog, Game Angst by Adrian Stone,  and Smash’s direct to video. On the less graphics focused front, The Witness blog starring Jon Blow and Ignacio Castaño, the Wolfire Games blog and Charles Bloom’s cbloom rants (as always). As a total hypocrite, I would like to call-out and encourage Brian Karis, Tim Farrar and Christer Ericsson to update their damn blogs.

Anyway, I’ve been reading more papers lately so maybe I’ll have some impetus to update this dumb blog. And if you still have my RSS feed in your reader, thanks!

As a side note, Civilization V was announced several weeks ago and has been available for pre-order on Steam. Go team!

Somehow I haven’t checked Humus’ website for about six months. Not sure how that happened, as that guy always has great little demos and tricks to share. Of particular interest to me is his trick for detecting where to perform multisampled deferred shading in his Deferred Shading 2 app. By passing SV_Position to the pixel shader with centroid interpolation, you can detect if you are at an edge by examining if the centroid sampled position has moved from the pixel center. Awesome! Saves you an edge detection pass.

Also of particular interest to me are Shader Programming Tips #1, 2, and 3. It’s great to see someone talking about GPU Shader Analyzer. The program is super-handy and I use it almost every day. I can’t imagine optimizing without it.

His little experiment with Alpha to Coverage here is pretty cool too. I’ve always thought A2C was lousy. I never thought that maybe that was partially because the HW implementation was not so good.

Thanks Humus for adding an RSS feed so that this will never happen again!

GameDev is hosting a free online copy of the ShaderX² books.

ShaderX²: Introduction & Tutorials with DirectX 9

ShaderX²: Shader Programming Tips and Tricks with DirectX 9

Pilfered from the Real-Time Rendering book blog.

Eric Lengyel has the slides from his GDC 2007 talk “Projection Matrix Tricks” available online. Included are techniques for formulating a projection with an infinite far plane (useful for rendering distance stuff right by the far plane, such as skyboxes) and clipping against a plane in the scene (useful for things like rendering geometry below a refractive surface).

Link to slides

At SIGGRAPH this year, there was a talk by the AMD/ATI Demo Team about the Ruby:Whiteout demo. It was disappointingly attended but it was filled to the brim with GPU tips and tricks, especially in the lighting department. This stuff hasn’t been presented anywhere else and I haven’t seen much discussion on the web so I decided to highlight a few of the key topics.

One of the really impressive subjects covered was volumetric lighting (w.r.t. particle and hair). Modeling light interaction with participating media is a notoriously difficult problem (see subsurface scattering, volumetric shadows/light shafts) and many surface approximations have been found. However, dealing with a heterogeneous volume of varying density, such as the case with a cloud of particles or hair, is still daunting. The method involves finding the distance between the first surface seen from the viewpoint of the light and the exit surface (the thickness), and also accumulating the particle density between those surfaces. Depending on how you decide to handle calculating this thickness and particle density, it could take two passes. They present a method for calculating this in one pass.

By outputting z in the red channel, 1-z in the green channel and particle density in alpha, setting the RGB blend mode to min and the alpha blend mode to additive and rendering all particles from the viewpoint of the light, you get the thickness and density in one pass. This same method can be applied to meshes such as a hair. It should be noted that this information can also be used to cast shadows onto external objects.

The presenters also discuss a few other tricks. These include rendering depth offsets on the particles and blurring the composited depth before performing the thickness calculation discussed above to remove discontinuities. Also, for handling shadows from non-particle objects, they suggest using standard shadow mapping per-vertex on the particles. I think I originally saw this idea mentioned by Lutz Latta in one of his particle system articles or presentations.

I might dredge some other topics from the presentation later on, but eveyone should check out the slides here.

Knowing the thickness of an object can be useful, for things like computing single-scattering of light through a participating media (think fog or a translucent material). The most obvious thing to do is render out the depth of the back faces, render out the depth of the front face, then use the difference between the two as the thickness of the object. This is fine-and-dandy for convex objects, but not so practical for more complicated objects. Look at a simple example of such an object in the below figure. A handy way to compute the thickness regardless of the object is to sum up the depths of all front faces at a pixel, then sum up the depth of all back faces, and subtract. You don’t have to resort to something like depth peeling to get these depths, just turn on additive blending when you render out depth for front and back faces. This was shared with me by my friend Thorsten Scheuerman but can originally be found in the NVIDIA Fog Volume SDK sample.

I was just working on something in which I needed linearized depth values. I couldn’t remember how to do this off of the top of my head. Turns out you just take into account w, which makes complete sense now that I’ve seen it (doesn’t it always work that way?):

float4 vPos = mul(Input.Pos,worldViewProj);
vPos.z = vPos.z * vPos.w / Far;
Output.Pos = vPos;

This was poached from Robert Dunlop’s page

Humus has a great little demo based on Chris Oat’s ambient aperture work . Oat’s stuff was used with terrain lighting in mind, but obviously it can be used on some bump maps also. This is a quick and dirty way to get some self shadowing on your bump mapped/parallax occlusion mapped surface without a bunch of extra texture accesses or aliasing. Oat’s method works by representing the unoccluded part of the hemisphere (the aperture) and the light source by spherical caps ( a direction and arc-length radius) and then computes the intersection of the two. Humus instead calculates the difference between the dot product of the aperture direction and the light direction minus the radius of the aperture. Pretty cool.

Please add this page to your RSS feed if like what you see so far.