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

I think these might make more sense in an “Object Visibility” (or similar label) subpanel. They should be grouped and separate from the modifier’s actual settings probably.

Would we expect it to be a problem that there’s no option for setting the visibility back to solid? Or similarly, back to visible. I doubt it, but we should be sure.

Not a real problem, but maybe it’s worth adding it

agree, even if it will make it less immediate

oh i didn’t realize that. Maybe putting all operators in a subpanel solves?

You talking the display type or where the hide viewport doesn’t reveal all objects if some gets disabled in outliner?

object_disable_3

3 Likes

For me we’re almost there. Only those hide icons… all alone there??

Yeah ,not a fan of all that space.

Edit:
How about this?

boolean_align_right

Or should they stay separated?
boolean_align_right_2

2 Likes

Hi! I am not sure if this is the correct place for this comment but, is there a plan to add output vertex groups for the boolean modifier like in the solidify modifier?

By output vertex groups I mean-


Having the option to get the operand, the cut and the operands(A, B and C in the image, not in that order) as separate vertex groups.

I created a thread on right-click select for the same a while ago. Link

2 Likes

you want that for boolean clean up using for example decimation or weldon C vertex group?

Yup, that was the initial thought. Having the functionality to add modifiers on just the ‘C’ vertex group. It can be really useful if you are doing hard surface modelling non-destructively.
For example, having a custom bevel depth for each boolean cut.

1 Like

mesh mashine addon have this ability. I also tryed to do it manualy for my workflow and it cinda works. You need before boolean operation add vertex groups to objects and asign them all. then when you make boolean option will those vertex groups combine in to one without those new vertexes created by boolean. next you need to go in vertex mode and just create new vertex group and asign inverted selection from that first vertex group. and you have C vertex group:D yea lot of work but is faster then manual selection sometimes if you have dense meshes.

1 Like

Maybe like this?

image

I updated the diff with them being separated. All the other visibility/render settings are just icons.

https://developer.blender.org/D8943

I think it looks better but having title only for bottom row looks odd. Also just having bunch of separated buttons reminds of 2.7x button soup.

How about something more in style of 2.8x:

изображение

With icons:

изображение

Also since Display as is kinda duplication of this object property but in button form shouldn’t we also include Textured as button?

изображение

If someone only used these buttons from modifier ui they could get confused why they also can’t restore texture visibility from there (rare user case where someone wants to turn boolean brush into “normal” object). Booltool addon has a button for that:

изображение

Is there consensus how much of Booltool functionally we should bring into base Blender? For example what about shortcuts, they are still number 1 reason to use addon instead of all these new visibility buttons and manual addition of modifiers (except new collection mode of course).

Because button soup is the only option that will get accepted. Your example is going back to a enum property. That got shot down, cause it overrides the object’s display settings.

button_soup

Hmm, what about just directly lifting these properties look from here and putting them inside Operand Display submenu:

изображение

Then they have consistent look / naming with object properties and can be animated.

EDIT: I reread topic and see what only operator / buttons will be accepted so this is not a solution.

This works for the old Boolean method but not for the new “exact” method that has been added to 2.91 :slightly_frowning_face:

I can understand the desire and usefulness of having the geometry affected by a modifier somehow be accessible to later modifiers in the stack. It feels like vertex groups is an imperfect, slightly hacky way to do this. I think ideally you would want edge groups for C and face groups for A & B in your diagram.

Also, such features should really be designed coherently and be added to all modifiers that similarly produce new geometry. There is already a bit of a piecemeal way of doing this (e.g., some modifiers have a material index to be assigned to new geometry). But it doesn’t feel like a good, coherently designed system to me. As usual, the refrain “Everything Nodes” is probably the right answer here.

Similarly, there is a desire/need, already expressed by others, for a good Python API for Boolean that exposes this information. Given that we are in bcon2 (the phase for 2.91 where we are not supposed to add new features, or at least “big” new features), I am reluctant to add these right now, though will likely do something for the release after. I think the API one is easier (rather than setting vertex groups, it would return a list of edges for C and lists of faces for A & B).

I am worried that even an operator / button approach will be perceived by the users as not being buttons. The UI style makes it hard to distinguish between a button and an enum state – the main difference is just that the enum state control stays pressed after you hit it – and this distinction may be lost on people. In fact they might complain that the button has no visual feedback in the UI after clicking it, so how do they know it “took”? (I know, they could just look at the viewport, but what if the viewport is very cluttered.)

I wonder if just adding the display setting would be better than operators? You can click and drag to change them quickly.

Object
object_display_setting

Collection
collection_display_setting

Thank you so much for the response! My initial feature suggestion (on right-click-select) was about having this functionality in all the relevant modifiers in the “Generate” section. But yes, I understand. This seems like something that should be well integrated with other systems in Blender. Modifier nodes should solve this and hopefully, by that time we will have edge groups too.

I like this, is quite clear. Can we just turn those enumerators into button operators? (and tell nobody…)

1 Like