Addressing all forms of aliasing

Ingenu said:
I think Simon was subtly asking whether you are/were Ghost of Envy.
No, I don't know who that is. I only recently participated in this forum although I have regularly been posting at the gamedev.net and opengl.org forums (under different pseudonyms). Are there anything similar besides the first 2 words of my and that person's pseudonyms that prompted Simon Fenney to make that post? I hope it's something good! :)
 
Ghost of D3D said:
No, I don't know who that is. I only recently participated in this forum although I have regularly been posting at the gamedev.net and opengl.org forums (under different pseudonyms). Are there anything similar besides the first 2 words of my and that person's pseudonyms that prompted Simon Fenney to make that post? I hope it's something good! :)
Sorry, it was just the combination of the similarity of the pseudonym, the statement that it was not your first post here, and the fact that it was a in interesting topic to start.
 
Last edited by a moderator:
Sorry for bringing this topic back up but it took me ages to search for info on the VSA100.

Blazkowicz_ said:
about the VSA/100, it has fully programmable sampling pattern.
I've read up on the VSA100 and I don't think the word "fully" is quite right. Correct me if I'm wrong (or better yet, a link would be most useful).

Going back to my original suggestion :

When you are doing multiple renderings and accumulating them (like the VSA100's T-buffer), you can jitter everything with the viewport, assuming you can do pixel fractions, which I believe is possible in most APIs.

For a single rendering, HW assist is needed. The VSA-100, since it was mentioned, could do this in a limited way - the control wasn't totally programmable as far as I understand it (anyone with a VSA100-based card that can confirm this?). I believe almost all chips these days use a rotated or jittered pixel center grid for spatial AA. When either (rotated or jittered) is the case, I'm sure it's quite debatable whether we want to sample the texture at the center of the pixel or at the exact jittered subsample location. There's some arguments either way, I'm sure - I can't remember off hand what they all are. And surely there must be some HW tricks in this area (anyone care to provide, um, insights?).

If my researches are correct, the grid on the VSA100 was a square grid of 4 locations rotated approx 30 degrees. There's no perfect pattern , you just want to make sure all the sub samples aren't in the same row or column (I think). For larger numbers of samples, you want to approach a random pattern, and I'm sure some SW renderers randomize it both in time and screen space.

Am I correct in my understanding? TIA.
 
Ghost of D3D said:
When either (rotated or jittered) is the case, I'm sure it's quite debatable whether we want to sample the texture at the center of the pixel or at the exact jittered subsample location. There's some arguments either way, I'm sure - I can't remember off hand what they all are. And surely there must be some HW tricks in this area (anyone care to provide, um, insights?).
One is called multisampling, the other is called supersampling.

Since sampling the texture at the center of the pixel for each sample will result in the same color for all samples, there is no point in calculating it multiple times. That's what multisampling is for: calculate one color, use it for all covered samples.

If my researches are correct, the grid on the VSA100 was a square grid of 4 locations rotated approx 30 degrees. There's no perfect pattern , you just want to make sure all the sub samples aren't in the same row or column (I think). For larger numbers of samples, you want to approach a random pattern, and I'm sure some SW renderers randomize it both in time and screen space.

Am I correct in my understanding? TIA.
VSA100 had 2 programmable sample locations per chip. IIRC they could be placed on an 8x8 grid, so they were using 3 bits per axis per sample to set the sample pattern. And usually the pattern remained fixed once it was set, although it wouldn't have been difficult to change it per frame.
 
Xmas said:
Ghost of D3D said:
When either (rotated or jittered) is the case, I'm sure it's quite debatable whether we want to sample the texture at the center of the pixel or at the exact jittered subsample location. There's some arguments either way, I'm sure - I can't remember off hand what they all are. And surely there must be some HW tricks in this area (anyone care to provide, um, insights?).
One is called multisampling, the other is called supersampling.

Since sampling the texture at the center of the pixel for each sample will result in the same color for all samples, there is no point in calculating it multiple times. That's what multisampling is for: calculate one color, use it for all covered samples.
Well, even when multisampling i.e. multiple Z sample but one texture sample, when a pixel is only partially covered, its debatable whether you should still sample texture at the center, or somewhere else (e.g. at one of the covered samples).

Of course, in true supersampling, there's no issue.
 
Xmas said:
VSA100 had 2 programmable sample locations per chip. IIRC they could be placed on an 8x8 grid, so they were using 3 bits per axis per sample to set the sample pattern. And usually the pattern remained fixed once it was set, although it wouldn't have been difficult to change it per frame.
Someone actually made a driverwith alternating AA pattern every second frame for V4/5 after the Temporal AA got first released on ATI.
 
Ghost of D3D said:
Well, even when multisampling i.e. multiple Z sample but one texture sample, when a pixel is only partially covered, its debatable whether you should still sample texture at the center, or somewhere else (e.g. at one of the covered samples).
I cant believe that you are not giving due credit to multisampling....there is a past post I need to try and dig up.

Edit: Post moderated
 
micron said:
right...:|

http://www.3dfxzone.it/dir/news/3dfx/am_3.1/

New settings for Direct3D and GLide/OpenGL

This kit is named as full version because it is shipped with both VSA-100(s) driver and 3dfx Tools like control panel. It has now an utilities set to switch D3D Render Mode from DirectX 7 mode to DirectX 8 and vice versa: this addon is very useful to enlarge supported games range shaping your system to these. Besides, 3dfx Tools have now a new setting to enable Temporal AntiAliasing with GLide/OpenGL based games.

Doesn't (apparently) work on V4 4500, nor on V5 6000's 8xAA mode, but works on V5 5500/6000 2x/4x modes.
 
radeonic2 said:
3dfx was only good because of glide.
Unless an API is significantly easier to use than others', then an API cannot make you "good". It only makes you "bad" if it sucks or is too different from the rest.

Uttar
 
Uttar said:
Unless an API is significantly easier to use than others', then an API cannot make you "good". It only makes you "bad" if it sucks or is too different from the rest.

Uttar
Well that was the case.. glide gave you direct access to teh hardware...
 
Kaotik said:
Someone actually made a driverwith alternating AA pattern every second frame for V4/5 after the Temporal AA got first released on ATI.
TAA glide was available a few weeks (or days?) earlier than TAA Catalyst.
 
no-X said:
TAA glide was available a few weeks (or days?) earlier than TAA Catalyst.
You sure? IIRC they got the idea to implement it after the TAA was found in Catalysts?
Even if it wasn't "official feature" yet, I'm quite sure it was "hidden" in Catalysts before 3dfx drivers.
 
Ghost of D3D said:
Well, even when multisampling i.e. multiple Z sample but one texture sample, when a pixel is only partially covered, its debatable whether you should still sample texture at the center, or somewhere else (e.g. at one of the covered samples).
That's what centroid sampling is for. With centroid sampling, the texture sampling location is adjusted to lie inside the rendered triangle, for edge pixels, e.g. by taking the centroid of all covered samples.
 
Kaotik said:
You sure? IIRC they got the idea to implement it after the TAA was found in Catalysts?
Even if it wasn't "official feature" yet, I'm quite sure it was "hidden" in Catalysts before 3dfx drivers.
TAA Catalysts were announced weeks before they were launched. And TAA glide was available between announcement and launch of this Catalyst version.
 
TAA in Catalyst was available unofficially in the releases before the feature was officially announced. I modified D3DFSAAViewer specifically so it could be used in the R420 hardware reviews. I even tested the thing on my 9700 to make sure it worked.
 
Back
Top