Best FSAA metod

[NocturnDragon]

What do you think is the best FSAA metod?
I know this is not a new topic and there have been lots of discussion about this already. I just would like to know the latest impressions.

[Kristof]

Best currently available on consumer hardware or in general ?

[psurge]

How about:
1. best in general
2. best on consumer class hardware
3. best on high-end visualization hardware
3. best on Bill Gates/goverment level income class hardware

:p

[jb]

Whoa,

what a loaded question. How's this for an answer. There is not any one best. Each have advantages and disadvantages depending on the application. For most people that application means games. But it does not have to be. For more complex work (AutoCAD, 3d aminmations or other computer high res work, ect) speed is not so much as important as over all alasing removal.

It all comes down to the good'ol engineer trade offs. For games is speed vrs alasing removal. And even in hardware you have to the trade off of the level of AA and method vrs how much die size (transistors) you want to dedicate to do the AA. Believe it or not the V5 has some dam good AA and is really hard to beat thanks to its RGSS method. However it is slow, very slow by today's standards. Current forums of MSAA from nVidia do not address texture alsisng and do no AA against Alpha Textures (except the 4s mode which does "some"). But nVidia's method is the most efficient in terms of speed vrs IQ for us gamers. Ands its pretty good. ATI's method is, well...kind of weird. Its a super sampling method so its slower than nVidias, but its still 100% unclear if its working as it was advertised. So for the gamer there is no one best. You have to ask your self what do you want it to do, can you live with the disadvantages and what price are you willing to spend.

Jb

[Tagrineth]

Best current consumer is definitely 3Dfx's J-RGSS.

Best theoretical is ATi Smoothvision, but why it isn't quite working as well as it should is anyone's guess (on a friend's 8500 I noticed it takes 6xQuality to look as good as my old V5's 4x).

Best current high-end is 3DLabs SuperScene.

Best 'prayer' method (Bill Gates Budget?) would be one which doesn't even point sample like that, it uses the graph of the vectors and the intersection points to determine the exact % of each texture colour within the pixel, then add or subtract .2-.5% at random from each colour to get a small inaccuracy and remove patterns (sort of like what J-RGSS does). Woo, I wonder if anyone's thought of that before...

And the worst ever AA method? OGMS. Blech.

[NocturnDragon]

Yeah i know i wasn't too clear on that question.
I meant what would the best on consumer class hardware in the upcoming months (or even couple of years)..

[Sharkfood]

I'd like to see an FSAA algorithm that matches SGI's current realtime AA methods on some of their workstations.

For those unfamiliar, this uses a multisampling/primitive method- not too unlike NVIDIA's RGMS modes, but at a higher sampling rate... then adds antialiased *textures* for fill. This allows supersampling of textures during the mipmap process.

I'd also like to see more clever technologies using same-scale sample buffers (a-buffer samples) as much performance is lost during direct buffer handling (i.e. proper scaling to sample size) as well as clever usage of DAC for the averaging versus matrix/sample averaging. Losing overhead from these two necessities should allow for better framerates for supersampling methods.

I also think 1:1 ratio post-filters should be done away with entirely. Quincunx and ATI's performance modes both operate on the same-scale with post-filters and while this can offer smoothing, the detail loss is almost self-defeating.

And lastly, I'd like hardware that is flexible. Rotated/jittered sample patterns versus static or dynamic ordered sample patterns all have their benefits. Such future AA hardware should offer end-user flexibility for controlling the sample pattern, be it from a 3-way toggle or more.

[aths]

The "best" AA method is doing "real AA" by calculating the exact coverage for every polygon for every pixel.

The best AA that we can pay for is may be 8x RGMSAA with a difference buffer (aka pseudo compression).

But there is no general best AA method for everything. Sometimes I wish the (RG) supersampling method back. Sometimes it worth to pay in lower framerates for supersampling, sometimes not.

As far I understand, AA is not quite easy to really understand.

[SA]

Anti-aliasing is a broad subject that is not limited to 3d graphics. In fact, much of the original research was done for sound processing.

There are several things to consider when evaluating the effectiveness of an anti-aliasing mechanism at removing aliasing. These include the filter shape, the filter size, and the continuity (sampled versus analytical input and filter function).

