Alternative AA methods and their comparison with traditional MSAA*

For me, it's because I didn't know about this form of AA. Marketing and gaming press have always simplified the space to pit costly MSAA against bad AA.

Secondly, some people were very sure the SPUs can't contribute to rendering, including AA. Some highlighted that developers don't have time for SPU tricks.

It's rather fresh to see developers innovating. In fact, I am contemplating buying a copy of Saboteur to show my support.

 

How would it perform on the GPU as a compute shader or with OpenCL?

 

Well.

 

It´s definitely a novelty within game development community. It´s really interesting seeing this paradigm shift from the standard MSAA technique.
I remember there was some discussion about the AA used in CE3, I am not sure it was established which technique they used, but I remember these posts by Fran and Barbarian.

I got a feeling some new AA technology was cooking from the comments above and it obviously is taking place on many fronts. It is really encouraging it is taking place at mulitplat developers. It seems like the current HD consoles still have a some steam left.

 

Well one of the things that MS pushed (and ATI followed, but Nvidia balked at) was moving towards allowing software devs greater freedom to implement AA through shaders. Unfortunately Dx10.0 without the stuff cut for Dx10.1 wasn't sufficiently fast enough.

And hardware box AA was still faster than software programmable AA. So G80 vs R600 sorta reinforced the view that hardwired AA was better than programmable AA, unfortunately.

But I think we're seeing forward movement again with regards to AA. At least I hope. I know I won't be a sad panda if fixed hardware AA disappears in favor of more flexible AA solutions.

Regards,
SB

 

well yeah. I figured u can do anything on a general purpose CPU as long as you want to. I was really wondering whether the performance then would make it a fools errand. On a desktop setup I'd think the graphics work would have to go into system ram before th CPU can work on it in any way making it a massive bottleneck or would it work in a similar fashion to Phsyics where the CPU simply calculates what is where and tells the GPU what to render

What about fixed flexible AA hardware. A daughter die on future GPUs to handle physics or aa or some other specialized function designed with some flexibility

 

(random thoughts) What might have helped was to operate on a downsampled buffer ala the SPE's post-processing setup. And with the GPUs, also use 4xMSAA+ to help create a better edge mask (edit: from the depth buffer)...

 

Isn´t it funny (or maybe sad) that the PC hardware development kind of suffocates software innovations as the brute force increase coming each year does not encourage developers to try new ideas. Better just keep doing the same thing, just some more of it.

The invariance of the consoles actually forces develpers to try new ideas, let's hope some of them will ported back to the PC space.

 

I think I'd have to see the game in person to be convinced, it's hard to tell from internet videos. One thing I noticed in that pic Shifty had linked was that to me it looked like there was blurring going on in more areas than just edges, which seemed to soften the image a bit. It makes more sense now knowing that they are going by luminance. I also saw this pic on Eurogamer:

http://images.eurogamer.net/assets/articles//a/8/6/7/8/5/1/Saboteur_Aliasing_000.jpg.jpg

I wish the lighting was the same on each pic, but either way it still looks like the PS3 version is being overly softened. The AA looks better on the PS3 pic, but to me many texture details have been sacrificed to attain that. Admittedly I tend to be very sensitive to that, I really notice it on games like AC2, RE5, etc that look much softer on PS3 and it bugs the heck out of me. It's also why I have an extreme disdain for quinqunx aa. I'm wondering if using both luminance and Z is the better way to go. It would take some more bandwidth to shuttle Z data over to spu, but after that some simple Z checks could spare the textures the detail loss.

 

I agree that there is a bit of blurring (and just general processing) going on in Saboteur where there shouldn't be, including the UI (which I already commented on). It's a general trade-off with a purely image based method between finding too many "edges" (and thus blur) and missing some of them, and I think they may have gone a bit too far into the former direction. Still, it's the first implementation we see in a retail game and I can't blame them too much considering how much interest it has (IMHO finally) generated in this topic.

 

As I understand it AA has the heaviest bandwidth cost of nearly any function done by the GPU. Does this technique nearly completely remove this cost?

Also since this technique is done at the post processing phase, would it not be possible to perform after 2xMSAA is done?

The 2 games I would be most curious to see this applied to:

GTAIV - Aliasing was terrible in that game and the graphics were similar in look to saboteur... I have a feeling this would be a good fit

Gran Turismo 5 - This would bring this game to a nearly rendered look. Edge detection would be trivial gievn the nearly flat shaded look of the textures. I find that even 4xAA at 720p is not enough for this game. Would be curious to see the output of MLAA at 1280x1080 (if possible with 2xMSAA combined).

 

Talking about the PS3 particularly, obviously doing it on the SPE removes any kind of *graphics memory* bandwidth impact, which I understand to be a problem in some cases on that platform. In general in a GPGPU setting you'd want to work on pieces of the image that fit into your on-chip memory, which again greatly reduces the external bandwidth requirements.

That's not a good idea. Getting good results out of a technique such as this depends on accurately reconstructing (the slope of) the edges based on the staircase pattern. When your "real" AA already blurs those it doesn't really help you at all.

 

I don't understand how that would be possible. How would the algorithm detect jaggies on an already AAed image, especially if it doesn't operate on depth?

 

That's true... how to combine both then?

 

Could this technique also be used to AA shadow buffers?

 

This could be a stupid question but here it goes, why not pass the MLAA before the MSAA?

 

It's not stupid, in fact it has been brought up before in this thread IIRC. You could indeed try to do the edge detection pass on the unresolved MSAA buffer (if you have access to it). That information could then be used to decide on how to blend which samples. The question is if it's worth the complications.

 

Not really as that stores depth values. If you have a 'bright' and a 'black' pixel near each other, then you'd have to change both to a 'mid' level for AA but that'd mean a completely different distance value. It's like the edges of an object would be moved several meters away from the camera, and the background would meet with those edges in the middle.

 

I imagine you'd get some really strange artifacts with the lower resolution shadowmap, setting up those separation lines/borders (if you took the RGB analysis).

 

what you could do is something like

A/ render a shadowbuffer but when it passes write the linear distance from the light occluder to the receiving fragment
B/ on the SPUs go though this buffer doing a 'similar' technique as mentioned

or combine A+B

result = better shadows than in any existing game (I think)