[REQUEST] Export options to remove Z fighting overlapping faces.

[Roll675]

Use case

Solution

I would like an option in the export to automatically fix the Z fighting as it takes a lot of manual work to fix in blender.
Edges are also not merged, which means selecting linked faces is not possible. It makes it very hard to edit meshes in large scenes.

Alternatives

Giving another export option to export each object separately or to mark objects to be separate before the export

Additional context

[ScoreUnder]

This is something I've wanted to do for a long time, but frankly the mathematics behind taking the difference of coplanar triangles in 3d space bends my mind into knots. It's not much easier in 2D (and one could probably find the tangent and bitangent of the plane on which those triangles lie and write a matrix based on them to transform the triangles from 3d space into a 2d space and vice versa). If there is anyone who knows of a good way to do this (short of "use cgal", which poses other problems for a cross-platform Kotlin project) then I would really appreciate some math help on this one.

As for the lack of edge merging, that is unfortunately a current limitation of the glTF format, or arguably the importer code in Blender: KhronosGroup/glTF-Blender-IO#590. Is there another export format you could recommend here? Since this is different enough from the other request I've added another issue for it: #170

[Roll675]

So this might be a bit of a stretch, but I am currently working with a small team that has inspected the Kotlin code and are working on an object ID separator so we can manually fix some Z fighting easier. But we really want to try and get this Z fighting stuff fixed if possible with you. Could we pull you into our Discord server so we can be more hands on in solving this? If we can help in any way to contribute to this project, it would help both of us out!

[TapGhoul]

Heyhey! I'm on said team. Hopefully this all comes out right, I'm typing this half asleep.

I wanna preface this first bit with I haven't looked into the glTF export code deeply yet - I'm still slowly churning through the RS structures primarily. So if you're already doing this, no stress.

For the glTF format: https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#meshes-overview - while untested by me, generally what you're looking for are index buffers, and it seems glTF has supported index buffers since at least 1.0/1.1, and 2.0 still does.

(Though according to This CG stackexchange answer the format had changed somewhat - but just in the sense that a lot of the things that were objects are now arrays, which only really matters for general surrounding spec and shouldn't matter here - posting anyway because it has a nice minimal triangle sample)

It is very possible that the blender importer just straight up doesn't support reading this data, but the spec does define it.

https://github.com/KhronosGroup/glTF-Tutorials/blob/master/gltfTutorial/gltfTutorial_009_Meshes.md#indexed-and-non-indexed-geometry seems to also go over it. To quote (from the section beneath it):

By default, the geometry data is assumed to describe a triangle mesh. For the case of indexed geometry, this means that three consecutive elements of the indices accessor are assumed to contain the indices of a single triangle. For non-indexed geometry, three elements of the vertex attribute accessors are assumed to contain the attributes of the three vertices of a triangle.

The issue with implementing the above, however, is it would force colours to be blended between faces - this may result in an incorrect appearance, and so may not even be wanted.

---

As for the z-fighting, we have some ideas, but plan to take a different approach on the rendering end where we are actually doing this, as some of the rendering differences between in-game and in your viewer seem to suggest that some objects are meant to draw over eachother, completely ignoring the depth buffer. Maybe because it was designed with a software renderer in mind? Still figuring things out, and need to figure out if the rendering overhead is worth taking the hit for under the constraints we are working within.

As for the separation bit @Roll675 mentioned above, we plan to split the world into more objects to build a more usable hierarchy with all the objects separated by chunk/region -> z layer -> object type -> object id as a 4 level hierarchy, to make it easier to mess with data, though we aren't decided on what exactly we want the export shape to be - we'd be down to contribute back the exporter changes (along with any other changes we make).

---

As @Roll675 said above, we are figuring this all out in a discord, so if you would like to take a peek in while we figure things out we'd be happy to chuck ya an invite.

[ScoreUnder]

I think the main problem you may encounter with the Z-fighting thing is that it's often the same model fighting with itself. I haven't seen a case yet where a model is fighting with another in any noticeable way. So unless I'm mistaken it looks like there's no easy way around the intense geometry study that this is going to involve. I would be open to trying indices as part of the glTF export, and I could help with that if necessary.

If you would like to add me on discord, I'm score#6846 (you can see this on my github profile too).

[jeadys]

Any updates on this?

[ScoreUnder]

@jeadys unfortunately i haven't been able to wrap my head around the math involved, nor has anyone I've talked to, and i can't find any jvm libraries capable of it. if you know of a way to take the difference of 2 triangles (i.e. triangle 1 intersected with inverse of triangle 2) in 2d space and then re-triangulate the resulting polygons, or if you know of someone who might be able to do that, that would be the holy grail of this issue. the second part, triangulating the polygons, is the easy part so I'm mostly looking for a sensible way to perform that difference operation and get back a set of polygons.