Texture clipping when leaving FPS mode

[Gyoo]

I know it's esthetic stuff, but still.

Textures underwater are clipping in front of the water texture at the end of the animation when you leave FPS mode

https://gfycat.com/NaiveEllipticalGuillemot

[flibitijibibo]

Paying closer attention to the water I think this is just some depth weirdness. I guess the water is somehow behind the triles at the time when it's pulling the camera back where it needs to be, then in 2D mode they revert back to their correct Z position. Perhaps the triles' depth gets changed, but the water's doesn't? I'd have to go look...

[flibitijibibo]

Sat down and figured out what needs to be fixed for this one.

What's happening is that the meshes used to render both the liquid are, for whatever reason, behind the triles during the transition process. The way I "fixed" this when diagnosing this was by simply moving the origin around a bit when the liquid host was constructing the mesh, but I couldn't quite find a combination that allowed for correctly-positioned water in 3D space that was always behind the triles.

@renaudbedard will probably have a better idea of how to deal with this while not breaking things (particularly for levels that might actually care about the water's position in a specific way), so I will defer to him for this one.

[flibitijibibo]

Another weird side effect that comes from the liquid not getting priority in first-person transitions:

[flibitijibibo]

I finally figured this one out... it's a bug from the old MonoGame version! @renaudbedard: Do you recall doing anything weird with the meshes (particularly the liquid mesh) when getting it to work with OpenGL?

What I did to get the water to stay was simply disabling MojoShader's DEPTH_CLIPPING feature. What's happening isn't actually a conflict with the triles, it's actually the GL clipping the water out! The way we can fix this is simply keeping the whole mesh past Z 0, instead of Z -1.

The Gomez side effect is still there, but I wouldn't be surprised if that existed in the 360 version. We could either draw Gomez after the water or simply disable the depth-writing on the final Gomez pass when perspective is turned on. That would mean the zoom-in would be on a Shadow Gomez, but the transparency works like it should there.

[flibitijibibo]

This actually appears to be a problem uniformly across all 3D data... probably the WVP then?

[flibitijibibo]

This will be "fixed" in the next update.

I cannot for the life of me figure out what caused breakage for this where it only works with [-1, 1] depth clipping. Nothing in the log suggests a change and the depth clipping is needed for D3D accuracy, so I'm left to assume that this was either in the 360 version or I'm just not reading any of this correctly.

What I've done is the following:

• Disable Gomez depth writes when in FPS mode. The difference is extremely hard to tell unless you look side-by-side, so this one's actually not so bad.
• When rendering liquid, disable depth testing for the first 10% of fading into FPS mode, and for the last 13% of fading out of FPS mode. This prevents any clipping at the cost of water jumping up ever so slightly when going back to normal view. It's definitely better than the bug's appearance, though!

Marking as fixed, but would love a correct solution to this.

[flibitijibibo]

Another way of looking at this boog: Jump up on Gomez' bookshelf and zoom in first-person mode.

0, 1 clip:

-1, 1 clip: