Problem, Rendertarget alpha == 1.0 always

[Ethatron]

I'm using ARGB16F screen-space rendertargets with alpha-blend and -test off. Still I can't transfer data through the alpha-channel, it's always 1.0. I also tried enabling blending just to see what's on, but instead of blending it still contains 1.0, and no blending occurs.
I'm a DX9-noob, all I know I learned by hacking Oblivion, and of course the rendertargets are in the middle of Oblivions post-pass itself.

Is there a specific location I have to look through to detect why this occurs? I tried searching but apparently it's not a common issue.

Another tangent: I also would love to implement a bokeh-effect with aparture-shape textures. I'd love a suggestion how to generate texture-quad positions for later screen-space blending under the DX9-API. I was reading about R2VB but I have the impression you have to create a fixed amount of geometry (vertex-buffer size), and you can't discard pixels with clip() while writing to the VB to ceate a variable number of coordinates. Point-sprites also came to mind, but I don't know if I can create and handle them entirely on the GPU, and I think I can't change the base-color of a point-sprite texture.

 

[Simon F]

I'm using ARGB16F screen-space rendertargets with alpha-blend and -test off.

Can you try an 8888 buffer and, if so, what happens?

 

[Ethatron]

Can you try an 8888 buffer and, if so, what happens?

Yes, that works.
Hardware is a 5870 I doubt FP16 targets can't have alpha with that hardware. I don't know about DX9 though. Maybe I need some magic-value SetRenderState like with enabling fetch4?

 

[MJP]

I'm using ARGB16F screen-space rendertargets with alpha-blend and -test off. Still I can't transfer data through the alpha-channel, it's always 1.0. I also tried enabling blending just to see what's on, but instead of blending it still contains 1.0, and no blending occurs.

You shouldn't have to anything special to write data to the alpha channel. As long as alpha blending is off and the render target has an alpha channel, you should be able to write with it and sample it just like the RGB channels. How have you determined that the alpha channel is always 1.0? Have you tried using PIX yet to peek at your render targets or debug your shaders?

Another tangent: I also would love to implement a bokeh-effect with aparture-shape textures. I'd love a suggestion how to generate texture-quad positions for later screen-space blending under the DX9-API. I was reading about R2VB but I have the impression you have to create a fixed amount of geometry (vertex-buffer size), and you can't discard pixels with clip() while writing to the VB to ceate a variable number of coordinates. Point-sprites also came to mind, but I don't know if I can create and handle them entirely on the GPU, and I think I can't change the base-color of a point-sprite texture.

You're somewhat limited with DX9, since you don't have proper means of implementing a feedback loop on the GPU. R2VB or vertex texture fetch are options, but like you already mentioned you have to stick with fixed amounts for rendering to your texture and for your draw calls. However you can always just have some means for clearly marking vertices that shouldn't be drawn, and then have your vertex shader move them off-screen. I know for the DX10 version of Lost Planet/Lost Planet 2 they implemented bokeh by having a 2D grid of verts, which sampled a downsampled version of the screen and then rendered bright spots as sprites, which should also be doable in DX9 with point sprites.

In DX11 you have a lot more flexibility for this sort of thing. I made a demo in DX11 that does it by extracting suitable points from the full res screen texture, and appending them onto an AppendStructuredBuffer (basically a stack that your shaders can push data onto). Then I used a DrawIndirect call to render the N points in the buffer as point sprites.

 

[Ethatron]

You shouldn't have to anything special to write data to the alpha channel. As long as alpha blending is off and the render target has an alpha channel, you should be able to write with it and sample it just like the RGB channels. How have you determined that the alpha channel is always 1.0?

I have two alterning rendertargets ping-ponging in a multipass effect, I can do:

...
return float4(0,0,0,0.333);
}

