Currently this conversion (which happens when using modifiers in edit
mode, for example) is completely single threaded. It's harder than some
other areas to multithread because BMesh elements don't always know
their indices (and vise versa), and because the dynamic AoS format
used by BMesh makes some typical solutions not helpful.
This patch proposes to split the operation into two steps. The first
updates the indices of BMesh elements and builds tables for easy
iteration later. It also checks if some optional mesh attributes
should be added. The second uses parallel loops over all elements,
copying attribute values and building the Mesh topology.
Both steps process different domains in separate threads (though the
first has to combine faces and loops). Though this isn't proper data
parallelism, it's quite helpful because each domain doesn't affect the
others.
**Timings**
I tested this on a Ryzen 7950x with a 1 million face grid, with no
extra attributes and then with several color attributes and vertex
groups.
| File | Before | After |
| Simple | 101.6 ms | 59.6 ms |
| More Attributes | 149.2 ms | 65.6 ms |
The optimization scales better with more attributes on the BMesh. The
speedup isn't as linear as multithreading other operations, indicating
added overhead. I think this is worth it though, because the user is
usually actively interacting with a mesh in edit mode.
See the differential revision for more timing information.
Differential Revision: https://developer.blender.org/D16249
Generally the `extern "C" {` brackets shouldn't be added around other
headers since it causes problems when using C++ features in them.
Follow that convention for the "bmesh.h" header.
Using the attribute name semantics from T97452, this patch moves the
selection status of mesh elements from the `SELECT` of vertices, and
edges, and the `ME_FACE_SEL` of faces to generic boolean attribute
Storing this data as generic attributes can significantly simplify and
improve code, as described in T95965.
The attributes are called `.select_vert`, `.select_edge`, and
`.select_poly`. The `.` prefix means they are "UI attributes",so they
still contain original data edited by users, but they aren't meant to
be accessed procedurally by the user in arbitrary situations. They are
also be hidden in the spreadsheet and the attribute list.
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when selection is used. When the flags are removed
completely, requirements will decrease.
Further notes:
* The `MVert` flag is empty at runtime now, so it can be ignored.
* `BMesh` is unchanged, otherwise the change would be much larger.
* Many tests have slightly different results, since the selection
attribute uses more generic propagation. Previously you couldn't
really rely on edit mode selections being propagated procedurally.
Now it mostly works as expected.
Similar to 2480b55f21
Ref T95965
Differential Revision: https://developer.blender.org/D15795
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Code that handled merging & initializing custom-data from other
meshes sometimes missed checks for this flag, causing bevel weights to
lost when the mesh was converted to a BMesh.
The following changes are a more general fix for T94197.
- Add BM_mesh_copy_init_customdata_from_mesh_array which initializes
custom-data from multiple meshes at once.
As well as initializing custom-data layers from Mesh.cd_flag.
This isn't essential for boolean, however it avoids the overhead of
resizing custom-data layers.
- Loading mesh data into a BMesh now respects Mesh.cd_flag
instead of only checking if the BMesh custom-data-layer exists.
Without this, the order of meshes passed to BM_mesh_bm_from_me could
give different (incorrect) results.
- Copying mesh data now copies `cd_flag` too. This is a precaution
as in my tests evaluating modifiers these values always matched.
Nevertheless it's correct to copy this value as custom-data it's
self is being copied.
`CustomData_bmesh_interp` use the same CustomData decryptor (in this case, `bm->ldata`) in both blocks.
So make sure that all CustomData layers match.
This commit also removes redundant `BM_elem_attrs_copy_ex` calls.
Maniphest Tasks: T81060
Differential Revision: https://developer.blender.org/D9159
This replaces header include guards with `#pragma once`.
A couple of include guards are not removed yet (e.g. `__RNA_TYPES_H__`),
because they are used in other places.
This patch has been generated by P1561 followed by `make format`.
Differential Revision: https://developer.blender.org/D8466
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
now, instead of making hidden copies of faces, the faces are copied into a temp bmesh.
also remove a hash that was being created and not used (old code).
Thanks for Sergey for finding the bug & patching, This fix works a bit differently.
Theres no need to allocate the customdata in the first place - since its written into. So add a flag for vert/edge/face/loop creation functions so they can skip customdata creation.
Added function: BM_face_create_ngon_vcloud
creating quads and tris use this too since it finds the best face winding direction based on surrounding face (if any)
* double default edge allocation size (double the number of verts/faces).
* CustomData_bmesh_init_pool was using allocsize & chunksize as the same variable. Now use type specific chunk size.
* bmesh copy and editmode conversion now allocate the BMesh mempool size needed for the entire vert/edge/loop/face arrays since its known already.
