Page MenuHome

Bevel improvements for "Correct Face Attributes"
Confirmed, NormalPublicDESIGN


@Germano Cavalcante (mano-wii) recently made a new commit {4387aff99e01} for adjusting uv's during mesh transformation. After discussing with him and @Campbell Barton (campbellbarton) 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

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

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.

Event Timeline

Daniel Bystedt (dbystedt) changed the task status from Needs Triage to Confirmed.Jul 7 2020, 10:19 AM
Daniel Bystedt (dbystedt) created this task.
Daniel Bystedt (dbystedt) moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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.

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

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.

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


Yes, the video in the top of this page seems to show a bug.
Bugs reported here
T78733: 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

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?

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

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.