[PeterT]

Originally Posted by joker454

Thinking about it some more, they must be using Z along with luminance, otherwise wouldn't their method blur any texture that had luminance variance within it, whether it was an edge or not? Then again, maybe that's why their game has that overall soft look to it.

Well, normally when you do some kind of morphological AA you are very conservative about what you consider an edge (the staircase patterns), so that shouldn't happen too often in textures, and when it does it's usually something you want to filter anyway. You can of course get sampling issues where lines that shouldn't be connected are connected and things like that (again with subpixel features).


Now, I'm not saying that screen-space AA techniques are a cure-all -- I've worked with them too much for that. There are a number of problems that have been lamented in the relevant literature since the 90s at least, and I'll try to summarize them here:

The one that's simple to see and has already been mentioned in this thread is whenever you have some feature that is sub-pixel size: you get exactly as much flickering as you would without any AA, since the edge detection doesn't have anything to work with.
This is a general problem with the method, but it doesn't decrease IQ below the previous state - it just doesn't improve it.

The second is harder to see (only in videos), but arguably a bigger inherent problem since it could decrease perceived image stability. What happens is that a slight (1 pixel) change can affect how a whole edge is interpreted. So what you get is a very different edge from one frame to the next, and maybe flickering back and forth between those states. (As opposed to only a single pixel flickering without any AA)

The third problem is not inherent to the technique, but only to the specific implementation used here. Since they use only luminance, they miss hue/saturation edges. (see my previous post) I think this is not a bad trade-off on current hardware, since I also had a rather difficult time finding those edges at native resolution. It's also a problem that could be solved easily at some additional cost by also looking for Hue/saturation edges.

Then there's a fourth problem with this particular version that I don't get at all: Them filtering the UI. This has some really ugly effects on stuff like circles and fonts and is completely unnecessary.

Anyway, the edge quality for sufficiently large feature sizes is still superb particularly considering the computational cost, if you can live with the minor drawbacks.

[joker454]

Originally Posted by PeterT

Well, normally when you do some kind of morphological AA you are very conservative about what you consider an edge (the staircase patterns), so that shouldn't happen too often in textures, and when it does it's usually something you want to filter anyway. You can of course get sampling issues where lines that shouldn't be connected are connected and things like that (again with subpixel features).

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/a...ng_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.

[patsu]

Originally Posted by Silent_Buddha

Would be interesting to see in motion. As in that shot my eye is instantly drawn to all the aliasing, there's quite a bit actually. And that's just with a quick glance...

Usually things get far worse once you see it in action and can see the aliasing "crawl"...

Originally Posted by djskribbles

This guy claims to be an ex-programmer for Pandemic and had this to say regarding the AA.

That link was posted in the previous page.

[grandmaster]

Looking at it in motion, I think it's a real leap. It is fair to say that the general make-up of the game means that the 0xAA on 360 isn't at all ugly, but side-by-side with the PS3 version, it's amazing just how smooth this technique looks. It's a blend, not a blur, and it's hugely impressive with just a few "odd" artefacts.

[nightshade]

Can we have an indepth analysis or dev interview for this in near future ?
It'd be real interesting to hear about this blend technique & its cost.

[AlStrong]

Originally Posted by nightshade

Can we have an indepth analysis or dev interview for this in near future ?
It'd be real interesting to hear about this blend technique & its cost.

Going by what was said at Neogaf, I wouldn't think we'd get much more than our discussion here.

[Butta]

For those interested in learning a little more about this technique, here is an interesting article on MLAA:

http://visual-computing.intel-resear...tions/mlaa.pdf

[Laa-Yosh]

This could be a must-have feature in the next generation of consoles though. Combined with at least 2x (but preferably 4x) MSAA, it could almost completely eliminate aliasing, which is one of the main differences between realtime and offline CG image quality.
The hardware engineers should pay very close attention to this issue so that they won't design an architecture that'd work against its efficient implementations.

[AlStrong]

There are papers that go back farther into the early 90s too, not unlike many other techniques described (even earlier) in the literature but only now just being used in real-time interactive situations.

[semitope]

Am I right in assuming this summarises as "an AA solution that uses the CPU rather than GPU RAM"?

If so it's actually pretty fascinating. If not... wha?

Digitalfoundry has published an article comparing 2 versions of the game and I made the following reply to the post above. I am wondering if its accurate an assumption.

Might have something to do with cell being a CPU/GPU. Its possble this same method can work on dx10 or dx11 GPUs and i'd think the reason its not on the 360 is because xenon is a general purpose CPU exclusively whilst xenos hasn't the extra oomph or feature set.

It wont work on just any CPU basically or just any GPU for that matter. Just a guess.

[AlStrong]

Of course it'll work on a CPU... performance will be the issue instead.

[semitope]

Originally Posted by AlStrong

Of course it'll work on a CPU... performance will be the issue instead.

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

Originally Posted by Silent_Buddha

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

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

[homerdog]

Originally Posted by AlStrong

Of course it'll work on a CPU... performance will be the issue instead.

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

[PeterT]

Originally Posted by homerdog

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

Well.

[PeterT]

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.

[Delta9]

