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

Graham

Hello :-)
Veteran
Supporter
Ok.

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

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:

ccd.jpg


However most LCD displays are more like:

lcd.jpg


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:

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

Why not do:

Code:
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:
samples.jpg


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


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

Code:
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.
 
Last edited by a moderator:
Wrong, blue is the MOST important colour silly! :p
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).
 
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...
 
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.
 
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:
Code:
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;
 
Back
Top