Definitely a great news, having exact solver enabled by default speed improvement is n°1 priority
hey i found a bug when using the boolean tool in edit mode… is leaving some nonsense loose vertices, edges and faces there after the operation…try both solversfaucet-test2.blend (276.8 KB)
thanks, I’ll look when I get some time.
Hi Howard - I don’t know if you remember this bug during the newboolean development phase last year…
Anyway - It’s fixed real good - I thought you would be entertained to see what’s been happening with blender thanks to the newboolean code you wrote…
There is a small chance it might be the worlds first welded aluminum boat designed using only blender and python
Thanks for sharing that!
That… is… AWESOME!
I’ve been working on a fluid simulator using newboolean to calculate hull waterline and stability curves - it’s working very well and VERY fast - I’m able to do whole simulations with thousands of boolean calculations in only a few seconds.
I think I uncovered a strange bug which is causing me to scratch my head:
Starting from empty scene (blender 2.92 release build):
- Add standard Cube Location(0,0,0)
- Add standard Icosphere Location (0,0,2)
- Cube object add boolean modifier intersect target Icosphere
Result (seems incorrect):
Result geometry occupies ALL of original icosphere volume - not ONLY the intersection space.
The unique thing about this scenario is there is only 1 vertex intersecting the cube top plane exactly on the plane surface of the cube (single vertex exact coplanar intersection).
If you change the icosphere position to Z 1.99 the result is CORRECT - the result is only the tip (intersecting geometry):
If you change the icosphere position to Z 2.01 the result is CORRECT - no geometry intersecting:
Thanks for finding this. I’ll investigate and fix.
I’m looking at a way to use collection info as source for boolean operation (many walls cut by one box), however looks like in result wall’s uvs are lost.
Thanks Stephen, I will look at it.
I’m working a lot with booleans and bevels and I was thinking if there is any possibility to add an option to Boolean Modifier (on/off) that would add bevel on booleans intersection (without swapping bevel modifier on bottom and trying to match with proper angle)?
I have wanted to do something like this for quite a while, but two things have held me back. First, I want to make bevel better so that it can really handle this task well. Bevel needs to work when the bevel amount causes the extending edges to overlap other geometry. Second, geometry nodes and attributes offers a more reasonable way to pass the intersection edges to a subsequent bevel operation to use as edges to bevel.
Why sometimes coplanar boolean does’t work? I don’t understand what is wrong with this example.
coplanar-boolean.blend (791.6 KB)
try applying scale
No need for this, in this example scale is 1.0.
this was the result of my test in 3.0 w/ decimate as well.
hey jerry what software do you use for recording these videos here? and how has the compression and video settings to be able to upload here without the upload limit warning?
I am actually posting them to discord then posting the links to other sites.
So there still that unnecessary geometry like this edge on the center. In my case there’s also not correctly joined geometry on the bottom.
@howardt How can I avoid something like that?
I have to consider what to do here. I hope to get time to look at it this coming weekend.
There are two things going on with coplanar intersections that are contributing to things like this:
My default assumption has been that any edges were original input edges (or pieces thereof) that made it to the output should stay in the output, even if they are embedded in a coplanar intersection.
When I dissolve the edges that don’t fit the criterion of 1 – that is, edges that were added to triangulate the original model, because the boolean and intersection algorithm only works on triangulated meshes – I have to be sure to leave valid BMesh faces. That means, for instance, that you can’t have disconnected-to-the-boundary edges, or even connected-to-the-boundary-at-only-one-place edges. The greedy algorithm I use to do this doesn’t always do the best possible job (as judged by we humans).
I am reconsidering whether (1) is a good assumption. I’m thinking it isn’t, for edges that are inside the result of a coplanar boolean result face.
I may have to think of a better algorithm for (2).