First day of work, so here are a few from coworkers and others:
- Naty passed on this blog post about RGBD, a compact way of storing HDR environment map colors.
- Gamasutra has an excerpt from Game Engine Architecture, a book we’ve mentioned before. Added bonus info on the author, Jason Gregory: he was a lead programmer on Uncharted 2 (which my older son loves, as do many others).
- Manny Ko mentioned the free program Mendeley, which he swears by for organizing his PDF collection of graphics papers. I’ll look into it once I’ve reloaded everything after my Windows 7 upgrade.
- Physics in graphics? Here’s one person’s extensive collection of abstracts through 2005.
- From Nicholas Wilt, interesting to hear how one brokerage firm is now using GPUs to run complex simulations for bond prices. That GPU Gems chapter on options pricing was prescient.
- Speaking of brokers and lots of GPUs, there’s this article. I’m a little skeptical of a GPU cloud for graphics (vs. running OpenCL), since graphics cards are not quite interchangeable parts at this point. Also, CPUs don’t normally need driver updates, GPUs do. OTOY I’m super-skeptical about, I have to admit, though I’d love to see them pull it off. Anyway, fun to think about situations where network bandwidth > graphics compute power and cloud cost < local cost.
- One more from the demoscene, Farbrausch’s The Cube – interesting effects, what looks like procedural clips and procedural surfaces using interior mapping. At least, that’s my guess. I wish they would spend a little time explaining what they did, though maybe that would ruin the magic.
I bet the Cube is rendered as a simple set of slices, front to back, for each of the three cube face axises. The shapes would arise from a procedural texture on the alpha channel. This would also generate a proper z buffer for use in the SSAO in the demo.
The complicated shaped walls later in the demo could be sets of misaligned slices, using the stencil to alternate visibility between cells in order to make the wall boundaries not match.
The warped coordinate system in some of the later sequences looks like it’s done with brute force tessellation of the slices followed by warping in the vertex shader. This is also consistent with the framerate slowing for those parts, no matter what the resolution.
The idea of it being rendered as a series of slices is also supported in the readme, which mentions the demo as being fillrate hungry. It also mentions vertex textures, which suggests that much of the noise is seeded through vertex lookups. It also makes a lot of use of Voroni distance, seeded by most likely a single random point for each cell, probably looked up from a texture – I think I see some repetition. These are probably in two dimensions, mapped to each slice.
Also in effect are bloom and depth of field.
Hi, I’m Fabian ‘ryg’ Giesen, one of the coders involved in “the cube”. Chaos (who did the effect) actually wrote a small explanation on our homepage (http://www.farbrausch.de/prod.py?which=167). Start there :).
During the first few parts, the number of triangles being drawn is actually in the hundreds (500 or so). The parts that also “wobble” the grid mesh use a tesselated version with a lot more vertices, but that’s not the reason for the slowdown – the wobbling causes a lot more overdraw in a scene that is already very fillrate intensive and incompatible with hiearchical Z. Not good. And yes, the wobbling uses vertex textures as displacement maps.
No need to do any stencil tricks to get the irregular slices; that mesh is generated from a cube by repeatedly clipping one of the active polyhedrons against a randomly chosen plane.
There’s no particular reason for the Voronoi distortion pattern except that it looked nice. As you correctly suspect, it’s using a texture anyway, and we simply tried a lot of likely (and some unlikely) suspects and this is what ended up looking best overall.
I have to admit I just looked at the YouTube video (my current GPU has enough problems with overheating), so didn’t see the readme. Thanks, guys – getting some explanation makes the demo even better.
I recently came across this 2008 OpenGL extension for 9-bit mantissa, 5-bit shared exponent (“Ward format”) RGB textures:
http://www.opengl.org/registry/specs/EXT/texture_shared_exponent.txt
It’s my new favorite format. At 32 bits, it has the same bandwidth and cost (on GeForce 280, at least) as RGBA8, you can use it as a render target, and this is enough precision to do HDR rendering and textures. It isn’t a compressed format, but other than that…pretty much awesome. Especially since your LCD display only has about 6 fixed point bits per channel anyway 🙂
-m