This sounds cool. Is this method able to be slapped on for games already in progress, or would you developers need it from the start?

[corduroygt]

720p at one bpp is 920kb, so they're most likely processing one quarter of the image at a time on a SPU. I wonder if 1 SPU is enough fast enough to do 4 passes including loading new data into the LS, or do they use 2 SPU's, or 4?

[joker454]

Originally Posted by corduroygt

720p at one bpp is 920kb, so they're most likely processing one quarter of the image at a time on a SPU. I wonder if 1 SPU is enough fast enough to do 4 passes including loading new data into the LS, or do they use 2 SPU's, or 4?

Spu's have 256k, but some memory at the bottom is taken by spurs and your code, some memory at the top is taken by stack, and whatever is left over needs to be split in two to double buffer, so that you can be dma'ing new data to one half of that memory while processing current data in the other half. So it would need to be split into more than four parts.

Originally Posted by Delta9

This sounds cool. Is this method able to be slapped on for games already in progress, or would you developers need it from the start?

In can be added in progress. On PS3 it's probably better to do it sooner than later, that way you can reserve the spu time for the task. On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

[Delta9]

Originally Posted by joker454

In can be added in progress. On PS3 it's probably better to do it sooner than later, that way you can reserve the spu time for the task. On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

Thanks for the input.

[Alucardx23]

Originally Posted by joker454

On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

So this kind of AA can also be done on 360?

[semitope]

Originally Posted by joker454

In can be added in progress. On PS3 it's probably better to do it sooner than later, that way you can reserve the spu time for the task. On 360 it would be better to add it closer to the end of the project, so that you could fit the alu heavy parts into sample heavy post process steps, and vice versa, to get as much of the process for free as you can on it's gpu.

I don't understand that. If you intend to do something definitely shouldn't you budget for it from the get go? If a developer decides to put in 2xMSAA constantly in their game wouldn't it be better to develop the game with the aa already part of the process instead of waiting till later to find that such and such level doesn't play too well with aa on. At what point do you start considering what its going to take to get it working well

Originally Posted by Alucardx23

So this kind of AA can also be done on 360?

I am wondering that as well, and how? Also what reason could there be to not work msaa into the 360 and PC builds? In the case of the PC version at least it is strange, unless its a direct port of the 360 version which would leave it with whatever reason there is no aa on the 360.

[joker454]

Originally Posted by Alucardx23

So this kind of AA can also be done on 360?

Yup.

Originally Posted by semitope

I don't understand that. If you intend to do something definitely shouldn't you budget for it from the get go? If a developer decides to put in 2xMSAA constantly in their game wouldn't it be better to develop the game with the aa already part of the process instead of waiting till later to find that such and such level doesn't play too well with aa on. At what point do you start considering what its going to take to get it working well

It comes down to a difference in implementation. First off, there is little incentive to do it on 360 since msaa is free on that platform. We know from peoples comments that the lack of msaa on PS3 versions is deemed not a big deal, or an "extremely minor difference", so we can conclude that the free 2x msaa on 360 is probably good enough for most. For the few games that can't use the free msaa, either because it's not compatible with their engine, or perhaps they are adverse to tiling for whatever reason, then they can consider a post process method.

Implementing this form of AA on 360 turns out to be fairly easy, easier than it would be on PS3. You don't have to carve up data, dma it back, none of that stuff. Think about it, you already have all your post process buffers sitting there in main memory, full Z, reduced Z, color, luminance, all of them totally accessible to the gpu. Just sample them in shader, easy as pie. The catch on the PS3 side is that you have to have enough spu time to spare. The catch on the 360 side is that you have to have enough gpu to spare. The reason to leave it until later in the process on 360 is to wait until your post process steps are nailed down. Then you can take advantage of it's gpu and fit the AA steps into gpu idle time in post process. It's been mentioned other times that sampling does not affect alu's on 360 unlike on PS3, so on 360 you want to move the workload around where it can be absorbed the most. You are more likely to know where the idle times are later in the project after your post process steps are more complete.

[assurdum]

Originally Posted by joker454

Yup.

From what I have readen in neogaf, 360 The saboteur version too use this filter but SPE give more result with this tech (the author at least said that in the reply.)

[corduroygt]

I'm wondering why are there so many games without MSAA on 360 if it's indeed free, are programmers truly that pressed for time? For example why didn't Pandemic use the free MSAA for Saboteur, since they had plenty of time to come up with this unique post process solution in the PS3 version? Come to think of it, it's not even in the PC version where power isn't a concern.

[Fafalada]

Originally Posted by corduroygt

For example why didn't Pandemic use the free MSAA for Saboteur, since they had plenty of time to come up with this unique post process solution in the PS3 version?

The implementation being PS3 specific, there's a cost associated with adapting it to anything else. Not to mention performance characteristics on the other platform - they could have been short on time, money, performance, or all 3 of them.

Come to think of it, it's not even in the PC version where power isn't a concern.

PC is notoriously horrible platform for experimental stuff - anything non-standard is annoying to use for huge-testing time alone. And the % of userbase that really cares will probably have access to SSAA hacks etc., and hw-power to use them, so why bother.