Render alpha on surface broken - Crest logo flickers

[huwb]

@holdingjason

Could i get a screenshot or in the best case video demoing this? I couldn't repro this - i looked out for it while reimporting/creating new projects trying to repro #51 .

Thanks!

[holdingjason]

Here ya go.

https://drive.google.com/open?id=1IAuIoYU7IUblOrZk8Ud9XS1pItWegEPd

BTW I am now on a new video card.

[huwb]

Thanks for that. That confounds me. I will ponder this for a while!

[holdingjason]

Will look into it as well. Might be something I changed on my side, only thing I can think of is the cull stuff. Will check.

[huwb]

Ohhh i reckon i have fixed this just now:

0f6b493

When i moved the main scene content up i noticed the logo was not tracking the sea level and fixed it. I think you're using a small offset of sea level from y=0 which would explain why the logo is cutting in and out. If you get a chance could i get a retest?

[holdingjason]

Crap I know what it is. I reset the render queue to output to 3000 instead of 2100. Sorry about that.

I was messing with that because of this issue. I can see islands etc far off in the distance. Not sure why that happens except that it appears that the zorder rendering of the ocean is sometimes higher then that land. That has no override or setting its just using the standard shader btw. Which i would have expected 2100 to work.

Here is it at < 2500

Above 2501+

[holdingjason]

Ok tracked it down. So this issue is caused by having Post Processing (v2) on with Deferred Fog Enabled (I am running in deferred rendering mode). For now I will leave my settings on the ocean material to render at 2501 which fixes that flicker issue.

[huwb]

Ok, that's a fun issue. It seems unity flips the order it renders things at 2500 which sounds like a trigger for your issue, but I'm not sure why yet. https://docs.unity3d.com/Manual/SL-SubShaderTags.html

I could probably have a pretty good run at the problem given a renderdoc capture. Same deal as the last time - full debug info in shader please. The capture will include your assets so you may want to send it via email if you like.

[holdingjason]

Would be happy to do that if it would be a time saver for you but also just FYI you can also setup your main scene by adding the post process layer to the camera, camera to deferred and turn on deferred fog in the post processing layer settings.

In lighting turn on fog and use linear with something like 200 and 600

[huwb]

Ah ok.. but do you think you could send me captures of the working and not working cases anyway?

If I recall you have turned backface culling off. Now in addition to that the above change will make unity render the ocean tiles from back to front. I can think of a worst case where some of your pixels will end up shading 14 layers of ocean, or more. If I'm right, then for a heavy shader like the ocean material this is a performance apocalypse, and I think it's worth digging deeper.

[huwb]

Ok sorry I'm replying on my phone so I'm delayed.. I'll see if I can repro it myself, thanks

[holdingjason]

Np. That does sound nasty. So is it a combo of the backface culling off with deferred AND fog or just deferred with back face culling off. Will try changing that just to see. Oh and I guess putting it into alpha test at 2501 which would have additional overhead.

[huwb]

okkkkk so i went down a very deep, very dark rabbit hole and have emerged with some results. for starters, i believe the following is true:

• unity knows the the ocean surface is not deferred rendered, probably due to the LightMode=ForwardBase tag which is required (weirdness ensues if its omitted - Black ocean from certain viewpoints #19).
• therefore it copies out the depth before rendering the ocean, and its this depth that is associated with the gbuffer and used for any postprocessing
• the ocean does write depth, and we could possibly recopy out the depth after the ocean finishes rendering, and then compute fog from that. that would look ok.
• BUT - consider for a moment another post proc effect: SSAO. if the ocean surface depth was taken into account, there would be dark creases where the water meets land (had this on a previous project, it sucked). if on the other hand we leave it as it is now, any crevices under the water will trigger SSAO - same kind of error as what we're getting with fog. we're screwed either way.
• conclusion - we need to do this the proper way - put it in geometry+501 (2501). unity docs refer to water being put here as well

back to the problem - potentially bad worst case cost due to back to front sorting that unity applies to this queue. here i think the well defined lod/tile structure can come to the rescue.. it looks like i can manually set the sorting order on the tiles so they always draw front to back! i just confirmed now that it seems to work in renderdoc..

i need to check it all again when im much less tired but i'm hopeful that this is the solution for us!

[holdingjason]

Gotcha. Ok that all makes sense. Thanks for digging into this.

[holdingjason]

Oh not sure if this is something that can really be done since I believe this is just not possible but alpha transparent shaded object under the water will not be rendered if you view them from on top of the water. So think of a semi transparent jellyfish or bottle floating on the surface. Those would not show up or only the parts sticking about the water.

[huwb]

Cool. Checked again this morning and it looks good to me on both forward and deferred so I pushed it! This is good.

Regarding alpha, ill move it to its own issue.

[huwb]

I keep thinking about you guys turning off culling and if it can be avoided. Perhaps you can use this to switch culling between back/front at runtime:

https://docs.unity3d.com/ScriptReference/Material.SetOverrideTag.html

So do something like this when the camera goes underwater:

_oceanMaterial.SetOverrideTag("Cull", "Front");

I have not tested it but it looks legit from the docs..

It will likely introduce a hitch so you'll want to prime it by setting it to front and then back at loading/init time if you can..

[holdingjason]

Will give that a try and let you know what happens. Thanks.

[holdingjason]

Tag did not work but this did.

Add this to properties
_Cull ("Culling", Float) = 0

Add this to the subshader uner tags

		Cull [_Cull]

In your script when you want to render underwater

    OceanMaterial.SetInt("_Cull", (int)CullMode.Front);

and above water

    OceanMaterial.SetInt("_Cull", (int)CullMode.Back);

Worked like a charm on mine.

Not sure what it did for perf but should go lighter on the GPU now.

[huwb]

Waaaa what is that dark magic - you're feeding a shader param directly into a rasterizer state!? Do you have a link/ref or did you just try it and it worked out? Just curious how "official" it is, and by extension how platform friendly it is.

Anyway i tried it myself and it worked great for me, and i plussed it slightly with the Enum attribute i found. Commit referenced above. Let me know if it looks fine to you.

Thanks - glad we worked this through!

[holdingjason]

So I based this on the standard shader. Downloaded those and took a look. You can see examples of them doing the same thing in the subshader for

        Blend [_SrcBlend] [_DstBlend]
        ZWrite [_ZWrite]

I had modified the standard shader before for some tree effects and noticed this. Figured if it works for that why not culling. However I am NOT a shader expert just starting to dip my toes in that area so have no idea as to how platform friendly it is but if they do it in the standard shader I would hope. However they do not do it for cullling which might be a different beast. Honestly you are so far ahead of me on this if you don't know well then... I did some research but so far found very little to nothing except a reddit post which basically says the same thing I said above.

https://www.reddit.com/r/Unity3D/comments/5bu1gw/can_i_change_a_shaders_pass_attributes_at_runtime/