There is no difference between "keep corners" and "all" under "UV Smooth" #83470

Closed
opened 2020-12-06 16:20:12 +01:00 by Chaowei Ding · 26 comments

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38

Blender Version
Broken: version: 2.92.0 Alpha, branch: master, commit date: 2020-12-05 13:56, hash: 52a6c4f34d
Worked: (newest version of Blender that worked as expected)

Short description of error
There is no difference between "keep corners" and "all" under "UV Smooth", the corners are supposed to be linked to the texture, but here the corners are not linked to the texture."All" should be unlinked from the textures. This will cause problems with the corner mappings, see attachment.

This model I imported into c4d and maya, also using "keep corners" under "UV Smooth" , they don't have this problem after subdividing, which leads to a problem that my models from other software need to be adjusted again in the position of the edges of the uv or mapping to handle correctly, which is very cumbersome.

Exact steps for others to reproduce the error
1.Select Model
2.Adding a subdivision surface modifier
3.subdivision surface modifier > advanced > uv smooth > keep corners
uv.blend

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1660 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.38 **Blender Version** Broken: version: 2.92.0 Alpha, branch: master, commit date: 2020-12-05 13:56, hash: `52a6c4f34d` Worked: (newest version of Blender that worked as expected) **Short description of error** There is no difference between "keep corners" and "all" under "UV Smooth", the corners are supposed to be linked to the texture, but here the corners are not linked to the texture."All" should be unlinked from the textures. This will cause problems with the corner mappings, see attachment. This model I imported into c4d and maya, also using "keep corners" under "UV Smooth" , they don't have this problem after subdividing, which leads to a problem that my models from other software need to be adjusted again in the position of the edges of the uv or mapping to handle correctly, which is very cumbersome. **Exact steps for others to reproduce the error** 1.Select Model 2.Adding a subdivision surface modifier 3.subdivision surface modifier > advanced > uv smooth > keep corners [uv.blend](https://archive.blender.org/developer/F9480712/uv.blend)
Author

Added subscriber: @Dayar

Added subscriber: @Dayar

Added subscriber: @APEC

Added subscriber: @APEC

Can you provide screens how it should be?

Can you provide screens how it should be?
Author

20201206233656.png
This is what it looks like in c4d.

![20201206233656.png](https://archive.blender.org/developer/F9480741/20201206233656.png) This is what it looks like in c4d.

This comment was removed by @APEC

*This comment was removed by @APEC*

Yes, it seems do some unwanted stretches here
bl.png
It better to go here for further discussion
https://devtalk.blender.org/t/subdivision-surface-in-blender-2-8-behave-different-compared-to-maya-and-zbrush/12248/29

Yes, it seems do some unwanted stretches here ![bl.png](https://archive.blender.org/developer/F9480771/bl.png) It better to go here for further discussion https://devtalk.blender.org/t/subdivision-surface-in-blender-2-8-behave-different-compared-to-maya-and-zbrush/12248/29
Author

UV is the same, the subdivision is also Catmull Clark
The result is the same, with distortion at the top and sides.

20201207002321.png

20201207002509.png

20201207002537.png

20201207002615.png

UV is the same, the subdivision is also Catmull Clark The result is the same, with distortion at the top and sides. ![20201207002321.png](https://archive.blender.org/developer/F9480796/20201207002321.png) ![20201207002509.png](https://archive.blender.org/developer/F9480795/20201207002509.png) ![20201207002537.png](https://archive.blender.org/developer/F9480794/20201207002537.png) ![20201207002615.png](https://archive.blender.org/developer/F9480793/20201207002615.png)

Yes, I got it, already made a message on the devtalk forum. Nice catch by the way!

Yes, I got it, already made a message on the devtalk forum. Nice catch by the way!
Author

Thank you.
(Forgive me for my poor English.)
I have one more question, when I tested some more features recently, I found that blender's 'Bevel Modifier' offered an 'Arc' in the 'Miter Outer' option, which I found to be very useful.
20201207010825.png
When working with such models, c4d users usually use the first method, while blender users can use the second method to make the process easier.
20201207005259.png
But it still requires an additional step, if there are too many in the model, which would require many cuts with the knife tool.
It may be a bit greedy to say this, but I'd like to make a suggestion, and that is, coud you please help us connect this line after you 'Arc' it, or provide an additional option under 'Arc' to connect or not, so that we quad modelers can save some more modeling time.

The model file is as follows :
Sharp vs Arc.blend

Thank you. (Forgive me for my poor English.) I have one more question, when I tested some more features recently, I found that blender's 'Bevel Modifier' offered an 'Arc' in the 'Miter Outer' option, which I found to be very useful. ![20201207010825.png](https://archive.blender.org/developer/F9480829/20201207010825.png) When working with such models, c4d users usually use the first method, while blender users can use the second method to make the process easier. ![20201207005259.png](https://archive.blender.org/developer/F9480827/20201207005259.png) But it still requires an additional step, if there are too many in the model, which would require many cuts with the knife tool. It may be a bit greedy to say this, but I'd like to make a suggestion, and that is, coud you please help us connect this line after you 'Arc' it, or provide an additional option under 'Arc' to connect or not, so that we quad modelers can save some more modeling time. The model file is as follows : [Sharp vs Arc.blend](https://archive.blender.org/developer/F9480833/Sharp_vs_Arc.blend)

I'm just a simple user as you.
Last request it's not for bug reporting thread. Moderators relocate you to such kind of resources like
https://blender.community/c/rightclickselect/
https://devtalk.blender.org/c/other-topics/usability/16
My suggestion is delete request message and duplicate it on resources above to keep this bug report clear as possible.

I'm just a simple user as you. Last request it's not for bug reporting thread. Moderators relocate you to such kind of resources like https://blender.community/c/rightclickselect/ https://devtalk.blender.org/c/other-topics/usability/16 My suggestion is delete request message and duplicate it on resources above to keep this bug report clear as possible.
Author

Haha, I see. I don't know much about it. Thank you.

Haha, I see. I don't know much about it. Thank you.

Added subscriber: @ostry

Added subscriber: @ostry

Opensubdiv does not know topology of uv map, only mesh. So corners created by placing seams on continous mesh are not seen as corners by opensubdiv.

Opensubdiv does not know topology of uv map, only mesh. So corners created by placing seams on continous mesh are not seen as corners by opensubdiv.

Added subscribers: @Sergey, @mano-wii

Added subscribers: @Sergey, @mano-wii

I can confirm that only the vertex uvs that are connected to only 1 face are kept in place.
Perhaps this option should affect all boundary vertices?

This does appear to be a bug, but this same behavior was seen in the old toggle "subdivide UVs".

This feature has been improved in 517f58be, it may need developer evaluation.

I can confirm that only the vertex uvs that are connected to only 1 face are kept in place. Perhaps this option should affect all boundary vertices? This does appear to be a bug, but this same behavior was seen in the old toggle `"subdivide UVs"`. This feature has been improved in 517f58be, it may need developer evaluation.

I also think it's not SDS patch's fault cos it exist in older blender versions (2.83).
As I mentioned on devtalk thread
"if mesh “closed” then unwrapped UV corners would be sharp, if mesh “opened” and some UV vertices have more then 2 edges, then this corners would be smooth, if UV vertex have only 2 edges then this corner would be sharp." - it's a correct behavior in my opinion.

I also think it's not SDS patch's fault cos it exist in older blender versions (2.83). As I mentioned on devtalk thread "if mesh “closed” then unwrapped UV corners would be sharp, if mesh “opened” and some UV vertices have more then 2 edges, then this corners would be smooth, if UV vertex have only 2 edges then this corner would be sharp." - it's a correct behavior in my opinion.

Do we need to create new task not related to Sub-D Patch?
Because this issue will be a huge loss for users who use paint on SDS in Blender and then use other soft for SDS.
Just look at this (its 2.90 without SDS patch)
UV_SDS_Issue.png

UV_SDS_Issue2.png
It seems that UV use it's own SDS modifier and do not respect geometry in 3D.
I can assure you that this does not happen in the other two major programs that I use with the OpenSubDiv (Catmull-Clark Sub-D).

Do we need to create new task not related to Sub-D Patch? Because this issue will be a huge loss for users who use paint on SDS in Blender and then use other soft for SDS. Just look at this (its 2.90 without SDS patch) ![UV_SDS_Issue.png](https://archive.blender.org/developer/F9531795/UV_SDS_Issue.png) ![UV_SDS_Issue2.png](https://archive.blender.org/developer/F9531799/UV_SDS_Issue2.png) It seems that UV use it's own SDS modifier and do not respect geometry in 3D. I can assure you that this does not happen in the other two major programs that I use with the OpenSubDiv (Catmull-Clark Sub-D).

OpenSubdiv is used for UVs interpolation. The behavior is explained in https://graphics.pixar.com/opensubdiv/docs/subdivision_surfaces.html#face-varying-data-and-topology (see the Face-varying Interpolation Rules section).

If the behavior in Blender is different from what is described then it is a bug, otherwise is more of a possible improvement.

OpenSubdiv is used for UVs interpolation. The behavior is explained in https://graphics.pixar.com/opensubdiv/docs/subdivision_surfaces.html#face-varying-data-and-topology (see the `Face-varying Interpolation Rules` section). If the behavior in Blender is different from what is described then it is a bug, otherwise is more of a possible improvement.

It behave different, so it's a bug since 2.8, I have no 2.79 can't test it.
I can provide UVs after sds applied from other 3d apps I used
https://devtalk.blender.org/t/subdivision-surface-in-blender-2-8-behave-different-compared-to-maya-and-zbrush/12248/45?u=apec

It behave different, so it's a bug since 2.8, I have no 2.79 can't test it. I can provide UVs after sds applied from other 3d apps I used https://devtalk.blender.org/t/subdivision-surface-in-blender-2-8-behave-different-compared-to-maya-and-zbrush/12248/45?u=apec

Added subscriber: @brecht

Added subscriber: @brecht

2.8 definitely behaves different from 2.79, as there is no UV smoothing strategy in OpenSubdiv which matches 2.79 exactly.

The current "Keep Corners" actually means "UVs are smoothed, corners on discontinuous boundary are kept sharp".

Not sure what default strategy in other software, but you need something like "Smooth, keep corners+junctions+concave" or "UVs are smoothed, boundaries are kept sharp". We would need expose those settings though.

@brecht, I remember we've been looking into non-confusing set of options to be exposed. Think it's time to re-evaluate the decision. Anything against P1883 ?
Also seems that boundary smoothing options might need more clarification (we can do it separately).

2.8 definitely behaves different from 2.79, as there is no UV smoothing strategy in OpenSubdiv which matches 2.79 exactly. The current "Keep Corners" actually means "UVs are smoothed, corners on discontinuous boundary are kept sharp". Not sure what default strategy in other software, but you need something like "Smooth, keep corners+junctions+concave" or "UVs are smoothed, boundaries are kept sharp". We would need expose those settings though. @brecht, I remember we've been looking into non-confusing set of options to be exposed. Think it's time to re-evaluate the decision. Anything against [P1883](https://archive.blender.org/developer/P1883.txt) ? Also seems that boundary smoothing options might need more clarification (we can do it separately).

Here is comparison Blender (blue) and other (red).
UV Smooth - Keep Corners
Suz_Comparison.png
Original other app pixar sds (for some other comparison cases).
Suz_Other_sep.png
Options for selecting UV behavior only mislead users, if its Pixar SDS, there is only one UV behavior, and only one Mesh behavior in 3d View.

Here is comparison Blender (blue) and other (red). UV Smooth - Keep Corners ![Suz_Comparison.png](https://archive.blender.org/developer/F9560942/Suz_Comparison.png) Original other app pixar sds (for some other comparison cases). ![Suz_Other_sep.png](https://archive.blender.org/developer/F9560954/Suz_Other_sep.png) Options for selecting UV behavior only mislead users, if its Pixar SDS, there is only one UV behavior, and only one Mesh behavior in 3d View.

@Sergey, rather than exposing all these options, maybe we should just make "Keep Corners" behave like SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_AND_JUNCTIONS or SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_JUNCTIONS_AND_CONCAVE?

I find all these options quite confusing, to me it seems like there is a correct solution that gives minimal distortion, and all these different options probably exist for legacy reasons.

@Sergey, rather than exposing all these options, maybe we should just make "Keep Corners" behave like `SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_AND_JUNCTIONS` or `SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_JUNCTIONS_AND_CONCAVE`? I find all these options quite confusing, to me it seems like there is a correct solution that gives minimal distortion, and all these different options probably exist for legacy reasons.

@brecht , To me it seems that both FVAR_LINEAR_CORNERS_PLUS1 and FVAR_LINEAR_CORNERS_PLUS2 (which is what we call SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_AND_JUNCTIONS and SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_JUNCTIONS_AND_CONCAVE, because it's way more interesting to inverse meaning of variables to keep brain sharp when reading specs ;) are there for legacy of software.

In theory it sounds good and such to have a single option, but then I'm not sure how to quantify which of the suggested ones is the way to go.

Another thing which I'm not sure how big of a deal here yet, is that it seems like some of the confusion is coming here from other software using some weird default in settings. Or, maybe, users are picking weird setting and then expect Blender to behave the same when importing models. So from fully supported interoperability it makes sense to support all interpolation rules (maybe hide obscure ones unless "advanced" options are shown).

@brecht , To me it seems that both `FVAR_LINEAR_CORNERS_PLUS1` and `FVAR_LINEAR_CORNERS_PLUS2` (which is what we call `SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_AND_JUNCTIONS` and `SUBSURF_UV_SMOOTH_PRESERVE_CORNERS_JUNCTIONS_AND_CONCAVE`, because it's way more interesting to inverse meaning of variables to keep brain sharp when reading specs ;) are there for legacy of software. In theory it sounds good and such to have a single option, but then I'm not sure how to quantify which of the suggested ones is the way to go. Another thing which I'm not sure how big of a deal here yet, is that it seems like some of the confusion is coming here from other software using some weird default in settings. Or, maybe, users are picking weird setting and then expect Blender to behave the same when importing models. So from fully supported interoperability it makes sense to support all interpolation rules (maybe hide obscure ones unless "advanced" options are shown).

Sorry for disturbing but where I can test this D10111 patch?

Sorry for disturbing but where I can test this [D10111](https://archive.blender.org/developer/D10111) patch?

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

Changed status from 'Needs Triage' to: 'Resolved'
Germano Cavalcante self-assigned this 2021-01-26 18:50:59 +01:00
Germano Cavalcante removed their assignment 2021-01-26 19:07:07 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#83470
No description provided.