Antialiasing still broken

[slax65]

Maybe Antialias Mode isn't broken, the issue could be caused by internal resolution ... could someone make a revision with internal resolution 1360*768 ??


[color=#1E90FF]http://www.youtube.com/watch?v=g-VVxm49aEE[/color]

[NaturalViolence]

No. That doesn't make any sense. Me and neobrain spent months arguing about this trying to fix it and I can assure you it has absolutely nothing to do with the internal resolution setting. The 4xSSAA shader doesn't work correctly, either the sample coordinates are off or the box filter is not working correctly.

It was broken by 6549 if you're curious. Changes made to the efb caused an incompatibility with the old 4xSSAA shader. Nobody has been able to fix the shader to work properly with the new efb code (which is more accurate and prevents off by 1 alignment errors).

[Runo]

This is very n00bish and I know I'm probably going to be a bit trolled for this but I want to learn how this works so I wont mind some informative lectures ^^ :

Isn't AA a known rendering technique? I mean, why can't we do this here, isn't it the same for any other program/game that have AA? I know the technical part of how AA works, I have no idea how it is for coding...
If it doesn't, can't we implement it post-processing? (like the post-processing shaders?)

[vortextk]

Doesn't really matter because it has worked for all graphical back ends before atleast, I can use a little bit older revisions for working dx9 AA and probably opengl but opengl usually doesn't run better or look better anyway on my machine. It's not like they don't know how to implement it, it's that it gets broken by other things they fix. Neither of these consoles supports AA natively so while emulating properly they then also have to put that on.

[slax65]

(07-22-2011, 01:43 PM)NaturalViolence Wrote: No. That doesn't make any sense. Me and neobrain spent months arguing about this trying to fix it and I can assure you it has absolutely nothing to do with the internal resolution setting. The 4xSSAA shader doesn't work correctly, either the sample coordinates are off or the box filter is not working correctly.

It was broken by 6549 if you're curious. Changes made to the efb caused an incompatibility with the old 4xSSAA shader. Nobody has been able to fix the shader to work properly with the new efb code (which is more accurate and prevents off by 1 alignment errors).

r6515 is a revision where antialiasing works perfectly, BUT only if internal resolution is set to "fractional", if it's set to "integral" it's like SSAA is broken ...

[LordVador]

(07-23-2011, 04:31 AM)slax65 Wrote:

(07-22-2011, 01:43 PM)NaturalViolence Wrote: No. That doesn't make any sense. Me and neobrain spent months arguing about this trying to fix it and I can assure you it has absolutely nothing to do with the internal resolution setting. The 4xSSAA shader doesn't work correctly, either the sample coordinates are off or the box filter is not working correctly.

It was broken by 6549 if you're curious. Changes made to the efb caused an incompatibility with the old 4xSSAA shader. Nobody has been able to fix the shader to work properly with the new efb code (which is more accurate and prevents off by 1 alignment errors).

r6515 is a revision where antialiasing works perfectly, BUT only if internal resolution is set to "fractional", if it's set to "integral" it's like SSAA is broken ...

Just to complete this r6515 and even r6505 work perfectly ONLY when "Fractional IR" is checked

[NaturalViolence]

Quote:Isn't AA a known rendering technique? I mean, why can't we do this here, isn't it the same for any other program/game that have AA? I know the technical part of how AA works, I have no idea how it is for coding...
If it doesn't, can't we implement it post-processing? (like the post-processing shaders?)

It would take me days maybe weeks for me to type out everything I know about AA and somebody like neobrain or rodolfo....probably months. Ask some specific questions and I'll answer them.

There are many different ways of doing AA so you need to be more specific.

MSAA is extremely efficient but can't be done in d3d9 because the API is too restrictive and we're using offscreen render targets for efb emulation. An extension was added with d3d10.1 that allows for MSAA to be done with offscreen render targets which is why it can be done with the d3d11 plugin ONLY if the hardware being used supports dx10.1 specifications or higher. OpenGL has no such restrictions which allows it to be implemented in the opengl plugin. Because MSAA has pre-existing functions in the API it can be easily implemented so long as the API does not place any restrictions that conflict with how you're using it.

SSAA does not have a common framework that we can use. The SSAA shaders were written totally from scratch by rodolfo in order to provide the d3d9 plugin with some form of AA that would work with offscreen render targets. Unfortunately the code is a mess and nobody fully understands it but him, and as you know he's virtually disappeared lately due to real life time constraints.

Post-processing AA would also require writing shaders from scratch....and nobody wants to do that with a program that has framebuffer management as complex as dolphin. If we didn't have to emulate the efb this would all be MUCH easier, but unfortunately we do so....yeah.

[vortextk]

10.1 huh? I guess that's why my 4870 likes dx11 AA just fine then, without actually supporting dx11. I love reading this kind of stuff, despite limited understanding. Digitalfoundry on eurogamer is always fun.

[Runo]

@NaturalViolence

Thank you very much for the insight, now at least I understand why this is such a complicated task. About Antialiasing itself, I think I'm google myself some content to read, I really want to learn more about this matter

[NaturalViolence]

Quote:About Antialiasing itself, I think I'm gonna google myself some content to read, I really want to learn more about this matter

Go in chronilogical order. Older methods of AA are usually the simplest, newer methods are usually more complex. Each generation sacrifices some quality for much better efficiency (ratio of quality improvement to performance hit). To me older games running at a high resolution with SSAA, proper texture filtering, and v-sync look way better than modern games running without these things. I can't stand playing games without SSAA to the point where I will lower the in-game settings (except resolution and texture quality) down to the minimum just to be able to play the game with SSAA at an acceptable framerate. Once you start using it with everything and getting used to it you can never go back to MSAA.

SSAA is the oldest and simplest method (at least when you're talking exclusively about video games and nothing else).

Then they figured out how to remove geometry aliasing without having to render any additional pixels. Which is MSAA, phenomenally more complex.

Then they figured out how to remove aliasing on a 2D bitmap that was already rendered (post-processing AA, such as MLAA or FXAA). This is phenomenally more complex than MSAA. This is where we are at right now. The only real reason this is becoming popular is because game developers are beginning to design rendering engines so complex that they can't get MSAA to work with their engines. So they need a method of AA that can run after the image has been rendered instead of being part of the rendering process.

When SSAA in the d3d9 plugin broke and I started talking a lot with neobrain about how it worked and how he might be able to fix it it got me interested in how various methods of AA worked. For months I read and read and read. The hardest thing to understand was how MSAA worked. That took a solid month by itself. I read so many articles on it but I could never understand what they were saying. This is because you have to already understand how 3D rasterization works. If you don't understand the process that video games use to render images to begin with you will never be able to make sense of how MSAA fits into it. This is because unlike SSAA, the process of MSAA is extremely difficult to visualize in my opinion. After this period of time I felt I had gained so much knowledge about it and the articles I had read were so poorly written I felt that I could do better. I started a section on my site but lost interest after only two days. I finished the template but barely had time to write any content, it takes forever: http://naturalviolence.webs.com/aa.htm

It would take me weeks to make it and actually explain how everything works rather than just taking the shallow approach that everyone else takes. And I still don't understand how the post-processing methods work yet so I would have to just post links to scholarly articles about them (none of which I can make sense of when I try to read them). I just don't have the motivation for that.

But you've sparked my interest a bit so maybe I'll start here and start copying it into the sections in my site.

Aliasing occurs because the rasterization engine takes geometry (which has an infinite level of detail since it's just points and lines) and uses it to produce bitmap images. Bitmap images have a finite level of detail since they have a finite number of pixels. If you could render an image with an infinite resolution you wouldn't need AA. Picture in your head that you're staring at an image of a red brick wall with a man standing 15 feet (about 5 meters) in front of it. When you think about pixels of the framebuffer try to image that your looking at the scene through a screen door and each square hole in that screen is a pixel that gets filled with a color. The engine draws that image by filling each coordinate where a pixel will be with a color (thus making it a pixel). It gets that color by sampling a color from the nearest texel (a pixel of a texture). Because of this you will see aliasing on the edges of the man. Each "edge pixel" is a coordinate that gets filled with a color from the center of the pixel, rather than an average of the entire area that it covers (remember since it's an edge pixel it's area covers both some of the man and some of the wall). So the problem is for each of those edge pixels it will take the color from either the man or the brick wall, not both. Let's say the man is wearing black clothing and the wall is bright red. The pixels on the edge of the two objects will either be totally black or totally bright red depending on whether there coordinate is technically on the man or the wall. This is because our resolution is limited. Those edge pixels actually cover both part of the wall and the man, that's why they are edge pixels. So they should be dark red, a halfway point between the two colors, in order to provide a smooth edge. So without AA some of the edge pixels will be bright red and some will be black, creating that stair step effect you see. Jesus I remember why I stopped now....this takes a long time to think about and type out. The easiest way to fix aliasing is to raise the resolution that you are rendering the scene at. By doing so you are essentially "shrinking" the aliasing to the point where it becomes unnoticeable or invisible. Of course as I said before, it will never be totally gone since your resolution will always be finite no matter how high you go. Alright now I'm done writing for now, I have a c++ project to finish. I'll continue this tomorrow. It is really hard to explain this stuff if you can't see it in your head. I'll add images tomorrow, that will help.

Edit: Excellent image of what I'm trying to communicate:


Picture those squares as the pixel area, the dots as the sample coordinates (the coordinates where it samples to get the color that it will fill the pixel with), the triangle is the geometry that we are trying to render, and the image on the right is a 4 pixel (2x2) bitmap image generated by the engine by rendering it at a resolution of 2 x 2. That picture does a much better job of explaining it than my entire paragraph....