Regression: Boolean Difference modifier - material of hole created by hidden object different for fast and exact #99592

New Issue

Don Manson · 2022-07-10T19:08:47+02:00

Don Manson commented

2022-07-10 19:08:47 +02:00

System Information
Operating system: Windows-10-10.0.19043-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.23

Blender Version
Broken: version: 3.2.1, branch: master, commit date: 2022-07-05 15:44, hash: a2d59b2dac
Worked: 3.1

Caused by a2d59b2dac

Short description of error
When using Boolean difference modifier with hidden objects, the material depends on whether the fast or exact solver has been used. With "Exact" the material is that of the hidden object. With "Fast" the material is that of the original object.

Exact steps for others to reproduce the error
Create object, say cube A. Material colour Blue.
Create second object, say cylinder B, partially inside cube. Material colour Red.
Create third object, say sphere C, partially inside cube A. Material colour Green.
Created boolean difference modifier acting on A with B as object using Fast solver.
Created boolean difference modifier acting on A with C as object using Exact solver.
Hide objects B and C from viewport and Render.

The hole created from Object B inherits colour from object A.
The hole created from Object C inherits its colour from object C.

The same issue is present in EEVEE and cycles.

This behaviour is inconsistent and different from Blender 3.1.

Previously the hole always inherited the colour from the original object A.

Boolean hidden object colour.blend

