Bevel improvements for "Correct Face Attributes" #78695

New Issue

Daniel Bystedt · 2020-07-07T10:19:16+02:00

Daniel Bystedt commented

2020-07-07 10:19:16 +02:00

@mano-wii recently made a new commit {4387aff99e01} for adjusting uv's during mesh transformation. After discussing with him and @ideasman42 I was asked to add a new task with suggestion for improvement to the bevel operator so that it works well with correct face attributes like mesh transform does.

Relevant links

#78671 (Improvements to "Correct Face Attributes")

Settings for correct face attributes can be found in the top right corner of the 3d viewport.

Bevel - bevel edge(s) currently does not work with Correct face attributes

bevel does not correct uv.mp4

Suggested behavior for bevel
Step 1 - selection

Step 2 - bevel
Created face inherits uv coordinate from one face and then uv coordinates are corrected. UV overlap are expected in a lot of cases.

@mano-wii recently made a new commit {4387aff99e01} for adjusting uv's during mesh transformation. After discussing with him and @ideasman42 I was asked to add a new task with suggestion for improvement to the bevel operator so that it works well with **correct face attributes** like mesh transform does. --- **Relevant links** #78671 (Improvements to "Correct Face Attributes") --- Settings for **correct face attributes** can be found in the top right corner of the 3d viewport. ![image.png](https://archive.blender.org/developer/F8674957/image.png) **Bevel - bevel edge(s) currently does not work with **Correct face attributes**** [bevel does not correct uv.mp4](https://archive.blender.org/developer/F8670121/bevel_does_not_correct_uv.mp4) **Suggested behavior for bevel** Step 1 - selection ![image](https://archive.blender.org/developer/F8670122/image.png) Step 2 - bevel Created face inherits uv coordinate from one face and then uv coordinates are corrected. UV overlap are expected in a lot of cases. ![image](https://archive.blender.org/developer/F8670124/image.png)

Howard Trickey was assigned by Daniel Bystedt

2020-07-07 10:19:16 +02:00

Daniel Bystedt commented

2020-07-07 10:19:16 +02:00

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

Daniel Bystedt commented

2020-07-07 10:19:16 +02:00

Added subscribers: @mano-wii, @ideasman42, @DanielBystedt, @howardt

Howard Trickey commented

2020-07-07 12:24:16 +02:00

This task is a lot harder than it looks. I have spent literally months getting UVs to do reasonable things on bevel, and it does attempt to do reasonable things. Among the considerations:

If there is no UV seam between the beveled eddges, you don't want to take all the UVs from one of the faces but rather want to just interpolate in UV space of the existing faces
You really want to stay within the UV space occupied by the union of all the existing UV islands, because the user may have only mapped images into those places Your diagram above for "suggested behavior" violates that, and would probably require the user to rework their images to use the new UV map.
If there are choices as to which UV island you interpolate the new bevel edges in, you want to make those choices :consistently" -- that is, in a way that looks visually good and not like a random choice of one adjacent face vs the other in which to interpolate. This was the cause of many bug reports, which I recently closed by making a fix in this area.

That said, the example you give is something that I agree would be a bug, and if you could fix it, that would be great. But please don't do what you did in your example - expanding the UV space into territory that the user wasn't using before - unless you get consensus from users and developers that that is the desired behavior.

I can share my "to me" notes on bevel, where I have about 20 pages of notes discussing the UV problem.

This task is a lot harder than it looks. I have spent literally months getting UVs to do reasonable things on bevel, and it does attempt to do reasonable things. Among the considerations: 1) If there is no UV seam between the beveled eddges, you don't want to take all the UVs from one of the faces but rather want to just interpolate in UV space of the existing faces 2) You really want to stay within the UV space occupied by the union of all the existing UV islands, because the user may have only mapped images into those places Your diagram above for "suggested behavior" violates that, and would probably require the user to rework their images to use the new UV map. 3) If there are choices as to which UV island you interpolate the new bevel edges in, you want to make those choices :consistently" -- that is, in a way that looks visually good and not like a random choice of one adjacent face vs the other in which to interpolate. This was the cause of many bug reports, which I recently closed by making a fix in this area. That said, the example you give is something that I agree would be a bug, and if you could fix it, that would be great. But please don't do what you did in your example - expanding the UV space into territory that the user wasn't using before - unless you get consensus from users and developers that that is the desired behavior. I can share my "to me" notes on bevel, where I have about 20 pages of notes discussing the UV problem.

Howard Trickey commented

2020-07-07 14:02:12 +02:00

Ha, I misunderstood and didn't notice that the task was assigned to me. I regard this as a bug, and will fix it (eventually).

Howard Trickey commented

