Lightmap unwrap improvements - performance improvement #113720

Closed
Sebastian Witt wants to merge 2 commits from SebastianWitt/blender:Lightmap_performance into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

This is the second part of two improvements i want to propose to the lightmap unwrap functionality.
The first part can be found here: #113716

In this i tried to improve the performance of triangle unwrapping. On meshes with high triangle counts this was very slow since the original algorithm iterates over all triangles and then calculates the edge length distance to each other triangle in every iteration resulting in ~n^2 complexity.

The proposed solution replaces this search by representing the 3 edge lengths of each triangle as 3d points and searching with a kd-tree.

On a mesh with ~20k Tris the old method runs in 40s while the new method takes 0.23s with a difference of <0.001%.

Testing:
To test the functionality it is not enough to compare the exact result of the old method with the new method since equal triangles might get mapped differently since the kd-tree doesn't reproduce the same order as with the iterative method.

The measures i took is the area of the resulting uvmap should be close to the original method and should only contain overlapping elements if the original method also produces an overlapping result. (There might be another bug related to tris)

My testing script is attached. It loads the original "uvcalc_lightmap.py" and a new "uvcalc_lightmap_kd.py" and runs the unwrap function on the currently selected object.

Sidenote:
To put the importance of this into perspective, the resulting lightmaps of high triangle count meshes is rarely usable since each tri is uvmapped as an island thus takes away a lot of space with added margins.
Regardless of that i think blender shouldn't freeze for ages if i unwrap such a mesh without thinking whether it will be useful.

Any feedback, tips, general thoughts or possible improvements to style etc. is very welcome!

This is the second part of two improvements i want to propose to the lightmap unwrap functionality. The first part can be found here: #113716 In this i tried to improve the performance of triangle unwrapping. On meshes with high triangle counts this was very slow since the original algorithm iterates over all triangles and then calculates the edge length distance to each other triangle in every iteration resulting in ~n^2 complexity. The proposed solution replaces this search by representing the 3 edge lengths of each triangle as 3d points and searching with a kd-tree. On a mesh with ~20k Tris the old method runs in 40s while the new method takes 0.23s with a difference of <0.001%. Testing: To test the functionality it is not enough to compare the exact result of the old method with the new method since equal triangles might get mapped differently since the kd-tree doesn't reproduce the same order as with the iterative method. The measures i took is the area of the resulting uvmap should be close to the original method and should only contain overlapping elements if the original method also produces an overlapping result. (There might be another bug related to tris) My testing script is attached. It loads the original "uvcalc_lightmap.py" and a new "uvcalc_lightmap_kd.py" and runs the unwrap function on the currently selected object. Sidenote: To put the importance of this into perspective, the resulting lightmaps of high triangle count meshes is rarely usable since each tri is uvmapped as an island thus takes away a lot of space with added margins. Regardless of that i think blender shouldn't freeze for ages if i unwrap such a mesh without thinking whether it will be useful. _Any feedback, tips, general thoughts or possible improvements to style etc. is very welcome!_
Sebastian Witt added 1 commit 2023-10-14 14:47:41 +02:00
Sebastian Witt requested review from Campbell Barton 2023-10-17 16:50:41 +02:00
Iliya Katushenock added this to the Modeling project 2023-11-30 17:01:32 +01:00
Iliya Katushenock added the
Interest
UV Editing
label 2023-11-30 17:01:44 +01:00
Sebastian Witt reviewed 2023-11-30 17:16:25 +01:00
@ -320,1 +345,3 @@
pretty_faces.append(prettyface((tri1, tri_lengths.pop(best_tri_index))))
if i % 100 == 0:
wm.progress_update(i)
print(f"Unwrap progress {int((100 * pairs_added / num_tri_pairs))}%")
Author
Member

I added some progress tracking. I am not too sure if this is desirable. It could be done without any wm.progress, with progress but no prints or with both.

I added some progress tracking. I am not too sure if this is desirable. It could be done without any wm.progress, with progress but no prints or with both.
Sebastian Witt changed title from WIP: Lightmap unwrap improvements - performance improvement to Lightmap unwrap improvements - performance improvement 2023-11-30 17:16:55 +01:00
Sebastian Witt changed title from Lightmap unwrap improvements - performance improvement to WIP: Lightmap unwrap improvements - performance improvement 2023-11-30 17:34:27 +01:00
Sebastian Witt changed title from WIP: Lightmap unwrap improvements - performance improvement to Lightmap unwrap improvements - performance improvement 2023-11-30 17:34:36 +01:00
Campbell Barton reviewed 2024-01-10 11:54:49 +01:00
@ -311,2 +333,2 @@
best_tri_index = -1
best_tri_diff = 100000000.0
# look in threshold vicinity to add all similar/equal tris in one go
if False and dist < tri_equality_threshold:

It's not clear why the disabled code is useful to add. Either there should be a description of what the code does that's useful and why it's currently disabled, or remove it.

It's not clear why the disabled code is useful to add. Either there should be a description of what the code does that's useful and why it's currently disabled, or remove it.
Author
Member

Thanks @ideasman42 ! I forgot to reenable that branch after benchmarking. It is not necessary from a functionality perspective. It just skips parts of the triangle pair matching with an additional kd lookup to match all triangles that are the same (within a threshold).

From testing it seems to be ~9% speedup depending on how many similar triangles there are.
In practise this is 1.34s vs 1.46s - it doesn't really matter at that point and comes with the cost of code complexity.

I am happy to leave it in or remove it.
The new commit is with the if branch/shortcut enabled.

Thanks @ideasman42 ! I forgot to reenable that branch after benchmarking. It is not necessary from a functionality perspective. It just skips parts of the triangle pair matching with an additional kd lookup to match all triangles that are the same (within a threshold). From testing it seems to be ~9% speedup depending on how many similar triangles there are. In practise this is 1.34s vs 1.46s - it doesn't really matter at that point and comes with the cost of code complexity. I am happy to leave it in or remove it. The new commit is with the if branch/shortcut enabled.
Campbell Barton requested changes 2024-01-10 12:23:15 +01:00
Campbell Barton left a comment
Owner

Disabled code should include comment explaining it's purpose (if it should be enabled, why it currently isn't for e.g.) or be removed.

Disabled code should include comment explaining it's purpose (if it should be enabled, why it currently isn't for e.g.) or be removed.
Sebastian Witt added 1 commit 2024-01-10 15:40:52 +01:00
870eca20ae reenable algorithm shortcut in lightmap pack
skipping similar triangles to speedup triangle pair match was in a disabled if branch
Sebastian Witt requested review from Campbell Barton 2024-01-10 15:51:43 +01:00

Committed 406a2fde91 without the progress changes since they could run multiple times per face group which would be misleading.

Now the performance has been improved, progress updates may not be needed.

In any case, if showing progress is useful it can be split into a separate PR.

Nice to see this old operator improved, thanks!

Committed 406a2fde91f9c945f3f1e3ca79877766e61d42e7 without the progress changes since they could run multiple times per face group which would be misleading. Now the performance has been improved, progress updates may not be needed. In any case, if showing progress is useful it can be split into a separate PR. Nice to see this old operator improved, thanks!
Campbell Barton closed this pull request 2024-01-11 00:37:05 +01:00

Pull request closed

Sign in to join this conversation.
No reviewers
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
2 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#113720
No description provided.