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.
2 Likes
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.
10 Likes
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
2 Likes
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 
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.
4 Likes
If you have a patch for this, AFWS, please post it to developer.blender.org 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.
5 Likes
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.
2 Likes
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.
Edit:
OK, I got it working. I had to make a custom dependency update for that property.
3 Likes
Nice work ! 
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.
7 Likes
Looks like it works across multiple objects and collections.
Children option on sphere.
Collection with the spheres.
4 Likes
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
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.
I’ve got to admit I’m getting a bit confused now that people are talking about Source and Target. Which is which?
I found the UI in post 11, easy to understand, and have gotten progressively more confused in successive posts as to what the UI was intended to mean.
Another possible UI would be a simple list of objects (not collections), each with an “include” or “exclude” flag that would be present if the operation were Difference. What do people think of that UI?
1 Like
It’s the same thing. I just renamed source to target. Does it look better expanded like post 11?
The list would work, but I think the use of collections is more elegant here, for a few reasons:
- It’s already used elsewhere-- the fluid modifier, for collision groups, and field weights in the rest of the physics system.
- There are quick visibility controls in the outliner for a collection of boolean objects that you might want to hide in a render, etc… Using the same collection organization for the modifier itself would be faster.
- This is more just a personal opinion, but in my opinion trying to include a good list UI in a modifier panel is a challenge at best, and redundant / ugly at worst. There’s a patch for a volume boolean modifier that has a UI list in it, and IMO the list is pretty cumbersome.
I also like the way that there’s a single operation per modifier here, it makes it easy to tell what’s going on at a glance.
EDIT: Also, maybe “Operand Type” is clearer than “Target”
3 Likes
All fair points in favor of collections. I like that better too, but was just floating another option.
I don’t know what the right answer is for the name of the thing is: “Target”, “Source”, “Operand Type”. In my mind, what it is is “the other operand”, where the first operand is implicitly the object that the modifier is attached to. When it is used in a Difference operation, “Cutter” is a good intuitive name, but for Union and Intersection (and, in my future imagining mind, some Knife-like operations), something as simple as “Operand” or “Other Operand” feels right to me.
2 Likes