Could activation of SSAA improve texture quality?

Tahir said:
But Gamma Corrected AA only works on the edges rather than the whole screen so would it matter that much from monitor to monitor.. can't say I have noticed the differences on several different monitors (old and new).
Think about it this way. If there is little difference visible in-game between the 2x modes of ATI and nVidia, then there will be even less difference between two different monitors on ATI's R3xx. But, I'm a perfectionist. Even if there isn't much difference, there is some, and I would like to see customizable gamma correct FSAA.
 
Chalnoth said:
The sampling pattern is the bigger plus, if only because ATI's gamma-correct FSAA is not adjustable (each monitor is different, and so each monitor should use a different gamma correction value...).
how do you figure?
 
But, I'm a perfectionist.

Well Mr Perfectionist all I can say to that is that you are not very consistent in your perfection. ;)

Think about it this way. If there is little difference visible in-game between the 2x modes of ATI and nVidia, then there will be even less difference between two different monitors on ATI's R3xx.

But there are still big differences in AA quality even with different monitors. I am currently testing a GFFX 5600 after having a 9700Pro for so long, also have been testing a 5200.

The difference between the ATI and NVIDIA AA quality is night and day. I am just talking about AA quality here by the way.

I will openly admit that I have been seriously spoilt by the level of AA quality from company x, and when comparing company y to it even on different monitors, systems and games/demo's I am confident in my opinion that you are talking out of your proverbial ;)

And Chalnoth why are you comparing apples to oranges.

You state:
If there is little difference visible in-game between the 2x modes of ATI and nVidia...

I disagree that there is 'little difference' but forget that for a second...

How does the difference in 2x modes lead to your conclusion?
then there will be even less difference between two different monitors on ATI's R3xx.

Answer is that it doesn't.

I said that the most important part in the R3xx AA IQ is the sample patterns....and even with gamma corrected AA on different monitors this is still true as the difference between ATI's and NVIDIA's modes is day and night - so gamma corrected AA is helping out but isn't the end all and be all of ATI's superiority even with different monitors. You agree with this by mentioning the sampling pattern as the 'bigger plus.'

You then state that you are the perfectionist and want to see customizable gamma corrected AA even though I state it is only working on the edges (but I do see your point of the different monitors but again I did say even then ATI's solution is much better)...

So from there why did you mention 2x AA modes of ATI and NVIDIA? Why mention even less of a difference as the actual difference is huge (In My Eyes)?

Like I said it screams of inconsistency, not to mention you dont even get gamma corrected AA with any NVIDIA solution ATM.

Sorry Chalnoth but sometimes I don't get you.
 
Tahir:
To make your comment compatible with the rest of the discussion in the thread.
Gamma Corrected MSAA only works on edges.
But Gamma Corrected SSAA works on whole screen.
I know you commented on R300, which use MSAA. I just thought it was best to be complete here.

Chalnoth:
It's nice to have customizable stuff. But since I think it could cost more than it tastes, there's a better way. The fix gamma is close enough for all monitors, and then you can adjust the rest in the display properties gamma settings. In fact, this would give a more correct image. The only bad thing would be if somebody else made a fix different gamma.
 
The needed gamma correction function isnt going to be an exponential curve for every one either, personally I use the brightness control on my monitor ... I am pretty sure that any error in the gamma correction resulting from the specific exponential response of my phosphors is completely overshadowed by blacklevel error.
 
But Gamma Corrected SSAA works on whole screen.

Sorry my bad, but since no one does that at this time do you not think it is a bit pointless to try and consistently rubbish the competition at almost any oppurtunity or perceived weakness? That is all I saw in Chalnoth's rather flippant remark.

Perhaps with SSAA and Gamma Correction you will need customizable tweaks but since you will be applying it to the whole screen it is just like the gamma settings you normally get anyway in NVIDIA and ATI drivers (could be wrong there).

Like you said, Basic, getting the customisations built in may not be worth it from a result point of view in the view of MSAA.

And Chalnoth if you truly are a perfectionist why haven't you thrown your GF4 away yet? :devilish:

Edit: ahh I see you editted your point as well concerning the fix gamma - so does that mean you agree with me (sorry me not know all the terms here..'fix gamma' :) )
 
Hey, the only edit I did was 'commant' => 'comment', don't try to say I changed the contents. :devilish: :D

If you have read this whole thread, you see that gamma corretion and SSAA is a hot topic. And the reason for the thread is probably that Vitall wondered if it would be a good thing if ATI enabled SSAA on R300 (which the hardware is rumored to handle.)

The need or not of customized gamma is not related to SSAA vs MSAA. And the need for gamma corrected AA (fixed or variable) is the same for MSAA and SSAA.

