Tag Archives: DirectX

Predicting the Past

Inspired by Bing (a person, not a search engine) and by the acrobatics I saw tonight in Shanghai, time for a blog post.

So what’s up with graphics APIs? I’ve been working on a project for a fast 3D graphics system for Autodesk for about 4 years now; the base level (which hides the various flavors of DirectX and OpenGL) is used by Maya, Max, AutoCAD, Inventor, and other products. There are various higher-level optimizations we’ve added (and why Microsoft’s fxc effect compiler suddenly got a lot slower is a mystery), with some particularly nice work by one person here in the area of multithreading. Beyond these techniques, minimizing the raw number of calls to the API is the primary way to increase performance. Our rule of thumb is that you get about 1000-1500 calls a frame (CAD isn’t held to a 60 FPS rule, but we still need to be interactive). The usual tricks are to sort by state, and to shove as much geometry and processing as possible into a single draw call and so avoid the small batch problem. So, how silly is that? The best way to make your GPU run fast is to call it as little as possible? That’s an API with a problem.

This is old news, Tim Sweeney railed against API limitations 3 years ago (sadly, the article’s gone poof). I wrote about his ideas here and added my own two cents. So where are we since then? DirectX 11 has been out awhile, adding three more stages to the pipeline for efficient tessellation of higher-order surfaces. The pipeline’s feeling a bit unwieldy at this point, with a lot of (admittedly optional) stages. There are still some serious headaches for developers, like having to somehow manage to put lighting and material shading in the same pixel shader (one good argument for deferred lighting and similar techniques). Forget about optimization; the arcane API knowledge needed to get even a simple rendering on the screen is considerable.

I haven’t heard anything of a DirectX 12 in the works (except maybe this breathless posting, which I feel obligated to link to since I’m in China this month), nor can I imagine what they’d add of any significance. I expect there will be some minor XBox 72o (or whatever it will be called) -related tweaks specific to that architecture, if and when it exists. With the various CPU+GPU-on-a-chip products coming out – AMD’s Fusion family, NVIDIA’s Tegra 2, and similar from other companies (I think I counted 5, all totaled) – some access costs between the two processors become much cheaper and so change the rules. However, the API still looks to be the bottleneck.

Marketwise, and this is based entirely upon my work in scapulimancy, I see things shifting to mobile. If that isn’t at least the 247th time you’ve heard that, you haven’t been wasting enough time on the internet. But, it has some implications: first, DirectX 12 becomes mostly irrelevant. The GPU pipeline is creaky and overburdened enough right now, PC games are an important niche but not the focus, and mobile (specifically, iPad and other tablets) is fine with the functionality defined thus far by existing APIs. OpenGL ES will continue to evolve, but I doubt we’ll see for a good long while any algorithmically (vs. data-slinging) new elements added to the API that the current OpenGL 4.x and DX11 APIs don’t offer.

Basically, API development feels stalled to me, and that’s how it should be: mobile’s more important, PCs are a (large but slowly evolving) niche, and the current API system feels warped from a programming standpoint, with peculiar constructs like feeding text strings to the API to specify GPU shader effects, and strange contortions performed to avoid calling the API in order to coax the GPU to run fast.

Is there a way out? I felt a glimmer while attending HPG 2011 this year. The paper “High-Performance Software Rasterization on GPUs” by Samuli Laine and Tero Karras was one of my (and many attendees’) favorites, talking about how to efficiently implement a basic rasterizer using CUDA (code’s open sourced). It’s not as fast as dedicated hardware (no surprise there), but it’s at least in the same ball-park, with hardware being anywhere from 1.5x to 8.1x faster for their test cases, median being 3.6x. What I find exciting is the idea that you could actually program the pipeline, vs. it being locked away. They discuss ideas for optimization such as loosening the “first in, first out” rule for triangles currently enforced by all APIs. With its “yet another language” dependency, I can’t say I hope GPGPU is the future (and certainly CUDA isn’t, since it cuts out non-NVIDIA hardware vendors, but from all reports it’s currently the best way to experiment with GPGPU). Still, it’s nice to see that the fixed-function bits of the GPU, while important, are not an insurmountable limit in considering more flexible and general interactive rasterization programming models. Or, ray tracing – always have to stick that in there.

