Possible D3D10.1 antialiasing idea... (feel free to shoot me down here)

[Graham]

Ok.

Firstly, I don't have vista OR a D3D10.1 capable video card (xp x64 & 8800 here ). So this is just a theory. A theory that I'm happy to know already exists too

Anyway. I've been working a lot with raw ccd images recently, and I thought about a way to apply some of this to anti-aliasing.


Anyway. Here is the idea:

In the ccd world, most sensors have the following pixel layout:

However most LCD displays are more like:

My understanding is that D3D10.1 allows you to control the MSAA resolve step (and the sample grid?)...

So for the antialiasing resolve, instead of doing:

// ignoring gamma correction, etc
resolve.rgb = (sample[0] + sample[1] + sample[2] + sample[3]) / 4;

Why not do:

resolve.r = sample[0].r;
resolve.g = (sample[1].g + sample[2].g) / 2;
resolve.b = sample[3].b;

So given a rotated grid of 4 samples:

Output them such that sample 0 goes to red, 1 & 2 go to green, 3 to blue.

Or more accurately, push 1 into red a bit, and give some 2 to blue.

resolve.r = (sample[1].r + sample[0].r * 3)/4; 
resolve.g = (sample[1].g + sample[2].g) / 2;
resolve.b = (sample[2].b + sample[3].b * 3)/4;

In effect, what cleartype does with text, but done with anti-aliasing.

Furthermore, with a higher sample count you can bias away from blue - given blue is significantly less important colour. 6 samples might work quite nicely.

 

[digitalwanderer]

Wrong, blue is the MOST important colour silly!

The rest of it is interesting though, even if I don't get it.

 

[Andrew Lauritzen]

Wrong, blue is the MOST important colour silly!

I thought this whole algorithm seemed a bit NVIDIA-biased, leaving AMD and Intel out on the perimeter as it were

Interesting idea, but not knowing much about LCDs and display technology I don't know whether there's some obvious flaw with it I'll contribute though that maybe you'd want to linearly interpolate the contribution (i.e. splat) of each MSAA sample to the adjacent colour cells rather than just choosing the nearest one to avoid flashing or banding.

You can actually do a manual resolve in D3D10 as well, although you can't query the hardware or assume standard sample positions (that's 10.1 only IIRC).

 

[TimothyFarrar]

Quite an interesting idea, but probably won't see this in anything for a while. Might work well on PC's as long as output resolution matches display native resolution, but for HDTV and upscaling issues with consoles (ie 360) you would get what appears as chromatic aberration...

 

[Simon F]

Hi Graham,
Some years back I experimented with this sort of thing but, IIRC, the gain was very small - in fact most didnt notice any difference apart from a slight decrease in colour fringes on, say, rectangles.

IIRC you also need to make your per-channel filters wider to stop strange colour effects.

 

[Davros]

why does a ccd have 2 greens ?

 

[Simon F]

why does a ccd have 2 greens ?

Because the eye is more sensitive to the luminance and green is the largest influence.

 

[Xmas]

Furthermore, with a higher sample count you can bias away from blue - given blue is significantly less important colour. 6 samples might work quite nicely.

I don't know what you mean by "bias away from blue" but it's important that the total contribution of each color channel stays the same. You don't want hue shifts.

Also, the filter support needs to be at least one pixel wide for each channel in order to avoid sampling gaps. So you need to have at least four samples contribute to each channel. For a simple box filter you could take the red channel of the rightmost sample of the left neighbour pixel, and the blue channel of the leftmost sample of the right neighbour pixel:

resolve.r = (left[3].r + mid[0].r + mid[1].r + mid[2].r) / 4.0;
resolve.g = (mid[0].g + mid[1].g + mid[2].g + mid[3].g) / 4.0;
resolve.b = (mid[1].b + mid[2].b + mid[3].b + right[0].b) / 4.0;