[v7 Beta 10] GData.depth is 0

[JohannesKlauss]

Description of the bug

I am fiddling around with the v7 branch, because the new render pipeline architecture looks super convienent to me. I tried accessing the depth value in GData, but it always returns 0.

To reproduce

• Use v7.beta-10 & three.js 0.175

• Set up renderer:

const renderer = new WebGLRenderer({
        powerPreference: "high-performance",
        antialias: false,
        stencil: false,
        depth: false,
        canvas,
      })

• Create a pass with this shader:

vec4 mainImage(const in vec4 inputColor, const in vec2 uv, const in GData data) {
    return vec4(vec3(data.depth), 1.0);
}

export class OutlineEffect extends Effect {
  constructor(args: ConstructorArgs) {
      super("OutlineEffect")

      this.fragmentShader = fragmentShader

      const uniforms = this.input.uniforms

      uniforms.set('uScale', new Uniform(args.scale || 1))
  }
}

• Add pass to render pipeline:

renderPipeline = new RenderPipeline(renderer);

    renderPipeline.add(
      new ClearPass(),
      new GeometryPass(scene, camera),
      new DepthCopyPass(),
      new EffectPass(new FXAAEffect(), new OutlineEffect())
    );

• Canvas is rendered black

Is this already implemented and do I actually need the DepthCopyPass? Because according to the manual the pass sets the depth value automatically.

And since I am already here, I got another question. The v7 manual states:

To sample depth at any location, use readDepth(depthBuffer, uv)

What is depthBuffer refering to? Trying to access gData.depth throws a compilation error: ERROR: 0:284: 'depth' : no such field in structure

Is the whole depth functionality not yet implemented?

Expected behavior

The depth value is set

Library versions used

• Three: 0.175.0
• Post Processing: 7.beta-10

Desktop

• OS: Mac OS 15.3.2 (24D81)
• Browser: Brave v1.76.82
• Graphics hardware: Apple M2 Max:

[JohannesKlauss]

Looking through the code I realized that I have to add the depth Buffer to the gBuffer input in the Effect class:

export class OutlineEffect extends Effect {
  constructor(args: ConstructorArgs) {
      super("OutlineEffect")

      this.fragmentShader = fragmentShader

      this.input.gBuffer.add(GBuffer.DEPTH)

      const uniforms = this.input.uniforms

      uniforms.set('uScale', new Uniform(args.scale || 1))
  }
}

But doing this, reading GData.depth returns 1.0 for every pixel, while accessing gBuffer.depth is still throwing an error.

Edit:
After digging around a bit more, I am a bit at a loss. Using the BufferDebugPass, I get this for depth, normals and color:

I don't quite understand why depth would output red.

[vanruesc]

I don't quite understand why depth would output red.

That's because the values stored in the depth texture are non-linear. The image appears red because most of the depth precision is bunched up at the near plane. If you move the camera closer to an object, it should become visible. You can also push out the near plane to improve the distribution of depth values.

Here's more information on the topic: https://developer.nvidia.com/blog/visualizing-depth-precision/

do I actually need the DepthCopyPass

No, that pass is only needed if you want to copy a depth frame to another buffer for further processing.

What is depthBuffer refering to?

That's a mistake in the docs - it should be readDepth(gBuffer.depth, uv). However, this function is only useful if you want to sample depth at coordinates other than the current one. The current depth is already available through gData.depth after all.

I realized that I have to add the depth Buffer to the gBuffer input

That's something that could be improved actually 🤔 The effect should figure out if it needs depth based on its fragment shader. Then it would no longer be necessary to explicitly define depth as a required input. I'll write that down.

[JohannesKlauss]

Ah I see. Thank you for you help. I can't really change the near and far plane of the main camera. Duplicating it (trying to follow the main camera) seems cumbersome, so I guess using the reversed z-trick seems to be the best solution for me (as mentioned in the article you linked).
Can I somewhere set the depth buffer to logarithmic in postprocessing? Or do I implement this myself? I guess I would have to run this calculation in the shader, then, right?

One more thing: I noticed that v7 doesn't respect the environment background set in three js. It's just a black background. Once I remove postprocessing passes, the background reappears. Is there something special I have to configure to make backgrounds work?

[vanruesc]

Can I somewhere set the depth buffer to logarithmic in postprocessing?

Log depth can be enabled through the renderer:

const renderer = new WebGLRenderer({
  logarithmicDepthBuffer: true,
  ...
});

It's possible that this setting won't work if you provide a custom canvas. In any case, postprocessing will work with any configuration. To use log depth in a shader, you'd need to do some calculations. However, log depth is obsolete because reverse depth is faster and more accurate. Support for reverse depth has only recently been added to three and it was broken until a few days ago. I haven't tested reverse depth with v7 yet, but will do so when I find the time.

One more thing: I noticed that v7 doesn't respect the environment background set in three js. It's just a black background.

That doesn't sound right - backgrounds are supported. Any chance you could provide more details or a reproduction of the issue?

[JohannesKlauss]

Setting reverseDepthBuffer does indeed work and fixes the depth buffer issue I had. Thank you so much for your support!

Regarding the background problem, I managed to create a reproducible: https://codesandbox.io/p/devbox/r3fvxv

I am using Threlte as a wrapper for three js, but this shouldn't be the issue since it worked fine with postprocessing v6.

While creating the reproducible I realized that I auto cleared the entire frame, so there was no background once the renderPipeline got activated. But fixing this created a new issue.

When I enable Postprocessing the whole background image gets rendered fit to the canvas, even though it is set to EquirectangularReflectionMapping. When I remove the PostProcessing component the background gets rendered correctly around the world. (Remove Line 24 in src/lib/components/Scene.svelte to see this behavior. You might have to reload the preview).

So it seem that postprocessing does rerender the background in an incorrect mapping type.

[vanruesc]

So it seem that postprocessing does rerender the background in an incorrect mapping type.

Yeah, rendering the background is a bit of a problem when using MRT to fill a G-Buffer. The main requirement is that all shaders must write to all render target attachments. So in the case of a skybox, all clear values must be passed into the shader and written to the respective outputs. Three currently doesn't expose its internal background mesh which prevents customization of the involved shaders and uniforms. That's why postprocessing is using its own background rendering setup which doesn't fully mirror three's background rendering features. It's a temporary solution that will be replaced at some point, hence the beta status of v7.

To workaround the issue, you can manually convert the texture to a cube map (that's what three does behind the scenes).

const renderTarget = new WebGLCubeRenderTarget(texture.image.height);
renderTarget.fromEquirectangularTexture(renderer, texture);
scene.background = renderTarget.texture;