Error "Manifold creation from mesh failed" with CSGMesh3D causing Plane and Quad meshes not to get rendered.

[TCROC]

Tested versions

I bisected and can confirm it was introduced by pr: #94321

I suspect issue #99888 was also introduced by the same PR.

Versions of Godot before this PR work fine. Versions of Godot after this PR error ranging from crashing to error messages depending on if you use a commit before the crash fix. The crash fix only fixed the crash though. The meshes still error and do not render which is what this issue is for.

System information

Godot v4.4.dev.mono (01b508724) - Pop!_OS 22.04 LTS on Wayland - X11 display driver, Multi-window, 3 monitors - Vulkan (Forward+) - dedicated Intel(R) Arc(tm) A750 Graphics (DG2) - AMD Ryzen 7 5800X 8-Core Processor (16 threads)

Issue description

Certain CSGMesh3Ds error and do not render. The ones I have discovered so far are planes, quads, and ribbon trail meshes. Here are some screenshots demonstrating.

Before #94321

After #94321

Crash with log:

Manifold creation from mesh failed:2
Manifold creation from mesh failed:2
Manifold creation from mesh failed:2

Master + #99959 that improves error messages

NOTE: Error messages without a crash are in current master. They just aren't as detailed as #99959 improves them to be

As you can see in the third one, the first three meshes do not draw and instead error in the console.

Steps to reproduce

1. Download the attached MRP
2. Open up main.tscn
3. See the error messages and meshes not being drawn
4. I use double precision + mono support. I do not know if this is required.

Minimal reproduction project (MRP)

mrp.zip

[elalish]

From the Manifold perspective, this is working as intended - we only operate on manifold meshes (e.g. watertight, containing volume), because those are the only kind of meshes for which Boolean operations like CSG are well-defined. If you take two quads and partially-intersect them and then try to subtract one from the other, what would you expect for a result?

[TCROC]

@elalish I'm confused. So its intended that Godot no longer renders planes and quads?

[fire]

Planes and quads that have volume are thin wedges and rectangular prisms. These can be CSG'd geometrically, but not perfectly thin quads or planes since they have no volume.

[fire]

We have this quote in the original design of CSG.

https://godotengine.org/article/godot-gets-csg-support/

Any mesh can be used for CSG, this makes it easier to implement some types of custom shapes. Even multiple materials will be properly supported. There are some restrictions for geometry, though:

It must be closed
It must not self-intersect
Is must not contain internal faces
Every edge must connect to only two other faces

This disallows planes and quads, as everything in CSG is now a CSGMesh3D.

[TCROC]

I'm still confused. Prior to pr #94321 , planes and quads rendered fine. Now Godot pushes errors and doesn't render planes and quads. This is expected behavior?

I'm personally not familiar with anything related to manifolds. But the behavior that I am visibly seeing feels like an error. And if it's not an error, I feel like it's a significant breaking change that we should reconsider as many (likely most) games such as ours rely on planes and quads as meshes in 3d space. The heaviest usages being particles and foliage.

But again, I'm not familiar with manifolds. If you guys are agreeing that this is an issue while simultaneously offering an explanation as to why this issue is happening, that explanation was entirely lost on me due to my ignorance of manifolds 😅

[TCROC]

Okay I just read that article on csg. Thanks @fire :) I noticed that is from 2018. So planes and quads have worked with csg since then. What changed? Maybe I should be using a different node for planes and quads? Are planes and quads no longer supported for csg?

[fire]

From a technical point of view, supporting planes and quads with the CSG nodes is impossible. We noticed they used to work, and many have used them in their games. Still, a significant reason the CSG nodes were having corruption issues is that we needed to be more consistent with manifold definitions and apply them consistently in code.

I want to help draft a release note for the next release including this CSG feature. Help wanted.

[TCROC]

Ah I see. What node should be used instead for planes and quads?

Also, should planes, quads, and ribbon trails be removed as options in csg? You can presently pick them.

[fire]

Adding depth to them will work in a mathematical sense.

[TCROC]

But how about without depth. With foliage and such. Does Godot just have a plane or quad node?

I don't need the csg. Prior to this I didn't even know what csg was. But it's really cool and I'll find a usage for it. For now tho, I and many (if not most) of Godot's user base need quads and planes without depth. Does Godot have a node for this?

[fire]

Are you aware of the MeshInstance3D node with a Mesh of type PlaneMesh, RibbonTrailMesh or QuadMesh?

new-game-project.zip

[TCROC]

Brilliant! Thank you! This is precisely what I need! :) So I guess I propose a few things to do before closing this issue:

1. Draft a release note in regards to a breaking change such as what you suggested above.
   • Make sure to note to change to MeshInstance3D as an alternative so ignorant people such as myself :)
2. Remove the incompatible csg options such as plane, quad, and ribbon trail
3. Update docs to indicate csg doesn't support planes, quads, and flat meshes. To use these we must use MeshInstance3D

Then I think we can close this! :)

Unless someone has an important reason to keep quad and plane support in csg. I personally don't have any objections to removing them, but its possible someone else may have a good reason to keep them. I am personally satisfied with the MeshInstance3D alternative.