**System Information** Operating system: Windows-10-10.0.19043-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1050/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 511.23 **Blender Version** Broken: version: 3.2.1, branch: master, commit date: 2022-07-05 15:44, hash: `a2d59b2dac` Worked: 3.1 Caused by a2d59b2dac **Short description of error** When using Boolean difference modifier with hidden objects, the material depends on whether the fast or exact solver has been used. With "Exact" the material is that of the hidden object. With "Fast" the material is that of the original object. **Exact steps for others to reproduce the error** Create object, say cube A. Material colour Blue. Create second object, say cylinder B, partially inside cube. Material colour Red. Create third object, say sphere C, partially inside cube A. Material colour Green. Created boolean difference modifier acting on A with B as object using Fast solver. Created boolean difference modifier acting on A with C as object using Exact solver. Hide objects B and C from viewport and Render. The hole created from Object B inherits colour from object A. The hole created from Object C inherits its colour from object C. The same issue is present in EEVEE and cycles. This behaviour is inconsistent and different from Blender 3.1. Previously the hole always inherited the colour from the original object A. [Boolean hidden object colour.blend](https://archive.blender.org/developer/F13283634/Boolean_hidden_object_colour.blend)

Don Manson commented

2022-07-10 19:08:47 +02:00

Added subscriber: @Don_Manson

blender-admin commented

2022-07-10 19:08:47 +02:00

#101054 was marked as duplicate of this issue

blender-admin commented

2022-07-10 19:08:47 +02:00

#100230 was marked as duplicate of this issue

Pratik Borhade commented

2022-07-11 14:19:44 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-07-11 14:19:44 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Pratik Borhade commented

2022-07-11 14:19:44 +02:00

Thanks for the report. I'm able to reproduce this. I suspect a2d59b2dac introduced the issue (will bisect just to be sure)

Thanks for the report. I'm able to reproduce this. I suspect a2d59b2dac introduced the issue (will bisect just to be sure)

Pratik Borhade commented

2022-07-11 14:55:40 +02:00

Changed status from 'Confirmed' to: 'Needs Developer To Reproduce'

Pratik Borhade commented

2022-07-11 14:55:40 +02:00

Added subscriber: @HooglyBoogly

Pratik Borhade commented

2022-07-11 14:55:40 +02:00

yes, changed in 5723bf926d
Unsure if this is expected behavior or not (I didn't understand the exact change made by that commit), @HooglyBoogly can you help?

yes, changed in 5723bf926dcb387224dd0de2a4c562bc316e8edc Unsure if this is expected behavior or not (I didn't understand the exact change made by that commit), @HooglyBoogly can you help?

Alaska commented

2022-07-15 06:00:32 +02:00

Added subscriber: @Alaska

Pratik Borhade commented

2022-08-08 07:42:48 +02:00

Added subscriber: @ChristopherGuest

Vitalii Shmorhun commented

2022-08-10 16:59:25 +02:00

Added subscriber: @acvarium

Vitalii Shmorhun commented

2022-08-10 16:59:25 +02:00

Tested version: 3.2.2, branch: master, commit date: 2022-08-02 18:15, hash: bcfdb14560. The same problem is present

Tested version: 3.2.2, branch: master, commit date: 2022-08-02 18:15, hash: `bcfdb14560`. The same problem is present ![scr2022-08-10_000.jpg](https://archive.blender.org/developer/F13357151/scr2022-08-10_000.jpg)

Omar Emara commented

2022-09-14 09:42:28 +02:00

Added subscriber: @chippwalters

Philipp Oeser changed title from ~~Boolean Difference modifier - material of hole created by hidden object different for fast and exact~~ to Regression: Boolean Difference modifier - material of hole created by hidden object different for fast and exact

2022-09-14 09:51:52 +02:00

Chipp Walters commented

2022-09-14 10:21:35 +02:00

It would be nice if someone could be assigned to fix this. It has been over two months now since it was first identified and it affects lots of people's workflows. We've been through a complete version update with it still broke.

Jan-Erik commented

2022-09-14 10:39:00 +02:00

Added subscriber: @JanErik

Jan-Erik commented

2022-09-14 10:39:00 +02:00

This comment was removed by @JanErik

*This comment was removed by @JanErik*

Steffen Dünner commented

2022-09-14 10:53:25 +02:00

Added subscriber: @SteffenD

Vitalii Shmorhun commented

2022-09-14 13:09:58 +02:00

To those who said it's not a bug, but feature. Just add this as a option to the modifier, if so. But it has to be disabled by default

Chipp Walters commented

2022-09-15 09:27:19 +02:00

Created a free addon to fix: https://youtu.be/L_jXRoGQD5g

Philipp Oeser commented

2022-09-15 09:50:23 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-09-15 09:50:23 +02:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

Philipp Oeser commented

2022-09-15 09:50:23 +02:00

Will raise prio to get feedback from @HooglyBoogly

Hans Goudey commented

2022-09-16 22:02:00 +02:00

Sorry for the delay replying here, I missed the notification above.
I'd say the behavior in exact mode is "correct" and certainly expected from the current code.
The previous material mapping was implemented that way because we couldn't change a mesh's materials during evaluation; the best compromise was to rely on manually assigning them on original data. Now that isn't necessary.

However, I recognize the change in behavior, when not noted in the release notes, is quite bad. Sorry about that.

Now that we're in this situation though, it's not clear to me that we should go back to the old behavior (which was also changed to fix a different bug #99191 and #93272).
Maybe it would be best to just make the fast mode consistent with the new behavior. Do you have an example of when the old behavior is better?

It's identified as a bug in the bug database

I wanted to clarify this (quote from the youtube), because it's not quite right. Reports are only bugs when they are classified that way, this report currently isn't classified.

Sorry for the delay replying here, I missed the notification above. I'd say the behavior in exact mode is "correct" and certainly expected from the current code. The previous material mapping was implemented that way because we couldn't change a mesh's materials during evaluation; the best compromise was to rely on manually assigning them on original data. Now that isn't necessary. However, I recognize the change in behavior, when not noted in the release notes, is quite bad. Sorry about that. Now that we're in this situation though, it's not clear to me that we should go back to the old behavior (which was also changed to fix a different bug #99191 and #93272). Maybe it would be best to just make the fast mode consistent with the new behavior. Do you have an example of when the old behavior is better? --- > It's identified as a bug in the bug database I wanted to clarify this (quote from the youtube), because it's not quite right. Reports are only *bugs* when they are classified that way, this report currently isn't classified.

Chipp Walters commented

2022-09-16 23:29:58 +02:00

First off, let me say the Boolean modifier operations in Blender are among the absolute best in the industry for surface modelers. I find none that are better. I even created a video about how great they are: https://youtu.be/g8x3UutEUGQ

There are a number of reasons I would hope you do not change the material swapping behavior-- and keep it like it was.

It's been that way for years and is expected behavior
Boolean modeling is about shaping a single object using cutters and unions. Why would you want every cut and union to by default be a possible different material?
There are lots of different libraries people use as Boolean "shapes" for Boolean modeling and having each of them carve out using a possibly different material creates confusion.
There is an easy existing and documented way to absolutely control the materials assigned to a target when modified by a Boolean.
No other program I'm aware of does it this way. Perhaps someone can provide a reference of a program that does by default transfer the boolean cutter material to the target object?

If you decide to change the behavior, perhaps you would consider adding a preference switch somewhere or a modifier property that allows for those of us who have existing pipelines and workflows to be able to continue as we are used to.

Some example of how bool modifiers are used to model:
https://youtu.be/KaTJssAwDno

And my thoughts on this:
https://youtu.be/SlXk51v6N8Y

First off, let me say the Boolean modifier operations in Blender are among the absolute best in the industry for surface modelers. I find none that are better. I even created a video about how great they are: https://youtu.be/g8x3UutEUGQ There are a number of reasons I would hope you do not change the material swapping behavior-- and keep it like it was. 1. It's been that way for years and is *expected* behavior 2. Boolean modeling is about shaping a single object using cutters and unions. Why would you want every cut and union to by default be a possible different material? 3. There are lots of different libraries people use as Boolean "shapes" for Boolean modeling and having each of them carve out using a possibly different material creates confusion. 4. There is an easy existing and documented way to absolutely control the materials assigned to a target when modified by a Boolean. 5. No other program I'm aware of does it this way. Perhaps someone can provide a reference of a program that does *by default* transfer the boolean cutter material to the target object? If you decide to change the behavior, perhaps you would consider adding a preference switch somewhere or a modifier property that allows for those of us who have existing pipelines and workflows to be able to continue as we are used to. Some example of how bool modifiers are used to model: https://youtu.be/KaTJssAwDno And my thoughts on this: https://youtu.be/SlXk51v6N8Y

Anthony Aragues commented

2022-09-16 23:47:45 +02:00

Added subscriber: @Anthong

Anthony Aragues commented

2022-09-16 23:47:45 +02:00

adding the material when doing a boolean should NOT be the default behavior.

usually booleans are for creating a shape. In which case a uniform material is expected.

In the cases where the material transfer is desired, it's a long standing and well known way to do it.

I don't see a reason to allow this to be changed in a way that would cause people more time in removing the material for the default use case.

Maybe if you made a checkbox to select the behavior in the modal? That might be cool for the cases where people want it.

If it's one or the other the old behavior was better

adding the material when doing a boolean should NOT be the default behavior. usually booleans are for creating a shape. In which case a uniform material is expected. In the cases where the material transfer is desired, it's a long standing and well known way to do it. I don't see a reason to allow this to be changed in a way that would cause people more time in removing the material for the default use case. Maybe if you made a checkbox to select the behavior in the modal? That might be cool for the cases where people want it. If it's one or the other the old behavior was better

Hans Goudey self-assigned this 2022-09-16 23:50:23 +02:00

Hans Goudey commented

2022-09-16 23:50:23 +02:00

Thanks for the feedback, you make good points. I will look into adding an option.

Hans Goudey commented

2022-09-16 23:53:59 +02:00

Also, I wonder if you'd suggest adding this option to the boolean geometry node too.
In a more node-based procedural context we've found it very troublesome to rely on material slot indices, which is what inspired the newer mapping behavior in the first place.
Ideally there would be some way to achieve the old goal (booleans just affect the shape) without requiring the material slot indices to match when material transfer is wanted.

Also, I wonder if you'd suggest adding this option to the boolean geometry node too. In a more node-based procedural context we've found it very troublesome to rely on material slot indices, which is what inspired the newer mapping behavior in the first place. Ideally there would be some way to achieve the old goal (booleans just affect the shape) without requiring the material slot indices to match when material transfer is wanted.

Chipp Walters commented

2022-09-16 23:59:48 +02:00

Yes, I agree it makes good sense to add this option to a the Boolean geometry node. Thanks.

Anthony Aragues commented

2022-09-17 00:02:18 +02:00

In #99592#1418498, @HooglyBoogly wrote:
Also, I wonder if you'd suggest adding this option to the boolean geometry node too.
In a more node-based procedural context we've found it very troublesome to rely on material slot indices, which is what inspired the newer mapping behavior in the first place.
Ideally there would be some way to achieve the old goal (booleans just affect the shape) without requiring the material slot indices to match when material transfer is wanted.

yes, plus that would provide some consistency between the two... option in both places with expected behavior

> In #99592#1418498, @HooglyBoogly wrote: > Also, I wonder if you'd suggest adding this option to the boolean geometry node too. > In a more node-based procedural context we've found it very troublesome to rely on material slot indices, which is what inspired the newer mapping behavior in the first place. > Ideally there would be some way to achieve the old goal (booleans just affect the shape) without requiring the material slot indices to match when material transfer is wanted. yes, plus that would provide some consistency between the two... option in both places with expected behavior

Jan-Erik commented

2022-09-18 15:51:17 +02:00

No other program I'm aware of does it this way.

Houdini does it in exactly this way by default

maybe an easy way could be to do not transfer the the material when the boolean has none assigned, but if it has, it will be directly transfered.
Then the ones who just use booleans as cutters can do their thing but also the ones that need the material transfer can get it quicker working than before

> 5. No other program I'm aware of does it this way. Houdini does it in exactly this way by default maybe an easy way could be to do not transfer the the material when the boolean has none assigned, but if it has, it will be directly transfered. Then the ones who just use booleans as cutters can do their thing but also the ones that need the material transfer can get it quicker working than before

Hans Goudey commented

2022-09-26 23:53:21 +02:00

maybe an easy way could be to do not transfer the the material when the boolean has none assigned, but if it has, it will be directly transfered.
Then the ones who just use booleans as cutters can do their thing but also the ones that need the material transfer can get it quicker working than before

Looking into this again, it seems like this might be a good option. The simple behavior is kept for both cases: materials and attributes transfer from the cutter object, but if they don't exist, they aren't transferred.
I'd imagine that meshes just used for cutting wouldn't have materials assigned anyway, they're usually set to wire display anyway.

>maybe an easy way could be to do not transfer the the material when the boolean has none assigned, but if it has, it will be directly transfered. > Then the ones who just use booleans as cutters can do their thing but also the ones that need the material transfer can get it quicker working than before Looking into this again, it seems like this might be a good option. The simple behavior is kept for both cases: materials and attributes transfer from the cutter object, but if they don't exist, they aren't transferred. I'd imagine that meshes *just* used for cutting wouldn't have materials assigned anyway, they're usually set to wire display anyway.

Chipp Walters commented

2022-09-30 21:23:17 +02:00

Yeah, but I have whole libraries of meshes which I use as cutters which already have a material assigned to it. Ugh. Why change behavior at all?

Not to mention I have over 50K KIT OPS users that use cutters to model with. Do I need to have them all download new cutters (or edit their existing ones) now?

The BEST solution is to have it as a preference or switch, as we've talked about before.

Yeah, but I have whole libraries of meshes which I use as cutters which already have a material assigned to it. Ugh. Why change behavior at all? Not to mention I have over 50K KIT OPS users that use cutters to model with. Do I need to have them all download new cutters (or edit their existing ones) now? The BEST solution is to have it as a preference or switch, as we've talked about before.

Jan-Erik commented

2022-10-01 18:29:09 +02:00

Why change behavior at all?

bcause the new behaviour is more intuitive and faster

your agumetation is based on your business case? Just cause you need to write a few new lines of code for your product, Blender should instead keep the slower and less intuitive current system in place?

> Why change behavior at all? bcause the new behaviour is more intuitive and faster your agumetation is based on your business case? Just cause you need to write a few new lines of code for your product, Blender should instead keep the slower and less intuitive current system in place?

Chipp Walters commented

2022-10-01 18:31:36 +02:00

Please stop attacking me. No, it's not about writing a few more lines of code for my product, that would be easy. It's about inconveniencing thousands and thousands of users. That's what I care about,

Anthony Aragues commented

2022-10-01 19:40:44 +02:00

Making it an option would make it work well for everyone.

Keep the old behavior for people used to that.

Keep the new behavior if you like that better.

User choice, everyone wins :)

Making it an option would make it work well for everyone. Keep the old behavior for people used to that. Keep the new behavior if you like that better. User choice, everyone wins :)

Jan-Erik commented

2022-10-02 12:53:12 +02:00

in almost every release, things change that were previously handled differently for years. But if a new workflow takes less time or is more intuitive, what's the point of keeping the old, more cumbersome way just because some people have gotten used to it?

Anthony Aragues commented

2022-10-02 21:03:29 +02:00

can we speak in specific and useful terms?

{F13607506

see attached screenshot. This is a common and everyday task. I was modeling out an object, I needed to cut some holes through it. So I did some boolean diffs and I get this. I would not expect to have a different material or removal of material in the areas I cutout without choosing to make it that way. I know I can correct this by specifically updating the materials.

how is this more intuitive? faster? more efficient? less "cumbersome" ?

I am genuinely interested to know... in my common, everyday usecase of cutting a shape out from another object, how is this new method an improvement across the board to the degree that you think everyone should simply adapt to the new way without any options?

can we speak in specific and useful terms? {[F13607506](https://archive.blender.org/developer/F13607506/Screen_Shot_2022-09-29_at_12.10.00_PM.png) see attached screenshot. This is a common and everyday task. I was modeling out an object, I needed to cut some holes through it. So I did some boolean diffs and I get this. I would not expect to have a different material or removal of material in the areas I cutout without choosing to make it that way. I know I can correct this by specifically updating the materials. how is this more intuitive? faster? more efficient? less "cumbersome" ? I am genuinely interested to know... in my common, everyday usecase of cutting a shape out from another object, how is this new method an improvement across the board to the degree that you think everyone should simply adapt to the new way without any options?

Chipp Walters commented

2022-10-02 23:28:22 +02:00

People have been doing Boolean modeling for quite some time now. Esp for games and concept modeling. Please review this video and you will see how much of a hassle it is to change thousands and thousands of users workflow. It just doesn't make sense. If you have thousands of users workflow use cases, you should consider showing them.

youtube video showing cutters issue

People have been doing Boolean modeling for quite some time now. Esp for games and concept modeling. Please review this video and you will see how much of a hassle it is to change thousands and thousands of users workflow. It just doesn't make sense. If you have thousands of users workflow use cases, you should consider showing them. [youtube video showing cutters issue ](https://youtu.be/SzP8-OzDpac)

Chipp Walters commented

2022-10-03 10:41:11 +02:00

Another Boolean bug different from the current one: If you create any object in Geo Nodes and use a "set material" node to apply a material, then add a difference modifier to the object, there is no way I know of to actually set the material of the difference cutout from the GN modifier. See example. https://www.youtube.com/watch?v=RFm7wTqJsdY

Chipp Walters commented

2022-10-06 04:48:32 +02:00

Here's an even more serious use case. Often you want to use the same "cutters" (bool diffs) to create two different objects, each with different materials. If you a worked with the "leave the cutter material slot empty" solution, it would never work. So, PLEASE do not consider that option as there are NO workarounds for it other than to duplicate all sorts of objects. Not to mention there are currently NO workarounds for the current 3.3 situation either. Way, way harder. Here's a video that describes this properly.

https://youtu.be/6_hOV5aLoX8

Here's an even more serious use case. Often you want to use the same "cutters" (bool diffs) to create two different objects, each with different materials. If you a worked with the "leave the cutter material slot empty" solution, it would never work. So, PLEASE do not consider that option as there are NO workarounds for it other than to duplicate all sorts of objects. Not to mention there are currently NO workarounds for the current 3.3 situation either. Way, way harder. Here's a video that describes this properly. https://youtu.be/6_hOV5aLoX8

Jeremy commented

2022-10-06 20:10:23 +02:00

Added subscriber: @Jeremy-J

Jeremy commented

2022-10-06 20:10:23 +02:00

I noticed some additional strange behavior with the way booleans are transferring materials in exact and fast modes. It is possible to create a situation where the boolean material overrides the entire material section of the target geometry.

How to replicate:

Create a cube and assign it a blue material
Create a sphere and assign it an orange material
add a difference modifier to the cube cutting it with the sphere
In exact mode you should now have a blue cube with an orange cutout
add a second material slot to the cube also set to the blue material
move that second material slot up in the stack to the first slot

the cube should now be entirely orange. despite only having 2 blue materials in its materials section

switching back and forth between fast/exact will change the color of the entire object
https://www.youtube.com/watch?v=CQw3NOiPh88

I think this is a bug, but I could also just be completely misunderstanding how materials slots work. Regardless, if it is intended behavior it's really counterintuitive.

I noticed some additional strange behavior with the way booleans are transferring materials in exact and fast modes. It is possible to create a situation where the boolean material overrides the entire material section of the target geometry. How to replicate: - Create a cube and assign it a blue material - Create a sphere and assign it an orange material - add a difference modifier to the cube cutting it with the sphere - In exact mode you should now have a blue cube with an orange cutout - add a second material slot to the cube also set to the blue material - move that second material slot up in the stack to the first slot # the cube should now be entirely orange. despite only having 2 blue materials in its materials section switching back and forth between fast/exact will change the color of the entire object https://www.youtube.com/watch?v=CQw3NOiPh88 I think this is a bug, but I could also just be completely misunderstanding how materials slots work. Regardless, if it is intended behavior it's really counterintuitive.

Jan-Erik commented

2022-10-07 00:21:50 +02:00

how is this more intuitive? faster? more efficient? less "cumbersome" ?

when you create new objects and edit them to use them as Booleans, by default these objects do not have a material and therefore do not transfer it. So the behavior should not usually bother you. But if you want to transfer a material, the new behavior is faster.

Often you want to use the same "cutters" (bool diffs) to create two different objects, each with different materials.

idk what often is, but yeah I agree, this case is a problem and should be considered

> how is this more intuitive? faster? more efficient? less "cumbersome" ? when you create new objects and edit them to use them as Booleans, by default these objects do not have a material and therefore do not transfer it. So the behavior should not usually bother you. But if you want to transfer a material, the new behavior is faster. > Often you want to use the same "cutters" (bool diffs) to create two different objects, each with different materials. idk what often is, but yeah I agree, this case is a problem and should be considered ```

Hans Goudey commented

2022-10-07 22:51:27 +02:00

Hi. I finally got some time to work on this. I'd like to start by addressing the issue with empty material slots or no materials on the target object.
In that case it seems very clear that transferring the materials is never desired. People don't choose the default material, it just means there's no material set.
D16187: Fix #99592: Boolean: Avoid transferring empty materials, add index-based option should handle that case. I made a build that should be downloadable soon from here: https://builder.blender.org/download/patch/D16187/

After that, let's come back to the other issue. I think that will make it much clearer whether more options are required and what they should be.

Hi. I finally got some time to work on this. I'd like to start by addressing the issue with empty material slots or no materials on the target object. In that case it seems very clear that transferring the materials is never desired. People don't choose the default material, it just means there's no material set. [D16187: Fix #99592: Boolean: Avoid transferring empty materials, add index-based option](https://archive.blender.org/developer/D16187) should handle that case. I made a build that should be downloadable soon from here: https://builder.blender.org/download/patch/D16187/ After that, let's come back to the other issue. I think that will make it much clearer whether more options are required and what they should be.

Chipp Walters commented

2022-10-13 22:41:33 +02:00

Added subscriber: @Hans-6

Chipp Walters commented

2022-10-13 22:41:33 +02:00

@HooglyBoogly, I tested your solution. Still not perfect, (for instance multiple slots in the cutter make for a tiresome workflow if you want to keep only a couple of materials). IOW, I can't just add a single material slot from the cutter to the target (say an emissive material showing led lights) without having to add ALL the slots.

Not to mention, in the legacy behavior, you only need add a single material slot to the target object and ALL the associated cutter objects which have the same material slot are automatically added. Very simple workflow-- and probably the reason it was designed this way in the first place.

Not sure why you insist on changing this behavior, which has been a staple of Blender for multiple years. I guess that is a nice benefit of being a Blender developer.

@HooglyBoogly, I tested your solution. Still not perfect, (for instance multiple slots in the cutter make for a tiresome workflow if you want to keep only a couple of materials). IOW, I can't just *add* a single material slot from the cutter to the target (say an emissive material showing led lights) without having to add ALL the slots. Not to mention, in the legacy behavior, you only need add a single material slot to the target object and ALL the associated cutter objects which have the same material slot are automatically added. Very simple workflow-- and probably the reason it was designed this way in the first place. Not sure why you insist on changing this behavior, which has been a staple of Blender for multiple years. I guess that is a nice benefit of being a Blender developer.

Hans Goudey commented

2022-10-14 23:25:13 +02:00

Removed subscriber: @Hans-6

Thomas commented

2022-10-15 12:33:59 +02:00

Added subscriber: @Thomas2

Hans Goudey commented

2022-10-19 00:01:53 +02:00

Not sure why you insist on changing this behavior, which has been a staple of Blender for multiple years. I guess that is a nice benefit of being a Blender developer.

Unfortunately the behavior already changed. I want to restore it, but the change also made it seem like there are a couple use cases where different options are helpful.
Relying on material slot placement is problematic in geometry nodes and I felt there was an opportunity for more predictable default behavior that can be shared between the modifier and the node.
Making the current logic at least work as expected would be a good way to make the next part more obvious, that's why I worked on this patch first. I hope all that sounds reasonable, I think it does.

IOW, I can't just add a single material slot from the cutter to the target (say an emissive material showing led lights) without having to add ALL the slots.

Good point. Maybe this is the deal-breaker. I had hoped that some case like below, where all faces except for one have an empty material would be able to reuse the material from the base mesh's faces.
That worked by chance in most of my tests, but thinking about it more, I don't think boolean has the information about which base mesh face was removed for every result face.
In that case, the whole "Only transfer non-empty slots" idea isn't as nice as I thought.

{F13708485 size=full}

>Not sure why you insist on changing this behavior, which has been a staple of Blender for multiple years. I guess that is a nice benefit of being a Blender developer. Unfortunately the behavior already changed. I want to restore it, but the change also made it seem like there are a couple use cases where different options are helpful. Relying on material slot placement is problematic in geometry nodes and I felt there was an opportunity for more predictable default behavior that can be shared between the modifier and the node. Making the current logic at least work as expected would be a good way to make the next part more obvious, that's why I worked on this patch first. I hope all that sounds reasonable, I think it does. >IOW, I can't just *add* a single material slot from the cutter to the target (say an emissive material showing led lights) without having to add ALL the slots. Good point. Maybe this is the deal-breaker. I had hoped that some case like below, where all faces except for one have an empty material would be able to reuse the material from the base mesh's faces. That worked by chance in most of my tests, but thinking about it more, I don't think boolean has the information about which base mesh face was removed for every result face. In that case, the whole "Only transfer non-empty slots" idea isn't as nice as I thought. {[F13708485](https://archive.blender.org/developer/F13708485/image.png) size=full}

Hans Goudey commented

2022-11-22 01:46:45 +01:00

I updated D16187 with the option I discussed here. I'll hope to get that into 3.4. @chippwalters (or anyone else), would you be able to test that to make sure it does what you expect? Thanks.

I updated [D16187](https://archive.blender.org/developer/D16187) with the option I discussed here. I'll hope to get that into 3.4. @chippwalters (or anyone else), would you be able to test that to make sure it does what you expect? Thanks.

blender-admin commented

2022-11-28 19:42:08 +01:00

This issue was referenced by 7540842ca7

This issue was referenced by 7540842ca7632dad4c2806989027a3a6b2a15668

blender-admin commented

2022-11-28 19:42:08 +01:00

This issue was referenced by bbb389589a

This issue was referenced by bbb389589a0555af9c516a2aacd96dc70bf2d522

Hans Goudey commented

2022-11-28 19:46:47 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Hans Goudey closed this issue

2022-11-28 19:46:47 +01:00

Vanessa Dannenberg commented

2022-12-11 16:21:48 +01:00

Added subscriber: @VanessaE

Vanessa Dannenberg commented

2022-12-11 16:21:48 +01:00

Just wanted to drop a note to say THANK YOU for fixing this annoying behavior. 🙂 I use a lot of booleans in my models, and they always have a material assigned which reminds me of their function - opaque red and green for difference and union, and translucent yellow for intersections.

I've been moving more and more toward non-destructive modeling, so having bits of a target object turn red because I had to use exact mode in one of its difference modifiers was incredibly irritating.

Just wanted to drop a note to say THANK YOU for fixing this annoying behavior. 🙂 I use a lot of booleans in my models, and they always have a material assigned which reminds me of their function - opaque red and green for difference and union, and translucent yellow for intersections. I've been moving more and more toward non-destructive modeling, so having bits of a target object turn red because I had to use exact mode in one of its difference modifiers was incredibly irritating.

EP commented

2023-01-05 10:50:09 +01:00

Added subscriber: @impacman

EP commented

2023-01-05 10:50:09 +01:00

What i really don't understand in reporting this as a bug is a thing:

If you booleans on pre production step (like using kitops) its mean you already have assigned materials to your objects used as booleans - different materials, emissivs. Why all these should be destroyed and reassigned manually?
If no, and you using booleans on modeling step with simple shapes, why do your booleans need and have own materials? I also remeber reading some topics people asked how to preserve materials after performing booleans (like modo and 3ds max do).
So i think it's a feature, not a bug.

What i really don't understand in reporting this as a bug is a thing: 1. If you booleans on pre production step (like using kitops) its mean you already have assigned materials to your objects used as booleans - different materials, emissivs. Why all these should be destroyed and reassigned manually? 2. If no, and you using booleans on modeling step with simple shapes, why do your booleans need and have own materials? I also remeber reading some topics people asked how to preserve materials after performing booleans (like modo and 3ds max do). So i think it's a feature, not a bug.

Christoph Lendenfeld referenced this issue

2023-02-10 11:56:21 +01:00

Blender LTS: Maintenance Task 3.3 #100749

Sign in to join this conversation.