Help wanted for MSAA and PS 1.1 algo (artifacts)

[Reverend]

Guys,

The Problem

MSAA breaks the [edit]normal[/edit] vision glow algorithm - artifacts are lights poking/seen through walls.

The MSAA issue with [edit]normal[/edit] vision glow algorithm :

(1) Render the scene normally, render every glowing object (it's a texture or object issue in normal vision, not a light intensity issue) with the stencil op at SET (to 1) and at SET (to 0) when it's not glowing.
(2) Replace the render target by a texture (cleared) but keep the stencil buffer, render every glowing object with it's associated glowing texture but only render if the stencil bit in the buffer is equal to 1.
(3) Do post processing filtering on the glow buffer (similar to the one in night vision)
(4) Add the result into the original render target to create the glow effect.

Step (2) is the problem. The Stencil/Depth buffer is allocated multisample but the render target (a texture) can't be allocated multisample... This means you "merge" a multisample surface (depth/stencil) with a non multisample surface (texture) and this is simply not allowed in DirectX.

Suggestions appreciated.

 

[ultrafly]

"glow buffer" is the second render target?

The second render target is only contain the glowing object associated glowing texture,then do post processing filtering on it. The post processing is only add noise(because you didn't render the scence to the second render target)?

Why did you use the stenci buffer?

I think:
(1)for every glowing object
if object is glowing
render it with it's associated glowing texture
(2)do post processing filtering on it
(3)replace the render target
(4)render the scence and every object normally
(5)render the fullscreen rectangle associated the first render target use some blend.

 

[Xmas]

"glow buffer" is the second render target?
Why did you use the stenci buffer?

I think because you don't need to render the whole scene twice, only the glowing objects.

In your proposal in (1), you need to render Z/stencil for all objects to find which glowing objects are visible. That's the reason they're trying to keep Z/stencil but render to another color target.

 

[ultrafly]

"glow buffer" is the second render target?
Why did you use the stenci buffer?

I think because you don't need to render the whole scene twice, only the glowing objects.

In your proposal in (1), you need to render Z/stencil for all objects to find which glowing objects are visible. That's the reason they're trying to keep Z/stencil but render to another color target.

I have a mistake.
It is a night vision,not a infrared thermal.

 

[Reverend]

Why did you use the stenci buffer?

Stencil buffer is used for the shadows. There are two options - either use shadow projection; or use shadow buffer... it depends on whether a video chip has depth texture support (DX8.1) or not. Under DX8.1, rendering into depth textures cannot be done on a R300 but can be done so on a GF3/GF4Ti/GFFX/Xbox.

 

[Reverend]

I have a mistake.
It is a night vision,not a infrared thermal.

Let's concentrate on the night vision algorithm, which is where the problem lies, but for information sake, the thermal vision algo uses 2 sequential dependant textures fetches using 2 pixels shaders execution one after the other, which could be done in a single ps_1_4 pass.

 

[ultrafly]

I have a mistake.
It is a night vision,not a infrared thermal.

Let's concentrate on the night vision algorithm, which is where the problem lies, but for information sake, the thermal vision algo uses 2 sequential dependant textures fetches using 2 pixels shaders execution one after the other, which could be done in a single ps_1_4 pass.

Your means is render the thermal object uses 2 sequential dependant textures fetches ?

 

[ultrafly]

"This means you "merge" a multisample surface (depth/stencil) with a non multisample surface (texture) "

Why did you merge the depth/stencil buffer with the render target ?

I think the object of the "merge" should been the first render target and the second render target.

 

[Reverend]

Your means is render the thermal object uses 2 sequential dependant textures fetches ?

Yes.

This means you "merge" a multisample surface (depth/stencil) with a non multisample surface (texture)

Why did you merge the depth/stencil buffer with the render target ?

I (or rather, Ubisoft) didn't because it can't be done under DX. Re-read my post about this part

 

[Joe DeFuria]

Just a related question....

Doe the same problems exist with supersampling methods?

 

[Reverend]

Just a related question....

Doe the same problems exist with supersampling methods?

I doubt so (i.e. I think SS would solve the problem) but I can't really tell at the moment because I have R300 in my box and I don't think there's anyway to "force" it to SS.

But you bring up a point I didn't think of before, hehe . Multisampling breaks a lot of past assumptions about texel centers and polygon coverage. Multisampling only helps edge aliasing, and doesn't do anything about aliasing on the interiors of polygons. That's a fine tradeoff when you're doing diffuse texturing, because bilinear/trilinear filtering antialiases the interiors properly. But when you go to per-pixel lighting, especially with non-linear lighting equations (like Blinn/Phong specular lighting), filtering of your source textures doesn't lead to proper post-light filtering of the resultant pixels.

 

[Joe DeFuria]

Right...another reason why I'd like to still have SuperSampling as an option...espectially for the latest cards with 'monster' fill-rate.

I hope ATI decides to follow-through with the supoer-sampling option for Smoothvision on the R350...

Multisampling is a great trade-off, but espeically now with pixel shading and post-processing, we are starting to really see some of the drawbacks.

 

[DeanoC]

Yep forced FSAA (User's overriding the app) should be banned.

SH2PC has loads of fullscreen filters and a few had to be turning off if we detected FSAA. Detecting FSAA isn't easy in an app, so sometimes you just get incorrect visuals. Nothing we could do bar warn people in the readme.

It occurs on any chipset/driver that overrides our explicit creation setting. When FSAA is forced on us, it changes the rules, the very rules we rely on for fancy effects.

We really need some kind of flag on the create render target calls to say NO FSAA no matter what the user asked for.

Unfortunatly I can't help Rev/Ubisoft, just to say I know your pain. And if they do come up with a solution I like to know it. All we could do was render a test triangle and then try and detect if FSAA had occured when rendering, if was far from fool proof.

 

[Joe DeFuria]

Yep forced FSAA (User's overriding the app) should be banned.

No........

If you can guarantee that every software developer will include FSAA in their new games as an option (where MSAA is viable), and develoeprs of all old games will release patches to have AA as an adjustable in-game feature, then it shoud certainly not be banned.

I understand your pain though. It should just be stated somewhere plainly that MSAA doesn't WORK with the game, and that it's not a driver bug or coding problem. So if it's forced, expect artifacts. Even if

 

[DeanoC]

Yep forced FSAA (User's overriding the app) should be banned.

No........

If you can guarantee that every software developer will include FSAA in their new games as an option (where MSAA is viable), and develoeprs of all old games will release patches to have AA as an adjustable in-game feature, then it shoud certainly not be banned.

I understand your pain though. It should just be stated somewhere plainly that MSAA doesn't WORK with the game, and that it's not a driver bug or coding problem. So if it's forced, expect artifacts. Even if

O.K. Maybe banned is a bit harsh BUT it should NEVER override us when we explicitly set no multi-sampling. I have a parameter, I asked for NONE, its actually a driver BUG to decide I don't know what I'm doing.

As I said, the best option would be to have the default as I_DONT_CARE and a flag to say NO_MEANS_NO.

Several reasons why the current system is bad,
A) Publisher's class this kind of visual errors as class A. No excuses if there is no fix, no ship.
B) Why shouldn't 99% of a game use FSAA with just 1 effect not using it. Thats what the API is designed for, we ask for it and control it explicitly but the current system where the user overrides us cause they think the know best, means 1 possible vital scene gets screwed.

IMHO no game that uses Dx8 or later should have its multi-sample setting overridden by the driver. I consider it no different from lying about hardware TnL capability (3DFX, ATI and nVidia have done or still do this), cutting up texture (3DFX cutting up textures >256) or even GFFX forcing FP16 in PS_2_0

 

[Joe DeFuria]

O.K. Maybe banned is a bit harsh BUT it should NEVER override us when we explicitly set no multi-sampling.

That, I agree with!

 

[GraphixViolence]

IMHO no game that uses Dx8 or later should have its multi-sample setting overridden by the driver. I consider it no different from lying about hardware TnL capability (3DFX, ATI and nVidia have done or still do this), cutting up texture (3DFX cutting up textures >256) or even GFFX forcing FP16 in PS_2_0

Perhaps if more games actually implemented a way to adjust FSAA settings via menus, this might make sense. But right now most games do not, and the few that do often recognize the settings for NVIDIA cards only and not ATI or anyone else. So the only way to get nice looking anti-aliased games with all the fancy new graphics cards is to have some way to force it on in the control panel.

 

[Reverend]

Whoops... I just found out that MSAA doesn't break the night vision glow algo but breaks the normal vision glow algo. My original post is edited to reflect this (I've removed the entire part containing the night vision algorithms).

 

[Reverend]

Okay, here's the visual representation of the artifacts when MSAA is used in normal vision when glow algorithm is used.

Glow Without MSAA

Glow With MSAA (i.e. the artifacts)

Horrendous isn't it?

Images taken with R300. MSAA when used is at 4x.

 

[Colourless]

The problem could be fixed by both ATI or Ubisoft. However, it's not strictly a problem just caused by either of them as far as I am concerned, but I don't know enough of the game internals. Forcing FSAA was bound to have some 'massive' issue on some game sooner or later, and it looks like this is the one.

Anyway, it should be obvious why this could be caused an ATI issue. They are not creating framebuffer in the format that is desired. The application thinking that the buffer is in the format it requested then tries to do something that then doesn't work (it's unintentionally mixes multisampling and non-multisampling surface). Now, ATI could 'fix' it by downsampling the multisample depth stencil surface to a non-multisampled surface. This however is only likely to work in very few cases (this game for one), and would likely break with other possible future games because the Z-values are going to be slightly wrong.

Now, as to why this could be a Ubisoft issue. IF they are actually using Render To Texture (rather than using a separate surface created with IDirect3DDevice8::CreateRenderTarget) they would be doing something that isn't exactly advised, which is mixing surfaces with different dimentions as render targets. The render to texture surface is not going to be the same size as the depth stencil surface. Now, for them to 'fix' this they would have to have 2 separate depth stencil surfaces, and have to re-render the scene to the second depth surfaces. This is going cause a performance penalty, and is obviously best avoided.