Broken depth on view models

[Graslu]

Broken depth on view models

[LanHikariDS]

Also true of DataDyne Investigation, if you walk into the bottom of the secret hatch at the end of the underground firing range.

[Graslu]

Also noticed this on all maps:

[tunbridgep]

I had a look at this, and I have no idea how to set the render order of a given model (if that's even possible), as I think that's the problem here. I have never done anything involving N64 code or pulled apart a project this complicated.

Lots of N64-specific code in here. I guess I was more expecting a port like this to be a completely native reimplementation of all the game's functions, but this works I guess.

Well, I tried my best, sorry it ended in failure :(

[MaikelChan]

I just took a look and tried to fix this issue.

The main problem is that the game originally cleared the depth buffer right before rendering the weapon, but in the PC port this was removed assuming it wasn't necessary (saw some comments in the code like this: // no reason to do a Z clear on PC, we already do it at frame start.

And without this functionality, I saw some workarounds implemented like trying to render the weapon and bullet casings with a modified depth range (I didn't exactly find the code for this, but the depth ranges of the weapon were different than on N64, so I assume something must have changed).

Whatever the case, no matter how the depth ranges are changed, there will be always cases of weapon clipping due to some levels having near scenery elements with a depth of 0. And that's not a bug, it's the same on N64.

So I tried to implement the depth clear... and it kind of works... sometimes, and my implementation is all over the place.

However other places like the Carrington Institute don't render at all now.

I tried different approaches, and what I finally did is to create another ext command:
#define G_DISABLE_COLOR_MASK_EXT 0x00000400

And reenable and modify the zbufClear function, removing the gDPSetColorImage call, and setting the new ext mode which basically does a glColorMask call:

gDPSetRenderMode(gdl++, G_RM_ZB_OPA_SURF, G_RM_ZB_OPA_SURF2); gSPSetExtraGeometryModeEXT(gdl++, G_DISABLE_COLOR_MASK_EXT);

But I don't know what render mode should I use, if at all. No matter the render mode, causes some issues or some others.

Not even sure if the glColorMask approach is the best. Also I had to do a workaround to force the z component of the vertices of the drawn rectangle to 1 when the color mask is all set to false, so it clears the depth buffer to white instead of black.

A bit of a mess really, but maybe this helps to reach the proper solution.

[fgsfdsfgs]

The depth ranges are calculated (very incorrectly) from the gSPPerspNormalize value, which is different between normal rendering and viewmodel/casing rendering. I assumed that's how it works, since that's how a lot of games did it back in the day, so I removed the depth clears, though I also had other issues with it like the one that you're having in CI. If you do want to try to put them back, you'll have to at least nuke the one at the start of the frame in gfx_run(). It would probably also be a better idea to add an explicit clear command instead of drawing a Z=1 rectangle or detect clear rects and replace them with a clear maybe.

[MaikelChan]

In fact, my first attempt was with a clear command, but I had some level elements drawing after the clear that I didn't know how to fix. Besides, I thought being more faithful to what the game does should be better, in case, for example, the game tries to clear the depth of only part of the screen (which doesn't seem the case anyway).

But now I tried again and turns out that to fix the issue I had I only needed to call gfx_flush(). And now it seems to be working great. I'll do tests and revise the depth ranges before doing a PR.

[MaikelChan]

@fgsfdsfgs Do you know why, even on N64, there's one gSPPerspNormalize(gdl++, mtx00016dcc(0, 300)) for the weapon, and then the casings render with the, apparently, default one gSPPerspNormalize(gdl++, viGetPerspScale())?

On emulator, somehow, both elements seemingly render with the same or similar depth ranges despite this. But on PC, even before the PC port changes, both elements render at very different depth ranges, which can make the weapon always render on top of casings (which might be intentional?). But at least, comparing with emulator, I get similar results by just having everything normalized with gSPPerspNormalize(gdl++, viGetPerspScale()) instead of different values.

But I guess there are two values for a reason?

[fgsfdsfgs]

That's because the depth range is not determined by PerspNormalize alone. That value is just 2 / (znear + zfar), so the renderer just kind of guesses zfar based on it. The actual near/far values are part of the perspective projection matrix and the PerspNormalize value is returned by the function that generates it, guPerspectiveF. You could instead somehow give the renderer access to g_ViBackData->znear and g_ViBackData->zfar and calculate Z range based on those.
Though that's still not entirely valid because you're already using the persp projection matrix.

[MaikelChan]

I can't exactly figure out how this works, and interestingly enough, GlideN64 ignores completely G_MW_PERSPNORM, so never actually changes depth ranges. At least, there's no more clipping and I can do a PR later with that fix.

[fgsfdsfgs]

Yeah, I've noticed that it doesn't. It's probably supposed to work as is, with only the clears, but I couldn't make it work and made a workaround based on the PerspNormalize thing. On the N64 it's used for some internal calculations involving perspective correction, so what the port does is technically very wrong, but it works since the value just happens to change when the viewmodel is rendered.

[fgsfdsfgs]

This should hopefully now be fixed with MaikelChan's PR.

[LanHikariDS]

Can confirm, it corrects the Eyepiece pause menu issue, and the guns clipping the ceiling hatch in DataDyne Investigation