In addition to effectiveness you must also consider bandwidth and computational requirements.

For analytical input such as procedural textures the most effective anti-aliasing technique is to use an analytical windowed sync filter kernel such as the Lanczos3 sycn filter (spline based). This is not practical yet for real time 3d.

For sampled input such as traditional sampled textures, true analytical filters are not an option and some form of sampled anti-aliasing must be used. Two of the best sampling anti-aliasing techniques are stocastic jittered sampling and sparse supersampling.

Stocastic jittered sampling is better when a large number of samples (say >32 in the kernel) is used.

Sparse supersampling works better for a smaller number of samples (say <= 32) since it provides a better use of samples at near horizontal and near vertical edges. Rotated grids are a simple mechanism that achieves some of this, however sparse supersampling provides even better use of the samples than a simple rotated grid. For instance, for 16 samples an ordered grid provides only 4 levels of gradation for near horizontal and near vertical edges, while a rotated grid will provide more gradations at these angles is has a similar problem to ordered grid at other angles. 16x sparse supersampling however provides 16 levels of gradation at all edge angles. Thus all the samples are fully utilized to provide graduated colors at all edge angles. When the number of samples gets high enough, it can be worthwhile to use a better filter shape (weighted) than a simple box filter.

Multi-sampling eliminates much of the high memory bandwidth costs by using the same surface color for each surface sample in a pixel (so the color is only calculated once per pixel rather than once per sample), but it only anti-aliases edges and requires special handling to properly deal with alpha blending. It must be coupled with anisotropic filtering of the textures for complete anti-aliasing of the scene. In this case, multi-sampling only processes the sample z values at the edge pixels, while anisotropic filtering only processes the sample color values at the interior pixels thereby eliminating much of the processing.

Anisotropic filtering has also been the focus of a lot of early anti-aliasing research. This is an efficient mechanism for anti-aliasing textures since it doesn't need to store or compare the z values at each of the sample points, eliminating this cost for all the interior pixels. The best forms of anisotopic filtering use adaptive, jittered sampling based on the degree of anisotropy and using a weighted filter kernel. It also requires some special handling to properly deal with alpha blended transparency.

Supersampling (using say either sparse supersampling or stocastic jittered supersampling techniques) provides a slightly better quality than a combination of multi-sampling and anisotropic filtering for the same number of samples per pixel and using the same sampling technique since it properly deals with variations of color within a pixel and properly deals with transparency with no special handling (assuming the surfaces were ordered properly when rendered). However, it comes at a very high cost in memory bandwidth and processing bandwidth, usually far too high for the slightly added benefit on current 3d hardware.

[SA]

The issue of anisotropic filtering and alpha blending points out a more general problem of anisotropic filtering and pixel shaders in general.

To properly anti-alias a pixel shader function (be it alpha blending or any other pixel shading function) it is necessary to perform the pixel shading function at each sample point in the pixel and then average (usually weighted) the result. Filtering the input samples separately and performing the pixel shading once for the pixel on the resulting filtered inputs gives the wrong results.

While performing pixel shading at each sample point in a pixel is expensive, it is still much cheaper than super sampling since the z values still do not need to be processed.

Hopefully, at least some of the 3d hardware vendors will properly implement anisotropic filtering with pixel shaders.

[NocturnDragon]

Thank you for the answers everything i clearer now..
But I am still waiting for a answer from Nappe1. :)

[mboeller]

How about using "Discontinuity Edge Overdraw"?
I just found this at the page from Hugues Hoppe (microsoft). This is an form of edgeAA only, but according to the pdf; the "cost" is low. So this could be an cheap form of MSAA (together with anisotropic filtering the quality of the final image could be really good).

"Discontinuity Edge Overdraw" uses AAed lines to AA the edges of objects only (should look like the modells in outcast). The visibility sorting is done with an/the Z-buffer. The drawback of this scheme is, that small features look bloated. See the ship on the last page of the pdf.

Manfred

Link : http://research.microsoft.com/~hoppe/overdraw.pdf

[Nappe1]

NocturnDragon: why you are waiting my answer? :)
well, to be honest I know why you are waiting my reply, but I am sorry, I can't comment it yet. As I said at MURC, G800 and Avalanche made me cautious, so no exact infos from me in this case. Just hints, so you have to just wait for product launch. (besides, I am even not sure if my infos are 100% correct...)

[Fred]

I'm curious, why cant there be some type of noise based multisampling?

[MfA]

mboeller: NVIDIA used that in their drivers in the bad old day's ... anyway, thats really something the developer has to concern himself with. The hardware usually doesnt know where edge's are, drivers can make guesses but the whole thing is just icky.

If the hardware were to know where edges were it could do one better, it could just mix the pixel on the edge with the pixel opposite the edge based on the coverage ... no need to extend the edges a pixel further. Still will have some artifacts, but wont make objects fat and is independent of the software.

[SA]

As mentioned above, to properly anti-alias pixel shaders you must process the pixel shading at each sample point and then filter the final result.

Although using correct anisotropic filtering alone eliminates sample z processing of the textures, as soon as you couple it with multi-sampling to create complete anti-aliasing it ends up requiring the same amount of texel processing, pixel shader processing, z processing and memory bandwidth as equivalent supersampling to produce the same quality results.

The brings up another important point. As soon as you use any short cuts in anti-aliasing that eliminate some visible information you end up with unwanted artifacts in the image. For instance, mip-mapping shortcuts processing by using pre-filtered images that assume the surface is normal to the viewer, thereby not accounting for that information when that is not the case. This produces excessive blur as an artifact in the image for off-normal surfaces. Standard anisotropic filtering performs additional processing to rectify this artifact by adaptively anti-aliasing the texels at run-time for each texture but avoids shader functionality at each sample. This eliminates the blur due to off-normal surfaces but still creates artifacts whenever the pixel shader functionality creates high contrast results within a pixel.

For high quality sampled anti-aliasing under all circumstances there is really no escape. You need to fully and correctly process the image at each sample point and then filter the final result.

For high performance you need to efficiently eliminate all the hidden information and use high bandwidth, on-chip memory with parallel sample processing. This is easier for tilers and chips using embedded RAM, though it still requires high external memory bandwith for the texel access at each sample. Somewhat similar performance can be approached using immediate mode renderers with external RAM by using a combination of hierachical z buffering, an on-chip hierarchical z cache, multiple parallel z testing per pixel, and by encouraging developers to implement two-pass application-driven deferred rendering (by sending unshaded geometry on the first pass that fills the z buffer, and shading only the visible geometry on the second pass).

[jb]

SA,

thanks for the information.

[mboeller]

mboeller: NVIDIA used that in their drivers in the bad old day's ... anyway, thats really something the developer has to concern himself with. The hardware usually doesnt know where edge's are, drivers can make guesses but the whole thing is just icky.

Thanks; I didn't know that Nvidia had implemented something like this in their old drivers. I thought the "Discontinuity Edge Overdraw" is an hardware-implementation (done in software) because they talk about 2x2 supersampling too, and that their approach is better. An pure software-approach would suck IMO.


If the hardware were to know where edges were it could do one better, it could just mix the pixel on the edge with the pixel opposite the edge based on the coverage ... no need to extend the edges a pixel further. Still will have some artifacts, but wont make objects fat and is independent of the software.

An deferred renderer should at least know the polygon-edges (vertex-buffer for the tile), has all the Z-buffer information at hand and all the texture's cached too if additional blending operations are needed. So why has no one tried to do this "Discontinuity Edge Overdraw" edgeAA or Your approach ? Has it drawbacks? Does it not work with transparent surfaces etc.. ?

[darkblu]

If the hardware were to know where edges were it could do one better, it could just mix the pixel on the edge with the pixel opposite the edge based on the coverage ... no need to extend the edges a pixel further. Still will have some artifacts, but wont make objects fat and is independent of the software.

actually, there's a very simple primitive-based solution:

all that is needed to be done is for the hw to move the triangle's open egdes 1 pixel out, and you won't get cross-span artifacts when doing coverage calculations w/ concatenated primitives. behold:

