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.

4 comments

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.

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.

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