So it’s “forward to the past”, looking at traditional algorithms like rasterization and ray tracing and how to gain efficiency (both in raw speed and in development time) on various modern architectures. That’s ultimately what it’s about for me, at least: spending lots of time fighting the API, gluing together strings to make shaders, and all the other craziness is a distraction and a time-waster. That said, there’s a cost/benefit calculation implicit in all of this. For example, using C# or Java is way more productive than C++, I’d say about 2x, mostly because you’re not tracking down memory problems like leaks and access uninitialized or non-existent values. But, there’s so much legacy C++ code around that it’s still the language of graphics, as previously discussed here. Which means I expect none of the API weirdness to change for a solid decade, at the minimum. Please do go ahead and prove me wrong – I’d be thrilled!

Oh, and acrobatics? Hover your cursor over the image. BTW, the ERA show in Shanghai is wonderful, unlike current APIs.

Gamefest 2010 Presentations

I attended this year’s Gamefest back in February. Gamefest is a conference run by Microsoft, focusing on games development for Microsoft platforms (Xbox 360 and Windows). This year (unusually, due to the presence of prerelease information on Kinect, at the time still known as “Project Natal”) the conference was only open to registered platform developers. For this reason, I didn’t blog about it at the time (no sense in telling people about stuff they can’t see).

Recently (thanks to the Legalize Adulthood! blog) I became aware that the Gamefest 2010 presentations are online on the conference website, and available for anyone (not just registered XBox 360 and Windows Live developers). I’ll briefly discuss which presentations I think are of most interest. First, the ones I attended and found interesting:

Lighting Volumes

This was a very nice talk about baking lighting into volumes by John O’Rorke, Director of Technology at Monolith Productions. Monolith were trying to light a large city at night, where the character could traverse the city pretty freely both horizontally and vertically. Lots of instances and geometry Levels-of-Detail (LODs), lots of dynamic lights. A standard lightmap + light probe solution took up too much memory given the large surface area, and Monolith didn’t like the slow baking workflow involved, as well as the inconsistencies between static and dynamic objects.

Instead, Monolith stored light probes in volume textures. They tried spherical harmonics (SH) and didn’t like it (too much memory, too blurry to use for specular). F.E.A.R. 2 shipped with an approach similar to Valve’s “Ambient Cube” (6 RGB coefficients), which has the advantage of cheap shader evaluation. For their new game they went with a stripped-down version of this, which had a single RGB color and 6 luminance coefficients; this reduces from 18 to 9 scalars and it was hard to tell the difference. Besides memory, this also sped up the shaders (less cache misses) and gave them better precision (since the luminance and color can be combined in a way that increases precision). For HDR they used a scale value for each volume (the game had multiple volumes in it) – this also gave them good precision in dark areas. Evaluating the “luminance cube” is extremely cheap (details in the slides). John also described some implementation details to do with stenciling out areas of the screen, using MIP maps, and getting around 360 alignment issues with DXT1 textures (all volumes were stored as DXT1).

Generation: the artists place lights (including area lights) and all the lights are baked (direct only, no global illumination (GI) bounces) during level packing. The math is simple – the tools just evaluated diffuse lighting for 6 normal directions at the center of each volume texel. Once the number of lights added by the artists started getting large this slowed down a bit so they added a caching system for the baked volumes. They eventually added GI support by rendering cube map probes in the game.

Downsides: low resolution, bad for high contrast shadows, can get light or shadow bleeding through thin geometry. They use dynamic lights for high contrast / shadow casting lighting.

For the future they plan to cascade the volumes and stream them. They also tried raymarching against the volume to get atmospheric effects, this was fast enough on high-end PCs but not consoles.

Rendering with Conviction: The Graphics of Splinter Cell

