Major Boolean Modifier Upgrade : Use as boolean object a whole collection


i don’t know if it was already suggested but here is a simple modification that could greatly improve our lifes while working on boolean modifiers, while we still keep the current workflow

use as boolean object an entire collection

Before :

most of the time, what take the most place in the stack is the booleans modifiers,
it can quickly grow way high, readability is not really in her prime here

After this simple modification:

Note :
-altho as bonus, use children as bonus could also be useful
-i use modifiers tools addon, the top bar after add modifiers is not part of my mock-up


In what order are the collection objects booleaned and how do you change that order?

why the order should matter ? if theres is no modifiers in between the result is the same in either union or difference, i just did some test to be sure.

maybe youre speaking about the threshold ? yes this pose a problem, maybe we could lock it to 0 if collection or parent option is choosed

this idea is not really useful for intersect tho

Maybe the order can just depends on the object’s name in alphabetical order. So adding just number at the beginning of the name it can affect the order of the operations.


The idea is not bad at all. The only main disadvantage I can see at the moment is that choosing the wrong collection by mistake can potentially freeze Blender. But anyway that is the case already for many operations when the user does something wrong.


This is an interesting UI suggestion.
The newboolean code I have been developing has been written so that it can do a boolean operation on many objects at once – and doing so will be much faster than doing them one after another. So I had been wondering what UI to use to expose that to users. I had been thinking of some kind of list view where you pick objects one by one. But the suggestion here would be easier to implement and has the advantage of also being more comprehensible to the viewer if the collection is large. Since my code does it all at once (and pays not attention to threshold, since arithmetic is exact), order does not matter. Also, intersection and union both work in this scenario.

I don’t quite get what is supposed to happen with the “children” box. Someone please explain.


that was just another minor sub proposal, nothing important compare to the main collection as cutter idea that could greatly improve booleans workflow.

basically use all children of the object as cutters

i was thinking of that because most of the time we are doing this for practical reasons, as we want to move the main object with all the cutters anyway


Nice move. Maybe a “Link boolean objects” would be more clear and let the user avoid the task of parenting everything?

edit: “Link boolean objects” is not a great choice of words. Too vague. It should make clear that it propagates the transforms of the object to all the booleans. You english speaking people find the right words please :wink:

1 Like

yeah maybe a simple operation for workflow practicality as a bonus ? this can be done in python easily.

i don’t know that much on how the main idea is implemented in C, but if the input is just a list of objects then having more options on how to generate this list (collections, children, or even a python API with raw object list, etc… ) don’t cost too much and give more options to the users which is always great imo.

Been playing around with this. Seems to work ok, although you can’t really use with intersection.

Error message if you try to use collection with modifier object.


If you have a patch for this, AFWS, please post it to and tag me as a reviewer. I would really like to do something like this after I have gotten newboolean in master and beaten down any bugs that come up.


I worked on this ,but the only way I could get the parented objects was through a collection.

This is using children option. Only using parented objects, even though the collection contains more objects.

This is collection option. Using the entire collection.


Needs more work ,but I can submit a patch. Couple issues needs solved first. It’s not updating when the objects in collection changes, unless you change a setting on the modifier.

A setting to see boolean results would be nice. Would keep from having to set each object in the entire collection one at a time.

OK, I got it working. I had to make a custom dependency update for that property.


Nice work ! :grinning:

Isn’t it possible to use a list of mesh-Data as input ?
Defining how the list is built could be done via GUI

That’s how I’ll do it using python but I’m not sure if the concept of list of object as input can be done in C++

1 Like

I have some projects on Boolean (mostly performance) that will take me a week or two, but after that I would seriously consider working on getting something like this into Boolean, so please do make a patch when you feel ready. Thanks.


Looks like it works across multiple objects and collections.

Children option on sphere.

Collection with the spheres.


Nice work

I find this quite confusing in a UX standpoint

Children are already inside their own object « collection » So why there’s the need to have a double filter here ? It’s like they need to be in two collections at once

Imo that’s a bit confusing

This How to use Main *bmain? ,plus it seems to be limited on what can be accessed from modifiers.

Maybe this is better. I got rid of Children as target option and added as toggle to limit collection objects to children.

You can see sphere.001 and torus is not used, even though it’s in the same collection.

Not sure if it’s possible but I feel like most optimal ux is to add children as target option and remove collection input field if it’s selected. Then it’s just one click (or no clicks at all and few ctrl+scrolls)

Having to change target to collection, then selecting children collection option in input and then clicking on children check mark is a lot of setup.

Most common use cases are gonna be:

Target Type: Object
Target: Some Object

Target Type: Collection
Target: Some Collection

Target Type: Children

I think it’s safe to assume what we want to use children of our main object and not something else, so there is no reason to expose input field.