a triangle span (as we're talking scan-conversion here) is closed from one side and open from the other, say [ , ). now, if we had two neighbour spans s0 (x0, x1) and s1 (x1, x2) from two neighbour primitives t0 and t1 we'd have:

[x0, x1) [x1, x2) - note that s0's last drawn pixel falls strictly within t0's interior, whereas the first pixel of s1 (the one at x1) may or may not be completely within t1's interior (depending on the (shared) edge slope), thus if our antialiasing is coverage-based we'd get t0's right edge of 100% primitive's color, and t1's left edge as < 100% primitive's color, i.e. we'd get a possibly visible edge between the otherwise concatenated primitives. this is a bad thing(tm).

now, this all can be avoided if when our edge antialiasing mode is enabled, primitives were taken as non-open-endian, i.e. spans would be:

[x0, x1] [x1, x2]

naturally, same rule could be applied to the vertical openness of the primitives.

[Sodiumlightbaby]

The underlying problem with AA in computer graphics is that we are trying to sample a description rather then an analogue signal.

In the art of signal processing it is well known that you can recreate any sampled signal if you sample at twice the rate of the highest frequency component of the original signal (presuming no quantification). Filtering the signal before sampling assures that no frequency component violates the alias free envelope. If we let signals violate the alias free envelope, we will, by trying to sample them, interpret higher frequency components as lower frequency components or "aliases". Keeping the recreated signal totaly free of aliases is what is know as anti-aliasing.

When we sample a polygon we basically ask "Is this sample point inside or outside the polygon?". This gives you an infinitively steep (90 deg) drop from "Here it is" to "Here it isn't". To know exactly where the drop is, we would have to use an infinitively high sampling rate. Any lower sampling rate than this will cause aliasing.

So technically we don't "antialias" when we sample a descrete description with higher sampling rate, we just push the aliasing higher and higher in the frequency spectrum. Reordering the sampling points in different configurations (OG/RG/JG) just helps with unifying the sampling rate along different xy directions. So why do we do it? Because it is easy to make fast and cheap implementation using this technique.

In real life OTOH, pushing the aliasing higher up the spectrum really enhances the IQ, and there might be a point where we no longer will be able to tell it's there. And the term "anti-aliasing" has been used for this technique in CG since the 70's so I have no plan to start a personal crusade to change the CG jargon - I'll leave that to the marketing department of the company to first release a TruAA(tm) enalbled chip in the open market.

[MfA]

Dark, a solution to what? I didnt say you'd get bleed through, I said everything would get "fat". We are saying the same thing really (the silhouette edge at x2 in your example gets pushed out).

[darkblu]

Dark, a solution to what? I didnt say you'd get bleed through, I said everything would get "fat". We are saying the same thing really (the silhouette edge at x2 in your example gets pushed out).

a solution to the problem of hw's not knowing the surface's silhouette - my point is that it can be done on a primitive (read triangle) level, not on a surface level.

regarding the issue of surfaces fattening out - it's not exactly true, as no pixels located outside the primitive will get drawn, just that partially-covered pixels will get drawn where only fully-covered were drawn before. it's another matter that those pixels touching the shared edge will be drawn twice - once for each of the primitives, but that's inevitable if we need proper results from the by-coverage blending.

[Bambers]

In the art of signal processing it is well known that you can recreate any sampled signal if you sample at twice the rate of the highest frequency component of the original signal

Wouldn't the samples have to be 'in phase' for that to work. You could end up getting no sound at all in some cases.

[Sodiumlightbaby]

Wouldn't the samples have to be 'in phase' for that to work. You could end up getting no sound at all in some cases.

You are right about the border case. I was a bit unprecise in my reply.

If you take a sinus wave with frequency B and sample it at exactly twice that frequency (2B), you will not be able to distinguish B from 0Hz - you have in fact met the first alias. And even if you choose to interpret 0Hz as B, aliasing screws up the bias and amplitude so you still won't be able to recreate the signal. Just a little skew on the sampling frequency beyond 2B and you should be fine.

So what I should have said is: "you can recreate any sampled signal if you sample at more than twice the rate of the highest frequency component of the original signal". My bad.

[nAo]

If you take a sinus wave with frequency B and sample it at exactly twice that frequency (2B), you will not be able to distinguish B from 0Hz - you have in fact met the first alias. And even if you choose to interpret 0Hz as B, aliasing screws up the bias and amplitude so you still won't be able to recreate the signal. Just a little skew on the sampling frequency beyond 2B and you should be fine.

This is not true, u don't need any skew at all.
When you are working in frequency domain your samples are vectors defined on a functional vectorial space.
Your vector filled with a inifite series of costant values are coefficients for the basis functions. Those functions could be trigonometric, like sine and cosine (Fourier...)
This final function is the reconstructed signal, not just the discrete samples taken on the frequency domain.

ciao,
Marco

[MfA]

a solution to the problem of hw's not knowing the surface's silhouette - my point is that it can be done on a primitive (read triangle) level, not on a surface level.
If on the second pass, when you draw the edges as AA'd lines, you redraw all primitive edges instead of just silhouette one's (which only the developer knows the location of) you are in even worse shape. Not only do edges get fat, internal edges get blurred. As I said, it gets icky if the driver tries to do it.
regarding the issue of surfaces fattening out - it's not exactly true, as no pixels located outside the primitive will get drawn, just that partially-covered pixels will get drawn where only fully-covered were drawn before. it's another matter that those pixels touching the shared edge will be drawn twice - once for each of the primitives, but that's inevitable if we need proper results from the by-coverage blending.
The background color has disappeared for good as soon as you push the edge out. You cannot blend the color of the "partially-covered pixels" with the background color by drawing AA'd lines for the edge's if you already drew the edge to them. The AA'd lines are alway's drawn to the pixel's just outside the edge, thats why you have a choice ... bleed through, or fattening and potentially blurring.

Marco

PS. it just occured to me that if you redraw the silhouette edge's you could also quite efficiently perform a post process blur of pixels opposite the edge based on coverage (ala the ATI patent) with a pixel shader. You need the screenspace normal of the edge pointing to the outside of the primitive in the pixel shader. You render the edges as AA'd lines with the frame as a texture. You compare the coverage to 1/2, if its smaller you invert the normal. You then point sample the texture twice, once with the texture coordinate shifted by the normal, blend them based on coverage and write the pixel.

PPS. hmmm, that would break down at corner points though :( Oh well.

[darkblu]

Marco,

i just realized that the technique depicted in the paper and the one you're talking about is functionally different to the one i was descrinbing (which is pretty much what 3dfx' edge-antialiasing was). sorry, my bad.

[Mintmaster]

The issue of anisotropic filtering and alpha blending points out a more general problem of anisotropic filtering and pixel shaders in general.

To properly anti-alias a pixel shader function (be it alpha blending or any other pixel shading function) it is necessary to perform the pixel shading function at each sample point in the pixel and then average (usually weighted) the result. Filtering the input samples separately and performing the pixel shading once for the pixel on the resulting filtered inputs gives the wrong results.

While performing pixel shading at each sample point in a pixel is expensive, it is still much cheaper than super sampling since the z values still do not need to be processed.

Hopefully, at least some of the 3d hardware vendors will properly implement anisotropic filtering with pixel shaders.

I think for this reason it really is best to just stick with supersampling. Multisampling is just a hack for edges, and not really that much faster than supersampling. With all those drawbacks you mentioned for pixel shaders, the only way you could really get an improved, more accurate picture is by supersampling.

I think ATI is headed in the right direction for AA, as they are trying to improve supersampling to a nice random sampling. However, I don't know how well it currently works.

Personally, I just prefer to crank up the resolution, which is essentially just supersampling as far as the eye is concerned anyway. I would only turn on AA if I had excess framerate at the highest possible resolution.



Do any of you think that temporal jittering may be useful? You may see a bit of wavering or flickering though, so I'm not sure about it's merits. However, at 60 fps it may not be noticeable, and so it'll probably do more good than harm. It may allow a reduction of required samples per frame as well.

In the Radeon 8500 review on Tech-Report they said that it does temporal jittering in quality AA mode, so screenshots couldn't capture the full effect. I don't know how much truth there is to that.

[Sodiumlightbaby]

Thanks for the comment, Marco.

This is not true, u don't need any skew at all.

When I say 'skew' I'm thinking of increasing the sample rate a fraction to avoid the 2B frequency. And all in the ideal world off cource, in the real world you would have do more becuase of limited interpolation filters etc.

I was also picturing,without explicitly saying so, the special case when we sample at exactly 2B and the phase between the signal and the sampling is 0 (mod Pi) (i.e. we just keep hitting signal zero crossings). Any other phase and we will "see" a sinusiod of frequency B but with wrong amplitude (except at Pi/2 and 2Pi/2 where we will get the correct amplitude).


When you are working in frequency domain your samples are vectors defined on a functional vectorial space.
Your vector filled with a inifite series of costant values are coefficients for the basis functions. Those functions could be trigonometric, like sine and cosine (Fourier...)
This final function is the reconstructed signal, not just the discrete samples taken on the frequency domain.

Yes that is true. Frequency analyzis and signal reconstruction are areas that I simplified a lot to make my point more clear - "If you don't take care to match your signal/data to be sampled with the sampling itself, you will probably introduce errors that will stick with you trough the frequency domain and signal recreation".

Here's something to think about. If we say that the target device (screen) has no subpixel resolution (e.g. normal CRTs), we should be able to produce perfect or near perfect anti-aliasing with only ONE sample point in each pixel.

[Bambers]

In the Radeon 8500 review on Tech-Report they said that it does temporal jittering in quality AA mode, so screenshots couldn't capture the full effect. I don't know how much truth there is to that.

THe 8500s AA does not work as it should (ie as it says in their whitepaper) it is mostly just normal ordered supersamling atm.
I don't think dynamically changing the sample pattern for each pixel for every frame would show up too much. ATis dithering in 16bit is dynamic and looks better imo than static dithering.

[darkblu]

Here's something to think about. If we say that the target device (screen) has no subpixel resolution (e.g. normal CRTs), we should be able to produce perfect or near perfect anti-aliasing with only ONE sample point in each pixel.

let us have a pixel which has 50% coverage by a white primitive and 50% coverage by a black primitive. where would you place the sample point? or did i get you wrong?

[nAo]

When I say 'skew' I'm thinking of increasing the sample rate a fraction to avoid the 2B frequency. And all in the ideal world off cource, in the real world you would have do more becuase of limited interpolation filters etc.

I know your 'skew' was intended as a slight increase in sampling rate :)
I just said that to reconstruct the original signal you don't need that skew.
Anyway..you need another thing I didn't mentioned, you need a global phase. Without that phase one can just found something like (e^i*phi)*F(x), the function module remain the same, but obviously that's not a unambiguous recontructed function :) Even if knowing the basis functions you can restrict the global phase domain (to 2 values with sin/cos functions)...


