Page MenuHome

Bevel modifier UV problem with corners
Open, Confirmed, MediumPublic

Description

Blender Version
Broken: 2.79. 2.8*

Description
Importantly for games with Weighted Normals and Bevels workflow it would be very desirable for Corners of UV to scale and connect correctly so there are minimal distortions and UV disconnections.

This is how it opens in max post export:

Please also note that in 2.8 Bevel modifier completely distorts UVs in "Vertex average"(and possibly other) Normal Modes. Works as in 2.79 without any normal mode.

Prepared debug scene (as requested by Howard):



Also available here: http://cgstrive.com/blend/debug_bevel_uv.blend

Thank you!

Details

Type
Bug

Event Timeline

Brecht Van Lommel (brecht) triaged this task as Confirmed, Medium priority.

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).

Juri Unt (juri3d) added a comment.EditedSep 7 2018, 6:34 PM

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!

Juri Unt (juri3d) added a comment.EditedSep 13 2018, 4:01 PM

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:


As a result of this inconsistency, it's required to collapse the stack and manually, very time-consumingly correct every bevel. It is a a big building, a lot of work. For correct Bevel+WN workflow utilizing the new modifier this should work implicitly (regardless which material is used, as long as consistent).

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?