@howardt if at some point this does become a bmesh.ops.*** something that would be awesome to have in the result is the list of edges that make up the intersection boundary.
4 Likes
Yes, I understand why that would be useful, and it shouldn’t be that hard to supply.
7 Likes
back up in da club.
edit: sorry to keep trying the same case.
knife as an operation would have made my day. I will continue to dream about non destructive supportive geometry.
Next up boxtest
Feeling faster compared to before but after cut 4 it gets a little choppy. One of my favorite test cases is the boolean / bevel / weighted normal combo to really crush things and see how it performs.
This is one of my fav tests to try.
Now for the crush case. Stacking bevels and booleans.
crash at the end prolly our fault
3 Likes
Thanks for the new tests.
Nothing really changed functionally from the previous build. I have just been making code changes to satisfy reviewers so that I can merge this code into master.
Today I am looking at performance again.
5 Likes
@howardt What do you think about adding a “union” mode without geometry merging, just like if meshes were simply joined in edit mode but with respect to their animations, modifier stacks, etc?
This seems like a rather different kind of modifier than what Boolean or even Boolean Knife is about. I suppose if I’m adding more modes then having one that is basically “don’t do anything to the mesh that is input to the modifier” would be possible. One has to worry about putting too many options in a tool though, for user understandability.
5 Likes
There are new builds up at the buildbot. I still haven’t fixed jachtarfranko’s bug; I’m looking at that now. The new build has one bug fix that may or not fix masterxeon1001’s bug - I can’t tell if I’m not doing the same or if the bug fix made it go away. At any rate, it looks similar to the jachtarfranko bug. The main change of the new build is a fairly big internal refactor that should do nothing by itself, but prepares for a nice speed increase soon after.
The other developers are OK with merging this to master now, but I would like one final kick of the tires by some of you to make sure it is basically OK (modulo those bugs just discussed). In other words, does this feel like “about as good as the old boolean?” (except for speed, which I am still working on). The plan is to put it in master for 2.91 with “Exact” as the default. Not sure if that’s what we would release with, but will get me more feedback during the alpha testing stage.
6 Likes
tests
If it could let me just get to box city with just exact on… (25+ booleans)
1 Like
If you could post a file with an example of a box city you’d like to be able to handle, I could use it as a timing example when I work on speedups.
2 Likes
In this example the first 5 cuts felt nice (shading aside) however once the next level of bevel was added it began to stack up. And with the Weighted normal at the end it was the nail in the coffin. I copied the cube into 2.90 to show how it works normally at this time. We still use this opportunity of slowness to dissect ourselves in hope of finding speed optimization.
Also did the obligatory example. Box Union.
3 Likes
This file was started on an i7 laptop and this morning I am testing it on an i9 nuc.
In this example I also testing the face translation in edit mode since it gives me the most accurate speed expectation.
5 Likes
I merged newboolean into master, so from now on you should look to nightly builds for updates.
I still haven’t fixed the bugs reported above, nor worked on any more speed improvements, but there’s an open weekend coming up…
26 Likes
Congrats Howard for your hard work, 
2 Likes
howardt is master 2.83.6? Is it merged into 2.90 and 2.91? Thanks
Only 2.91.
2.84 and 2.90 are feature locked already
2 Likes
Just confirming that gorion103 is correct. 2.83 and 2.90 are separate branches from master, and do not get automatic backports of new things (only bug fixes are going to those two now).
Newboolean will show up in nightly builds now, and will be in 2.91 (barring anything unforeseen).
3 Likes
I fixed the bug that jachtarfranko reported a while ago (though there’s a lingering bug where it doesn’t dissolve all the diagonals it could – I’m working on that now). This also seems to have fixed the problem that masterxeon1001 found with certain repeated box unions.
This fix should show up in the next nightly build. Or you can pull from master and build yourselves. If you do that, be sure to set WITH_GMP in the cmake options, or else the Exact mode boolean will not be built in. This will be the default when configuring a new build from scratch, but not sure what will happen if you have an existing CMakeCache.txt.
3 Likes
Hi Im wondering if this lag is also by uv vertex data from every added new boolean object with already added uv in default? I am sculptor for 3d printing and i found that those uv vertex data, color, groups ect. they slow down performence of everything when it goes with booleans and another different modifiers in use that not remove vertex data any kind.
Regards and thanks for fantastic work
Thanks for the thought, but this is not the biggest source of lag right now. The biggest source of lag at the moment is a step that finds all of the coplanar triangles that overlap. I know how to fix this. Then something else will be the biggest source of lag…
9 Likes
thanks, boolean will be very usefull now 