I was also picturing,without explicitly saying so, the special case when we sample at exactly 2B and the phase between the signal and the sampling is 0 (mod Pi) (i.e. we just keep hitting signal zero crossings).

I was specifically referring to that case...


Here's something to think about. If we say that the target device (screen) has no subpixel resolution (e.g. normal CRTs), we should be able to produce perfect or near perfect anti-aliasing with only ONE sample point in each pixel.

Umh..the problem is how to find that special point :)
THat's remind me the contraction point theorem (also called the fixed point theorem) on complete metric spaces.
If one could just proof that the scren space is a complete space with a given metric and if it's possibile to build such a 'AA' contraction operator in that space then it would be possible to find that special point.
I'm wondering about the algorithm complexity...maybe it could be even viable for some high-level AA.
Ok..back to reality.. :wink:

ciao,
Marco

[Simon F]

SodiumLightbaby wrote:
Here's something to think about. If we say that the target device (screen) has no subpixel resolution (e.g. normal CRTs), we should be able to produce perfect or near perfect anti-aliasing with only ONE sample point in each pixel.
I'm not entirely sure why you specifically mention CRTs, but if
the image data could be modelled as a continuous function in X and Y (i.e. replace step functions at polygon edges with very steep segments) and
the image was monochromatic
then I'd imagine that you could "invoke" the Mean Value Theorem to say that there must exist a sample point within each pixel such that the value at that sample point equals the "antialised" pixel value.

