Transparent vs Opaque + Opaque Texture

[abstract flare]

Hey guys,
Another niche question here.
URP, mobile game
We have levels that have a large amount of toon-style water (custom hlsl shader) and we're trying to reduce overdraw. It's mostly opaque on the surface, you can only see things through it when they are near the surface
(Shoreline, shallow pool, etc)
We had an idea to try and set the shader to be "Opaque" and then use the Opaque Texture as a sort of fake transparency.

• As in, render everything below the water, save it to the opaque texture, then render the "opaque" water in the transparent queue with the opaque texture sampled and lerped in based on depth texture

Just wondering, what's the take on this? If the shader is set to render as opaque but still renders in the transparent queue, is that any cheaper than a standard transparent texture? Is this clever at all or is this just barking up the wrong tree?

(I know the answer is profile, just asking for a high level gut response before we prioritize it, profiling in our game is a huge pain in the butt because of networking requirements)

[storm cobalt]

Sounds like alpha blending but with extra steps. I wouldn't worry too about overdraw assuming that the water is the only transparent object being blended. Otherwise maybe try some opaque dissolve and see how that looks.

If you want to do opaque blending, I would just do it all in the opaque queue, grab the depth from the water, and use that to compare to the later opaque objects being rendered.

https://discussions.unity.com/t/mobile-water-with-depth-alpha-or-depth-opacity-or-darker-stuff-deeper/672814
That's actually similar idea to what I'm thinking

[proper cedar]

If it renders in transparent queue you'll get overdraw either way because at that point opaques already were rendered, front to back, and in transparent queue materials are being rendered back to front

[abstract flare]

I seeeeee, I see...

[proper cedar]

Animated screenspace dither pattern for alpha clipping can be smoothed by TAA for a fuzzy kind of transparency that's technically opaque

[abstract flare]

right now it's not, but we're trying to minimize it as much as possible. got some alpha clipped materials rendering in a few too many layers on top of the water too. Those would be easier to tackle at least

[abstract flare]

I dont think we have TAA enabled either.

we might just be boned on this one. :v

Thanks for the tips guys, it's good food for thought

[abstract flare]

that was the plan, yes

[proper cedar]

The water could be calculated entirely in the shaders of objects which intersect with it, that would eliminate overdraw for sure

Rather than a mesh, you'd compare the material position and camera distance against a math plane

And map a texture to that arbitrary plane too if needed

[proper cedar]

How would you compare depth to another material that's rendered "later"
I guess you may be describing the same thing as me, in different words

[storm cobalt]

Water would render first, no? Front to back

I'd make a custom depth map just for the water

[abstract flare]

ohhh wait I misread.
we are indeed on forward rendering but in order to make it work we needed to put it in transparent queue. Yeah, to render the opaque underside first. So you're right there is still overdraw there, I guess the hope was just that we'd reduce it to only one
but that doesnt make much sense thinking it out a bit more

[proper cedar]

So water would have to not render to depth, or depth testing on the materials behind it changed in some way to not just get skipped
At that point how do the submerged materials get any information about the water material?

[proper cedar]

How would you use it?

[storm cobalt]

materials under it would have to compare against this depth map, then instead of discarding the pixels outright you'd blend with the current water rendering. I mean I guess it's just basically just alpha blending anyway, but more selective as you don't need to blend against all pixels.

which could be ideal if say you just want to show objects under the seafloor but not the seafloor itself

But I guess you could just stencil that idea too instead of depth

Well, depth would provide a bit more information on how much to blend the further those objects are from the water surface

[proper cedar]

I'd think in either case you'd be blending against "just" the pixels which are below water, and overdrawing them too?

[storm cobalt]

yeah for the most part. Only benefit here would be selective blending I guess

from that link I've posted, there's a similar idea and looks pretty good if say you do want to render object that extrude in and out of the water

and more so that if you do want to render the seafloor that's closer to the surface you can still do depth comparisons without worrying too much about far cull plane

problem with that example though is I feel like it would create problems with multiple meshes stack onto each other since it uses only the camera depth

having a secondary depth map allows you to populate it with the water depth once but otherwise not written to by anything else

[proper cedar]

Depth map specifically meaning another pass to produce a depth texture of just the water mesh?

If so, wouldn't that be a third (partial) layer of overdraw

[storm cobalt]

If the water draws first, you're just updating the camera depth + the additional depth map. Unless we're talking deferred rendering?

[proper cedar]

Not necessarily, just unfamiliar with additional depth maps

[storm cobalt]

I bought some big water asset earlier, they use bunch of additional depth maps for the sake of figuring out how the water collides with the shore and similar things

got tired of not having that HDRP water in my urp projects

[proper cedar]

I've used RT cameras for rendering an additional texture to use as depth, but I don't think they're all that performant
Assuming in this case the one camera we have was to be used to render another depth texture the same way as the default one, but just including the water geometry?

[storm cobalt]

oh, but you can bake them too which is a great idea too. Yeah RT cameras