When multiple packing methods results in effectively the same bounds,
prefer the packer that uses the smallest area. When all islands can
easily fit this is usually the box packer instead of alpaca. The zigzag
method of the latter has a tendendcy to take up more area and rotate
islands.
Fix#110724: smart UV project unnecessarily rotates islands
Pull Request: https://projects.blender.org/blender/blender/pulls/112295
This has a tendency to place islands diagonally in the image which is
not usually wanted, even if it's maximimizing the number of pixels for
the island.
Fix#109906: UV unwrap packs island diagonally instead of straight
Pull Request: https://projects.blender.org/blender/blender/pulls/112295
This makes the code reusable in a few more places,
particularly by tests for a new boolean implementation
also defined in the geometry module.
It also makes the way some primitives are reused among
different nodes a bit clearer.
Pull Request: https://projects.blender.org/blender/blender/pulls/112255
Regression [0] which merged index assignment into an earlier loop.
This caused the indices to be overwritten by p_chart_abf_solve
causing unwrap to fail.
[0]: 8ace65e3c6
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
Add three cached topology maps to `Mesh`, to avoid computations when
mesh data isn't changed. Choosing the right maps to cache is a bit
arbitrary, but generally we have to start somewhere. The limiting
factor is memory usage (all the new caches combined have a
comparable footprint to a UV map).
For now, the caches added are:
- Vertex to face corner
- Vertex to face
- Face corner to face
These caches are used in quite a few places already;
- Face corner normal calculation
- UV value merging
- Setting sharp edges from face angles
- Data transfer modifier
- Voxel remesh attribute remapping
- Sculpt mode painting
- Sculpt mode normal calculation
- Vertex paint mode
- Split edges geometry node
- Mesh topology geometry nodes
Caching topology maps means they don't have to be rebuilt every time
they're used. Meshes copied but without topology changes can share
the cache, further reducing re-computations. For example, FPS with a
large mesh using the "Corners of Vertex" node went from 1.8 to 2.3.
Entering sculpt mode is slightly faster too.
There is some obvious work for future commits:
- Use caches in attribute domain interpolation
- More multithreading of second phase of map building
- Update/build caches eagerly in some geometry nodes
Pull Request: https://projects.blender.org/blender/blender/pulls/107816
The new split edges code from e83f46ea76 started the use of
Mesh rather than BMesh as a performance improvement. However, the code
contained a complex loop used for de-duplicating edges that gave invalid
indices in some circumstances. That was fixed by b226c115e2,
but in turn that commit caused loose edges to be skipped. That was
fixed by 111e378366, however that caused another crash.
Long story short, the code is quite complex and the existing algorithm,
while an improvement from the original, is fiddly. For example, instead
of working with just the input and output states, it adjusted topology
data for an intermediate state halfway through the change.
Fixes#109236
**Goals**
- Only use topology maps from the input mesh. This should work better
with future topology caching improvements (See !107816).
- Run de-duplication in a per-edge context to allow parallelization.
- Optimize for real world use cases when there is merging of new edges.
- Improve readability by making each step's inputs clear, improving naming,
and separating functions.
- Improve handling of loose edges.
- Reuse existing edges for the first new split edges, simplifying
edge attribute propagation.
**Timing**
I tested performance with a Ryzen 7950x and a grid with 4 million faces
with different random portions of the mesh selected.
| Selection | Before (ms) | After (ms) | Change |
| --------- | ----------- | ---------- | ------ |
| 100% | 1869.4 | 351.8 | 5.3x |
| 50% | 1636.0 | 356.0 | 4.6x |
| 10% | 1148.8 | 238.2 | 4.8x |
| 4 Million Face Grid | 10% | 50% | 100% |
| ------------------------------- | ---- | ---- | ---- |
| `vert_selection_from_edge` | 2.7 | 4.1 | 4.3 |
| `selection_to_bit_vector` | 0.7 | 3.9 | 0.2 |
| `vert_to_corner_map` | 22.3 | 22.5 | 22.4 |
| `edge_to_corner_map` | 47.7 | 47.6 | 47.6 |
| `corner_to_face_map` | 3.3 | 3.3 | 3.3 |
| `calc_all_corner_groups` | 21.0 | 44.1 | 38.3 |
| `calc_vert_ranges_per_old_vert` | 3.0 | 7.4 | 7.9 |
| `update_corner_verts` | 2.8 | 12.7 | 15.5 |
| `calc_new_edges` | 28.8 | 44.1 | 35.5 |
| `update_unselected_edges` | 9.8 | 9.3 | 0.0 |
| `propagate_edge_attributes` | 35.7 | 51.3 | 61.7 |
| `propagate_vert_attributes` | 24.0 | 27.0 | 31.7 |
| `propagate_vert_attributes` | 24.2 | 29.7 | 36.9 |
**Tests**
New regression tests have been committed separately. Existing
tests were updated since the new code gives different indices.
When the final curve point indices are in the same order as the input
points, and there are many curves, avoid copying point domain
attributes, by generalizing the existing check from the mesh
to curve conversion node.
Pull Request: https://projects.blender.org/blender/blender/pulls/111662
Fill face offsets in one multithreaded loop with an offset indices
utility function instead of keeping track of the index and setting
the offset for each face.
The count of faces destroyed could be wrong when more than one groups
of vertices on the same face resulted in the face collapsing.
The solution is to break the loop on the first collapsed face
detection.
Caused by 6ec842c43c.
Include counts of some headers while making full blender build:
- BLI_color.hh 1771 -> 1718
- BLI_math_color.h 1828 -> 1783
- BLI_math_vector.hh 496 -> 405
- BLI_index_mask.hh 1341 -> 1267
- BLI_task.hh 958 -> 903
- BLI_generic_virtual_array.hh 509 -> 435
- IMB_colormanagement.h 437 -> 130
- GPU_texture.h 806 -> 780
- FN_multi_function.hh 331 -> 257
Note: DNA_node_tree_interface_types.h needs color include only
for the currently unused (but soon to be used) socket_color function.
Future step is to figure out how to include
DNA_node_tree_interface_types.h less.
Pull Request: #111113
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
The split face code relied a lot of the edges added to the weld context.
But with 113004687d, some edges are removed from context. And even more
edges can be removed (reducing loops and arrays).
Removing the dependence on edges decreases the array and time spent in
loops.
Furthermore, the corner edge array should not be needed for the
merge by distance operation.
So this commit redoes the face/loops iterator which previously
needed the `loop_next` member to skip loops depending on the previous
one (possibly linked to the edge whose vertex will be merged) and now
uses the `switch_to` member to switch loops instead of skipping and
depend on the former.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Bug identified in #110942.
In cases where the last corners of a polygon are out of context, the
`weld_iter_loop_of_poly_next` iterator skips these corners.
This means that some corners of the resulting mesh do not have the
value set, which can even result in infinite loops.
The solution was not simple. The iterator had to be practically redone
to not use the `loop_end` member (which caused the problem).
Fortunately the code is more simplified with this change.
Remove the "_for_read" suffix from methods to get geometry and geometry
components. That should be considered the default, so the suffix just
adds unnecessary text. This is consistent with the attribute API and
various implicit sharing data access methods.
Use "from_mesh" instead of "create_with_mesh". This is consistent with
the recently used naming for the `IndexMask` API.
Pull Request: https://projects.blender.org/blender/blender/pulls/110738
The aim is to replace the `BKE_mesh_faces_flip` functions with
this newer C++ function using the attribute API. But that is must
be called by RNA, so move this to blenkernel to avoid a circular
dependency between the geometry module and RNA.
This is mostly boilerplate code to add a new `GeometryComponent` as well as making sure
the new `GeometryComponent::Type` is handled in all the `switch` statements.
Pull Request: https://projects.blender.org/blender/blender/pulls/110457
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
The cleanup of blenkernel last weeks , caused the house of cards to
collapse on top of bf_gpu's shader_builder, which is off by default
but used on a daily basis by the rendering team.
Given the fixes forward in #110394 ran into a ODR violation in OSL that
was hiding there for years, I don't see another way forward without
impeding the rendering teams productivity for "quite a while" as there
is no guarantee the OSL issue would be the end of it.
the only way forward appears to be back.
this reverts :
19422044eda670b53abe0f541db97cbe516e8c813e88a2f44c4e64b772f59547e7a31707fe6c5a57
The problematic commit was 07fe6c5a57
as blenkernel links most of blender, it's a bit of a link order issue
magnet. Given all these commits stack, it's near impossible to revert
just that one without spending a significant amount of time resolving
merge conflicts. 99% of that work was automated, so easier to just
revert all of them, and re-do the work, than it is to deal with the
merge conflicts.
Pull Request: https://projects.blender.org/blender/blender/pulls/110438
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
This reverts commit b226c115e2.
Fixes#110005.
I have been working on a fix branch, but the problem was fairly
fundamental to the algorithm and the fix ended up being a rewrite
that I didn't quite finish yet, and I will be away next week. Since
the other bug is a crash rather than a change in behavior, better to
have the other bug than this one in the meantime.
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
The `groups_map` array (which indicates the group an element belongs
to) is only intended to reduce loops when creating groups, speeding up
that part of the code.
But on the downside, it requires more memory usage, and adds one more
step to access groups (`groups_offs[groups_map[i]]` instead of just
`groups_offs[i]`).
So removing that array decreases memory usage and speeds up access in
another part of the code.
The profile showed a +6% advantage when the Weld modifier affects large
portions of the mesh.
But it also showed a loss of around -0.6% in performance for cases
where the Weld modifier affects small parts of the mesh.
The biggest benefit is to save memory and speed up some cases.