I think, however, that you'd need three points for doing R, G, and B since these'd be independant functions of X and Y and there's no guarantee that the three ideal sample points would coincide.

To Na0 (hmm "Sodium Oxide".. any relation to the other poster :P ), I'm afraid I can't remember the my Metric spaces course(s) so I'll won't comment further . :D

[Sodiumlightbaby]

Anyway..you need another thing I didn't mentioned, you need a global phase. Without that phase one can just found something like (e^i*phi)*F(x), the function module remain the same, but obviously that's not a unambiguous recontructed function :) Even if knowing the basis functions you can restrict the global phase domain (to 2 values with sin/cos functions)...

Yes, you are right, if you have global phase or a combination of phase and basis function, you're ok. :D


THat's remind me the contraction point theorem (also called the fixed point theorem) on complete metric spaces.
If one could just proof that the scren space is a complete space with a given metric and if it's possibile to build such a 'AA' contraction operator in that space then it would be possible to find that special point.

Hmm... looks like I'll have to read up on metric spaces....


I'm wondering about the algorithm complexity...maybe it could be even viable for some high-level AA.
Ok..back to reality.. :wink:


It's all the special cases (corners/overlap/texturing etc) that give the greatest challenges. It' might be something for the future. I'll have come back later...


I'm not entirely sure why you specifically mention CRTs,