This great talk (by Stephen Hill from Ubisoft) went into detail on two rendering systems used in the game Splinter Cell: Conviction. The first was a software hierarchical Z-Buffer occlusion system. They used this in various ways to cull draw calls from shadows as well as primary rendering. The system could handle over occlusion 20,000 queries in around 1/2 millisecond. Results looked pretty good.

Next, Stephen discussed is the game’s ambient occlusion (AO) system. The game developers didn’t use screen-space ambient occlusion (SSAO), since they didn’t like the inaccuracy, cost, and lack of artist control. Instead they went for a hybrid baked system. Over background surfaces (buildings, etc.) they bake precomputed AO maps. The precomputation is GPU-accelerated, based on the GPU Gems 2 article “High-Quality Global Illumination Rendering Using Rasterization” (available here: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter38.html). For dynamic rigid objects like tables, chairs, vehicles, etc. they precompute AO volumes (16x16x16 or so). Finally for characters, they analytically compute AO from an articulating model of “capsules” (two half-spheres connected by a cylinder). Ubisoft combine all of these (not trying to address double-occlusion, so results are slightly too dark) into a downsampled offscreen buffer. Rather than simple scalar AO, all this stuff uses a directional 4-number AO representation (essentially linear SH) so that they can later apply high-res normal maps to it when the offscreen buffer is applied. They figured out a clever way to map the math so that they can use blending hardware to combine these directional AOs into the offscreen buffer in a way that makes sense. The AO buffer is later applied using cross-bilateral upscaling. For the future Ubisoft would like to add streaming support for the AO maps and volumes to allow for higher resolution.

Stephen showed the end result, and it looked pretty good with a character running through a crowded scene, vaulting over tables, knocking down chairs, with nice ambient occlusion effects whenever any two objects were close. A system like this is definitely worth considering as an alternative to SSAO.

Stripped Down Direct3D: Xbox 360 Command Buffer and Resource Management

This excellent talk (by Wade Brainerd, who like me works in Activision‘s Studio Central group) dives deep into a low-level description of Xbox 360 internals and the modified version of DirectX that it uses. A rare opportunity for people without registered console developer accounts to look at this stuff, which is relevant to PC developers as well since it shows you what happens under the driver’s hood.

Fluid Simulation Driven Effects in Dark Void

This talk by NVIDIA contained basically the same stuff as the I3D paper Interactive Fluid-Particle Simulation using Translating Eulerian Grids, which can be found here: http://www.jcohen.name/. It was interesting to hear about such a high-end CUDA fluid sim system being integrated into a shipping game (even if only on the PC version) – they got some cool particle effects out of it with turbulence etc. These kinds of effects will probably become more common once a new generation of console hardware arrives.

Advanced Rendering Techniques with DirectX 11

This talk was about various ways to use DX11 Compute Shaders in graphics. This talk included stuff like fast computation of summed area tables for fast anisotropic blurring of environment maps and depth of field. The speakers also showed an A-buffer-like technique for order-independent transparency, and a tile-based deferred rendering system that was more efficient than using pixel shaders. Like the previous talk, this seemed like the kind of stuff that could become mainstream in the next console generation.

Realistic Rendering with Spatially-Varying Reflectance

