Trouble setting depth in a shader for a Material Topic is solved

[jwwalker]

I have a Material whose fragment shader sets color and depth, and the color is showing up but the depth is not. (To debug, I dump the color and depth textures to image files after rendering a frame.) I've fiddled with depth in a Material's fragment shader before, but previously the Material was used by a render_quad pass, and now I am directly applying the Material to Items. The material script specifies depth_check off and depth_write on, and likewise when I create the Material, I supply an HlmsMacroblock with mDepthCheck = false and mDepthWrite = true. The rendering of these Items is happening in a render_scene pass whose script specifies store { depth store }.

The Metal fragment shader looks like:

Code: Select all

#include <metal_stdlib>
#include <metal_math>
using namespace metal;

struct PS_OUTPUT
{
    float4 color [[color(0)]];
    float depth [[depth(any)]];
};

fragment PS_OUTPUT main_metal
(
    depth2d<float, access::read>    reflectedDepthMap   [[texture(0)]],
    depth2d<float, access::read>    mainDepthMap        [[texture(1)]],
    float4 gl_FragCoord [[position]]
)
{
    PS_OUTPUT result;
    // irrelevant stuff
    result.depth = 0.0;
    result.color = float4( 1.0, 0.5, 0.0, 1.0 );
    return result;
}

Any idea what could be wrong?

[dark_sylinc]

Disabling depth checks force-disables depth writes.

What you want to do is:

Code: Select all

depth_func always
depth_check on
depth_write on

This will tell the GPU to always pass the depth check (as if there were no depth check) while also writing.

[jwwalker]

Thanks! By the way, do I need to specify the depth options both in the material script and in the HlmsMacroblock?

[dark_sylinc]

When the material is being parsed Ogre will create an HlmsMacroblock with the settings you provide (or use defaults otherwise).

If you later want to change a setting you need to specify all the settings from scratch to form a new HlmsMacroblock.

If you create a new HlmsMacroblock with the exact same settings it already had, you'll end up wasting a few cycles because we search if a block with those settings already exists and return the same internal/cached handle (they are reference counted).