UV-space triangulation wrong #102683
Labels
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#102683
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Arch Linux
Graphics card: NVidia 1080 Ti
Blender Version
Broken: 3.3.1
Worked: none?
Short description of error
Triangulation of (concave) N-gons is wrong in UV-space.
Exact steps for others to reproduce the error
Just check the UV-space of Suzanne: on the right side of the main island, where the hole of the ear is, see the screenshots.
Added subscriber: @neXyon
Added subscriber: @OmarEmaraDev
Changed status from 'Needs Triage' to: 'Needs Developer To Reproduce'
UV unwrapping seems to work correctly. It is just that the default UV map is not great for that particular face. Not sure if this is hard-coded or is generated on demand somehow. Tagging developers for more information.
Added subscriber: @deadpin
I think the essence of the report is about concave n-gon drawing. Not all concave n-gons exhibit the problem but many do including that area above for Suzanne:
The drawing sometimes creates virtual edges that are not really there:
It's not only the drawing. The UVs are also exported with this triangulation when you export to obj for example.
Hmm, that may be unavoidable. At least on the model above, that Edge is a legitimate edge after triangulation (I'm assuming you're exporting to OBJ with the triangulate option):
Changed status from 'Needs Developer To Reproduce' to: 'Needs User Info'
I am not sure I understand the issue. Triangulation happens in 3D space and is reflected in the UV space, so why would we expect them to be different?
You're both right, they shouldn't be different. However, it would be nice if the triangulation considers the UV coordinates. Of course it is possible to construct a case (like @deadpin's) where no matter what, one of the triangulations (either in 3D or UV space) would be wrong and in that case I'd give the preference to 3D space, but if it's possible it would be nice to consider that during triangulation.
@Chris_Blackbourn : opinions?
I saw Suzanne's patch/pr fix uv but can't find/
Yeah, I've been avoiding this one for a little while now.
Story time!
The central problem here is that the triangulation isn't well defined (for reasons mentioned above).
To summarize, every non-overlapping 2D polygon does indeed admit a non-overlapping triangulation [0].
However, for the case of UV-mapped polygons, the triangulation chosen comes from the 3D geometry, not the 2D geometry.
So for example, a 3D polygon converted into triangles can be non-overlapping, but those same triangles in UV space can be overlapping.
It gets worse, for overlapping polygons, a triangulation is not possible.
That is, if the boundary of the polygon in UV space is self-intersecting, then every [1] triangulation will be overlapping, and potentially outside of the boundary in UV space.
Indeed, the "correct" result may actually have a curved boundary like the gray representation here:
The code to actually compute these sorts of things is also a bit messy in the general case.
Which is a long-winded way of saying there's no perfect solution and also no "easy" solution.
=> So whatever happens, we'll be forced to use a Heuristic instead.
I think a better way to interpret the issue is that the Heuristic has room for improvement, and it should at least be investigated.
More concretely, these UVs really do represent something to the artist using the package, they're not just abstract polygons in the 2D plane that requires a formal standards proof-of-correctness.
(Perhaps we should replace the word "wrong" in the description with a phrase like "could be improved" or "is confusing" to make the description less formal and proof-based.)
TL;DR: We should try harder to find a better heuristic which provides the most value to the User, even though an exact solution can't exist.
[0] https://en.wikipedia.org/wiki/Polygon_triangulation
[1] Obviously I'm simplifying here. The formal statement of this result includes such language as "except for a set of measure zero". Feel free to hit me up separately if you want the formal version.
Just a quick note for any coders who want to take this on: As this is a render issue in the UV Editor, the heuristic can add new vertices and/or work in screen space if that makes things easier.
This is not just a render issue! It is also an issue when exporting e.g. an obj and triangulating the mesh there.
Also, I would say that there are two cases: polygons where the triangulation can be made correct and polygons where it is impossible. I agree that this is not trivial to determine, but I think there is a way to find a correct triangulation where possibile and be sure of it, not just using some heuristics. For the cases where it is impossible, a heuristic can be used, sure.
.OBJ files support n-gons. If the user enables the "triangulate" option, the .OBJ export uses the 3D geometry to determine triangulation, and that triangulation in 3D induces the same triangulation in UV co-ordinates.
I'm not seeing how the problem described here applies to the .OBJ exporter?
Yeah, it's the triangulation that is the issue. Basically it should make sure that the triangulation is correct at concave vertices in both 3D and UV space.
For example:
Left is 3D space, right is UV space. The first row shows a quad where a correct triangulation is possible in both spaces. Both triangulations work in 3D and only the blue one works in UV space. In the second row, neither triangulation works. The red one is wrong in 3D space and the blue is wrong in UV space.
Apologies for the spam, still trying to figure out what all these gitea buttons!
NexYon writes:
It can see the usefulness, but it feels a little out-of-scope for this particular issue.
It this is required, perhaps creating a design task to add an option to the "Triangulate Faces" operator. It currently has Quad/N-gon methods for Beauty, Fixed, Longest edge etc. It seems reasonable to add options for "Prevent UV overlaps" and specify the source UV map.
But again, that feels out-of-scope for #102683, as a feature request there wouldn't fix the rendering issue here.
Ok, I've created a design task (#105710). This specific issue here can however be solved in the same way, i.e., by having a correct triangulation in UV space. Not in every case as we have discussed, but for suzanne it would work.