New demo

[Humus]

There's a new demo on my site that implements supersampling from the application utilizing the accumulation buffer. From a technical point of view it's nothing new, but if you use it together with multisampling in the driver control panel it should give you sort of an unofficial preview of how the new SuperAA modes might look like.

Screenshot:

(Yes, it looks very similar to an older demo I did, this is just a quick modification to that)

Grab it at the usual place:
http://www.humus.ca/

 

[Moloch]

8)

 

[CMAN]

Quick question....Why does turning up the samples make the textures sharper?

 

[Humus]

That's what supersampling does, given that you also adjust the LOD, which this demo does. With more samples, you can essentially use a higher mipmap level without getting aliasing.

 

[tEd]

Could you provide the sample patterns?

2x        4x            11x

*       *     *
                        ?
*       *     *

Why such a odd number(11)?

 

[Xmas]

Use the source, tEd.

// Rotated grid sample pattern
static vec2 samples2[] = {
	vec2(-1,  0.333f),
	vec2( 1, -0.333f),
};

// Rotated grid sample pattern
static vec2 samples4[] = {
	vec2(-0.333f,  1),
	vec2( 0.333f, -1),
	vec2(-1, -0.333f),
	vec2( 1,  0.333f),
};

// Sparse grid sample pattern
static vec2 samples11[] = {
	vec2( 0.8f, -1.0f),
	vec2(-0.2f, -0.8f),
	vec2( 0.2f, -0.6f),
	vec2( 1.0f, -0.4f),
	vec2(-0.6f, -0.2f),
	vec2( 0.0f,  0.0f),
	vec2( 0.6f,  0.2f),
	vec2(-1.0f,  0.4f),
	vec2( 0.4f,  0.6f),
	vec2(-0.4f,  0.8f),
	vec2(-0.8f,  1.0f),
};

Those sample positions are bad, Humus. -1.0 and 1.0 are exactly on the edge of a pixel, so you get blur. For a proper sparse grid, you should always use some position like
(x * 1/N + 1/2N) / pixel width.
In fact, you can drop the + 1/2N part if you like (but that will shift the scene a bit).

These should give better results:

// Rotated grid sample pattern
static vec2 samples2[] = {
	vec2(-0.5f,  0.5f),
	vec2( 0.5f, -0.5f),
};

// Rotated grid sample pattern
static vec2 samples4[] = {
	vec2(-0.75f, -0.25f),
	vec2(-0.25f,  0.75f),
	vec2( 0.25f, -0.75f),
	vec2( 0.75f,  0.25f),
};

float rcp11 = 2 / 11.0f;

// Sparse grid sample pattern
static vec2 samples11[] = {
	vec2(-5 * rcp11,  2 * rcp11),
	vec2(-4 * rcp11, -5 * rcp11),
	vec2(-3 * rcp11, -1 * rcp11),
	vec2(-2 * rcp11,  3 * rcp11),
	vec2(-1 * rcp11, -4 * rcp11),
	vec2( 0 * rcp11,  0 * rcp11),
	vec2( 1 * rcp11,  4 * rcp11),
	vec2( 2 * rcp11, -3 * rcp11),
	vec2( 3 * rcp11,  1 * rcp11),
	vec2( 4 * rcp11,  5 * rcp11),
	vec2( 5 * rcp11, -2 * rcp11),
};

 

[nAo]

That's what supersampling does, given that you also adjust the LOD, which this demo does. With more samples, you can essentially use a higher mipmap level without getting aliasing.

Well..even without biasing the LOD you get higher mipmap levels with supersampling since partial texture coordinates derivatives get smaller if rendering resolution goes up.

 

[Xmas]

Well..even without biasing the LOD you get higher mipmap levels with supersampling since partial texture coordinates derivatives get smaller if rendering resolution goes up.

But only if it goes up. When you render multiple jittered images instead you have to simulate this effect by using LOD bias.

 

[Humus]

Why such a odd number(11)?