float4 next(float4 in) {
return in.a;
...

Just a sketch of course, but I don't have any problems verifying what's in .a, it's always 1.0 with ARGB16F, and the correct value with ARGB8 - no other changes or switches applied.

Have you tried using PIX yet to peek at your render targets or debug your shaders?

We inject a DLL into Oblivion we can not use PIX.
I know that inside the geometry-pass Oblivion can alpha-blend water for example into the ARGB16F-target. It's just that in the post-effects-pass where we have problem. I don't know which things can cause a==1.0 but I'd appretiate a hint where to look.

You're somewhat limited with DX9, since you don't have proper means of implementing a feedback loop on the GPU. R2VB or vertex texture fetch are options, but like you already mentioned you have to stick with fixed amounts for rendering to your texture and for your draw calls. However you can always just have some means for clearly marking vertices that shouldn't be drawn, and then have your vertex shader move them off-screen. I know for the DX10 version of Lost Planet/Lost Planet 2 they implemented bokeh by having a 2D grid of verts, which sampled a downsampled version of the screen and then rendered bright spots as sprites, which should also be doable in DX9 with point sprites.

Yes I know, fake scattering writes. Sadly the downsampled variant ...

In DX11 you have a lot more flexibility for this sort of thing. I made a demo in DX11 that does it by extracting suitable points from the full res screen texture, and appending them onto an AppendStructuredBuffer (basically a stack that your shaders can push data onto). Then I used a DrawIndirect call to render the N points in the buffer as point sprites.

... I consider no option for trying to port _your_ Bokeh to DX9-Oblivion. Though the non-bokeh related portion works just fine. Rendertargets are automipped, I use tex2Dlod (thus the gather-version) and it looks great with great performance.

 

[Ethatron]

So what could be the issue? We know alpha-blending itself in the FP16 target works because the mainpass just functions right. In the screenspace post-pass we simply turn off alpha-blend, alpha-test, z-write and culling. And the alpha-channel in (all) post-effect with multiple passes and two alterning RTs is always 1.0. Switching to non-HDR INT8 targets just functions correct.

What would be my checklist? Trying INT16 RTs fe.? I have to stick to the FP16s in the end.

 

[Davros]

are these pixels supposed to be between 0.0 and 1.0
rounding error maybe ?

 

[LeGreg]

Have you tried writing for something else than Oblivion ?
The AMD driver may do some "optimization" behind the scene which results in the alpha seemingly not written on your end.
(actually from what I remember they convert all FP16 targets to a smaller 32bit compressed float format. So I would try to write my own app, or rename the Oblivion executable).

 

[Davros]

Enable Surface Format Optimization

The Surface Format Optimization checkbox allows improved performance in selected games that use 16-bit floating point surfaces for HDR rendering.
AMD developed a profile that intercepted calls to FP16 formats and substituted them for FP11.

 

[Ethatron]

Have you tried writing for something else than Oblivion ?
The AMD driver may do some "optimization" behind the scene which results in the alpha seemingly not written on your end.
(actually from what I remember they convert all FP16 targets to a smaller 32bit compressed float format. So I would try to write my own app, or rename the Oblivion executable).

Hmm, that's an interesting notion. I'm going to try to fool the driver a bit then. Too bad we don't have any control over the application of those game-patches. Or do we, with some CAP-tool?

Hm, thinking about it, this would mean on nVidia hardware the alpha-channel should work just fine if the theory is right.

Would it have some prospect of success to write Dave to get in contact with the driver-programmers?

 

[Ethatron]

Enable Surface Format Optimization

The Surface Format Optimization checkbox allows improved performance in selected games that use 16-bit floating point surfaces for HDR rendering.
AMD developed a profile that intercepted calls to FP16 formats and substituted them for FP11.

Ah, damn, I think I start hating driver-side game-patches. I shall try that. Is it a given that "Enable Surface Format Optimization" turns it off those game-manipulations definitely?

 

[Davros]

I think it is, if its off its off

 

[Ethatron]

Hey guys.

A thousand thanks for that tip, the surface-optimization removed the issue, as well as other problems (like artefacts with manual MLAA on the HDR-buffer).

This means Oblivion is now officially a MLAA-native citizen.
Takes 0.09ms on my 5870 with FP16 rendertargets and 1400x1050.

Too bad we now have to advise everyone to turn both (MLAA & surface optimization) off. I'd love to be able to control that from the application-level, but well ...

So after MLAA, FXAA and DLAA I'd love to try Humus' GPAA but I got no edge-information yet, seems I have to wait for GPAAv2, or the achievement of a z-prepass, which I very much like to persue, but which is of course very difficult (try to hack an entire custom renderpass into the render-pipeline of a game you only got the binary from).

 

[Davros]

nfs shift2 didnt work with surface-optimization (cars appear all white)
and it was fixed in a driver update
im just wondering if you rename oblivion.exe to shift2u.exe does the problem disappear ?