Molly Rocket

[Won]

[icastano]

[NocturnDragon]

Jon Olick will talk about Id's raycasting on sparse octrees tech at Siggraph.

http://ompf.org/forum/viewtopic.php?f=3&p=8319

[NocturnDragon]

Paper is now available here:

http://s08.idav.ucdavis.edu/olick-current-and-next-generation-parallelism-in-games.pdf

Any comment?

[sean]

unfortunately, they're slides, not a paper, which makes it nigh impossible to figure out what's being proposed.

Also, I think I'm back to disbelieving in it. I note that both of the example images aren't textured. One of the big problems with the voxel representation is that you give up bilinear interpolation, and I think that's going to induce some pretty hideous artifacts.

I've argued this before, possibly on this forum: texture mapping so quickly dominated and is successful because there is a clear 1-to-1 mapping between small 2d screen areas and 2d areas on polygonal geometry, and texture mapping offers well-defined ways to smoothly and continuously provide detail on those 2D elements of the world so that detail maps directly to the 2D area of the screen and is thus cleanly able to be defined. A post-process blur is just a hack.

For voxels, there are a number of approaches to mapping them to 2d elements:

• Splatting provides continuous smoothness, but only by inducing unnecessary blur, it has anistropy problems, etc.
  
• Converting to isosurfaces (but he doesn't seem to be talking about doing that, and you sill have some issues for nicely mapping your colors onto that surface, and from thence to pixels)
  
• Treating each voxel as a little cube of a given color (what I think id is doing, which is why I think it's probably actually hideous)
  
• Treating each voxel as a little cube, and allowing a different color on each corner of the voxel (this might give reasonable result, although transitions between voxel miplevels is a pain)
  

Ah yes, I did say this before in this thread.

[sean]

Here's an example.

In the paper, he says they believe they can compress the positional data down to 1.15 bits of data per voxel. You can see how that makes it compelling if you're doing fully-unique texturing: having fully-unique positional data per texture sample isn't that much overhead.

Then he uses the examples of "160 bits per triangle" and "80 bits per triangle" for comparison, although I guess he really means per vertex. But then he calls the first a "2.2:1 compression ratio" and the second a "1.1:1" compression ratio, and I have no idea what he means. Maybe we're assuming two triangles cover an 8x8 block of texture, and that's the ratio comparing voxels to triangles?

But, anyway, the whole thing just totally ignores the possibility of, e.g., displacement maps, which only require 8 bits of positional data per texel sample, while still letting you use a triangle pipeline and bilerping and all that good stuff.

[Zaphos]

I like the "Infinite Surface Detail" slide -- if we could adapt some sort of multi-scale texture synthesis to voxels and get infinite detail, that seems quite neat! (Of course -- I'm not saying practical, just neat.) Also, then we can just recursively evaluate the voxels until we have multiple in a single pixel, and we seem to brute-force past the interpolation issues ...

[ryg]

[Zaphos]

[ryg]

[sean]

There is a valid point here: real supersampling will give you... something. But the cost of, say, 16x supersampling is pretty enormous.

(On the other hand, I think we really need to go there in the long run rather than expect people to analytically band-limit their pixel shaders.)

But here's the thing. Doom was "rock solid" in one sense, because it was sub-pixel precise. That gave it a solidity that most of its contemporaries lacked. But it was still point-sampled. And it looks like this would be pretty similar.

So why isn't 16x super-sampling enough? Well, let's look at bilinear filtering. If you take just the 1d case, the way people normally think of bilinear filtering is that you're making a sort of piecewise-triangle wave signal, and point sampling it. You define your texture to be this nice C1-continuous function, and point sample it.

However, there's a totally different way to look at bilinear sampling. If you instead consider your texture to be made out of lots of little constant-colored squares--in other words, the continuously-defined reconstruction of your texture has C0 discontinuities at every texel edge--then the process of computing a bilinear filter at any given point is the process of computing an analytic box filtering of a 1x1-texel-sized box positioned in that location, partially overlapping 4 different constant-colored square texels.

Now, that's not going to be an exactly pixel-sized thing, and it's treating the underlying data as weirdly discontinuous, but I actually think this is the right way to best understand why bilinear filtering is so important. (On magnification, though, the 1x1-texel-sized box is nothing like the size of a pixel, and so the interpretation is much more apparent, and I think that's why people don't tend to think of it this way. But magnification is the lame, bad-looking case!)

If you rotate the camera infinitesimally, every pixel on the screen changes value slightly. If you rotate it infinitesimally again, everything changes again. Keep repeating, and eventually the original scene has been shifted over by a pixel (to a first approximation).

If you have 16x subsampling, you don't get this effect at all. As you move the camera so the contents of one pixel migrates over to the adjacent pixel, there are at most only 16 intermediate values the pixel can undergo. That's better than 1, but I doubt it's good enough to look clean.

I'm not sure how many multisample locations Pixar uses for their renderings (which are generally totally aliasing/artifact free). But they use micropolygons that are approximately pixel-sized (not sub-pixel sized!), and gouraud shade the micropolygons to get a similar effect. (On the other hand, the micropolygons have an advantage that they are coherent in object space as things move around, instead of being evaluated at arbitrary locations like pixel shaders are; this aspect of it is closer to a voxel evaluation, since both are object-space.)

Again, if you defined colors at the corners of voxels, and drew each voxel face as a little pair of triangles, I bet you'd get perfectly acceptable visual results (with sufficient multisampling). The problem is that it seems pretty expensive to try to bolt that onto a raycasting engine.

[Won]

I think I agree with you, Sean, but I don't really follow your argument. So there are a bunch of ways of looking at tent filtering, but they all seem pretty equivalent. I don't see the "aha" from thinking about it in terms of one factoring of box convolutions over another. If anything, talking about gouraud-shaded micropolys or voxels sounds more like pixels sampling the C1 continuous curve rather than box convolution?

Also, I wonder how effective more sophisticated reconstruction filters would be to make supersampling look smoother. ATI is already doing wide, edge-detecting filters for multi-sampling that are supposed to be pretty good.

So, reading through the slides (this time paying attention to the annotations), I'm not sure I believe that even the ID guys are really 100% behind this idea. I mean, they could still decide to render their characters traditionally. And there was that thing about laying down coarse geometry to avoid a bunch of octree traversal. I imagine as soon as you're doing that, you could figure out a way to eliminate all of it, doing some kind of displacement mapping on crack.

[Zaphos]

Thanks for the explanations, ryg and Sean!

Sean's argument made sense to me ... although now I'm curious to see exactly how noticeable having 16 intermediate values would be.

[TomF]

[sean]