Quincunx & FSAA: how is it changed between Geforces

[Mintmaster]

MS is just an interim measure to provide better performance at the cost of IQ, just like ATI's aniso.

I totally agree. A few years ago, MS would just cost a bit too much hardware for it to be useful (might as well add more pipelines), and a few years from now MS will only be useful for simple pixels (no fancy shaders causing aliasing in the interior). However, there will be more than enough horsepower to supersample simple pixels anyway, so MSAA/FAA will essentially be useless.

 

[Jerry Cornelius]

MS is just an interim measure to provide better performance at the cost of IQ, just like ATI's aniso

I totally disagree. If you want to get rid of texture aliasing, filter the texture better. Oversampling is a very crude and brute force solution. As far as I'm concerned it's only merits are simplicity and completeness.

I don't think there's going to be much of this in future products especially since you're looking at huge memory footprints to effectively AA a scene.

 

[Ailuros]

Hmmm anyone up for the guessing game?

 

[KimB]

Given that both shots appear to be using FSAA, and the fence is more "filled in" in the top shot, it is most likely a Radeon 8500.

Since the fence uses an alpha test instead of an alpha blend, the GeForce4 is certainly going to have problems with it (in comparison to the 8500 when both are using FSAA). For the rest of the image, it is very had to tell any differences, partically because they're not at the exact same position.

 

[Ailuros]

Guessing the sampling method should be enough for what I intended them for. Which accelerator is of less importance.

The fence looks bad with either method in motion, but it's the game's fault.

 

[Jerry Cornelius]

I'll guess, the top is FSAA, the bottom MSAA. Honestly, I have a hard time telling the difference.

 

[KimB]

The fence looks bad with either method in motion, but it's the game's fault.

Yes...which is why such textures should always use alpha blends.

 

[Ailuros]

I don´t think that´s the problem with the fence anyway. It flickers like crazy with both sampling methods. If I´d spend more time to catch identical angles for both screenshots the fence would have turned out the same.

There´s a very significant difference between them elsewhere which there is a possibility that it affects performance quite some. There´s just no way that I can verify it.

 

[KimB]

I'm reasonably certain it's because the fence uses an alpha test.

With a plain alpha test, parts of the fence are either transparent or not...so once the significant objects of the fence get roughly smaller than pixel size, massive aliasing occurs.

Supersampling helps by increasing the distance at which this problem begins to occur.

An alpha blend works much better, and allows such a texture to sort of fade out more realistically, avoiding most aliasing.

 

[Ailuros]

With the settings used in both cases the fence looks identical on both as I said already. There´s no use I have to spell it out: do shadows underneath the car look the same?

 

[KimB]

Hrm, yes, the shadow on the upper shot certainly looks better.

But whether it is more correct rendering or not, I don't know...since I don't know exactly why the edge looks less jagged there (It looks like the shadow map is more "blurred" in the top shot...).

Assuming that the difference is between multisampling and supersmapling, then the fence will certainly look better in supersampling.

Additionally, regardless of any actual difference in the fence between the two situations, nearly all aliasing problems with the fence would be solved with an alpha blend.

Edit:
Btw, the top shot has the fence angled further away, which would usually make for more aliasing, but instead there appears to be less...

 

[Ailuros]

I´m not an ungrateful bastige, so I know to whom gamers owe "Smooth Alpha" in UT/openGL.

I remember asking Kristof last year in a forum about PVR´s D3D/"soft edge on cut out textures" implementation and why it wasn´t forced on API level. If my memory serves me well the problem was somewhat related to Microsoft (Kristof correct me if I´m wrong).

Speaking of couldn´t it be forced via the drivers at least in openGL globally? (I mean a driver variable where it can be switched on/off, but when switched on to get forced across the API).

 

[KimB]

No, because alpha blends aren't depth-correct, and thus must be sorted before rendering (fortunately, alpha textures are generally not that numerous, and when they are, they are usually logically laid-out, making sorting easy).

For example, if you play the Op Na Pali mod for UT with my renderer and UseSmoothAlpha enabled, there will be some objects that you cannot see behind vines and such. It does look very strange. Fortunately, the way UT renders, UseSmoothAlpha just works everywhere I've seen, at least in the normal game.

 

[Ailuros]