2020-07-07 14:31:58 +02:00

And a side conversation with Daniel revealed that my assumptions about requirements 2 and 3 are deeply seated in an assumption that the user of UV maps is mapping images with distinguishable features in them, whereas in game development, one often (usually?) has tiled textures so that the rules I gave are unnecessary.

It seems like there are two very different use cases: (1) the underlying texture is a continuous "background" kind of texture that is either tiled or procedurally generated; (2) the underlying texture is an image that has different distinguishable things in different parts. For (1), it is more important to just keep the new faces match the scale of the old ones, and overlap and "going outside the lines" doesn't matter. For (2), overlap and "going outside the lines" is very important. I had only every been thinking about case (2). I may need to have an option to choose between the two kinds of interpolation.

And a side conversation with Daniel revealed that my assumptions about requirements 2 and 3 are deeply seated in an assumption that the user of UV maps is mapping images with distinguishable features in them, whereas in game development, one often (usually?) has tiled textures so that the rules I gave are unnecessary. It seems like there are two very different use cases: (1) the underlying texture is a continuous "background" kind of texture that is either tiled or procedurally generated; (2) the underlying texture is an image that has different distinguishable things in different parts. For (1), it is more important to just keep the new faces match the scale of the old ones, and overlap and "going outside the lines" doesn't matter. For (2), overlap and "going outside the lines" is very important. I had only every been thinking about case (2). I may need to have an option to choose between the two kinds of interpolation.

Daniel Bystedt commented

2020-07-08 12:21:00 +02:00

Here are some example images, Howard. Sorry for the long post. Perhaps I should break off each part in separate task?

BUGS
Yes, the video in the top of this page seems to show a bug.
Bugs reported here
#78733 (Bevel edge with segment = 1 produces undesired UV result on UV boundry edge)

UV warping with current bevel
NOTE: Let me know if I should move this to a separate task

I realized that there seem to be some warping of the uv when using multiple segments when one uv vertex has a "uv corner connection"
|
Starting point|
Current behavior|

Desired behavior

|
Starting point|

Current behavior. There are some minor stretching on the new faces. New faces does not have equal width in uv space compared to 3d space This is a very minor issue. Perhaps it's better to leave it alone in order to spend time coding other things|

Desired behavior. I detached the uv vertices marked with a blue circle and then equalized the width of the spans, but kept the uv boundry coordinates.

Bevel of edge with one uv vertex at UV boundary produces strange triangle UV mapping
NOTE: Let me know if I should move this to a separate task

Starting point	Strange UV result after bevel marked RED

Bevel with correct face attributes

Current bevel behaviour for uv's (what I would call "locked uv boundry")
I think this type of uv behaviour is really good as standard. It could be improved by correcting the bugs in the text above. It suits well when placing uv's on an image with predefined texture elements where the user wants to keep the current uv boundry (case 2 in your text as far as I understand). I think the way bevel works is very solid if the bug mentioned above is fixed. You mentioned something about

New behavior for bevel (i.e correct face attributes)
As you suggested, Howard, this should be an option in the bevel operator. Some notes on the behaviour:

Overlapping of uv faces as a result of bevel with correct face attributes is completely ok
UV boundry coordinates does not need to be kept
UV of new face created by bevel can be separated from existing UV if it is needed (see Example 1 & 2, image 3 bevel with correct face attributes)

Example 1
|starting point| current bevel behavior (notice a slight texture squash/stretch on the texture) |

bevel with `correct face attributes` }

Example 2
|
starting point|

current bevel behavior|

bevel with `correct face attributes`

Example 3
|
starting point|

current bevel behavior|

bevel with `correct face attributes`

