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?
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”
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.
I got confused too after post 11, especially because of all that children options.
What I understood at the beginning is that a checkmark would allow to treat all the boolean objects in the collection as if they were children, or in other words they would have transforms linked to the main ‘booleaned’ object
Does this explain it better? I removed everything related to children ,since it was confusing. I thought the reason behind it was to be able to move the “cutters” with the modifier object? If you watch the video, it works with the collection option, so no reason really for a third “Children” option. You just need to parent those objects.
Would probably be possible ,but I don’t think the devs are a fan of modifiers changing things on other objects. I have the display option which is useful ,but that will probably get rejected, since it overrides the objects settings.
Is this related to this bug report https://developer.blender.org/T80432 ? Looks like it might be ,but not sure. Was getting ready to submit patch then discovered one case where a crash happens.
It crashes as soon as you make the modifier cube disappear with the big cube. It doesn’t crash when set to Union, if only the cube is in collection or operand type set to object.
I don’t know if it is the same bug. I cannot reproduce the crash in my debug build for T80432, though the result is clearly wrong so there is something for me to investigate there. Does your case work OK if you use the Exact mode instead of Fast?
Does this error message work properly? I just did a make full to test Exact mode and noticed it still gives this warning. According to blender_full.cmake GMP should be enabled when doing full build.
Seems it crashes when scaling and it’s both Exact and Fast. Could be related stuff I did ,but it’s odd it doesn’t do it for union.
#ifdef WITH_GMP
const bool use_exact = bmd->solver == eBooleanModifierSolver_Exact;
#else
if (bmd->solver == eBooleanModifierSolver_Exact) {
BKE_modifier_set_error(md, "Compiled without GMP, using fast solver");
}
const bool use_exact = false;
#endif
Did your make full make a completely new CMakeCache.txt? I worry that it may carry old values. You need to have WITH_GMP to be set in order to get the Exact mode to actually use the new code.
Hi Howard.
Writing here the first time. Thank you for your great job. New Boolean is much much more reliable!
The idea of having a whole collection as one of the input is awesome! I would vote for implementing it!
I also would like to suggest one little improvement:
what if we could have fourth operation, which combines Difference and Intersection?
I saw many hard modelling tutorials and time-lapses and would believe such a feature could save some time and one modifier less in a stack.
I’m afraid I don’t know what you mean by combining Difference and Intersection. Can you perhaps give an example (with pictures) of what you want to have happen?
It’s usually called Slice in Booltool and other addons, it works by copying object A and setting first Boolean Modifier to Difference and second to Intersect so you end up with 2 parts separated by live boolean. It’s very good for creating paneling with combination of bevel modifier on top:
I see. This is like what the Intersect (Knife) does in Edit mode, except that it wouldn’t remove interior faces the way a Boolean might. In typical cases, though, it is the same. I have been thinking of adding the Knife modes to the modifier. Or making a Knife modifier.