Last OT: Has any of you attempted to make Undying run in openGL? I copied several openGL renderers in the game´s system file, the best I got is the game attemting to load and give me a glorious 3D hardware initialisation failure error.

I am assuming that since the ini file contains a few openGL variables that there is a chance that it could be run in openGL too.

 

[KimB]

Sorry, I haven't, but I do know that they've probably made some changes to the renderer that would prevent any UT OpenGLDrv.dll from working. Perhaps if somebody could get the renderer source from the developers of Undying, a modified version of Loki's OpenGL renderer could be created, but I don't know if I could do it (and neither do I have Undying...).

 

[Althornin]

I totally disagree. If you want to get rid of texture aliasing, filter the texture better. Oversampling is a very crude and brute force solution. As far as I'm concerned it's only merits are simplicity and completeness.

I don't think there's going to be much of this in future products especially since you're looking at huge memory footprints to effectively AA a scene.

What form of texture filtering reduces aliasing very well?
Aniso does a so-so job at it, but is more designed to make the texture clearer at angles and further in the distance than it is designed to reduce aliasing.
Aniso does a poor job of decreasing texture aliasing, imo. It does make textures look better (esp far away textures)

 

[Gollum]

Huh? To the best of my knowledge Aniso definitely helps with texture aliasing and that is also one of its primary purposes. It helps in increasing texture sharpness and detail, yes, but should also reduces aliasing dramatically. Unless you are using an overy agressive LOD or the aniso implementation doesn't properly filter textures for some reason (or doesn't have enough samples), texture aliasing should always be noticably reduced by enabling aniso, at least it works that way on my GF4! Whenever I encountered textures that cause severe aliasing in some game, activating aniso has always helped (I usually have 2x as default, in some games I use 4x or 8x too).

Of course 8x aniso alone isn't as effective on textures as lets say 4x SSAA + 8-16x aniso, but its already quite good and without an overly agressive LOD you will rarely encounter any artifacts. Once upcoming cards support 16-64x aniso at usable framerates, SSAA will basically be a fruitless waste of power IMHO (edit: concerning texture AA benefits).

 

[Sharkfood]

Gollum-

To the best of my knowledge Aniso definitely helps with texture aliasing and that is also one of its primary purposes. It helps in increasing texture sharpness and detail, yes, but should also reduces aliasing dramatically.

This really is a perfect example of why current IHVs have started to stray away from the true purpose of anisotropic filtering, and instead gotten caught up in some performance race with little regard for the resultant image quality.

The 29.42s automatically fudge aggressive LOD bias when enabling AF on my GF4 and games turn into shimmer/sparkly fests of aliasing. This wasnt the case, say, with a GF3 and the 12.90s. ATI is doing the same kind of thing with LOD Bias and AF. The sad thing is, there is very little method to reduce LOD smoothly as it doesnt appear to be a uniform application by mipmap in either case, so you wind up making the scene overly blurry in further mipmaps in order to reduce texture aliasing in closer mipmaps- but only with AF enabled (i.e. LOD Bias seems to function properly/more uniform once AF is disabled in both cases, where this actually functions in drivers).

It's really pathetic that this is obviously some method of trying to show valid "difference" in anisotropic levels for the sake of still shots likely for website review purposes and a race for FPS, versus a focus on what anisotropic filtering can truly deliver to image quality. I still use a GF3 + 12.90s as a litmus test of what AF can truly deliver. Unfortunately, GF4/8500 and current drivers have strayed so far from this level it's not even worth discussing.

Cheers,
-Shark

 

[Jerry Cornelius]

What form of texture filtering reduces aliasing very well?

Any advanced texture filtering process should include some amount of anisotropy. I'm just saying that texture aliasing should be corrected at the texture filtering level, since that's where the problem lies.

 

[Althornin]

What form of texture filtering reduces aliasing very well?

Any advanced texture filtering process should include some amount of anisotropy. I'm just saying that texture aliasing should be corrected at the texture filtering level, since that's where the problem lies.

I wonder what level of SSAA would be nessesary to give good quality when using point sampling?
And if its not too high, what if you used all the die space+transistors that are being used for texture filtering for SS instead?
You might be able to get better speed that way - and, you wouldnt be filtering the texture twice.