Alternative way to handle Z-fighting

[MirceaKitsune]

I had an interesting idea in regard to how the TDM engine handles Z-fighting. It comes after my last FM where people reported terrain patches that were too flat causing visible Z-fighting with the ground brush: It seemed weird as both surfaces had the same shader and their mapping lined up, therefore even if the surfaces overlapped the same pixels should have been fighting with no visible artifacts. Turns out the engine makes it so even if the material and its relative mapping is identical, the surface also becomes brighter whenever there's overlapping.

I was wondering if unless we're stopped by deep limitations in OpenGL, there is at least a way to get rid of this brightening effect. If we have the ability to control how Z-fighting is handled, I had an idea which could turn it into a great feature available in other engines: My suggestion is to mix the colors on all material maps, so instead of randomly adding them together we settle for the average of all Z-fighting surfaces per pixel.

The reason this would implement an useful feature is if we could do it per map, we'd have support for mixing the albedo + normal + specular maps on multiple surfaces in realtime, something not currently possible unless done by the texture or material. Imagine a graffiti drawing on the wall: We could deliberately have the decal perfectly overlap the surface of the brush instead of having it suspended a bit in front... doing so would cause both the albedo / specular / normal maps to be combined, lighting would then follow the bump map of both the brick as well as the decal so both produce depth on top of each other on what would still appear to be a single surface.

Even if my particular idea isn't possible, it would be nice if we could at least get rid of the brightening; Z-fighting would still occur, but at least it wouldn't be as obvious if you don't look closely.

[AluminumHaste]

If you make zfighting less obvious, how are you supposed to find it and correct the underlying cause?

[datiswous]

But you would take away some player's main motivation to beta test.

[MirceaKitsune]

4 hours ago, AluminumHaste said:

If you make zfighting less obvious, how are you supposed to find it and correct the underlying cause?

I now wonder if Z-fighting should still be considered an issue the author has to find and solve. Especially with modules aligned in some positions, it happens so often it's often hard to address correctly. Wouldn't it be better to handle this by mixing the surfaces in a better looking way, perhaps use a separate debug mode for creators who want to catch and avoid it?

[jaxa]

5 hours ago, datiswous said:

But you would take away some player's main motivation to beta test.

I feel attacked!

[AluminumHaste]

Keep in mind, z fighting is a symptom. The underlying problem is misaligned and overlapping geometry. If you do this with brushes, the engine can't properly optimize triangles during dmap.

[MirceaKitsune]

On 11/21/2024 at 2:19 PM, AluminumHaste said:

Keep in mind, z fighting is a symptom. The underlying problem is misaligned and overlapping geometry. If you do this with brushes, the engine can't properly optimize triangles during dmap.

I can see that. Wonder if Z-fighting between brushes should be handled differently than between models and patches: Brushes are meant to be merged by dmap, other forms of geometry are often intended to interact more freely.

This makes me wonder if it's logical to treat brush intersections in particular as the issue, maybe have a separate debug mode for catching them. Like a heatmap style render where normal geometry appears green, Z-fighting between non-brush geometry is yellow, Z-fighting between brushes is red... maybe blue for backfaces and anything else one may or may not want to make sure doesn't show up during a normal run.

[AluminumHaste]

Models are triangulated when exported from 3D program so engine doesn't need to optimize them in that way. So modeler should have done their job.

Something that accentuates z-fighting would be helpful as it's not always easy to see. There is a rendering mode that I think colours faces based on # of lights hitting it, so something similar might be doable.