How to prevent model surfaces "shimmering" at extreme distances?

[Enjay]

I am trying to set something up where the player can find a distant spot on a cliff-top and spy on the bad guys. In order to facilitate this, I give the player a binoculars "weapon" that can zoom in (using A_ZoomFactor). When spying on the enemies, the player is approximately 7500 map units from the area that they are looking at. All good, it basically works as intended.

The problem is that some of the decorations in the area that the player needs to spy on are made from MD3 models. It seems that at the distance mentioned, the models seem to "shimmer" when you look at them through the binoculars. There are several quite different models (one tall street lamp, a much smaller wall mounted lamp, a wall-mounted security camera and a flag) and they all do this. Close-up they are fine. In fact, even through the binoculars at around 4000-4500ish units away they look fine. So, it appears to be a problem associated with the extreme distance.

If the player looks at the models from the full distance without the binoculars, it's also fine. The models may, or may not, be shimmering but they are so far away, you can't tell.

Regular textures and sprites also look fine. It's only models that show the problem.

Does anyone have a solution to this?

[phantombeta]

Without a video, it's hard to know what you mean.

If you have no materials (i.e., no normal/specular and no PBR) on the models, it could be plain aliasing. The solution would be MSAA, and possibly model LODs. (the latter of which I don't think GZDoom has...)
If you do have materials, it could be specular aliasing, which there's not really any solution for with GZDoom.
It could maybe be something else, but there's no way to know without seeing it for ourselves.

[Enjay]

It actually looks a little bit like z-fighting (but I don't think it is that). I'll try and get a video.

[Enjay]

[edit: Solved - see the end of the post]

Without a video, it's hard to know what you mean...

OK, looking at the video myself, I *think* I might know what's going on. Solving it is another issue entirely though.



The video has the FOV in game zoomed in as much as possible and the movement in the video is not me changing the FoV, it's me flying backwards and forwards using noclip2. As I get closer to the flag, the effect goes and the flag looks correct. The effect is most obvious on the flag, but you can see it on the security camera to the left. I'm less convinced about the tall lamp. It may just be that as the players view moves slightly, you can see the bright "light" part of the lamp becoming visible below the edge of the lamp housing. Or maybe it's the shimmering effect too. I'm not sure that it can be seen on the wall lamp in this video.

The really interesting thing is that sometimes you can see a reverse image of the flag kind of superimposing itself onto the front view. That's telling because the model is effectively a very thin multi-faced rectangle with the front and back both facing out so that I can have the image on the flag be the correct way around regardless of which side you view it from.



However, I haven't got around to flipping the part of the skin that is used on the back of the flag, so that's what can be seen bleeding through to the front. This wasn't obvious to me before because I was just using a place-holder skin that was less obviously "sided".

The camera also has a double thickness "shell" around the top. The parts of the tall lamp housing aren't quite as close, but it also has a front and back separated by a few units.

So, what I think is going on, is that at an extreme distance, the distance between the front and back of the model is effectively so close that the game can no longer distinguish the thickness of the model and is trying to draw the front and back in the same plane (i.e. it is effectively z-fighting after all).

So, I guess the "fix" would be to make the models thicker, but given that I already feel the flag is a bit thick, that's not particularly desirable. As I understand it, you are correct, G/UZDoom doesn't have LODs and the only way to do it is have separate models and swap them out dynamically using ZScript and checking distance. Unfortunately, that's not ideal either.

[edit] OK, the proper fix - based on the above, and doing a bit of thinking, I realised that what was bleeding through to the front of the flag was the backface of the back of the flag. Very helpfully, MODEDEF has a FORCECULLBACKFACES flag, and that fixes the issue. So, provided all my backfaces face out (which they do) I can use that flag and it fixes things. The backface of the flag can't bleed through if it isn't being drawn.

It doesn't work as well for the camera, because it's not just the other side of the outer shell that's bleeding through is the front face of the camera's "inner shell" too. The flag was the really problematic one. I can live with the camera looking a bit shonky from a great distance.

[phantombeta]

Good to know you've figured out a way to fix your issue.
That's indeed Z-fighting. The Z buffer uses floating-point numbers, and the further away you get from the camera, the lower the precision it has. That means things will start exhibiting Z-fighting even if they're not actually overlapping.

[Enjay]

Thank you. Your knowledge and insight have really helped me in a few threads recently.

I suppose that using FORCECULLBACKFACES for this is sort of a workaround, and won't work in all cases, but at least it has solved this particular instance and it's good to know why.

For the camera, I have combined FORCECULLBACKFACES and a slight tweak to the camera model to make the top cowl sit slightly further away from the camera body. The difference in shape is barely noticeable in game (and it actually prompted me to add a little support cylinder that now logically means the cowl isn't just magically floating above the camera). However, that slight adjustment was enough to make it so that there is enough distance between the inner and outer parts and they no longer z-fight either. So, that one's fixed too.



The tall lamp only had minimal problems anyway and FORCECULLBACKFACES fixed the most obvious of those (not that it was that obvious). There's another area where you can see it if you are really, really looking but it's so minimal that it's not worth bothering about because fixing it would involve quite an awkward tweak to the model and it's simply not needed. It may not even be the same thing. It might actually be SSAO causing a slight flicker at the junction between two parts of the model.

The wall light, I think was just me misinterpreting the effect of the distant pixels kind of merging with each other because the model was so far away. There's nothing really on the model to cause problems.

So, yeah, thanks again. The scene is as fixed as it can be and it's definitely good enough now - certainly far better than it was.

[phantombeta]

I suppose that using FORCECULLBACKFACES for this is sort of a workaround, and won't work in all cases, but at least it has solved this particular instance and it's good to know why.

I wouldn't really call it a workaround, it's actually the default for most engines to cull backfaces. GZDoom is the weird one that has no backface culling for models by default 😅
It's actually rather wasteful that GZDoom doesn't cull backfaces, I'd actually recommend adding it to all models where it doesn't cause issues... And fixing models where it does. Pretty much the only case where you don't want the backface culling is for some models where either the textures have transparency, or you're gonna use them with translucent renderstyles and/or less than full alpha.

It may not even be the same thing. It might actually be SSAO causing a slight flicker at the junction between two parts of the model.

It's actually possible it's the precision loss in the Z buffer causing issues with the SSAO, since SSAO is based entirely on the Z buffer's data.

The wall light, I think was just me misinterpreting the effect of the distant pixels kind of merging with each other because the model was so far away. There's nothing really on the model to cause problems.

Is the detail on the wall light just on the texture? Pixels shouldn't "merge" like that... Texture filtering should fix any shimmering in textures.
Do you have anything like FXAA on? It can sometimes cause things like that, but I don't think it should be happening in this case...

[Enjay]

I was wondering if there might be some value in going through my modeldefs and setting all appropriate ones to force backface culling. I have the fear that I might find too many models that need fixing though. Yeah, I'll probably work through the models slowly. I have quite a few in use. I *think* most of them are set up with the faces pointing the correct way. I wonder how much difference it is likely to make. I'm guessing probably nothing particularly detectable, but it is a lot of faces being unnecessarily drawn.

Interestingly, I think the only time that *ZDoom culls backfaces by default is with translucent renderstyles. So, it doesn't do it with "solid" models, but it does with translucent ones. Pretty much the opposite way around from what you said would be expected.

There is a bit of detail on the surface of the light model, it's not just the texture.



So, yes, it could well be the same kind of thing (or, given what you said, a bit of SSAO on the edges of the details). It's almost unnoticeable on that particular model though. So I'm less concerned about it, but I will see if I can minimise it.

Thank you once again.