Render to texture effects and MSAA...

[Guden Oden]

The increasingly popular bloom effect is messing with antialiasing in some titles. I remember the latest demo version of Painkiller had issues here whenever bloom was enabled, but they fixed that in the release version.

Now the issue is with World of Warcraft instead, enabling bloom (or as it's known there, 'full-screen glow effect' or somesuch) will also turn off AA on both my 9800 and 6800... Unfortunately, AA has a big IQ impact in that particular title due to its low poly density and many nearly horizontal/vertical lines.

Why is that, really? From what I've been told, bloom is just a transparent texture laid on top of the rest of the graphics, so if any render-to-texture limitations with MSAA are concerned, they should only apply to the bloom texture, and there it shouldn't matter because that's just a big blur anyway.

So what's the deal here really?

And can someone please tell me why the Lampion shader compo entry refuses to run on my 6800, stating: "Device doesn't support floating point render target texture (D3DFMT_R32F)!

Shouldn't the 6800 have MORE comprehensive support in this regard than the 9800, or has Nvidia still no support for floating point render targets after over 2 years since DX9 was released? :?

 

[bloodbob]

Why is that, really? From what I've been told, bloom is just a transparent texture laid on top of the rest of the graphics, so if any render-to-texture limitations with MSAA are concerned, they should only apply to the bloom texture, and there it shouldn't matter because that's just a big blur anyway.

Okay the reason was in the intial DX9 sdk/ddk or whatever there wasn't a way to disable or vice-versa enable AA and AF on render to texture. So of course everyone disabled those effect because for reflections and stuff you don't really need it. Since no bothered has bothered to update their SDK and use the new features ( it might be something seperate to render to texture ) so all these new games still don't support AA with framebuffer effects.

 

[AlNom]

that's it???

Just update the SDK? Or am I missing the hard part...

 

[bloodbob]

that's it???

Just update the SDK? Or am I missing the hard part...

Update the SDK and change some code I believe I don't like d3d so I haven't really touched it.

 

[Xmas]

And can someone please tell me why the Lampion shader compo entry refuses to run on my 6800, stating: "Device doesn't support floating point render target texture (D3DFMT_R32F)!

Shouldn't the 6800 have MORE comprehensive support in this regard than the 9800, or has Nvidia still no support for floating point render targets after over 2 years since DX9 was released? :?

This is strange, NV4x does support R32F.
However, do not assume NV4x supports every texture format R3x0/R4x0 does (and vice versa).

that's it???

Just update the SDK? Or am I missing the hard part...

Yes, updating the SDK/runtime and knowing when and how to use IDirect3DDevice9::StretchRect().
There's one GDC presentation from NVidia describing this: http://download.nvidia.com/developer/presentations/2005/GDC/Direct3D_Day/D3DTutorial06_Effects.pdf

 

[DOGMA1138]

for the 9800 just run WoW in OpenGL mode and use the HDRish smart shader. AA will work fine im not so sure about the preformance tho.
for the 6800 shouldn`t SSAA work with the bloom effect? SS should sample textures w/o polygon edges no?

 

[Inane_Dork]

that's it???

Just update the SDK? Or am I missing the hard part...

Yes, updating the SDK/runtime and knowing when and how to use IDirect3DDevice9::StretchRect().
There's one GDC presentation from NVidia describing this: http://download.nvidia.com/developer/presentations/2005/GDC/Direct3D_Day/D3DTutorial06_Effects.pdf

If that's the presentation I'm thinking of, I thought there was a huge hole in it. Rendering to the backbuffer enables support for all modes of MSAA, yes. But it also kinda takes the "H" out of "HDR." The whole point of allocating a scree-sized off-screen buffer was that the backbuffer does not support HDR formats (yet).

Anyway, sorry if I'm thinking of a different presentation.

 

[LeGreg]

If that's the presentation I'm thinking of, I thought there was a huge hole in it.

There is no way you can get multisample AA with floating point rendertarget, whatsoever. This is not the point of the discussion.

Both the thread and the presentation are about "antialiasing and post processing", you've apparently missed that.

 

[Guden Oden]

for the 9800 just run WoW in OpenGL mode and use the HDRish smart shader.

Not sure it will be comparable. The glow effect in WoW, in case you haven't seen it, is very subtle. It's easy to miss it altogether, mostly it just tends to make the graphics slightly brighter overall.

for the 6800 shouldn`t SSAA work with the bloom effect?

But Nvidia's SSAA is ordered-grid, no? If so, it's POS quality compared to the RG-MSAA they offer, plus lots slower too. Speed might not be an issue in WoW as it's such a non-intensive title, but it would be in other titles I wager if I forced SSAA on globally (as there is no switch in-game in any title that I know of for this type of AA).

 

[Inane_Dork]

There is no way you can get multisample AA with floating point rendertarget, whatsoever.

Right now, yeah. I already stated so. I'm not sure what you're getting at by driving the point home.

This is not the point of the discussion.

Both the thread and the presentation are about "antialiasing and post processing", you've apparently missed that.

I know. I'm quite aware (though I should point out the thread is not exactly about that, but I wave that point). I'm not sure why you're so snippy with me.

My point is that HDR is needed for some post processing effects. Tone mapping, camera exposure adjustment and light bloom/flare are all post process effects that require or can be built on HDR rendertargets. And I thought it a very valid point to bring up that HDR and AA do not mix right now.

It's all on-topic. I don't see how it could be more on topic than it is.

 

[Guden Oden]

And I thought it a very valid point to bring up that HDR and AA do not mix right now.

It's all on-topic. I don't see how it could be more on topic than it is.

On-topic, apart from absolutely no titles whatsoever available right now use those techniques. Particulary not world of warcraft!

 

[OpenGL guy]

Okay the reason was in the intial DX9 sdk/ddk or whatever there wasn't a way to disable or vice-versa enable AA and AF on render to texture.

You most certainly can use AF when rendering to a texture: Texture samplers are completely unaffected by what sort of render target you are rendering to.

Also, you can certainly have AA on render targets. If you look at the SDK docs you'll see that CreateRenderTarget() has an msType field. The issue is that CreateTexture() does not have an msType field. Thus, if you do render to texture, you can't get MSAA. DX9.0a added a workaround for this by allowing you to render to a MSAA render target then allowing a StretchRect() to the texture you want AA on. Previously, StretchRect() required that both surfaces have matching msTypes.

Now, if your application does not support AA (WoW doesn't) then you can't expect forced AA to work with post-processing effects because the app is not going to know to follow the procedure I discribed above.

 

[DOGMA1138]

EDIT: since the new patch the bloom effect doesnt messup AA!!! YEY!

for the 9800 just run WoW in OpenGL mode and use the HDRish smart shader.

Not sure it will be comparable. The glow effect in WoW, in case you haven't seen it, is very subtle. It's easy to miss it altogether, mostly it just tends to make the graphics slightly brighter overall.

for the 6800 shouldn`t SSAA work with the bloom effect?

But Nvidia's SSAA is ordered-grid, no? If so, it's POS quality compared to the RG-MSAA they offer, plus lots slower too. Speed might not be an issue in WoW as it's such a non-intensive title, but it would be in other titles I wager if I forced SSAA on globally (as there is no switch in-game in any title that I know of for this type of AA).

from what i`ve seen the bloom on NV4X hardware looks just like the HDRish SM, on any other hardware i havent seen any diffrence.

oh and is this bloom+aa?

 

[Guden Oden]

EDIT: since the new patch the bloom effect doesnt messup AA!!! YEY!

That patch hasn't gone live in europe yet. It's those damn lederhosen and frogeaters who refuse to learn english that slow everything down with their damn localization needs... The italians and spanish have to make do with english WoW I believe (not to mention all of eastern europe, greece etc), so why can't the german and the french?

 

[DOGMA1138]

heh the itlian and spanish just hijacked servers, agamaga somthing is the "official" spanish server, and the chat is floded with spanish.

 

[Demirug]

Also, you can certainly have AA on render targets. If you look at the SDK docs you'll see that CreateRenderTarget() has an msType field. The issue is that CreateTexture() does not have an msType field. Thus, if you do render to texture, you can't get MSAA. DX9.0a added a workaround for this by allowing you to render to a MSAA render target then allowing a StretchRect() to the texture you want AA on. Previously, StretchRect() required that both surfaces have matching msTypes.

Yes, but it seems that this did not work in any case with current ATI drivers. If I do this it looks like that the StretchRect copy only one of the four samples to the surface of the texture.

Now, if your application does not support AA (WoW doesn't) then you can't expect forced AA to work with post-processing effects because the app is not going to know to follow the procedure I discribed above.

It can work if you render to the backbuffer and than use StretchRect to copy the backbuffer to a texture. In this case the application does not need to support AA because the driver knows that the backbuffer have AA. Splinter Cell 3 as an example does it this way.

 

[OpenGL guy]

Also, you can certainly have AA on render targets. If you look at the SDK docs you'll see that CreateRenderTarget() has an msType field. The issue is that CreateTexture() does not have an msType field. Thus, if you do render to texture, you can't get MSAA. DX9.0a added a workaround for this by allowing you to render to a MSAA render target then allowing a StretchRect() to the texture you want AA on. Previously, StretchRect() required that both surfaces have matching msTypes.

Yes, but it seems that this did not work in any case with current ATI drivers. If I do this it looks like that the StretchRect copy only one of the four samples to the surface of the texture.

Known driver limitation, stay tuned!

Now, if your application does not support AA (WoW doesn't) then you can't expect forced AA to work with post-processing effects because the app is not going to know to follow the procedure I discribed above.

It can work if you render to the backbuffer and than use StretchRect to copy the backbuffer to a texture. In this case the application does not need to support AA because the driver knows that the backbuffer have AA. Splinter Cell 3 as an example does it this way.

Except that this may not be possible if the backbuffer contains data you want to keep. Anyway, I said, "You can't expect..." that doesn't mean it's impossible it just means that you shouldn't expect it to work.

 

[LeGreg]

Known driver limitation, stay tuned!

What is the limitation ? I would expect it to work, considering
many products out there use the capability ?

Except that this may not be possible if the backbuffer contains data you want to keep. Anyway, I said, "You can't expect..." that doesn't mean it's impossible it just means that you shouldn't expect it to work.

Hmm.. usually you discard backbuffer info between frames (especially on ATI's hardware which needs the clear between frames to be fully accelerated), so what's wrong with
render to backbuffer, stretchrect to texture, render the rest to backbuffer, display ?
Or do you mean something else ?

 

[OpenGL guy]

Known driver limitation, stay tuned!

What is the limitation ? I would expect it to work, considering many products out there use the capability ?

Since you know so much about ATI's drivers, you tell me!

Except that this may not be possible if the backbuffer contains data you want to keep. Anyway, I said, "You can't expect..." that doesn't mean it's impossible it just means that you shouldn't expect it to work.

Hmm.. usually you discard backbuffer info between frames (especially on ATI's hardware which needs the clear between frames to be fully accelerated), so what's wrong with render to backbuffer, stretchrect to texture, render the rest to backbuffer, display ?
Or do you mean something else ?

If the application only uses a single texture for multiple effects, you can't render to backbuffer, copy to texture, render to backbuffer with the texture, then do the same process for the next effect since the backbuffer already has data that can't be overwritten..

 

[LeGreg]

If the application only uses a single texture for multiple effects, you can't render to backbuffer, copy to texture, render to backbuffer with the texture, then do the same process for the next effect since the backbuffer already has data that can't be overwritten..

So what is your proposal to improve the API ? Allow for multisampled textures ?