UV: Add option to Pack UVs using xatlas strategy #105821
No reviewers
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105821
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "Chris_Blackbourn/blender:uv-pack-xatlas"
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?
Loosely based on the "xatlas" algorithm.
See https://github.com/jpcy/xatlas
Adds
shape_method
with ED_UVPACK_SHAPE_AABB, ED_UVPACK_SHAPE_CONVEX and ED_UVPACK_SHAPE_CONCAVERef #68889, #105680
bad_packing_from_Bystedt_220920:
Marble fireplace:
suzanne_pieces:
NonSquare3:
Sweater 3D paint:
Very promising.
Be sure to add license and copyright info in the code, like this:
Removing myself as reviewer since this is WIP and doesn't need to be in my review queue yet.
The overall approach seems fine. For this to be ready for review it would need an overview of what is still planned to be done as part of this PR, what would be done after, timing comparisons and an example with margins.
Updates from second commit (
7911fd0ba2
)bad_packing_from_Bystedt_220920 (<1second) :
UVFreeze (4 seconds) :
Detail from UVFreeze :
NonSquare3 (2 seconds) :
Still WIP.
Update 3 with commit
180a55a447
Add support for "Convex Hull" in addition to "Concave + Holes"
Suzanne_Pieces (modified), Convex Hull, no rotate. (1 second)
Detail from UVFreeze, Convex Hull, margin:0.001. (4 seconds)
Prototyping.blend, margin = 0.004. (2 seconds)
Is there interest in a "Package Build" at this time?
Im not sure how buggy or not is it, but sooner or later we will want start the testing, as i said im not sure how functional is it to test, im not a developer so can't determinate how functional would be a build at the moment.
If it can unwrap and pack four times in a row without crash i would like to test it.
just to clarify, are we talking about this builds, right?
Very keen for crash repros.
Mostly interested in performance issues, if there are particular meshes where it takes > 10 seconds on a fast machine (or > 60 seconds on a slow one)
@blender-bot package
UV Editor > UV > Pack Islands > Shape Method >
Package build started. Download here when ready.
great ill pick the build up to test once its done, i have a ryzen 9 3900x 12 cores but less than 4ghz per core when working all at the same time.
This is nuts, default cubes 2500 cubes (its a synthetic test, ill prepare a proper model later) its lagier moving those uvs than packing, its really fast in this scenario.
Is there a particular situation where the packer struggles with? different size islands, two big several small? maybe this test is fast because of alpaca?
I test pinning a few islands i imagine its not supported but it worth trying ^-^
5000 cubes different uv island, size keeps packing as fast as before
however some things start to happens (to be fair, considering the huge object count fixing a few islands by hand its not that big of a deal)
Ill keep testing
interesting offset pattern with islands rotated in this 5000 cube file.
Nice! Will take a proper look when I'm back on my machine later.
It might crash on geometry bombs? e.g. get a map of the world in vector format, so there's lots of polygons with high vertex count and degenerate geometry etc.
Polygons with internal holes might trip it up too?
Also UVs where the scale is wildly different. E.g. a single cube with uvs 1e8f across, and lots of dust at 1e-5f across...
I choose to go trough my work folder, personal and professional, this uvs are repacked with this patch all this models where used in commercial productions, this are not extremely heavy meshes because some are for game engines others for sub-d, sorry im not sure if i can show the models but uvs, who would know, besides this are new uvs ^-^
I have other models but have simetrical uvs and probably its far from the scope of this packer.
All these tests and a few more extreme dense and broken meshes, didn't make the build crash. . . so it may be buggie and experimental but it packed production models without crashing once.
The grey uvs on the side are mirror modifier offset, packed with no crashes even with that enable.
Next mission, try to make it crash :)
Latest commit (
e99ce8f43c
) increases accuracy and gives us a bit of headroom for improvement for later when we want different strategies beyond alpaca and xatlas. Also fixes a couple slow cases.Unfortunately "5000 cube uv pack test.blend" turns my machine into a laggy mess so I can't really test it :(
@blender-bot package
I think there's a still a delay on heavy meshes with a large "margin" parameter. Not sure how serious that one is at this stage.
Also setting Margin Method to "Fraction" will slow things down quite a bit.
I might nerf those cases in next commit. Unless there's any other requests, might move to code review next.
(Just as a heads up, this is only on the "Pack Islands" operator for this particular PR. I'll create additional commits for "Smart UV Project" and Geometry Nodes later...)
Any feedback before then?
Package build started. Download here when ready.
This new build is more precise indeed (5000 cube uv pack test.blend same pack parameters margin 0.0001) also seems to be 1 second faster but i don't have a profiler and manually stooping a chronometer in the phone its not the most precise measure, four seconds top around three normally in this 5000 cube test.
Fraction margin was as you mention much slower, it was easier to time around 8 to 9 seconds, still faster than yesterdays build, the old version with Fraction as margin method was around 15 seconds.
Cpu Ryzen 9 3900x - ubuntu 22.04 lts
Question:
¿why don't the little bits go to the holes like other islands?
(this question its just because curiosity, this extreme example would rarely be used in real work or at all)
by the way new test 5000 cubes with holes, still no crash
I was able to make it crash with an absurd scale factor as you mentioned before but the max scale factor that blender allowed me to use was 1e36
"v pack crash.blend"attached
Awesome!
It's basically to move the core algorithm into a different "time Vs pack efficiency" regime, by splitting the problem into an "easy" section and a "hard section".
In a bit more detail, the core algorithm in this PR runs in time-complexity
O(N^4)
whereN
is the number of islands. By forcingN<1024
, I can cut some corners and turn it intoO(N^3)
(*). That still leaves all the other tiny islands, so I just run the Alpaca (O(NlogN)) on them and squish them around the sides.More long terms, there's things we can do to put all the "dust" into the interiors ("Fast!"), and other things that will improve the tiny islands ("Fast enough"). For right now though, I want to try and keep the PR simple.
(*) This is worst case performance, think something like 100,000 irregular annulus shapes, covering only a narrow band of sizes in UV space.
Further testing with the "5000 cubes with holes" i try subdividing the cubes four times, this raise the packing time from 3-4 seconds to 8 seconds
5000 objects - 2760000 verts - 2750000 faces - 5500000 triangles.
Just because i have the addon i try UVPackmaster 3.0.6 default and does a lovely tighter job but it took around 45 seconds from pressing the button to -packing done- status.
So 4 to 8 seconds for this patch looks really promising :)
more test(its becoming a kind of hobbie) only five cubes but highly subdivided, 1638000 triangles it took around 15 seconds.
I was about to upload the .blend but its 40mb compressed and its five cubes with subdivision
Requesting changes although these are mostly details, overall this seems to work well - further improvements can be iterated on in the main branch.
@ -1390,6 +1390,8 @@ static void uvedit_pack_islands_multi(const Scene *scene,
selection_center[1] = (selection_min_co[1] + selection_max_co[1]) / 2.0f;
}
MemArena *arena = BLI_memarena_new(BLI_MEMARENA_STD_BUFSIZE, __FILE__);
This function should also create a
Heap
forBLI_polyfill_beautify
inaddPolygon
to use to avoid re-creating the Heap for every faces with >3 vertices.@ -1560,2 +1585,4 @@
};
static const EnumPropertyItem pack_shape_method_items[] = {
{ED_UVPACK_SHAPE_FASTEST, "FASTEST", 0, "Fastest", "Pack as fast as possible"},
Names are a bit esoteric.
"Bounding Box (Simple)"
description can be "Use a simple method of packing for maximum performance". This could use thealpaca
method always (and not bother with a lower cut-off).CONVEX/CONCAVE - while correct I wonder if users will be able to quickly visualize the difference here. I can't think of good alternatives though. e.g. "High Quality", "High Quality (Fill Holes)"... descriptions could note about concave/convex.
@ -1596,0 +1633,4 @@
RNA_def_enum(ot->srna,
"shape_method",
pack_shape_method_items,
ED_UVPACK_SHAPE_CONVEX,
Shouldn't CONCAVE_HOLE be the default? (as far as I was aware this is what users want practically all the time).
@ -24,1 +27,4 @@
/* Compute signed distance to a line passing through `uva` and `uvb`.
*/
static float signed_distance_to_edge(float2 probe, float2 uva, float2 uvb)
*picky* could have
signed_distance_to_edge_squared(..)
(both squared non-squared if both are needed) as it seems callers don't require thesqrt
in some cases.@ -25,0 +83,4 @@
/* Beautify improves performance of packer. (Optional) */
Heap *heap = BLI_heap_new();
BLI_polyfill_beautify(source, vert_count, tris, arena, heap);
Does this help? I would have thought in the case of packing/rasterizing - there wouldn't be much/any advantage.
If it's needed, a brief comment explaining why would be good.
@ -113,0 +228,4 @@
public:
Occupancy(const float initial_scale);
void increaseScale(); /* Resize the scale of the bitmap and clear it. */
Prefer snake-case over camel case for methods.
@ -113,0 +330,4 @@
}
/* Iterate in opposite direction to outer search to improve witness effectiveness. */
for (int y = iy1 - 1; y >= iy0; --y) {
*picky* by convention,
--
is used after values in most of Blender's code, unless the result of the addition/subtraction requires the prefix version to be used.@ -113,0 +356,4 @@
float Occupancy::traceIsland(PackIsland *island,
const float scale,
const float margin,
const float2 uv,
pass a reference?
@ -113,0 +399,4 @@
if (extentH < 0.0f) {
return horiz;
}
float2 vert(t / occupancy.bitmap_scale_reciprocal -
const
?@ -113,0 +400,4 @@
return horiz;
}
float2 vert(t / occupancy.bitmap_scale_reciprocal -
BLI_rctf_size_x(&island->bounds_rect) * scale,
*picky* prefer brackets when mixing add/subtract with multiply/divide. Bugs caused by edits that don't take order of operations into account happen from time to time, so better avoid them entirely.
@ -113,0 +467,4 @@
while (i < island_indices.size()) {
PackIsland *island = islands[island_indices[i]->index];
float2 best = find_best_fit_for_island(island, scan_line, occupancy, scale, margin);
const
?@ -113,0 +476,4 @@
scan_line++;
}
else {
scan_line += 2; /* !! (Don't change this line.) !! */
Unhelpful comment, assume it's from up-stream? If so, note that the upstream code considers this important but it's not known why it's needed. (or better, note why it's needed).
@ -149,3 +556,3 @@
});
/* Partition island_vector, largest will go to box_pack, the rest alpaca_turbo.
/* Partition island_vector, largest will go to slow_packer, the rest alpaca_turbo.
As
slow_packer
isn't a named packer. Suggestdefault (slower) packer
.@ -155,0 +560,4 @@
int64_t alpaca_cutoff = int64_t(1024);
if (params.margin_method == ED_UVPACK_MARGIN_FRACTION) {
if (margin > 0.0f) {
alpaca_cutoff = int64_t(80);
Assign 80 to a variable and name it, explain the reasoning for using a different cutoff.
@ -1390,6 +1390,8 @@ static void uvedit_pack_islands_multi(const Scene *scene,
selection_center[1] = (selection_min_co[1] + selection_max_co[1]) / 2.0f;
}
MemArena *arena = BLI_memarena_new(BLI_MEMARENA_STD_BUFSIZE, __FILE__);
Also use
__func__
instead of__FILE__
, generally more useful in allocation messages.From discussion outside this PR, none of my requests require and extra iteration, accepting.
WIP: UV: Add option to Pack UVs using concave hulls with hole fillingto UV: Add option to Pack UVs using concave hulls with hole fillingUV: Add option to Pack UVs using concave hulls with hole fillingto UV: Add option to Pack UVs using xatlas strategyNoice!
Hello, i made few tests and suddenly i have corner case here. When rotation is turned on, algorithm rotates similar pieces to one orientation and it decreases efficiency of packing.
Tested with this free scene and the tree is an issue
2023-04-05_10-38-05.mp4
https://sketchfab.com/3d-models/camp-scene-free-download-700e1953be114f82977506a7c4664477
Heyas! The
xatlas
strategy is still a work-in-progress and doesn't yet fully support rotation.I'll be commiting more improvements shortly, hopefully that will help.
Better rotation support is in
43476e2d71
Suzanne_Pieces, compare with earlier version above ^^^.
... Still more improvements to come ...