Ply Exporter broken with use_uv=True if uv non-unique #99249
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
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-addons#99249
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
Description of problem:
Exporting a bmesh with the ply plugin while setting
use_uv=True
can produce broken meshes if the vertices of a face share the same loop and the sameuv
. The vertices are flagged as "non-unique" as theuv
attribute match, but position and other attributes are completely ignored. See94bd481980
(especially around line 105 inio_mesh_ply/export_ply.py
)On my humble opinion this should not be the intended behavior as the
uv
attribute can be whatever the user wants it to be. I would rather recommend to base the "uniqueness" of a vertex on all exported attributes.Steps to reproduce
A simple reproduction of the problem is to select all the
uv
s of the default cube, scale it with 0 and export it via ply. The resulting ply file will be like this:Possible solution:
This should be easy to fix. Just integrate all exported attributes into the
ply_vert_map
key.Attached data:
See attached blend file for the actual scene:
PlyExportError.blend
The resulting ply file. It is in ASCII format for readability:
PlyExportError.ply
Operating system and hardware information do not matter here, but for completeness:
System Information
Operating system: Ubuntu 22.04, Windows 11
Graphics card:
Nvidia RTX 3080
,Nvidia RTX 2080 Super
andNvidia Quadro blender/blender#2000
Blender Version
Broken: 3.2.0 stable and Blender 3.1.x stable
Added subscriber: @PearCoding
Added subscriber: @PratikPB2123
Changed status from 'Needs Triage' to: 'Confirmed'
As I need a workaround for the problem asap, I fixed the bug myself.
Here I share my solution with the following patch: fix-t99249.patch
It might be a good starting point. It fixes the issue above and is - on my understanding - a complete solution.
To support non-smooth faces - which the above patch does not - it would make sense to change the lines:
to something similar like this:
Added subscribers: @MikhailRachinskiy, @Chris_Blackbourn
Hi @MikhailRachinskiy , Any thoughts on this one? Looks like two potential fixes, one for UVs and a seperate fix for smoothing?
Basing uniqueness of a vertex on corner data basically means splitting edges and duplicating geometry. Which in my opinion is an awful way to export mesh.
I plan to rewrite PLY exporter and importer #103230, so it would use face corner domain to store UVs.
Vertex color data will be taken from vertex domain instead of corner domain.
And after that I will investigate better ways of exporting normals.
This wouldn't work without splitting edges:
normal = v.normal if f.smooth else f.normal
Hey @MikhailRachinskiy, Just trying to understand this one a little more.
Is the situation with UVs and the situation with normals different or the same? (i.e. will the same fix / rewrite work for both, or are there unique issues that are different between UVs and normals?)
Can you expand on this one a little more? I understand that creating additional duplicate geometry is "bad", but at the same time, being unable to export UVs makes the PLY exporter unusable for certain workflows.
How would you feel about having an exporter option where the user can choose to duplicate geometry to support splitting UVs and normals? (I'd be happy to make the change...)
It seems to me that could add that relatively easily in the interim before the rewrite (to use the face corner domain) comes online.
Sorry for the confusion here, I know very little about the PLY exporter and have ended up here coming in a bit sideways.
The difference between UVs and normals, is that UVs can be stored in corner domain, for normals I don't know yet. If there is no such possibility, then they only way of exporting corner normals is splitting edges.
There is no issue with exporting UVs at the moment. The author of this task experiences problems with UVs because they use old Blender version without this fix
60299fcc23
It already works that way and always did, if user clicks export UVs option, then edges get split.
I've just checked the repro steps here in master in everything seems fine.
In that case, can we go ahead and mark #99249 as a duplicate of #103203 and close it as resolved?
(Or is there more here still to do?)
This issue can be closed as resolved.
If anyone has additional input, they could provide it in #103230
Changed status from 'Confirmed' to: 'Resolved'
Closed as duplicate of #103203,
60299fcc23
See also #103230
Closed as duplicate of #103203