Maniphest T60302

bevel modifier material problem
Closed, Archived

Assigned To
Howard Trickey (howardt)
Authored By
Massimiliano Puliero (mmaaxx)
Jan 8 2019, 4:24 AM
Tags
  • BF Blender
Subscribers
Howard Trickey (howardt)
Jacques Lucke (JacquesLucke)
Massimiliano Puliero (mmaaxx)

Description

System Information
Operating system: win 10
Graphics card: gtx 1070

Blender Version
Broken: blender-2.80.0-git.91a155833e59-windows64

Short description of error
Bevel modifier gives unpredictable results when -segment- value is an odd number.

Exact steps for others to reproduce the error
open the attached file.
thanks

Related Objects

Mentioned In
T76199: Bevel modifier and materials "bleed" over faces
Mentioned Here
rBe3a420c4773a: Fix T76199 Bevel materials "bleed" over faces.
rB91a155833e59: Cleanup: comments causing bad clang-format output

Event Timeline

Massimiliano Puliero (mmaaxx) created this task.Jan 8 2019, 4:24 AM
Jacques Lucke (JacquesLucke) lowered the priority of this task from 90 to 30.Jan 8 2019, 11:30 AM
Jacques Lucke (JacquesLucke) added a subscriber: Jacques Lucke (JacquesLucke).

It seems to behave normally here.

Please provide more information about what behavior is unpredictable.
And provide a screenshot that shows what's wrong/what you would expect.

Massimiliano Puliero (mmaaxx) added a comment.Jan 8 2019, 1:28 PM

sorry, I wasn't clear.
Please take a look at the attached image, I hope this can help to understand what I mean.
Thanks.

Jacques Lucke (JacquesLucke) raised the priority of this task from 30 to 50.Jan 8 2019, 1:32 PM
Jacques Lucke (JacquesLucke) added a subscriber: Howard Trickey (howardt).

Ah now I see what you mean. Yes I can reproduce it.

Howard Trickey (howardt) changed the task status from Unknown Status to Archived.Jan 8 2019, 4:23 PM
Howard Trickey (howardt) claimed this task.

This is "working as intended" in that the code doesn't try to be consistent here, and this isn't a regression. It is more like a feature request to come up with a consistency rule.

I'm sorry, but I don't have any good idea on how to fix this.
When there are an odd number of segments, it has to pick the material from one side or the other and it is a bit of a coin flip which side to pick. The logic used currently just depends on which edge happened to be picked to begin the list of edges around a vertex. Maybe in particular cases like yours one could propose heuristics like "pick the side with the lowest average z-value for coords" that might put some kind of consistency on, but I have no idea how many such inconsistent cases would be fixed by a rule like that, and how many would need a different rule.

I am closing this for now, but keeping this in mind as a feature request. There's a similar one for consistency of UV splitting, and I may work on both together some time in the future.

Jacques Lucke (JacquesLucke) added a comment.Jan 8 2019, 4:29 PM

@Howard Trickey (howardt), would it be possible to just prioritize the materials based on the material slot index?

Howard Trickey (howardt) added a comment.Jan 8 2019, 9:45 PM

That's a nice idea, Jacques! I could easily implement that, and think I will. Thanks for the suggestion.

Howard Trickey (howardt) added a comment.Jun 26 2020, 1:07 PM

Just noting that commit rBe3a420c4773a fixed this case.