Bevel modifier UV problem with corners #56625

New Issue

Juri Unt · 2018-08-31T09:31:13+02:00

Juri Unt commented

2018-08-31 09:31:13 +02:00

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

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

Thank you!

**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. ![bevel_blender.png](https://archive.blender.org/developer/F4475661/bevel_blender.png) This is how it opens in max post export: ![bevel_max.png](https://archive.blender.org/developer/F4475899/bevel_max.png) 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. ![bevel_2_8_broken.png](https://archive.blender.org/developer/F4475852/bevel_2_8_broken.png) Prepared debug scene (as requested by Howard): ![bevel_test_scene.png](https://archive.blender.org/developer/F4475830/bevel_test_scene.png) [debug_bevel_uv.blend](https://archive.blender.org/developer/F4475906/debug_bevel_uv.blend) Also available here: http://cgstrive.com/blend/debug_bevel_uv.blend Thank you!

Juri Unt commented

2018-08-31 09:31:13 +02:00

Added subscriber: @JuriUnt

blender-admin commented

2018-08-31 09:31:13 +02:00

#101322 was marked as duplicate of this issue

blender-admin commented

2018-08-31 09:31:13 +02:00

#97170 was marked as duplicate of this issue

blender-admin commented

2018-08-31 09:31:13 +02:00

#66067 was marked as duplicate of this issue

blender-admin commented

2018-08-31 09:31:13 +02:00

#61709 was marked as duplicate of this issue

Howard Trickey was assigned by Brecht Van Lommel

2018-08-31 12:05:25 +02:00

Howard Trickey commented

2018-08-31 12:10:00 +02:00

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

Howard Trickey commented

2018-09-07 13:58:28 +02:00

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.

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.

Juri Unt commented

2018-09-07 15:27:43 +02:00

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

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 ![uvcorners.gif](https://archive.blender.org/developer/F4614418/uvcorners.gif) Thank you

Howard Trickey commented

2018-09-07 16:10:52 +02:00

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

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 commented

2018-09-07 18:34:00 +02:00

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.gifI 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!

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: ![bevel_uv_246.jpg](https://archive.blender.org/developer/F4616617/bevel_uv_246.jpg) 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 commented

2018-09-13 16:01:56 +02:00

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!

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: ![2_9132018_de74.png](https://archive.blender.org/developer/F4687446/2_9132018_de74.png) 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!

Howard Trickey commented

2018-09-13 18:50:05 +02:00

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.

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.

Brecht Van Lommel commented

2019-02-20 14:00:38 +01:00

Added subscribers: @cyp-2, @howardt, @ZedDB

Howard Trickey commented

2019-02-20 15:33:04 +01:00

The merged-in #61709 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?

The merged-in #61709 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?

Brecht Van Lommel commented

2019-06-24 13:52:16 +02:00

Added subscriber: @RobinKarlsson

Floatharr commented

2019-11-09 17:37:45 +01:00

Added subscriber: @Floatharr

Floatharr commented

2019-11-09 17:51:27 +01:00

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.

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. ![blender_6Sm0r8Zx3M.png](https://archive.blender.org/developer/F8005025/blender_6Sm0r8Zx3M.png)

Frederico Martins commented

2019-11-29 16:17:22 +01:00

Added subscriber: @FredericoMartins

Frederico Martins commented

2019-11-29 16:17:22 +01:00

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.

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. ![Screenshot_1_uvs.jpg](https://archive.blender.org/developer/F8178465/Screenshot_1_uvs.jpg)

Howard Trickey was unassigned by Dalai Felinto

2019-12-23 16:36:00 +01:00

Germano Cavalcante commented

2020-02-11 13:28:13 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2020-02-11 13:28:13 +01:00

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

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

Howard Trickey commented

2020-06-26 12:56:40 +02:00

The commit e3a420c477 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.

The commit e3a420c477 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.

Robert Rioux commented

2021-04-13 04:24:20 +02:00

Added subscriber: @Funnybob

Robert Rioux commented

2021-04-13 04:24:20 +02:00

Hey guys. I had issues with internal corner losing their UVs as demonstrated here: https://youtu.be/VZub6OHlkHI?t=516

Dan McLaughlin commented

2021-08-02 15:59:00 +02:00

Added subscriber: @DrMc

Dan McLaughlin commented

2021-08-02 15:59:00 +02:00

My use case is exactly as described by OP. game assets with low/high poly workflow, 1 bevel/chamfer WN most common. For larger bevels I use three, which doesn't create too many edges to deal with and looks pleasing for the high poly wrapping. I'm on 2.93 and still seeing corner get squashed UV Faces with even number of bevels, e.g.

and

@howardt is this still fixed and in 2.93? Since we produce thousands of pieces, the one glitch in the process is having to destructively apply the low poly bevel and fix up the errors. A more pleasing shape is always welcome, but since the texels squash visually along bevels that's less of an issue then getting UV faces that are so distorted.

As a workaround, as OP noted even bevels do better, testing with four indeed while there is mild distortion it should be acceptable.

My use case is exactly as described by OP. game assets with low/high poly workflow, 1 bevel/chamfer WN most common. For larger bevels I use three, which doesn't create too many edges to deal with and looks pleasing for the high poly wrapping. I'm on 2.93 and still seeing corner get squashed UV Faces with even number of bevels, e.g. ![image.png](https://archive.blender.org/developer/F10259981/image.png) and ![image.png](https://archive.blender.org/developer/F10259985/image.png) @howardt is this still fixed and in 2.93? Since we produce thousands of pieces, the one glitch in the process is having to destructively apply the low poly bevel and fix up the errors. A more pleasing shape is always welcome, but since the texels squash visually along bevels that's less of an issue then getting UV faces that are so distorted. As a workaround, as OP noted even bevels do better, testing with four indeed while there is mild distortion it should be acceptable.

Reslav Hollos commented

2021-11-15 00:00:03 +01:00

Added subscriber: @Radivarig

Reslav Hollos commented

2021-11-15 00:00:03 +01:00

Here's another way to reproduce bevel modifier with 1 segment that causes UVs to form lines instead of triangles in Blender 2.93.5.
reproduced_bevel_1_segment_incorrect_uv_triangles.blend

create new project and select default cube
add the bevel modifier with 1 segment
select all faces, mark seams and unwrap
select pack all islands with 0.05 margin to move vertices inward from 0-1 space
enable UV Sync Selection to see beveled UVs in texture paint workspace without applying the modifier
in texture paint workspace add a base color texture and start painting on cube corners

While in texture paint workspace with UV editor opened you'll see that only 2 out of 8 corner triangles are correct, others form a line because 2 of their 3 vertices are on the same position.

You can now change bevel segment count to see how it unwraps directly while painting.

If you apply the bevel modifier and in UV editor select and move any of the corner line vertices you'll see that they are connected to the wrong adjacent vertex.

Here's another way to reproduce bevel modifier with 1 segment that causes UVs to form lines instead of triangles in Blender 2.93.5. [reproduced_bevel_1_segment_incorrect_uv_triangles.blend](https://archive.blender.org/developer/F11804516/reproduced_bevel_1_segment_incorrect_uv_triangles.blend) - create new project and select default cube - add the bevel modifier with 1 segment - select all faces, mark seams and unwrap - select pack all islands with 0.05 margin to move vertices inward from 0-1 space - enable UV Sync Selection to see beveled UVs in texture paint workspace without applying the modifier - in texture paint workspace add a base color texture and start painting on cube corners While in texture paint workspace with UV editor opened you'll see that only 2 out of 8 corner triangles are correct, others form a line because 2 of their 3 vertices are on the same position. ![bevel_segments_1_does_not_form_triangles.PNG](https://archive.blender.org/developer/F11804489/bevel_segments_1_does_not_form_triangles.PNG) ![all_corners_painted.PNG](https://archive.blender.org/developer/F11804497/all_corners_painted.PNG) You can now change bevel segment count to see how it unwraps directly while painting. If you apply the bevel modifier and in UV editor select and move any of the corner line vertices you'll see that they are connected to the wrong adjacent vertex. ![bevel_uv_triangle_not_correct.PNG](https://archive.blender.org/developer/F11804492/bevel_uv_triangle_not_correct.PNG) ![bevel_uv_triangle_not_correct_moved.PNG](https://archive.blender.org/developer/F11804494/bevel_uv_triangle_not_correct_moved.PNG)

Alexander boluzhenkov commented

2021-12-28 10:48:56 +01:00

Added subscriber: @polyguner

Alexander boluzhenkov commented

2021-12-28 10:48:56 +01:00

Please fix this, Bevel modifier is useless at current stage for real production

Alexander Fomichev commented

2021-12-28 12:32:23 +01:00

Added subscriber: @AlexanderFomyichev

Albert commented

2021-12-28 13:58:06 +01:00

Added subscriber: @r35tnx

Igor Dmytrenko commented

2021-12-28 14:41:36 +01:00

Added subscriber: @IgorDmytrenko

Igor Dmytrenko commented

2021-12-28 14:47:35 +01:00

In #56625#1279188, @polyguner wrote:
Please fix this, Bevel modifier is useless at current stage for real production

+1

> In #56625#1279188, @polyguner wrote: > Please fix this, Bevel modifier is useless at current stage for real production +1

Nadya Fomicheva commented

2021-12-28 14:48:07 +01:00

Added subscriber: @Nadya-3

Dmitry commented

2021-12-28 15:04:30 +01:00

Added subscriber: @trupikkkkk

Howard Trickey commented

2021-12-28 23:45:51 +01:00

I am working on the example given by Reslav Hollos a couple replies back.

Andrey Rusnak commented

2021-12-29 09:35:52 +01:00

Added subscriber: @AndreyRusnak

Aleksandr Ivanov commented

2021-12-29 11:52:10 +01:00

Added subscriber: @old702

Aleksandr Glukhachev commented

2021-12-29 14:08:22 +01:00

Added subscriber: @Alexandr

Pablo Caracena commented

2022-02-26 17:59:35 +01:00

Added subscriber: @Pablo_Caracena

Joel Azzopardi commented

2022-03-16 20:44:14 +01:00

Added subscriber: @insideitall

CybranM commented

2022-04-12 09:56:08 +02:00

Added subscriber: @IihT2cWA9xiP30BsYphz3EiEISNoScoe

hujin commented

2022-04-13 16:19:54 +02:00

Added subscriber: @2046411367

Pratik Borhade commented

2022-04-14 14:47:35 +02:00

Added subscriber: @PratikPB2123

blender-admin commented

2022-04-22 15:26:34 +02:00

This issue was referenced by 984cd552f0

This issue was referenced by 984cd552f0033c674b3cef6ec55d1facdcb81c2d

Howard Trickey commented

2022-04-22 17:35:22 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Howard Trickey closed this issue

2022-04-22 17:35:22 +02:00

Howard Trickey self-assigned this 2022-04-22 17:35:22 +02:00

CybranM commented

2022-04-22 18:01:13 +02:00

Do you think this will make it into Blender 3.2?

Howard Trickey commented

2022-04-22 18:17:47 +02:00

Yes, it is in master and thus will be in 3.2

CybranM commented

2022-04-22 18:22:33 +02:00

Awesome, I'm looking forward to it!

Aleksandr Ivanov commented

2022-04-22 22:17:02 +02:00

Cool!

Adam Janz commented

2022-05-18 22:01:18 +02:00

Added subscriber: @AdamJanz

Adam Janz commented

2022-05-18 23:59:34 +02:00

Thank you so much, @howardt for your work on this! I'm not sure if I've downloaded the correct beta build for 3.2, I have tried the latest 35e73aa347 but it seems the issue is persisting, except it manifests in a different way than in 3.1.0. Please see attached screenshots and test .blend file. When one applies the Bevel Modifier, different results manifest in 3.1 and 3.2, but neither seems to be correct. I don't believe the bevel modifier should be splitting ANY UVs based on an algorithm, but rather keeping any new generated vertices joined and scaled out evenly from where they originated. It seems the algorithm in 3.2 is currently putting the inner vertex at the center rather than merging it with the one below it, and is separating the outer two vertices rather than merging them at the center. Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges. I have noted in the final screenshot what should be happening to the vertices. If your fix has already corrected this and it has simply not been applied to the latest 3.2 beta build then I truly apologize!

Mesh before Bevel:

Mesh after Bevel (3.1.0):

Mesh After Bevel (3.2.0):

Desired Result:

Sample Blend file: Bevel-UV_Issue1.blend

Thank you so much, @howardt for your work on this! I'm not sure if I've downloaded the correct beta build for 3.2, I have tried the latest 35e73aa3472a but it seems the issue is persisting, except it manifests in a different way than in 3.1.0. Please see attached screenshots and test .blend file. When one applies the Bevel Modifier, different results manifest in 3.1 and 3.2, but neither seems to be correct. I don't believe the bevel modifier should be splitting **ANY** UVs based on an algorithm, but rather keeping any new generated vertices **joined** and **scaled out evenly** from where they originated. It seems the algorithm in 3.2 is currently putting the inner vertex at the center rather than merging it with the one below it, and is separating the outer two vertices rather than merging them at the center. Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges. I have noted in the final screenshot what should be happening to the vertices. If your fix has already corrected this and it has simply not been applied to the latest 3.2 beta build then I truly apologize! Mesh before Bevel: ![Mesh_before_Bevel.png](https://archive.blender.org/developer/F13087694/Mesh_before_Bevel.png) Mesh after Bevel (3.1.0): ![Mesh_after_Bevel (3.1).png](https://archive.blender.org/developer/F13087696/Mesh_after_Bevel__3.1_.png) Mesh After Bevel (3.2.0): ![Mesh_after_Bevel (3.2).png](https://archive.blender.org/developer/F13087698/Mesh_after_Bevel__3.2_.png) Desired Result: ![Mesh_Desired_Result.png](https://archive.blender.org/developer/F13087746/Mesh_Desired_Result.png) Sample Blend file: [Bevel-UV_Issue1.blend](https://archive.blender.org/developer/F13087729/Bevel-UV_Issue1.blend)

Adam Janz commented

2022-05-19 00:18:39 +02:00

EDIT: The following information was incorrect: "Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges". It appears (at least for my test .blend file) the new algorithm in 3.2 is just splitting the bevel operation between the straight and the angled UV islands, rather than keeping the bevel on the angled island (as in 3.1). The rest of the info shared still applies, however.

Thanks!

EDIT: The following information was incorrect: *"Additionally, some UV edges generated from applying the Bevel Modifier are left untouched completely and simply get stuffed under the original UV edges"*. It appears (at least for my test .blend file) the new algorithm in 3.2 is just splitting the bevel operation between the straight and the angled UV islands, rather than keeping the bevel on the angled island (as in 3.1). The rest of the info shared still applies, however. Thanks!

Adam Janz commented

2022-05-19 20:32:38 +02:00

In addition to potentially stretching textures in undesirable ways, one of the destructive side-effects of this bug is how texture bakes will get messed up because of the triangular holes ripped in the UVs. Stitching torn vertices in the UV editor is unfortunately not very straight forward, and becomes quite tedious for many hard-surface mesh parts. I confirmed the issue existed since at least 2.79b, so it is not a regression. Strangely, it seems increasing the Bevel Modifier's "segments" to an even number like 2 or 4 prevents the issue of split UVs on the angled pieces in my test file, but then the straight pieces still get split UVs, and of course, UV seams are not preserved either (they also get split apart). Having unnecessary UV seams is not ideal for game assets, as the extra seams will increase the vertex cost, and having unnecessary geometry (from extra bevel segments) will also negatively impact performance. It appears the only way to currently mitigate these issues is to set all seams and perform all UV unwraps AFTER the modifiers have been applied. This is a destructive workflow and can also mean an enormous amount of re-unwrapping for detailed hard-surface models that have already been unwrapped.

In addition to potentially stretching textures in undesirable ways, one of the destructive side-effects of this bug is how texture bakes will get messed up because of the triangular holes ripped in the UVs. Stitching torn vertices in the UV editor is unfortunately not very straight forward, and becomes quite tedious for many hard-surface mesh parts. I confirmed the issue existed since at least 2.79b, so it is not a regression. Strangely, it seems increasing the Bevel Modifier's "segments" to an even number like 2 or 4 prevents the issue of split UVs on the angled pieces in my test file, but then the straight pieces still get split UVs, and of course, UV seams are not preserved either (they also get split apart). Having unnecessary UV seams is not ideal for game assets, as the extra seams will increase the vertex cost, and having unnecessary geometry (from extra bevel segments) will also negatively impact performance. It appears the only way to currently mitigate these issues is to **set all seams and perform all UV unwraps AFTER the modifiers have been applied.** This is a destructive workflow and can also mean an enormous amount of re-unwrapping for detailed hard-surface models that have already been unwrapped.

Adam Janz commented

2022-05-19 23:18:21 +02:00

In case it may be helpful to someone else, you may want to bake your textures from duplicated objects that have the bevel modifiers removed. This way you can bake without gaps or other potential errors. Then on your original object, apply your bevel and other modifiers and assign the new textures you baked. If the extra generated UV seams fall along sharp edges (they most likely do), then there shouldn't be any additional vertex cost in a game engine, otherwise you can optionally clear those new seams. Depending on the required precision of your diffuse / roughness / normal maps, etc, you may be able to completely get away without having to stitch any of the torn UVs back together, but your mileage may vary. :-) However, if there is noticeable stretching or other artifacts in the material you will have to either stitch the UVs or re-unwrap after the Bevel Modifier has been applied and bake to this new UV map.

In case it may be helpful to someone else, you may want to bake your textures from duplicated objects that have the bevel modifiers removed. This way you can bake without gaps or other potential errors. Then on your original object, apply your bevel and other modifiers and assign the new textures you baked. If the extra generated UV seams fall along sharp edges (they most likely do), then there shouldn't be any additional vertex cost in a game engine, otherwise you can optionally clear those new seams. Depending on the required precision of your diffuse / roughness / normal maps, etc, you may be able to completely get away without having to stitch **any** of the torn UVs back together, but your mileage may vary. :-) However, if there is noticeable stretching or other artifacts in the material you will have to either stitch the UVs or re-unwrap after the Bevel Modifier has been applied and bake to this new UV map.

Howard Trickey commented

2022-05-20 16:50:55 +02:00

Changed status from 'Resolved' to: 'Confirmed'

Howard Trickey reopened this issue

2022-05-20 16:50:55 +02:00

Howard Trickey commented

2022-05-20 16:50:55 +02:00

Adam:

When I claimed that this bug was fixed, I was referring to the problems of making zero-area polygons in UV space. I knew there were remaining cases where the UV layout, if done by hand, could be better, but also that Blender's bevel has never so far been able to do that well, so it wasn't exactly a bug or a regression.

When you say " I don't believe the bevel modifier should be splitting ANY UVs based on an algorithm, but rather keeping any new generated vertices joined and scaled out evenly from where they originated." What I think you are saying is that: where UV vertices on the same island come from the same model vertex, they should stay joined in UV space (of course, there are cases where some UV vertices coming from the same model vertex are in different islands, and those have to be split). I agree with what you say, but I don't know how to make this happen at the moment.

It may need a completely different approach to how I manage the UVs after bevel. Right now, the algorithm looks at each quad and center polygon that make up the "vertex mesh", and for each vertex in those, tries to figure out which face of the original model to drop that vertex to, and then use that drop point to interpolate UVs (that is, looking at how that original polygon is laid out in UV space, where in UV space does that dropped vertex fall?). Sometimes it works better to snap the dropped point to the nearest edge of that original polygon before interpolating, so the code tries to figure out for each vertex int he corner mesh: which edge do I snap to (if any) and then which face do I interpolate UVs in. This sometimes results in a vertex not being in what looks like the middle of a UV edge instead of attached to another one. I try to make consistent choices for vertices that are the same but in different faces of the corner mesh, but don't always succeed. Things are especially difficult (because more cases come into play) for the center polygon of the vertex mesh. And that appears to be where your complaints are for the current test file and algorithm. I will re-open this bug to see if there are tweaks to what I am doing that can make it better for your case here.

Another approach that would be radically different would be to just try to do everything in UV space itself rather than doing all of this face interpolation. This would require probably a few months of work to get right. I worry that there might be all sorts of strange topology/layout in UV space that my new algorithm might not be anticipating. But it would allow me to do a better job of minimizing distortion in UV space. For instance, now if there are 3 segments along a UV seam, the split side that gets one segment will have a thicker segment that the two on the two-side.

As an extra piece of information: another thing I did in this latest change was to try to do a better job at deciding which island to put the center segment and center polygon of an odd-segment bevel in. I used better tie-breaking rules. I think I achieved this goal, but there will always be cases where one would, manually, desire a different assignment of which island the center segments should go on.

Adam: When I claimed that this bug was fixed, I was referring to the problems of making zero-area polygons in UV space. I knew there were remaining cases where the UV layout, if done by hand, could be better, but also that Blender's bevel has never so far been able to do that well, so it wasn't exactly a bug or a regression. When you say " I don't believe the bevel modifier should be splitting ANY UVs based on an algorithm, but rather keeping any new generated vertices joined and scaled out evenly from where they originated." What I think you are saying is that: where UV vertices on the same island come from the same model vertex, they should stay joined in UV space (of course, there are cases where some UV vertices coming from the same model vertex are in different islands, and those have to be split). I agree with what you say, but I don't know how to make this happen at the moment. It may need a completely different approach to how I manage the UVs after bevel. Right now, the algorithm looks at each quad and center polygon that make up the "vertex mesh", and for each vertex in those, tries to figure out which face of the original model to drop that vertex to, and then use that drop point to interpolate UVs (that is, looking at how that original polygon is laid out in UV space, where in UV space does that dropped vertex fall?). Sometimes it works better to snap the dropped point to the nearest edge of that original polygon before interpolating, so the code tries to figure out for each vertex int he corner mesh: which edge do I snap to (if any) and then which face do I interpolate UVs in. This sometimes results in a vertex not being in what looks like the middle of a UV edge instead of attached to another one. I try to make consistent choices for vertices that are the same but in different faces of the corner mesh, but don't always succeed. Things are especially difficult (because more cases come into play) for the center polygon of the vertex mesh. And that appears to be where your complaints are for the current test file and algorithm. I will re-open this bug to see if there are tweaks to what I am doing that can make it better for your case here. Another approach that would be radically different would be to just try to do everything in UV space itself rather than doing all of this face interpolation. This would require probably a few months of work to get right. I worry that there might be all sorts of strange topology/layout in UV space that my new algorithm might not be anticipating. But it would allow me to do a better job of minimizing distortion in UV space. For instance, now if there are 3 segments along a UV seam, the split side that gets one segment will have a thicker segment that the two on the two-side. As an extra piece of information: another thing I did in this latest change was to try to do a better job at deciding which island to put the center segment and center polygon of an odd-segment bevel in. I used better tie-breaking rules. I think I achieved this goal, but there will always be cases where one would, manually, desire a different assignment of which island the center segments should go on.

Adam Janz commented

2022-05-20 17:31:21 +02:00

Thank you so much @howardt for that very detailed reply. I can see this issue is a lot more complicated than I had assumed, and I'm glad you were able to fix the zero-area polygons issue.

Re: my comment; yes, where UV vertices on the same island are generated from the same source vertex, they should stay joined in UV space and be scaled out evenly away from that source vertex (similar to how the Solidify modifier scales generated geometry evenly outwards when "Offset" is at 1 and "Even Thickness" is checked -- see this sample VIDEO for an example. Not sure if it's possible to take that principle / algorithm and apply it to the UVs on vertices generated from the Bevel Modifier). Of course in reality, programming such a thing is probably much different than my artist brain would envision it... but I'm sure you will eventually find a phenomenal solution! :-)

Thank you so much @howardt for that very detailed reply. I can see this issue is a lot more complicated than I had assumed, and I'm glad you were able to fix the zero-area polygons issue. Re: my comment; yes, where UV vertices on the same island are generated from the same source vertex, they should stay joined in UV space and be scaled out evenly away from that source vertex (similar to how the Solidify modifier scales generated geometry evenly outwards when "Offset" is at 1 and "Even Thickness" is checked -- see this sample [**VIDEO** ](https://youtu.be/g0j4fKONB6o) for an example. Not sure if it's possible to take that principle / algorithm and apply it to the UVs on vertices generated from the Bevel Modifier). Of course in reality, programming such a thing is probably much different than my artist brain would envision it... but I'm sure you will eventually find a phenomenal solution! :-)

CybranM commented

2022-06-10 16:32:21 +02:00

After downloading 3.2 and trying it out I still occasionally run into zero area faces:
It seems to be caused by having multiple UV channels, if I remove UVMap.001 -> UVMap.005 it works as expected. Problem is for our workflow I need those extra channels so removing them is unfortunately not an option.
I've attached the .blend file so you can test it out for yourself
3-2 zero area face.blend

Thanks for all the work youve already put in @howardt, I'm hoping theres still a chance this last small issue will be solved 😃

After downloading 3.2 and trying it out I still occasionally run into zero area faces: ![2022-06-10_16-24-40_blender.png](https://archive.blender.org/developer/F13143455/2022-06-10_16-24-40_blender.png) It seems to be caused by having multiple UV channels, if I remove UVMap.001 -> UVMap.005 it works as expected. Problem is for our workflow I need those extra channels so removing them is unfortunately not an option. I've attached the .blend file so you can test it out for yourself [3-2 zero area face.blend](https://archive.blender.org/developer/F13143458/3-2_zero_area_face.blend) Thanks for all the work youve already put in @howardt, I'm hoping theres still a chance this last small issue will be solved 😃

Omar Emara commented

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

Added subscriber: @Jonathan-27

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bevel modifier UV problem with corners #56625