"fix gamma":
Gamma is a float that defines a transfer function from frame buffer value to light intensity. ATI's AA is designed for a constant (fix) gamma, so it needs the contents of the framebuffer to be stored in a form compatible with that gamma. Luckily, if you don't know anything about gamma when you create your gfx, you tend to use the one (or similar to) ATI's fixed.
(To be complete: the term "gamma" is used for more than one step of the transfer function from frame buffer value to light intensity. So it can be a bit confusing. I hope I didn't add to that.)

And about Chalnoth:
I'd say it was a rather mild "flip", and I was actually more suprised at your comment when he said that the error from mismatch in ATI's fixed gamma was small.
But I'll leave that discussion now.
 
Hey if I am wrong please correct me.
I can take it!

I guess it does go to show that I didn't read the whole thread.

Let me get one thing straight though, if you gamma correct an SSAA screen and you correct the whole screen by doing it does then what about the settings for gamma correction in the drivers tab we have now?

Also the customisation of gamma corrected AA won't be as pronounced in changing the end screen on an MSAA implementation?

Another point to consider is that adding another section to tweak in the drivers won't help the average user surely?

And I am only upset at Chalnoth because he used a poor apples to oranges comparison to make a point in my humble opinion. But he is a big lad and can defend himself and can point out where I am wrong... ;)

Sometimes I just dont see the logic in the gripes Chalnoth mentions....it is not playing fair to raise one product to an incredibly high pedalstool and at the same time to say it isn't perfect when you at the same time ignore and gloss over another products lack of abilities. BUT that is what I see from Chalnoth's comments now and in the past and I am sure others would definitely disagree with me.
 
Tahir said:
Let me get one thing straight though, if you gamma correct an SSAA screen and you correct the whole screen by doing it does then what about the settings for gamma correction in the drivers tab we have now?
When you compute your output colors (predownsample) obviously everything has to be gamma correct (most times by just picking the proper source data). However, when you do your downsample, you have to do the calculation in a gamma correct manner also. With MSAA, because polygon edges are the only place you need to compute anything, the gamma correction only applies there. With SSAA, each pixel will need to be computed so you're likely going to be doing the calculation across the whole screen.

Hope that clears things up.
 
BenSkywalker said:
That sounds like you are simply applying a weighted filter. That's what I was saying - the subpixel position of each sample can determine the weight applied to that sample.

I'm not talking about a fixed weighting such as 50%/12.5% ala Quincunx, I'm talking about utilizing a weighted sampling based on the relative intensity of focus in relation to the camera angle.
For each super sample, a set of texels will be chosen, each of which will weighted according to the texture's orientation relative to the camera. The 'fixed weighting' is only applied to the the collection of all supersamples and so individual texels will have dynamic weights.

Anyway, there's no need to go mucking about with finding individual vectors - the overall projection of the scene at a higher rendering resolution will take care of it all.

I'm not asking if you think it is good enough, I'm asking if you are saying it wouldn't be any better.
From what I understand of what you are asking, I don't think it is going to be any (or significantly) different. By the sound of it, you are only re-ordering the maths.

I'm possibly being a bit thick but what exactly are you asking?

Do you think using the current isotropic filtering implementation as it relates to AA would be equal to or greater then a sampling implementation that was weighted based on angle in relation to the camera?
I still think there is some confusion here. When a screen pixel is projected into texture space, the footprint of that texel becomes distorted into an ellipsoidish shape (if you consider texels to be circular) or an arbitrary quad (if originally square). When people refer to isotropic filtering of textures they mean that the algorithm approximates that 'foot print' by a weighted sum of four (bilinear) or eight (trilinear) axis aligned square sets of texels.

Anistropic texture filtering (and the quality is implementation dependent) just tries to model that footprint a bit better. One typical approach is by dicing it into a smaller set of squares and using more bilinear/trilinear samples. FWIW, in the original texturing paper, by Catmull, the system exactly sampled the set of texels. Unfortunately this is too slow hence all the approximations (eg William's MIP Mapping/Trilinear and others) that have followed.

With supersampling, OTOH, the original screen pixel may be generated in an isotropic space, but each super sample will be individually projected into the texture and so the combination of the smaller samples will automatically approximate the arbitrary footprint of the entire pixel. In addition, it will take into account obscuring due to intersections of objects or occlusion.

There is nothing to stop you combining SS with AF-Texture-filtering.

In summary, I think what you are asking will already be occuring with (correct) SS.

Tahir said:
But Gamma Corrected AA only works on the edges rather than the whole screen so would it matter that much from monitor to monitor.. can't say I have noticed the differences on several different monitors (old and new).
It's also important away from the edges as well - if you have a fast changing texture or lighting it's better to downsample in the linear domain.
As for differences in monitors, it's not that important. Even a rough approximation to the nonlinear gamma is a lot better than none at all!

But I would definitely think it was the sample patterns used.
Assuming that you don't pick a stupid pattern (!), I'd say that gamma is more important.

But there are still big differences in AA quality even with different monitors.
Could also be that many people have their brightness cranked up far to high.
 
Tahir said:
And Chalnoth if you truly are a perfectionist why haven't you thrown your GF4 away yet? :devilish:
1. Linux support
2. More comprehensive anisotropic filtering with less texture aliasing (in my experience)
3. The Radeon 9700 still has issues in a number of games.
4. The Radeon 9700 is somewhat unstable (something which I typically do not like to mention because it is a Rev. 1 card).
 
Chalnoth said:
Tahir said:
And Chalnoth if you truly are a perfectionist why haven't you thrown your GF4 away yet? :devilish:
do not like to mention because it is a Rev. 1 card).

I thought that myth was dispelled?

Anyway I agree NVIDIA have much better Linux drivers.

However the 2nd point I don't agree with either. I am having a lot of issues at the moment with my borrowed GFFX 5600 .. but I'm sorry we are talking about a 2 year old technology the GF4... my bad.
 
Back
Top