Here are some example images, Howard. Sorry for the long post. Perhaps I should break off each part in separate task? **BUGS** Yes, the video in the top of this page seems to show a bug. Bugs reported here #78733 (Bevel edge with segment = 1 produces undesired UV result on UV boundry edge) **UV warping with current bevel** NOTE: Let me know if I should move this to a separate task I realized that there seem to be some warping of the uv when using multiple `segments` when one uv vertex has a "uv corner connection" |![image](https://archive.blender.org/developer/F8677792/image.png) **Starting point**| ![image](https://archive.blender.org/developer/F8677795/image.png) **Current behavior**| ![image](https://archive.blender.org/developer/F8677805/image.png) **Desired behavior**| | -- | -- | -- | |![image](https://archive.blender.org/developer/F8677845/image.png) **Starting point**| ![image](https://archive.blender.org/developer/F8677848/image.png) **Current behavior**. There are some minor stretching on the new faces. New faces does not have equal width in uv space compared to 3d space **This is a very minor issue. Perhaps it's better to leave it alone in order to spend time coding other things**| ![image](https://archive.blender.org/developer/F8677877/image.png) **Desired behavior**. I detached the uv vertices marked with a blue circle and then equalized the width of the spans, but kept the uv boundry coordinates. | -- | -- | -- | --- **Bevel of edge with one uv vertex at UV boundary produces strange triangle UV mapping** NOTE: Let me know if I should move this to a separate task | ![image](https://archive.blender.org/developer/F8677968/image.png)Starting point | ![image](https://archive.blender.org/developer/F8677975/image.png) Strange UV result after bevel marked RED | | -- | -- | --- **Bevel with correct face attributes** **Current bevel behaviour for uv's (what I would call "locked uv boundry")** I think this type of uv behaviour is really good as standard. It could be improved by correcting the bugs in the text above. It suits well when placing uv's on an image with predefined texture elements where the user wants to keep the current uv boundry (**case 2** in your text as far as I understand). I think the way bevel works is very solid if the bug mentioned above is fixed. You mentioned something about **New behavior for bevel (i.e `correct face attributes`)** As you suggested, Howard, this should be an option in the bevel operator. Some notes on the behaviour: - Overlapping of uv faces as a result of bevel with `correct face attributes` is completely ok - UV boundry coordinates does not need to be kept - UV of new face created by bevel can be separated from existing UV if it is needed (see Example 1 & 2, image 3 bevel with `correct face attributes`) **Example 1** |![image](https://archive.blender.org/developer/F8677679/image.png)starting point| ![image](https://archive.blender.org/developer/F8677682/image.png) current bevel behavior (notice a slight texture squash/stretch on the texture) | ![image](https://archive.blender.org/developer/F8677769/image.png) bevel with `correct face attributes` } | -- | -- | -- | **Example 2** |![image](https://archive.blender.org/developer/F8677690/image.png) starting point| ![image](https://archive.blender.org/developer/F8677692/image.png) current bevel behavior| ![image](https://archive.blender.org/developer/F8677707/image.png) bevel with `correct face attributes` | | -- | -- | -- | **Example 3** |![image](https://archive.blender.org/developer/F8677775/image.png) starting point| ![image](https://archive.blender.org/developer/F8677777/image.png) current bevel behavior| ![image](https://archive.blender.org/developer/F8677783/image.png) bevel with `correct face attributes`| | -- | -- | -- |

Howard Trickey commented

2020-07-08 12:47:09 +02:00

Thanks for the examples and analysis. I like your naming of what I am trying to do in the current bevel uv behavior as the "locked uv boundary" case.

I don't particularly like the name "Correct Face Attributes" for the suggested new mode, since the user's idea of what "correct" means could be either what I am calling case 1 or what you have now named the "locked uv boundary" case. I would like to think that bevel will always produced "correct face attributes" -- it's just a matter of the user telling us which meaning of "correct" to use in a particular bevel operation. So I'd like to have an option called something like "UV interpolation" or "UV Boundary" , which choices "Locked UV Boundary" and "Free UV Boundary", where the first would be the default and give the current behavior (with bug fixes as you have reported), and the second would give the behavior you call "New behavior" above. What do you think of those names? If you don't like them, do you have suggestions for something you like better?

Thanks for the examples and analysis. I like your naming of what I am trying to do in the current bevel uv behavior as the "locked uv boundary" case. I don't particularly like the name "Correct Face Attributes" for the suggested new mode, since the user's idea of what "correct" means could be either what I am calling case 1 or what you have now named the "locked uv boundary" case. I would like to think that bevel will always produced "correct face attributes" -- it's just a matter of the user telling us which meaning of "correct" to use in a particular bevel operation. So I'd like to have an option called something like "UV interpolation" or "UV Boundary" , which choices "Locked UV Boundary" and "Free UV Boundary", where the first would be the default and give the current behavior (with bug fixes as you have reported), and the second would give the behavior you call "New behavior" above. What do you think of those names? If you don't like them, do you have suggestions for something you like better?

Daniel Bystedt commented

2020-07-08 14:18:16 +02:00

I think "Free UV Boundary" sounds like a great name! Let's go with that

Daniel Calderón commented

2020-07-10 18:26:18 +02:00

Added subscriber: @xdanic

Daniel Calderón commented

2020-07-10 18:26:18 +02:00

Could we consider an option for manually deciding where new faces go to one face or another? We could have a toggle like the insert edge ring and edge slide for modeling where pressing F flips the new edge to have the same edge siluete as one of the sides.

Daniel Bystedt added this to the Modeling project 2023-03-14 08:48:58 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bevel improvements for "Correct Face Attributes" #78695