Mesh Boolean now has a “Manifold” solver in the alpha for release 4.5. While I prefer bug reports for bugs, please put any other questions or discussion in this thread.
16 Likes
A bit of Weird behavior I found. I don’t know why it’s occurring.
^ This is the mesh doing the boolean, procedurally set up to find the highest and lowest point of the input mesh and instance and realize some cubes.
This is obviously on the test:rubbertoy from Houdini, since Blenders Suzzane is non-manifold. But I doubt that it being from other software matters. Instead I thought maybe it’s the number of islands? The rubber toys flippers and back fins are all floating islands, not connected to the body, but they are all water tight, no holes anywhere.
I used Suzzane too, I just deleted some of the eyes and bridged the edges from the eyes and the eye sockets to make it all watertight. That seemed to work fine as you can see in the video.
And just to make sure, I used the pighead from Houdini as well, an airtight suzzane like object, had no problems there.
However in nice news
This setup used to HAVE to use the exact solver and was simply too computationally heavy to work with without baking after every single boolean. It’s now completely workable without any baking using manifold.
Each green highlighted node is a Boolean operation, so 5. Smooth as butter~~
12 Likes
It is interesting that some of your booleans form a tree of boolean operations. How common is this (question addressed in general to Geometry Node users).
The Manifold library encourages such trees to be fed to it all at once, both so that it can optimize the ordering of the operations, but also so that it avoids the needed conversopm back and forth between its internal format and the external format that I feed in and take out (not to mention a bunch of other work I do to merge triangle and triangle fragments afterwards).
All of this to say: I should definitely try to figure out how to take advantage of that in Geometry Nodes. Three approaches come to mind: (1) cache the intermediate form with the intermediate Geometry-Mesh structures inside of Geometry nodes, and retrieve those instead (this would only gain part of what I’m talking about); (2) provide a “boolean mesh expression tree node”; (3) somehow process the node graph and automatically recognize such subgraphs and do “something”.
To the Geometry Node developers: does any one of these sound more attractive to you than the others?
This would not be on the top of my priority list to work on right now, as I am back working on a bevel node; maybe some other developer or volunteer developer would like to take a crack at this?
5 Likes
Nearest one is recent talks about support of the holes mask in a gp.
Not sure there is a good way to embed such a tree into geometry nodes, mainly because this will introduce new kind of referencing. Like if you can such a tree, and use it result mesh in some node, but also add one more node into the tree and now taking its new result where we should compute the meshes?
If to make it fully constext depend this will ednup in fields-like a form so this will be fully context-depend socket type build from Mesh to Op, set of operations like Add and result node Operations to Mesh.
Maybe its would work to use gp approach and represent such a tree as just an instances of meshes with same instance attribute like cut/not cut. But current representation of instances would make it less effective\
Extremely common actually.
Just to exemplify this without using my own work:
No need to watch the video here, but linking for posterity.
Our good friends over at Entagma, who occasionally do Blender Geometry Nodes Tutorials did a tutorial this march that has multiple boolean operations, one branching off of the “main” geometry.
Fortunately they offer the project files so I didn’t have to make this, but I cleaned up the graph slightly. Again I highlighted the 3 Boolean operations in green. One is in a repeat zone, and another in a for each loop.
Each boolean operation can be seen here (except for #1):
- Input Geometry
- Create crystalline Shape
- Create edgewear
- Create Inner Geometry for Refraction Purposes while Rendering
Notably, the first boolean operation directly makes the setup for the third boolean operation (the one in the for each loop), and the third boolean operation directly uses the second boolean operation in it’s inputs.
Hope that helps some!
They added to sculpt mode!!! it works great just leaves a decimated mesh as result, the good thing is that the sculpted details (probably any face that its not flat) are intact.
this is one of those “Im not sure if its a bug or a feature”
2 Likes
In my mind it is a bug that some original faces get merged on output. I’m looking into why this is happening.
2 Likes
I get a lot of inverted faces on more complex. Not sure if the is expected behavior. This is just the pighead from the second post here
Hey ^ relevant
Basically the mesh boolean can be used as a decimate node lol, not sure it’s good that it doesn’t tell that to the user since it will change part of the mesh that have nothing to do with the boolean.
There seems to be some situations where the difference operation on manifold does boolean but doesn’t remove the geometry, leaving “scratch marks” on the mesh.
While I can probably reproduce these kinds of things from the videos, it would be most helpful to me if you could find a file as simple as possible where this happens and file a bug. That saves me the initial work of trying to get a small example that I can print debugging information about without it being too much data to wade through. That will also make it easier for me to track whether or not I’ve addressed each issue yet.
I don’t need this for the issue of overaggressive face merging. I already am working on that. So this is more of an “in the future” desire. But if you don’t have the energy to do that, that’s fine too, it is nice to be made aware of these problems in any way possible.
1 Like
I’ve reported the normal issue, and provided two files which pertain to the 2 first posts in this forum.
I can’t seem to recreate this anymore with the latest built.
Thanks, I will look into the flipped normal one.
The other one must have been due to the bug about transformations, because that’s the only relevant code change that has happened since the first release of this feature.
I found a way to fix the “original coplanar faces get merged” problem. However, it doubles the time to do the boolean on a 250k face example.
The Manifold maintainers think they can change things so that the old way I was using would work (and, hopefully, be at the current speed). So I’m in a bit of a quandry: should I submit the current fix, which will not have the problem of merging coplanar faces, or wait until a fix from Manifold? I guess I’ll do the former, but it means that those of you testing the speed of this new solver should be aware of the temporary (I hope) slowdown.
4 Likes
im testing after the “fix” the speed with Manifold its on par with Float mode and doesn’t flicker like crazy so its very decent.
Why not include both? I mean just as an exposed setting
If you mean, both the “does proper maintaining of existing faces” and “is faster” methods: well, the Manifold maintainers are working on something that should both of those things at once.
We want to be careful about adding more options: it is more difficult to understand, document, maintain, test, and puts a backwards compatibility burden on future maintainers of the code. So the default position is “don’t add an option unless it is REALLY valuable for a bunch of use cases”.
6 Likes
One this note, is there any chance we will see some of the other very usful functions in the manifold libery as well? Like @costavojik meantions, having it as a decimation node could be very usful!
Not to meantion the make mesh manifold function, node! Then the booleon could work in even more cases, fix meshes for 3d printing or a fill hole functions etc 
3 Likes