No particular reason other than that I had an 11 sample sparse sample pattern available from other stuff I've been doing and I'm too lazy to work out a 8 or 16 sample one. I just threw this demo together in 30 minutes. The particular feature of that sampling pattern is that one of the samples is exactly in the center (that's why I needed an odd sample count), which was needed for the SoftShadows2 demo for instance.

. . . . . | . . . X .
. . . . X | . . . . .
. . . . . | X . . . .
. . . . . | . . . . X
. . X . . | . . . . .
----------X----------
. . . . . | . . X . .
X . . . . | . . . . .
. . . . . | . X . . .
. . . X . | . . . . .
. X . . . | . . . . .

 

[Humus]

Those sample positions are bad, Humus. -1.0 and 1.0 are exactly on the edge of a pixel, so you get blur. For a proper sparse grid, you should always use some position like
(x * 1/N + 1/2N) / pixel width.

Now that I give it another thought, you're right. I actually started out that way, then I changed it. Oh, well, I uploaded a new version of the demo. The visual difference is minimal though. I couldn't spot any difference at all.

 

[digitalwanderer]

Nice demo Humus, thanks!


/me waits for patch that lets me apply this to games...

 

[Temporary Name]

It's a nice way of testing the combined effects of MS+SSAA, but I think the environment should be more "contrasty" for this purpose.

The textures are all very mellow and the scene lighting tends to create low contrast. I had to fly around for a while to find a view that would clearly show the difference between 2 and 4 sample SSAA, even without any MSAA.

 

[Guden Oden]

No particular reason other than that I had an 11 sample sparse sample pattern available from other stuff I've been doing

Why is it so irregular? The upper right and lowe left quadrants are mirrors of each other, but not the upper left and lower right are not (more like inverted, but not).

A diagonal line going through the upper left corner to lower right would not be antialiased the same way as a line going through upper right to lower left. What's the logical reason for this assymetry?

 

[Xmas]

Now that I give it another thought, you're right. I actually started out that way, then I changed it. Oh, well, I uploaded a new version of the demo. The visual difference is minimal though. I couldn't spot any difference at all.

Ah, that is much better

 

[Humus]

Why is it so irregular? The upper right and lowe left quadrants are mirrors of each other, but not the upper left and lower right are not (more like inverted, but not).

A diagonal line going through the upper left corner to lower right would not be antialiased the same way as a line going through upper right to lower left. What's the logical reason for this assymetry?

Actually, they aren't mirrors of each other if you look a bit closer. Two of the samples are mirrored, but not the third (1, 3) and (-2, -4). Those that mirror each other are merely coincident.

It's supposed to be irregular though so that any angle through the pattern doesn't line up with more than at most a couple of samples. That's what makes ordered grid look bad at vertical and horizontal angles, the samples and the edge lines up so that it doesn't go smoothly like 0,1,2,3 but rather goes like 0, 2, 4 if you understand what I mean.

 

[Xmas]

To expand on Humus' point, here are some very regular sparse sample patterns (up to 16x):

The red ones are those that form a rotated and skewed grid over the whole screen. The blue ones are those where the "lines" don't exactly continue over pixel borders.

In screenshots those patterns will look very good, maybe with the exception of some thin lines (e.g. antennas, electricity lines) that are exactly aligned with the pattern grid.

In movement, however, those edges aligned with the pattern grid will not move completely smooth, e.g. even with the 16x pattern there are situations where such a moving edge will only jump between 3 intermediate steps.

Here are some irregular (well, some aren't) patterns that should give very good results in any situation:

 

[nAo]

Wow Xmas, do you design sampling patterns for a living?

 

[Ailuros]

Wow Xmas, do you design sampling patterns for a living?

I'm actually wondering for quite some time now, how come no company has not employed him yet. That means if he actually can or wants to at the moment.

 

[_xxx_]

Wow Xmas, do you design sampling patterns for a living?

I'm actually wondering for quite some time now, how come no company has not employed him yet. That means if he actually can or wants to at the moment.

We thought about it, but he's spending too much time in some discussion forums...

 

[Mark]

To expand on Humus' point, here are some very regular sparse sample patterns (up to 16x):

The red ones are those that form a rotated and skewed grid over the whole screen. The blue ones are those where the "lines" don't exactly continue over pixel borders.

In screenshots those patterns will look very good, maybe with the exception of some thin lines (e.g. antennas, electricity lines) that are exactly aligned with the pattern grid.

In movement, however, those edges aligned with the pattern grid will not move completely smooth, e.g. even with the 16x pattern there are situations where such a moving edge will only jump between 3 intermediate steps.

Here are some irregular (well, some aren't) patterns that should give very good results in any situation:

I notice that there is only 1 sample position per row and column. If that was intentional, would you mind explaining to me why? Does it have to be that way for a sample pattern or is it that way simply because it is the optimal approach?