Allow more operations on the 3D View depth buffer texture

[robojeb]

What problem does this solve or what need does it fill?

Some post-processing or rendering effects want to be able to read from the depth buffer of previous render passes as a texture. Currently in prepre_core_views_system() the "view_depth_texture" is only marked with the usage TextureUsages::RENDER_ATTACHMENT so it cannot be used be used either as a the source of a Texture-Texture copy or as a Texture directly.

What solution would you like?

I think the best solution would be to add TextureUsages::COPY_SRC to the "view_depth_texture". Users who want texture access to the depth buffer can copy the buffer off to their own texture and use that texture as a sampling source.

What alternative(s) have you considered?

An alternative would be to add TextureUsages::TEXTURE_BINDING and allow users to directly bind the depth texture. The downside of this configuration is that you cannot use the depth texture as both a render attachment and a texture at the same time. This prevents some rendering configurations which want to write new meshes with correct depth filtering while using the depth of the previous pass as part of the calculation (eg water shaders).

Additional context

This would need #3776 to be resolved and probably also wants to be implemented in concert with #3552.

[jngls]

Since the recent camera oriented renderer updates, the system which prepares the depth texture is now prepare_core_3d_depth_textures(). This issue is still valid otherwise.

[jngls]

One complication here is that even if the depth buffer is marked TEXTURE_BINDING it's not trivial to access the depth texture once it's written to. It's currently spawned on demand in the render world, with no public facing Image handle.

Another Alternative

So another alternative suggestion, in addition to those you've described above, would be to allow the user to pass their own depth Handle<Image> into a camera's RenderTarget. This seems like it wouldn't be too tricky to add, though maybe there's some validation needed to ensure the image sizes match (is that even a valid concern?).

EDIT - It turned out to be very tricky. wgpu isn't happy about copying depth textures in webgl or gles. It fails with error: Error in Queue::write_texture: copying to textures with format Depth32Float is forbidden. My test branch: https://github.com/alexmadeathing/bevy/tree/depth-target

[superdump]

I’ve been working on a depth prepass. The main difficulty is in making it work in a nice way with custom vertex shaders without doing a bunch of unnecessary vertex shader work only to throw it away

[jngls]

Ace! I'm interested! Given that the pre-pass would reduce overall fragment cost, is the doubled vertex cost that much of a worry?