Addressing all forms of aliasing

[Ghost of D3D]

First of all, I just recently registered here (although this is not my first post). Thanks for being patient with me is a general disclaimer I use after the previous sentence.

The title of my thread can be a little bold but I'm relatively new to the topic of 3D technology.

There are a number of ways that aliasing can occur, and more importantly, present itself to any one particular sufferer. I am not sure if what I am suggesting below is viable, or is already being implemented (or at least, considered) in behind-doors next-gen offerings, or if it was simply too expensive :

A hardware feature that would be a very helpful component to address all forms of aliasing would be the ability to have the exact pixel centers (probably on a per-quad basis, so derivatives are still correct) jittered in a controllable way instead of being on a fixed grid. Just jittering the texel sampling point in a shader does indeed reduce all forms of in-surface aliasing (at the expense of adding noise, almost usually), but wouldn't it be nice to have that "unified" geometric anti-aliasing as well?

How viable is this?

 

[Humus]

Well, you could easily jitter the samples yourself by adding the gradients multiplied with a jitter offset (which you sample from a texture or do some math on vPos to get a pseudo-random value).

 

[Ghost of D3D]

Well, you could easily jitter the samples yourself by adding the gradients multiplied with a jitter offset (which you sample from a texture or do some math on vPos to get a pseudo-random value).

Yes, that is certainly possible but involves work from ISVs when it comes to spending resources on a topic ISVs have generally been inclined to distance themselves from if it involved anything other than checking CAPs.

Again (and rather more clearly this time ) : With aliasing and AA being what is it from the POV of ISVs, I had basically asked how viable (or even reasonable, now that I think about it) it would be for IHVs.

 

[Bob]

I had basically asked how viable (or even reasonable, now that I think about it) it would be for IHVs.

Have you tried simulating it? Seems to me that it'll make your image more grainy than anything.

 

[Ghost of D3D]

Well, you could easily jitter the samples yourself by adding the gradients multiplied with a jitter offset (which you sample from a texture or do some math on vPos to get a pseudo-random value).

Okay, I tried this in software. It works for texel centers but nothing can be done in software for edge inclusion AFAIK.

Seems to me that it'll make your image more grainy than anything.

It adds some noise to the image, but it makes texture pattern aliasing essentially disappear.

 

[darkblu]

A hardware feature that would be a very helpful component to address all forms of aliasing would be the ability to have the exact pixel centers (probably on a per-quad basis, so derivatives are still correct) jittered in a controllable way instead of being on a fixed grid. Just jittering the texel sampling point in a shader does indeed reduce all forms of in-surface aliasing (at the expense of adding noise, almost usually), but wouldn't it be nice to have that "unified" geometric anti-aliasing as well?

How viable is this?

viable to the point of having already been implemented. check out 3dfx's (RIP) implementation of FSAA as found on the VSA100.

 

[ERK]

Seems like such a method would have lots of frame-to-frame temporal problems. Similar limitations to ATI's temporal AA.

 

[_xxx_]

Any screens for us with lacking imagination?

 

[o.d.]

The biggest benefit would be in removing texure aliasing which is probably easiest seen while moving.... still pictures might not get the idea across.

 

[Xmas]

viable to the point of having already been implemented. check out 3dfx's (RIP) implementation of FSAA as found on the VSA100.

I think Ghost of D3D is talking about (pseudo)random jittering, not just programmable sample positions that are the same for all pixels. Besides, VSA100 didn't support dependent texture reads.

 

[Ghost of D3D]

I think Ghost of D3D is talking about (pseudo)random jittering, <snip>... Besides, VSA100 didn't support dependent texture reads.

Almost entirely correct on the first count (I was simply wondering about the possible removal of a certain existing limit, grids) and not sure on the second (3dfx's VSA100 was a time when I was looking for a job!).

In any case, I will apologize for throwing this thread off-tangent with this post because I will switch to the (anti-)aliasing of shadow maps.

Mr John Carmack had been gracious enough to trade emails with me recently when I sought his advice and suggestions on the existing techniques of anti-aliasing shadow maps. Suffice to say that I was very surprised to learn that he had (has?) been experimenting with software anti-aliasing solutions. I have (since I posted this thread) found out that the game he is currently working on will use shadow buffers (i.e. shadow maps). A bit more prodding by me about how he intends to solve (solved?) the aliasing inherent with this technique (behind brute force approaches like higher shadow map resolutions) has not resulted in any further replies from him

Question : What is the cheapest way to produce :

a) Soft shadows via shadow maps;
b) Anti-aliased shadow maps;
c) (a) and (b) ?

Thanks, and sorry going OT.

 

[Blazkowicz]

you should look for the transcripts of his Quakecon 2004 and 2005 speeches, I read them not long ago here on B3D forum.
I guess that by software anti-aliasing he means done in a fragment program, not done on the CPU.
You'll be able to choose whether 1, 4 or 16 samples are taken for the shadow maps; 1 off course means no anti-aliasing, 4 being a good trade off (looks good according to him) and 16 being very expensive but should look great. and 64 if you use the engine for off-line rendering (yes!)
but besides that he also says a lot of awfully complicated and interesting stuff about his soft shadows. it's fun trying to understand, a bit like listening to major Carter in Stargate SG1, but much harder

 

[Blazkowicz]

about the VSA/100, it has fully programmable sampling pattern. this allows for ATI's temporal AA to be done, it was implemented (in 2004 I think!) with a modified glide2x.dll and glide3x.dll. it's really the same thing but RGSS instead of RGMS. and it actually sucks, because text is all shaky. so, I used it a tiny bit, was useful in Quake 1 but sucked in CS.

(as it requires both supersampling and very high framerate to be useful, not much games can use it)

 

[EasyRaider]

You'll be able to choose whether 1, 4 or 16 samples are taken for the shadow maps; 1 off course means no anti-aliasing, 4 being a good trade off (looks good according to him) and 16 being very expensive but should look great.

That's with hardware PCF and pseudo-random jittering, so 1 sample is also anti-aliased. But no matter how many samples you take, you won't get real soft shadows. I'm a bit disappointed he didn't aim higher, but I guess hardware just isn't fast enough.

 

[Xmas]

That's with hardware PCF and pseudo-random jittering, so 1 sample is also anti-aliased. But no matter how many samples you take, you won't get real soft shadows. I'm a bit disappointed he didn't aim higher, but I guess hardware just isn't fast enough.

You can get soft shadows by enlarging the filter kernel, e.g. depending on the distance to the occluder and/or light source. Not entirely correct, but it can look very good.

 

[Jerry Cornelius]

Well, it won't solve shadow mapping problems, but area summing would adress just about any kind of aliasing. It would have to involve more than one surface to solve edge aliasing though, likewise really small polygons. A hardware implementation of this would sure be interesting to see.

 

[flick556]

If the resolution was very high this would seem to be more viable. At current rezes the blurring/grainy effect might be too dramatic.

 

[bloodbob]

Well, it won't solve shadow mapping problems, but area summing would adress just about any kind of aliasing. It would have to involve more than one surface to solve edge aliasing though, likewise really small polygons. A hardware implementation of this would sure be interesting to see.

SAT would be nice until you get to tiling.

 

[Simon F]

First of all, I just recently registered here (although this is not my first post). Thanks for being patient with me is a general disclaimer I use after the previous sentence.

Sorry, but out of curiousity, were you a jealous spirit in the past?

 

[Ghost of D3D]

Sorry, but out of curiousity, were you a jealous spirit in the past?

Huh? Sorry but I don't quite get what you're saying?