Tsus

Hi!

Will your float texture ever contain negative values?

It's not strikingly elegant, but: in case you need to clear a pixel, you could write out a large negative value, giving you after the additive blending something that is smaller than zero.

When you use the texture later, you could clamp the value again up to zero: max(0, texture_color).

Hi,

Your suggestion is already the solution. So, yeah, you got it right. I'll summarize the steps briefly for you:

Your transparent rendering would happen in the rendering loop after the deferred pass:

1. Fill your deferred buffer (color, depth, …)
2. Do the deferred lighting
3. Render the transparent objects

For the last step, do the following:

1. Disable depth writing (glDepthMask) -> we want no transparent object to be culled by other transparent objects
2. Enable depth test (glDepthTest) -> compare with your deferred depth buffer (cull by opaque geometry)
3. Use additive blending (source: GL_ONE, dest: GL_ONE)
4. Bind two new render targets; let’s call them AccumColors (four (half) float components) and AccumCount (single float component)
5. Render the transparent objects into those two targets (explained in a moment)
6. Bind deferred color buffer as render target
7. Disable depth test (glDepthTest)
8. Use back-to-front blending (source: GL_ONE_MINUS_SRC_ALPHA, dest: GL_SRC_ALPHA)
9. Bind AccumColor and AccumCount as textures
10. Full screen pass: compute the average color/transparency (explained in a moment) and blend with the deferred color buffer

The idea is to compute the average of the colors, weighted by their transparencies. For blending with the background, we additionally need the average opacity. (FYI: I assume that alpha = 1 means opaque, and alpha = 0 means transparent)

Step 5 computes the sums. This is what the fragment shader does:

Input: vec3 color, float alpha
Output: 
  AccumColor = vec4(color*alpha, alpha);  // color multiplied (=weighted) with alpha!
  AccumCount = 1;

Step 10 compute the average color. Again, the fragment shader:

Input: vec4 AccumColor, float AccumCount

if (AccumCount < 0.00001 || AccumColor.w < 0.00001)
{
  discard;  // nothing here; discard the fragment.
}
else
{
  vec4 avgColor = vec4(
  AccumColor.xyz / AccumColor.w,    // weighted average color
  AccumColor.w / AccumCount);        // average alpha
  // the alpha, used to blend with the background is computed by assuming 
  // that all transparent layers have the average alpha:
  float dstAlpha = 1-pow(max(0,1-avgColor.w), AccumCount);
  // write out the average color and the alpha, used for compositing
  result = vec4 (avgColor.xyz, dstAlpha);
}

Hope that gives some insights.

Best regards!

Hi!

Your render target view (that views the texture to render into) and your depth stencil view (the corresponding depth buffer) have different multi-sampling settings.
When using multi-sampling, every pixel needs to store extra data for the sub-samples (their depth and the coverage bits). Each texture resource is prepared for one certain multi-sampling setting and to make them work together, both the color texture and the depth buffer (after all, it’s just another texture) need the same setting. You can have resources with different settings, but you can only bind them together, if their settings coincide.

If you disable multi-sampling, it would be:

sampleDesc.Count = 1;
sampleDesc.Quality = 0;

High-quality 4x MSAA (for instance) is achieved by setting:

sampleDesc.Count = 4;
sampleDesc.Quality = 16.

Keep in mind that MSAA comes at a cost. If you don’t need it, try to avoid it. Also, combining multi-sampled with single-sampled textures requires you to convert one into the other. (I'd advise you to first familarize yourself with the rendering to textures, before working with multi-sampling)

Okay, so try to set in your default texture (system class):

texd.SampleDesc.Count = 1; 

and make sure that your view dimensions are set to the single-sampled types, e.g.,

for the depth stencil view: D3D11_DSV_DIMENSION_TEXTURE2D  (not: D3D11_DSV_DIMENSION_TEXTURE2DMS).
 

Cheers!

I'm not quite sure, but.. right next to the big rock in the center seems to be a pattern that repeats (the faster texture layer).

Somehow the layer seems to move very, very slowly perpendicular to the flow direction, because this patterns moves after 3 or 4 iterations closer to the rock.

From that I'd guess they used static textures.

Perhaps just try to implement this with static textures first. I guess, having nice textures does the trick, here.

Hi!

Since you have to specify which slice you want to render into in a geometry shader by using the semantic SV_RenderTargetArrayIndex, I'd suggest to use the geometry shader approach.

I would render 100 vertices as a point list, without actually binding a vertex buffer (so that you get 100 vertex shader invocations).

The vertex shader does nothing.

In the geometry shader you can take the SV_PrimitiveID (in 0..99) to specify the target slice to render into. Expand then a quad (as a triangle strip) with the coordinates (-1,-1,0) (-1,1,0) (1,-1,0) (1,1,0).

The pixel shader receives with SV_Position the texel coordinate in the slice. (Additionally you can pass the SV_PrimitiveID from the geometry shader to the pixel shader, if you need the slice id.)

Be careful, though, because SV_Position comes in as float, so better cast it to int.

You can also use a compute shader, if you want to avoid the rasterization pipeline. (Hard to tell, whether it will be faster, since you'd need to switch from the rasterization pipeline to the compute pipeline and back. If I recall correctly, I heard in a talk at gamefest someone mentioning that frequent switches are to avoid.)

Cheers!