Thank you very much @fire and @elalish! :) I learned about a new feature of Godot from this issue! I consider that a win in and of itself! :)

[Zireael07]

As someone who did quite a lot of prototyping with CSG in Godot, I don't think I used plane but I think I might've used quad once or twice. However, a big yellow warning note and/or a project conversion thing (like for shader renames sometime along the 4.x) would probably suffice

[fire]

#93865 may also help resolve this 3d manifold issue for other shapes.

[TCROC]

@fire Are you suggesting it my resolve it for planes and quads? Or are you referring to different shapes?

[fire]

I am referring to different Mesh primitive shapes that probably are erroring because they have a small gap in their edges.

[TCROC]

Ah I see. Thanks for the clarification! :)

[SpockBauru]

Just read the notes for Dev 6 and came here. So no planes with CSG anymore? This would brake my CSG Terrain thing, where the terrain is a CSG plane that is shaped with curves, and I can merge, cut and dig holes easily with CSG stuff:

CSG_Terrain.mp4

Is there any plan to make it work again in order to be back compatible, or I will need to figure out some workaround?

[TCROC]

This seems like a pretty solid reason to support planes with csg... But I'm curious. @SpockBauru , can the same effect be achieved with a cube? Giving it a large scale in the x and z direction, but small in the y direction?

If not, this is definitely a very solid argument for figuring out how to support flat meshes such as planes with csg while still having the manifold fix. I'm not familiar with what manifolds are, but apparently they fix a bunch of other bugs.

[SpockBauru]

Currently my main issue is the number of vertices. Making 6 sides, each one with the same number of quads of the terrain plane, would be unfeasible. So a way to reduce the number of extra vertices will be needed.

Considering terrain with 100x100 quads (10 thousand vertices). One possible solution is to generate a cube with 100x100 quads on the top face and each side with 100x1 quads. But I have no idea how I would decrease the number of vertices in the bottom face without creating something like a pole with 396 edges and problematic thin triangles...

In a short, it's possible but would take time and the outcome would not be pretty.

[fire]

Can you do a feasibility test? As far as I know, the CSG algorithm will handle the edges of the modification similar to tesselation.

[fire]

I tried to simulate your terrain use case with CSG.

csgpath 2.zip

With bugfixes from master & #100020

Edit: Try CSGPolygon Path or CSGPolygon Depth to get the initial ground

[SpockBauru]

I think I didn't explained how it works correctly, sorry.
I generate the terrain mesh from scratch using curves and only apply to the CSG mesh after, for making CSG operations with other shapes.

Just made the repository available so you can take a look. I will try to close my shape tomorrow and make the feasibility test.

[TCROC]

@SpockBauru that repo / tool looks awesome btw! We might make use of it in one of our future games! :)

[fire]

@SpockBauru I couldn't complete the code, but my approach was to turn the path into the side profile of a CSGPolygon3D and give it depth for your terrain tool.

[SpockBauru]

I was able to attach a cube bellow the terrain on the mesh generation code, now the tool works on 4.4 dev6 :D

CSG_Terrain_cube.mp4

The cut does not make missing faces anymore so I can make holes in mountains, anime style \0/

But I'm not sure how to feel about that weird box bellow the terrain and possible performance issues... The old plane style feels better...

[fire]

Where does the perf fail? Curious.

[SpockBauru]

Where does the perf fail? Curious.

With several terrain slices, there will be lots of hidden geometry bellow the terrain that the player will never see. I don't know how these will be handled by the engine, but is surely more data:

CSG_Terrain_hidden_geometry.mp4

[fire]

It looks low polygon, might be ok

[fire]

In engineering stress simulations and animations, we prefer triangles of equal size, but the long, thin triangle approach gives better triangle reduction.

Currently, I need a robust way to convert long, thin triangles to isotropic triangles. Still, for optimizing the triangle counts of static terrain, long triangles are what you want, and the manifold library will cut the mesh for you.

See also

https://www.gradientspace.com/tutorials/tag/Unreal

https://discourse.mcneel.com/t/gh-script-or-component-for-isotropic-remeshing/47279

[SpockBauru]

In engineering stress simulations and animations, we prefer triangles of equal size, but the long, thin triangle approach gives better triangle reduction.
Currently, I need a robust way to convert long, thin triangles to isotropic triangles. Still, for optimizing the triangle counts of static terrain, long triangles are what you want, and the manifold library will cut the mesh for you.

See also
https://www.gradientspace.com/tutorials/tag/Unreal

https://discourse.mcneel.com/t/gh-script-or-component-for-isotropic-remeshing/47279

Thanks! I will take a look.

[fire]

Oh, before I forget, I had this tooling for manifold meshes that can give the equal triangle size measure https://github.com/V-Sekai/TOOL_mesh_intrinsic-triangulations

Initial

Improved

[elalish]

That Delaunay thing looks nice! As some other options, Manifold also has RefineToLength() and RefineToTolerance(), though the second is more for working with our smooth tangent mesh refinement system.

[fire]

We discussed two enhancements.

• make tutorial for blender 3d toolbox to force manifold via unholy means
• root csg shows node tree editor warning for non manifold

[fire]

I started a draft for the manifold documentation godotengine/godot-docs#10417