FreeIVA exterior textures missing

[theodorhansson]

On a fresh install using only Deferred 1.1.12 and FreeIVA some textures are transparent/missing when looking out from a spacecraft's window at another part belonging to the same spacecraft. See the debug screenshots below.

[theodorhansson]

Also, it works fine if FreeIVA isn't installed.

[JonnyOThan]

Agh. The way FreeIva normally handles this is by relying on the transparent window geometry to write to the depth buffer so that the internals of distant parts don't get drawn on top of everything else during the internal camera pass. Is it possible to render the transparent meshes that have z-write during the geometry pass? Or do we need to do something more complicated?

More details here: https://github.com/FirstPersonKSP/FreeIva/wiki/Everything-you-never-wanted-to-know-about-depth-masks

[LGhassen]

Thanks for the info @JonnyOThan, should be easy to put back z-writing, I probably didn't have it enabled in my replacement shader or something similar.

[JonnyOThan]

Does deferred still respect the render queue ordering for transparent shaders? FreeIva also adjusts those to make sure that these windows draw before opaque things.

[LGhassen]

It does, but you can't make transparencies render before deferred opaque objects anymore if you were using that, it would need to be changed to a depthMask, assuming that's the issue.

The order is:
Opaque deferred objects ordered by renderqueue -> deferred lighting pass -> opaque forward and transparencies ordered by renderqueue.

[LGhassen]

@JonnyOThan I took a look and the transparent windows use the shader "KSP/Alpha translucent" which indeed renders before the rest of the geometry and writes to depth without Deferred.

With deferred the problem is this is a transparent alpha-blended shader which can only render in forward so will always render after all opaque deferred objects are rendered.

To fix this I can think of 3 solutions:

1. Preload the the IVA camera depth buffer with adjusted depth from the flight camera (needs a few calculations to adjust for different clip planes, probably the simplest solution, the lighting pass may need to be adjusted somehow to not relight old fragments, uses a bit of additional VRAM when the IVA camera is active)
2. If FreeIVA is detected I can render a prepass which renders the IVA camera with a replacement shader for transparencies that is just a depth mask -> may have some unintended effects for other transparencies, may scale badly with RPM elements and such that have a lot of drawcalls
3. You can add a second material that is a depth mask to transparent windows in FreeIVA -> not sure if you have this kind of granular control in FreeIVA

Let me know if you have any thoughts on these solutions otherwise I'd probably try 1

[JonnyOThan]

Thanks @LGhassen

I don't think option 1 works because you would see the outer shell of adjacent parts instead of seeing through an open hatch into them. This is basically the cause of the rendering artifacts that occur when looking into an adjacent part that has windows - since the windows merely blend over whatever was in the color buffer, you see the close part geometry in the places where windows would be.

Option 2 seems reasonable if you apply this only to transparent meshes that use the earlier renderqueue value. FreeIva knows the difference between transparent meshes that are windows and those that aren't, and sets the renderqueue values appropriately.

Option 3 seems like the best solution. I'm not sure how to do it though - it's just as simple as adding a second material to the meshes? This would require no additional code or runtime work once FreeIva sets up the internal prefabs during loading. Would there be any risk of z-fighting though?

[LGhassen]

@JonnyOThan thanks for replying

1. You're right, I missed that

2. This is using Camera.RenderWithReplacementShader so I cannot apply this selectively using renderqueues, only using tags (ie transparent, opaque), therefore it has to be done for all transparencies, although a depth offset can be added to avoid z-fighting.

3. You'll need to add a second material to the renderer https://docs.unity3d.com/ScriptReference/Renderer-materials.html.
   You'll also need to write the background stencil value to avoid deferred lighting doing wrong lighting on "empty" pixels. Bit 7 is the non-background object bit so I think you can write 0 to it in the depthMask pass, something like this should work.

            Stencil
            {
                Ref 0
                WriteMask 128
                Comp Always
                Pass Replace
            }

You'd have to add that to a modified version of the depthMask shader https://github.com/LGhassen/Deferred/blob/master/shaders/DeferredKSPShaders/Assets/Shaders/Replaced%20shaders/DepthMask.shader

I think z-fighting shouldn't be an issue with LEqual ztest mode but you'll have to test it, in the worst case a depth offset can be added to the depth mask like this (but positive instead of negative) https://github.com/LGhassen/EnvironmentalVisualEnhancements/blob/master/Assets/Shaders/SphereTerrainCityLights.shader#L32

[JonnyOThan]

Finally getting around to this...I actually already have a version of the depthmask shader that does backface culling here: https://github.com/FirstPersonKSP/FreeIva/blob/main/FreeIva_Unity/Assets/ForBundle/DepthMask_Culling.shader

This is necessary because you don't want to see these on other parts when looking out at them - only when you're looking out from inside one.

I noticed your depth shader has subshaders for both lightmodes - do I need that too? Or maybe with Lighting Off it doesn't matter?

Should the Stencil go in the SubShader or the Pass block? I see both in example docs.

[JonnyOThan]

ok sweet, this seems to work on the parts where it's in use. So now I just gotta do the part that adds it to the alpha-blended meshes.

https://github.com/FirstPersonKSP/FreeIva/blob/main/FreeIva_Unity/Assets/ForBundle/DepthMask_Culling.shader

[LGhassen]

I noticed your depth shader has subshaders for both lightmodes - do I need that too? Or maybe with Lighting Off it doesn't matter?

Not sure how that works exactly, I remember only getting mine to work in both forward and deferred if I included both subshaders in that order.

Should the Stencil go in the SubShader or the Pass block? I see both in example docs.

I think stencil can go in both. I did some testing again recently on stencil bits and it appears think writemasks are ignored by unity in deferred rendering apart from the first 3 bits (and even those are completely removed in later versions of unity), so you won't trick it by writing a background bit. The good news is that this is only needed in LDR and I found a workaround for it in this issue #42 so you won't need to do anything on your side, you can remove the stencil block.

[JonnyOThan]

FreeIva 0.2.19.0 is now available and should fix this.