how difficult would it be to make the boolean modifier multy threaded?

It seems the modifier only uses one 15% load and I am running on an 8 core xeon system.
Boolean operations can be quite slow when the input meshes are using subdivision surfaces.

A speed boost could really propel the usability of the modifiers alot - specifically because 3d printing becomes
something very accessible and still with good subdivision surface surfaces you can simulate a lot of NURBS precission modeling.

I’m not a programmer but I would imagine quite difficult if the mesh was continuous.
Even if you could speedup/multithread boolean modifier with mesh/s that is made up of multiple separate elements already (for example roof tiles), that would be extremely welcome.

No a programmer here either - but the slow computation time can really discourage users from using the boolean as an interactive tool.

And Blender compared to Modo is so much usable because of the modifiers being interactive !!!

It depends, it doesn’t sound to me like the Boolean modifier has the kind of operations that be easily be split into a parallel process.

The boolean modifier for example looks to be working on the entire mesh at once, and you need to note that not everything can just be told to use multiple cores and it magically speeds up, it needs to have processes in the code that can afford the ability to be divided among multiple cores.

I guess if you split the mesh into virtual segments or tiles for each thread to work on it might theoretically work, but then you might have issues on how to deal with triangles that would go across those divisions, it’s not really an easy thing to answer unless you got a reply from an actual coder.

My guess is: It doesn’t matter. Blender just wraps Carve, Carve isn’t multithreaded and isn’t being developed and there is no multithreaded alternative. If there was any substantial parallelism in the algorithm, it probably would’ve been implemented threaded in the first place. Otherwise the speedup you get from threading is likely negligible or even negative.

No a programmer here either - but the slow computation time can really discourage users from using the boolean as an interactive tool.

I believe the main thing discouraging people from using polygonal booleans is the results you get. Why spend increased effort on something that is never going to work well, anyway?

The core usability problem here is that Blender locks up completely when calculating modifiers. If you could move around things while calculating the result in the background, that would improve usability tremendously. No matter how fast you can make booleans through threading, you’ll always easily get into areas where it isn’t usable anymore. The same is true for many other modifiers.

Modo is the king in this. For me this is how boolean should works. it can even be Baked… i don’t care if the output would be such good i am all in.

This is a bit private video only from this link u can watch it… So really cool stuff

I think you underestimate the power of booleans and they work pretty well in Blender as well.
I can also in Alias lock up the system well just with a complex NURBS model. Blender is no exception here.

Booleans are with polygons not an all wonder product specifically because you cannot round edges reasonable with polygons at all.
So the way how I use booleans is simple simulating a process I would follow with NURBS. Edge rounding I do as a feature at the end.
Seeing it this way Booleans are incredible useful.

But they have to follow a subsurf modifier which makes it I would say less to nearly useless for character design. But for everything else they are terrific.

It surely would be great if there would be something put into Blender that could freeze the update of booleans at all. Or when moving an object also stop the calculation till yo release the mouse.

Well this is a plug-in not really Modo itself. So not so really king till it is released and then I am curious how much it will cost.

The result is interesting while the edge rounding had a lot of surfacing problems …

3:11 this is superb bevele… I Can say to you that 80% people on this forum have no idea how to model such think with support loop for beveled edge.

For me the Booleans’ greatest letdown is that they triangulate your mesh rather than rely on Ngons. It makes them near useless during modelling - it’s almost always faster to model by hand than to clean up after a Boolean op.

Carve was integrated into Blender just a tiny bit before Bmesh, and Naz-gul mentioned in his notes it was possible to support ngons, but after bmesh went in, nothing happened.

No question that the Boolean modifier needs to be cleaned up. I wonder if trying to re-implement it as a Boolean tool would be easier than keeping it as a modifier. Because as it stands I - and it seems everybody - applies it, and then spends some amount of time cleaning it up.

You can use X->limited dissolve with max angle of 0.001 basically that will convert your flat faces into ngons. Or use a decimate modifier on planar mode which is basically the same thing but a modifier.

But you still need to manually create some supporting edgeloops if you want to chamfer or sub-surf or something. However this topic is more about the speed/performance of the modifier rather than quality.

I really don’t think I do. I’ve used them extensively and I’m aware that for what they are, they’re working well.

I can also in Alias lock up the system well just with a complex NURBS model. Blender is no exception here.

I’m not saying that it is, almost all tools fail miserably in this regard. They don’t put emphasis on it, because they don’t value user experience as much as not having to deal with concurrency.

Just use a limited dissolve, either in the decimate modifier or as an operator.

This only works with objects of a certain topology, not arbitrary topology. It’s made by the guys from Groboto. Of course, non-general or approximate solutions easily can achieve better results.

it works with all toplogy. Acctualy there is secound video but i don’t have a link… Where was much complicated object… with very desne mesh and they import another object from zbrush and just cutted it out.

I believe it when I see it. It may work with arbitrary amounts of these boolean objects to get complex meshes, or on another quad mesh, but not with arbitrary triangle meshes.

Oh come now, I’m already taking that into account. Rebuilding the topology the limited dissolve destroys still often takes more time than modelling by hand.

Wait for next modo :>

Well, what they promise is that it works with any sub-d mesh (hence the original name of the plug-in “Sub-D Fusion”). Since triangle meshes don’t go well with subdivision, that has - strictly speaking - never been part of what Mesh Fusion is supposed to offer. However, if Mesh Fusion should work as advertised (having my doubts myself), this will be far superior to any boolean solution I know of.

Again, it’s a plugin that focuses on integrating some of the Groboto functionality directly into Modo. It won’t be a part of the next Modo release since it is developed by the Groboto team and will likely cost an arm and a leg to buy.

Seeing Groboto it seems to quad divide mesh where needed to force geometry into the shape it needs. The problem is you end up with high density meshes. If you are on a only poly workflow you might have not any other choice, if you are having access to a SDS to NURBS workflow it would be overkill.

When I learned Maya I started with NURBS and they hardly teach it today, but nearly everything I see at the GROBO website I could better and faster build with NURBS and end up with a less heavy poly model afterwards.

Interesting how preferences change …