The main idea was that the sampling could be adjusted to the target pixel layout. Think ClearType for LCDs. I haven't studied it, but just acknowledged that target screen subpixel layout could be exploited.


but if
the image data could be modelled as a continuous function in X and Y (i.e. replace step functions at polygon edges with very steep segments) and
the image was monochromatic
then I'd imagine that you could "invoke" the Mean Value Theorem to say that there must exist a sample point within each pixel such that the value at that sample point equals the "antialised" pixel value.
I think, however, that you'd need three points for doing R, G, and B since these'd be independant functions of X and Y and there's no guarantee that the three ideal sample points would coincide.

There are heaps of problems to figure out, so I think I'll leave it at that now and go back into my thinking hat :wink:


To Na0 (hmm "Sodium Oxide".. any relation to the other poster :P )

Good one :lol: Didn't see it before

[Mintmaster]

THe 8500s AA does not work as it should (ie as it says in their whitepaper) it is mostly just normal ordered supersamling atm.
I don't think dynamically changing the sample pattern for each pixel for every frame would show up too much. ATis dithering in 16bit is dynamic and looks better imo than static dithering.

The only thing is that two adjacent colours in dithering are fairly close, whereas on a polygon edge the colours may be completely different. This would definately make it more noticeable. Whether it would still be unnoticeable, I don't know.

Its a shame about the 8500 AA not working to its ability. Any way of confirming this?

[LeStoffer]

I think for this reason it really is best to just stick with supersampling. Multisampling is just a hack for edges, and not really that much faster than supersampling. With all those drawbacks you mentioned for pixel shaders, the only way you could really get an improved, more accurate picture is by supersampling.


Oh no! While multisampling may just be "a hack for edges" it is still way faster. We need that speed. If we want to "clean up" textures there are other ways to go about doing anisotropic filtering faster like using a texture-engine that can fetch more samples per pass [or cycle] than today (e.g. 32 vs 8 on a Geforce today).

Supersampling gives good image quality but we need to use the available fillrate/pixel shader ops per cycle/memory bandwidth the most intelligent way. IMHO of course!

[Bambers]

Smoothvision is currently at this state:

OGL: ordered grid used for all settings
D3D: ordered used for all settings except for 2x and 4x quality settings (using a certain fog cap will revert even these to ordered) where a non ordered grid is used. The 2x one shows some signs of varying its pattern but it only swaps between 2 and does not vary per pixel like it should (looks like they're the same pattern, just one is rotated 90 degrees) See here (http://www.jamesbambury.pwp.blueyonder.co.uk/2xqaa1.jpg) and here (http://www.jamesbambury.pwp.blueyonder.co.uk/2xqaa2.jpg).

If you look at the white paper for SV on atis site then its clear that the results should be much better than the ones being produced (see the beyond3d 8500 review pt1 for ordered grid AA pics that the 8500 will produce in most cases).
One thing I'm not sure on from the whitepaper was if SV was supposed to be a dynamic random pattern that changed every frame or just a fixed one.