This presentation discussed research published in the SIGGRAPH Asia 2009 paper “All-Frequency Rendering of Dynamic, Spatially-Varying Reflectance“ (available here: http://research.microsoft.com/en-us/um/people/johnsny/). The presentation was by John Snyder, one of the paper authors. It’s similar to some other recent papers which represent normal distribution functions as a sum of Gaussians and filter them, but this paper does some interesting things with regards to supporting environment maps and transforming from half-angle to view space. Worth a read for people looking at specular shader stuff.

Xbox 360 Shaders and Performance: How Not to Upset the GPU

This talk was probably old hat to anyone with significant 360 experience but should be interesting to anyone who does not fit that description – it was a rare public discussion of low-level console details.

Bringing Characters to Life: Using Physics to Enhance Animation

This talk was about combining physics with canned animation (similar to some of NaturalMotion‘s tools). It looked pretty good. The basic idea is straightforward – artist paints tightness of springs connecting the character’s joints to the skeleton playing the animation – a state machine allows to vary these tightness values based on animation and gameplay events.

The Dark Art of Shadow Mapping

This was a good, basic introduction to the current state of the art in shadow mapping.

The Devil is in the Details: Nuances of Light Mapping

Illuminate Labs (the makers of Beast and Turtle) gave this talk about baked lighting. It was pretty basic for anyone who’s done work in this area but might be good to brush up with for people who aren’t familiar with the latest practice.

Other Talks

There were a bunch of talks I didn’t attend (too many overlapping sessions!) but which look promising based on title, speaker list, or both: Case Studies in VMX128 Optimization, Best Practices for DirectX 11 Development, DirectX 11 DirectCompute: A Teraflop for Everyone, DirectX 11 Technology Update, and Think DirectX 11 Tessellation! – What Are Your Options?

Just Cause 2 makes 3

A demo of the game Just Cause 2 is available on Steam today. What’s interesting is that this is the third DirectX 10-only game to be released. There have been any number of DirectX 10 enhanced games, but until a few months ago there was just one DirectX 10-only game release, Stormrise, a mediocre game released in March 2009. Shattered Horizon then came out in November from Futuremark, who are known more for their graphics benchmarks. Just Cause 2 is a sequel, and distributed by a well-known publisher. Humus describes the logic in going DirectX 10-only.

I’m looking forward to see how DirectX 11’s DirectCompute gets used in commercial applications. Perhaps the day there’s a DirectX 11-only game of any significance is the day we need to start writing a fourth edition. Let’s see: DirectX 10 was released November 2006 with Vista, so it took about three and a quarter years for an anticipated game to be released that was DirectX 10-only (and even now it’s considered dangerous by many to do so). DirectX 11 was released in October 2009, so if the same rule holds, then we’ll need to start writing in February 2013. Pre-order today!

Even now, 13% of Steam gamers have only SM 2.0. Games like World of Warcraft and Left 4 Dead 2 don’t require more, for example. So what’s the magic percentage where the AAA games decide to set the minimum level to the next shader model? I don’t recall it being much of a deal between shader model 2.0 and 3.0 games; there was a little hype, but I think this was because going from SM 2.0 to 3.0 involved just a card upgrade, vs. an OS upgrade. Which is funny, in that an OS upgrade is usually cheaper than a new GPU, but I think it’s also because it’s more critical, like a heart transplant vs. a cornea transplant.

Poking around, I found the interesting graphs below. I’m sure games have been left off, and some are miscategorized, e.g. Cryostatis is the only one under SM 4.0, and it doesn’t require DirectX 10. But, let’s assume this data is semi-reasonable; I’m guessing the games are categorized more by a “recommended configuration” than a minimum. So Shader Model 1.x game releases (and remember, 1.x was pretty darn limited) peaked in 2006, 2.0 peaked in 2007 but outnumbered 3.0 until 2009. SM 3.0 hasn’t peaked yet, I’d say (ignore 2010 and 2011 graph values at this point, of course). Remember that SM 2.0 hardware came out around 2002, so it peaked 5-6 years later and still was strong 7 years later (and perhaps longer, we’ll see). SM 3.0 came out in 2004, and seems likely to continue to be strong through 2010 and into 2011. 4.0 came out in 2006, so I’d go with it peaking in 2011-2012 from just staring at these charts. Which entirely ignores the swirl of other data—Vista and Windows 7, Xbox trends, GPU trends, blah-di-blah—but it’ll be interesting to see if this prediction is about right. (Click on a graph for the lists of games for that shader model.)

Shader Model 1.x

Shader Model 2.0

Shader Model 3.0

7 Things for February 8

I use a LIFO stack for these link collections, so we’re starting to get into older news. Olds? Still good stuff, though.

  • I hadn’t noticed this set of notes before from Valve, “Post Processing in the Orange Box.” It’s about sRGB (think, gamma correction), tone mapping (think, rescaling using the histogram), and motion blur (think, types of blur). Interesting that a variable frame rate combined with blur made people sick. They’d also turn blur off if a single frame was taking too long. (from Morgan)
  • Wolfgang Engel has posted DirectX 11 and DirectX 10 pipeline overview charts. In a similar vein, Mark Kilgard has a talk about the changes from OpenGL 1.0 to 3.2 with some worthwhile data flow diagrams and other material.
  • openSourceVFX.org is a catalog of open source projects that are particularly suited for film visual effects and animation work. It is maintained by professionals in the field, so the resources listed are those known to actually be used and production-worthy. (thanks, Larry)
  • Here’s another PhysX demo, of water—a little jelly-like (good spray is hard, since it’s so fine-grained), but pretty amazing to see happen at interactive rates.
  • One resource I didn’t recall for my blog entry about tools for teaching about graphics and game creation: Kodu, from Microsoft. For grade schoolers, it uses a visual language. Surprisingly, it’s in 3D, with a funky chiclet terrain system. For still more tools, check the comments on the original blog entry—some great additions there. (pointed out by Mark DeLoura)
  • Another interesting graphics programming tool is NodeBox 2, now in beta. It uses a node graph-based approached, see some examples here.
  • The story of Duke Nukem in Wired is just fascinating. We all like to tell and listen to stories, so it’s hard to know how true any narrative is, but this one seems reasonably on the mark. A little balance is provided by Raphael van Lierop.

7 Things for February 7

Comin’ at ya, lots of one-liners, vs. yesterday’s verbose posting.

7 Things for February 6

With the excitement of Ground Hog’s Day and James Joyce’s birthday over, it’s time to take off the silly paper hats and get back to writing “7 things” columns. Here goes:

  • Jeremy Shopf gives a nice summary of recent ambient occlusion papers. AO is becoming the new Shadows—every conference must have a paper on the topic. Honestly, it’s amazing that some of these ideas haven’t popped up earlier, like the line integral method. If you accept the basic approximation of AO from the start, then it’s a matter of how to best integrate the hemisphere around the point. I’m not downplaying the contribution of this research. Just the opposite, it’s more along the lines of “d’oh, brilliant, and why didn’t anyone think of that earlier?” The answer is both, “because those guys are smart” and, “they actually tried it out, vs. thinking of an idea and not pursuing it.”
  • Thinking about C++ and looking at my old utilities post, I realized I forgot an add-on I use just about every day: Visual Assist X. This product makes Visual Studio much more usable for C++. Over the years it’s become indispensable to me, as more and more features get integrated into how I work. I started off small: there’s a great button that simply switches you between the .cpp and .h version of the file. Then I noticed that other button which takes a set of lines I’ve selected and comments them out in a single mouse press, and the other button that uncomments them back. Then I found I could add a control that lets me type in a few characters to find a code file, or find a class. On and on it goes… Anyway, there’s a free trial, and for individuals it’s an entirely reasonable (for what you get) $99 license. By the way, you really don’t need to get the maintenance renewal every year.
  • As you may know, MIT has had a mandate for a number of years to put all of its courses online in some form—there are now 1900 of them. The EE & CS department, naturally enough, has quite a selection. The third most visited course on the whole site is Introduction to Computer Science and Programming, from Fall 2008 (and I approve: they use Python!). There’s only one computer graphics course, from 2003, but it covers unchanging principles and concepts so the “ancient” date is a minor problem.
  • Naty pointed out this article about deferred rendering. He notes, “A nice description of a deferred rendering system used in a demo—of particular interest is the use of raytraced distance fields for rendering fluids, and the integration of this into the overall deferred system.”
  • A month and a half ago I listed some articles about reconstructing the position or linear z-depth in a shader. Here’s another.
  • It’s the ongoing debate, back again. No, not dark vs. milk chocolate, nor Ferrari vs. Porsche, but DirectX vs. OpenGL. My own feeling is “whatever, we support both”. By the way, the upcoming book GPU PRO (which also has a blog, and has just been listed on Amazon) includes an in-depth article on porting from DX9 to OpenGL 2.0. Mark Kilgard’s presentation also discusses the differences, including the coordinate space and window space conventions.
  • I love human pixels. The Arirang Festival in North Korea is a famous example, check out Google Images. But that’s just a card stunt, impressive as it is. This video shows a technique I hadn’t seen before (note that some of it is sped up—check the speed of the people on the field—but still fantastic). There are other videos, such as this and this.

C++, Baby

I was catching up on the Communications of the ACM, and noticed this article, Computer Science in the Conceptual Age. The “catch your eye” text on one page was: “Programming interns/job seekers from our program Spring 2009 (35 interviewed in the game industry) found no companies administering programming tests in Java.”

There are other chewy bits, such as: “The USC experience is that 100% of its students interviewed for programming positions are given three-to-four-hour-long programming tests, with almost all companies administering the tests in C++.”

Also, this: “The game industry will also tell you that it wants the first four programming classes in C++, not Java, according to M.M. McGill and my own private communications with directors of human resources in major game-development companies.”

One final morsel: “Many game companies say they will not interview or hire someone whose first programming language is Java.”

Wow, that last one’s harsh, especially since my experience with two teenage sons (one in high school, the other a freshman computer science major) is that Java is the norm for the first “real” language taught (I don’t count Scheme as a real, “you’ll get paid programming in it” type of language). I don’t think I’d rule someone out for knowing Java first, though having gone from C++ to Java and then back, the transition from Java to C++ is like being thrown out of the promised land: you suddenly again spend half your time messing with memory in one form or another. C# and Java are darn productive in that way. And, no, for me at least, those auto-pointer classes in C++ never quite seem to work—they need a different sort of discipline I don’t appear to have. I also love that my first Java program, from 1997, still works on the web; some of my C++ programs from back then won’t run on Vista or Windows 7 because the WinG DLLs are not a part of those operating systems (thanks, Microsoft).

Nonetheless, the article’s right: at Autodesk we’ve dabbled with Java and C#, I’ve seen Python used for UI control around the fringes of a program, but the heart of client-side graphical programs is almost always C++ (or isn’t, with regrets and cancellation often soon following—been there myself, though Java was only a little bit to blame, to be fair). Also, XNA, which uses C#, does not have a 64 bit version. In addition, Microsoft’s managed code support usually lags behind the “real” DirectX, i.e., the one for C++.

Looking around, I did find an open-source project, SlimDX, that does support 64-bit assemblies for interfacing with DirectX. Interestingly, they claim one AAA game title shipped using SlimDX, but no mention of which. So I asked. They’re keeping the information confidential, which is fine, but the other comment sounds about right: “The large majority of professional commercial PC/console games are still developed in C++ because of the sheer amount of legacy code the studios developing those games have that is already in C++ (and because of the generally poor support from major console vendors for languages other than C or C++, which contributes to lock-in).”

Long and short: it’s C++, baby.

Clearing the Queue

I’ve have a goal this week (it should be clear by now) of clearing my queue of stored-up RTR links by my birthday, today! (Hint: I want a pony.) So excuse the excessively-long list o’ links. Next task on my list, update the main RTR page itself.

  • StructureSynth. This looks pretty cool, and I love procedural models (my ancient SPD package was all about this, back in the days when downloading models was oppressively slow). I do wish they just provided an executable – building looks like a pain.
  • That previous link was on Meshula.net, which also blogs about Pixel Bender Fractals. Great stuff, sort of steampunk computer graphics: you must click this link, if no other on this page, and look on in awe.
  • Shapeways has a blog, and it’s not just dull company announcements. I’m glad they find people as pixels as interesting as I do. They also cover exporting Spore characters to Collada files (which is a great addition to Spore) and creating physical models from these.
  • In related news, The Economist has a reasonable summary of some trends in 3D printing. Their Technology Quarterly also has articles on Augmented Reality, 3D displays, and CAPTCHAs, among other topics.
  • This is one more reason the Internet is great: an in-depth article on normal compression techniques, weighing the pros and cons of each. This sort of article would probably not see the light of day in traditional publications, even Game Developer – too long for them, but all the info presented here is worthwhile for a developer making this decision. Aras’ blog has other nice bits such as packing a float into RGBA and SSAO blurring.
  • I need to add a link to the article itself to the object intersection page, but Morgan McGuire recently verified that he found this ray/box algorithm super-fast in SIMD. Code’s downloadable from that page, free version of article is downloadable here. Morgan uses this test in the ray tracer for his cool photon mapping paper at HPG 2009; if nothing else, you should at least see the video.
  • In related news, I am happy to see that AK Peters is beginning to put past journal of graphics tools articles online. At $15 each, the price of an article is quite high for individuals (or at least this individual), but current journal of graphics (gpu, & game) tools subscribers have full access to this archive for free. The mechanism to get access is a little clunky right now: if you’re a subscriber, you need to register with Metapress, then tell AK Peters your userid and they’ll provide you access.
  • Related to this, I hope Google Books conquers the world (or anyone else doing similar work, as long as it isn’t Apple or Amazon or other overcharging closed-box “we’re just protecting the authors, who get 10% or less for a purely digital sale with nil physical cost to us per unit” retailers – rant over, and I do understand there are fixed start-up costs for the retailer/publisher/etc., but really…). Google Books is so darn handy to look for short articles in books at Google’s repository, such as this one giving a clean way to build an orthonormal basis given a vector, from Graphics Tools: The JGT Editors’ Choice.
  • Humus provides a whole slew of new cubemaps he captured, if you’re getting tired of Grace Cathedral.
  • CUDA itself (vs. others) may or may not be a critical technology, but what it shows about the underlying GPU architecture is fascinating.
  • It should be mentioned: August 2009 DirectX SDK is available. Includes the first official release of DirectX 11.
  • This is hilarious, and possibly even useful!
  • I love seeing things like this: build your own multitouch display. Not that I’ll ever do it, but I hope others will.
  • You might be sick of Larrabee news (ship one, already!), but I found Phil Taylor’s article pleasantly hype-free and informative.
  • ATI’s Eyefinity (cute marketing name, I must admit – now I want to use the word everywhere) seems to me to solve a problem that rarely occurs: too much GPU for too few screens. Still, it’s nice to have the option. Eyefinity allows up to six monitors to be driven by a single GPU. I guess Eyefinity is useful when running older flight simulator programs on newer GPUs; otherwise, Eyefinity is pretty irrelevant. Eyefinity, eyefinity, eyefinity. At work I find two displays is plenty, one to run, one to debug. Anyway, the sweet spot for the monitor:GPU ratio is 13:1, as can be seen here:
    Flight Simulator - living the dream
  • There’s an article on instancing animated grass using DX10 on Gamasutra.
  • Humus’ summary of z interpolation is a good summary of the topic. He gives some of the key tricks, e.g., if you’re using floating point, use a near=1.0 and far=0.0 to help preserve precision.
  • Here’s a basic tutorial on different projection methods used in videogames, with lots of visual examples (add “Zaxxon” and it’s complete, for me). The one new tidbit I learnt from it was about reverse perspective, an effect I’ve made myself once every now and then when I screw up a projection matrix.
  • While I’ve been on break (one of the reasons I’ve been posting so much – Autodesk gives wonderful 6 week “sabbaticals”, aka “long vacations”, to U.S. employees every four years you’re there; it’s like being French or Swedish every fourth year), the rest of the company’s been busy: this new sketch application for the iPhone looks pretty cool, at the usual $2.99 “cup of coffee” type price.
  • Caustics can be dangerous. I can attest to this myself; a goofy award Andrew Glassner gave me long ago sat on my windowsill for years (I moved once, as you should discern from the picture), until I noticed what was happening to the base:
    caustics
  • I usually don’t have time to keep up with Slashdot, but SeenOnSlash, the funny bits of SlashDot, is sometimes entertaining. Graphics-related example: AMD’s latest chip.

7 Things for July 18th

Well, I have 69 links stored up, wade through them here if you want unedited content. I’ve decided that getting 7 links out per post is a good round number, so here’s the first.

  • This is my screen-saver du jour: Pixel City (put the .scr file in your Windows directory). It’s fully described (along with source) in this great set of articles; if you’re too busy to read it all (though you should: it’s an fun read and he has some interesting insights), watch the video summary on that page. If you feel like researching the area of procedural modeling of cities more thoroughly, start here.
  • The book Real-Time Cameras, which is about camera control for games, now has a sample excerpt on Gamasutra.
  • NPR: Forrester Cole has two worthwhile GPU methods for deriving visible line segments for a set of edges (e.g., computing partial visibility of geometric lines). He’s put source code for his methods up at his site, the program “dpix“. Note: you’ll need Qt to compile & link.
  • The author of the Legalize Adulthood blog has recently had a number of posts on using DirectX10.
  • DirectX9 is still with us. Richard Thomson has a free draft of his book about DirectX 9 online. He knows what he’s about; witness his detailed pipeline posters. The bad news is that the book’s coverage of shaders is mostly about 1.X shaders (a walk down memory lane, if by “lane” you mean “horrifically complex assembly language”). The good news is that there’s some solid coverage of the theory and practice of vertex blending, for example. Anyway, grist for the mill – you might find something of use.
  • Around September I have 6 weeks off, so like every other programmer on the planet I’ve contemplated playing around with making a program for the iPhone. The economics are terrible for most developers, but I’d do it just for fun. It’s also interesting to see people thinking about what this new platform means for games. Naturally, Wolfenstein 3D, the “Hello World” of 3D games, has been ported. Andrew Glassner recommended this book for iPhone development, he said it’s the best one he found for beginners.
  • Speaking of Andrew, he pointed me at an interesting little language he’s been messing with, Processing. It’s essentially Java with a lot of built-in 2D (and to a lesser extent, 3D) graphics support: color, primitives, transforms, mouse control, lerps, window, etc., all right there and trivial to use. You can make fun little programs in just a page or two of code. That said, there are some very minor inconsistencies, like transparency not working against the background fill color. Pretty elaborate programs can be made, and it’s also handy for just drawing stuff easily via a program. Here’s a simple image I did in just a few lines, based on mouse moves:
    Processing output
That’s seven – ship it.

This and That

I’ll someday run out of titles for these occasional summaries of new(ish) resources, but in the meantime, this one’s “This and That”.

Christer Ericson’s article on dealing with grouping and sorting objects for rendering is excellent. It mostly depends on input latency, but has concepts that can be applied in immediate mode.

An element that continues to renew the field of computer graphics is that the rules change. This article is about taking Quake 2 (from 1997) and moving it to a modern GPU.

If you haven’t seen it yet, Farbrausch’s demo “debris” is truly impressive. It’s only 183,462 bytes, and is absolutely packed with procedural content. Download here (last link works). Or be lazy and watch on YouTube.

NVIDIA’s pulled together its resources for shadow generation and ambient occlusion all onto one handy page (plus ray tracing – just one entry so far, but it’s a good one).

How to deal with various rendering paradigms on multiple platforms? GRAMPS looks intriguing.

Gamasutra put a useful Game Developer article online, all about commercial middleware game engines currently available.

OpenGL will always exist, since Macs and Linux need it. It’s easier to use in college courses because of its clarity and readability. But otherwise the pendulum’s swung far towards DirectX. Phil Taylor comments on and gives some historical context to the controversy around the latest release, OpenGL 3.0.

A nice trend for OpenGL is that people continue to write useful bits, such as GLee, which manages extensions.

New info on older effects: blur and glow, volumetric clouds, and particle systems.

The glorious teapot. I like “a wireframe view”. Yes, the real thing is taller than the synthetic model, as the model makers were compensating for non-square pixels.

“What’s the future hold?” is always a fun topic, one we’ve used each edition to end our book. I liked this presentation on SlideShare for its sheer “here are a hundred things that hurtle us towards the Singularity” feel, though I don’t buy it for a minute. SlideShare, where it is hosted, is a pleasant medium-attention-span kind of place, with all sorts of random and fun slidesets.

Finally, I am pleased to find that LittleBIGPlanet is just as gorgeous as it looked like it would be. I’ve played myself for only a bit, but walking by when my kids are playing I find I have to stop and stare.