Thanks for the report. Will look at fixing this problem soon,

I've looked at this some now.
There is no quick, easy fix. So this will take some thinking.
The problem is that we have to decide which side of a seam to put the bevel parts on. In the provided example, the side has been chosen consistently so that there is pleasing overall symmetry. I need to see if I can think of an algorithm that has that effect.
In addition, there are the triangular corners that now get mapped to go only halfway across their adjacent edges. I'm not sure why that is. Needs more debugging. Bug also not clear if just having them extend all the way across the adjacent edge would satisfy the bug reporter.

Thank You for looking into it.

I can understand why this task is more difficult than appears. Symmetry/consistency is desirable, however not critical as this does not cause texturing artefacts (as long as everything is connected). On the other hand UV corners with disconnections and a different in scale does cause artefacts. Such asset will be rejected in professional pipeline. This contradicts the goal of Bevel+WN workflow as modifiers must be collapsed, asset UV manually corrected. If just the corners could be fixed, would be a big deal. It's probably not something urgent (as boxes are fast to UV), but in general for valid Bevel+WN workflow, this should be addressed.

Issue/Fix way i understand it: http://cgstrive.com/blend/uvcorners.gif

Thank you

Thanks for the gif. It helps confirm that I understood what was bothering you, and what would make you happy (or, happier). And it should be easier to fix that than to produce exactly your ideal results.

I am also curious about what you think should happen for bevels with multiple segments. For instance, I think I was trying to have cases where there are an even number of bevel segments split the uv map along the center. Not sure if that is necessary or desired, but seemed to make sense to me (so, for instance, if two adjacent faces were different colors, then after beveling the parts that were perceptually part of the original faces would still have those colors).

These are great questions.

The UV looks really good with even numbers, just corners should to be stitched. With uneven numbers there's something interesting going on:
http://cgstrive.com/blend/bevel_uv_uneven.gif

Image showing UVs:

Predictably we can see the same problem with Material on a high res model. In current case it fails with 1,3,5 etc:
http://cgstrive.com/blend/bevel_material_prob.gif
I tested after recording the gif that it works perfectly with even numbers.

To recap:

• Uneven numbers is the problem. Should be continuous. If this is hard to fix, can be overlooked.
• For even numbers, it looks really nice, just corners need to be fused as demonstrated in prior post.

PS. Not sure how helpful this is, but from point of view of gamedev workflow that utilizes Bevel+WN, rarely more than a few segments are used (90% of time just 1 as it's enough for WN. 2,3 for bigger assets). Having UV consistency between 1-3 segments will cover nearly all cases I can subjectively envision. Rounder objects would have UV done differently. For non-game assets, the higher the segment count, the less this is a problem (such as with material gif). 1-3 = most important.

Edit: Directly answering the question - splitting UV/mat from center is ideal behavior for many segments, just unreliable with higher segs. For 1 segment if it's easier to make exception, it would already resolve most issues.

Thank you once again!

I apologize for being such a nuisance, but thought I'd show another case study of material splitting inconsistency when working with buildings for games. Due to scale of buildings different materials are assigned to different areas and maps are titled in game engine. Here you can see the inconsistent material splitting as a result of Bevel modifier with uneven number (1 seg) that is needed for WN:

Thank you!

You are not being a nuisance. I appreciate hearing about the real-world problems people have. This is unfortunately another example of the harder part of your original report -- getting a more global consistency. I have a vague idea of some rules that might help, but have to think through some more.

I did make some progress on debugging the easier part of your report, this morning. But progress is slow because my day job is very busy right now.

The merged-in T61709 is a somewhat different problem, but I'll address it as part of this task. In that task, it is just doing an outright wrong UV assignment in the supplied example.

As to the original problem of this task, Jaques Lucke had a nice suggestion on another thread: use the material slot index as a tie-breaker when there are an odd number of segments -- that is, if the bevel is adjacent to two faces and they have different materials, use the material with the lower (say) slot index as the one to use in the center odd segment. Juri, would that solve the problem in a satisfactory way, do you think?

I think my issue is related to this. I've been getting these zero area faces stitched to the wrong side of the bevel in my UVs after applying a bevel modifier, so far the only way to fix it is to apply bevels before UVing or stitch all the faces manually which takes time. It would be amazing to see some progress on this. This bug is making it difficult to work with nondestructive bevels in game assets.

All I did to replicate this was inset and extrude a face on the default cube, add a bevel modifier, cube project UVs, average UV scale, pack UV, and apply bevel modifier.

Hi Guys, I have a similar issue, hope it is ok to post here.

Here is what Im doing:
All the objects have same object data (as the one on the left without modifiers).

• One on the middle has a bevel with a 6 Segments set,
• The one on the right has 3 bevel modifiers with increasingly halved Width values but just one Segment each.

the one on the right gives me very continous UVs, and the one on the middle just looks broken on the curve :(

On the bottom are the uv results of them with the modifiers applied.

I think this is a limitation that would be nice if it were described in the manual:
https://docs.blender.org/manual/en/dev/modeling/modifiers/generate/bevel.html

The commit rBe3a420c4773a I just made improves the situation here: now a more consistent choice is made as to which UV island gets the extra geometry needed after a bevel. But the original bug report also wants a better shape in the resulting UV map for the interpolated faces. That is harder to fix, and so it remains a Known Issue that the UV map will not be exactly as the original reporter would like.