Alpha test -> alpha to coverage tool
- Thread starter Humus
- Start date
For D3 I comment out the "ForceMSAAMode = 6" line and make use of the in-game AA changer instead. Also, where I tested 4 samples made very little difference compared to 6 and even 2 samples was very good.
I noticed a few errors when you get very close to some chain-link fences, with background seeping in but overall, very nice.
Btw, after running it I get a "SmartShaderErrorLog.txt" file with the following: "Line 1: Cannot open source file '--NONE--'".
Nice job Humus.
I noticed a few errors when you get very close to some chain-link fences, with background seeping in but overall, very nice.
Btw, after running it I get a "SmartShaderErrorLog.txt" file with the following: "Line 1: Cannot open source file '--NONE--'".
Nice job Humus.
Humus said:
If I remove both your files, run D3 and quit the file is not there. If I put the opengl32.* files in, run D3 and quit the file is created.
No, I don't have any smartshader enabled.
Radeonic2: Assuming you installed it in the default dir it should be in C:\Program Files\Doom 3
I've only been semi-following the several threads on this area. One thing I'm not clear on --is the consensus this is a software-only solution that NV has come up with and that therefore ATI can follow at more-or-less the same fps cost? Or is there any evidence there is some hardware acceleration going on here specific to G70, whatever software h/a/c/k/s/ wizardry has been applied as well?
I think the topic of this thread proves that ATI can follow...geo said:
There seems to be support for a modified alpha to coverage mapping, but I think it's mostly useless, and it could be done with a single scalar mad_sat instruction in the pixel shader as well.
geo said:
It's my understanding that the G70 has a hardware solution to work around the aliasing with alpha test on multisampling by simply doing supersampling as soon as alpha test is enabled. The main issue here is that alpha testing for transparency is a hack to begin with. It's horribly prone to aliasing, which stands out even with antialiasing disabled. The proper solution is to alpha blend, however, that requires back to front sorting, which is very hard to do in the general case. For static geometry a BSP tree can easily do the trick, but for dynamic stuff it's very hard to do in real time. There are some solutions to order independent transparency, but they are costly. A good solution to this problem would be "the next big thing" according to some. In the meantime we need hacks to workaround this hack that's used in many games. While transparency AA is another tool in the toolbox which doesn't hurt to have it's not really a very good solution. Alpha-to-coverage is generally a better solution. The problem is that supersampling doesn't solve the underlying problem, that alpha-testing introduces discontinuities, so while it reduces aliasing it just pushed the problem down a mipmap level or so. What you want is to map alpha to transparency directly to properly work with mipmapping. This is what alpha-to-coverage does, while keeping the order independence like alpha-test but unlike alpha-blend. It's a sort of hack too, but it works pretty well in practice most of the time.
I have to somewhat disagree with that. Discontinuities aka edges are not the problem, they are in fact usually the purpose of alpha test. The problem is that it is somewhat hard to impossible to have mipmaps represent the exact "shape" that's encoded in the base map. But with a little care when creating mipmaps, one can at least improve the result a bit. For minification, alpha-blend and alpha-to-coverage do indeed give better results. With magnification however, they result in blur.Humus said:
The best way would probably be a combination of both methods, i.e. doing supersampling when magnifying and alpha-blend/alpha-to-coverage when minifying. Unfortunately, there is no direct relation between texture LOD and alpha functions. You'd have to either write a LOD-dependent shader or do two-pass rendering with a special texture, one for the magnified portion and one for the minified one.
btw, there are two other cases where TSAA kicks in: shaders writing depth and shaders using texkill.
Thanks. What I got out of that is there are three solutions to the problem, and NV has hardware accelerated the easiest (and least satisfactory from a robust results pov) of the three.
Which, btw, is still better than nuttin' --I'm not minimizing that, tho I utterly respect you purists pining after a more general solution, that us plebes would not recognize much more than "ain't that pretty!" more often than lesser solutions.
Edit: Whups, I missed Xmas response to my original. ATI can follow at reasonable performance trade-off without new hardware support? Yes, I know that is subjective. . .but I saw a 6600GT getting 10fps upstream. . .
Which, btw, is still better than nuttin' --I'm not minimizing that, tho I utterly respect you purists pining after a more general solution, that us plebes would not recognize much more than "ain't that pretty!" more often than lesser solutions.
Edit: Whups, I missed Xmas response to my original. ATI can follow at reasonable performance trade-off without new hardware support? Yes, I know that is subjective. . .but I saw a 6600GT getting 10fps upstream. . .
Well, both supersampling and alpha-to-coverage are "hardware accelerated". But there's no point in having hardware logic that decides whether something is needed depending on render states. The driver can do that just as well.geo said:
I guess that's a bug. On my Mobility Radeon 9600, Humus' a2c-Demo shows a drop between 0% and 20% (<5% average) going from alpha-test to alpha-to-coverage.
The irony is that, in Humus' demo, alpha blending is not only the best-looking method, but also the fastest, most of the time. Only when you get very close to the alpha surfaces (i.e. when you get big holes) do the other methods come ahead by a significant margin.
Back in the days of the GeForce2, NVidia recommended using alpha test in conjunction with alpha blending, to mask out the framebuffer reads/writes for totally transparent pixels. Today, having tile-based framebuffer compression, that's counter-productive unless you have large "holes" in the texture.
Can you whip up a quick one to work in GTA:SA for me?
