| Age | Commit message (Collapse) | Author |
|---|
|
This commit replaces the `Mesh_Runtime` struct embedded in `Mesh`
with `blender::bke::MeshRuntime`. This has quite a few benefits:
- It's possible to use C++ types like `std::mutex`, `Array`,
`BitVector`, etc. more easily
- Meshes saved in files are slightly smaller
- Copying and writing meshes is a bit more obvious without
clearing of runtime data, etc.
The first is by far the most important. It will allows us to avoid a
bunch of manual memory management boilerplate that is error-prone and
annoying. It should also simplify future CoW improvements for runtime
data.
This patch doesn't change anything besides changing `mesh.runtime.data`
to `mesh.runtime->data`. The cleanups above will happen separately.
Differential Revision: https://developer.blender.org/D16180
|
|
|
|
When setting the old face set custom data type, do it in the
"layers to write" vector instead of the mesh's poly custom
data layers, which weren't "prepared" yet. Otherwise this
could make the mesh's custom data typemap invalid.
|
|
|
|
|
|
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 2480b55f216c
Ref T95965
Differential Revision: https://developer.blender.org/D15795
|
|
This is very similar to D14077. There are two differences though.
First is that vertex creases are already stored in a separate layer,
and second is that we can now completely remove use of `Mesh.cd_flag`,
since that information is now inherent to whether the layers exist.
There are two functional differences here:
* Operators are used to add and remove layers instead of a property.
* The "crease" attribute can be created and removed by geometry nodes.
The second change should make various geometry nodes slightly faster,
since the "crease" attribute was always processed before. Creases are
now interpolated generically in the CustomData API too, which should
help maintain the values across edits better.
Meshes get an `edge_creases` RNA property like the existing vertex
property, to provide more efficient access to the data in Cycles.
One test failure is expected, where different rounding between float
the old char storage means that 5 additional points are scattered in
a geometry nodes test.
Differential Revision: https://developer.blender.org/D15927
|
|
Similar to the other refactors from T95965, this commit moves sculpt
face sets to use a generic integer attribute named `".sculpt_face_set"`.
This makes face sets accessible in the Python API.
The attribute is not visible in the attributes list or the spreadsheet
because it is meant for internal use, though that could be an option
in the future along with other similar attributes. Currently the change
is small, but in the future this could simplify code by allowing use
of more generic attribute APIs.
Differential Revision: https://developer.blender.org/D16045
|
|
Converting to the SoA format (T95965) immediately when reading meshes
means that none of the changes from versioning would be applied first.
This means important fixes like f14995aba70a aren't properly applied,
so modifications could be done to invalid CustomData. To fix this, move
the SoA changes into versioning code, in a new versioning_400.cc file.
Differential Revision: https://developer.blender.org/D15919
|
|
`MPoly` is used and copied in many places. To avoid the need to use a
special function for copying MPoly, or the need to add a copy
constructor, just rename the `mat_nr` field to include "legacy" in the
name. This keeps the original purpose of notifying developers that
the field shouldn't be used without any further complexity.
Apply the same fix to `bweight`.
Differential Revision: https://developer.blender.org/D15841
|
|
When there was only a single material assigned to the mesh, the material
index attribute didn't necessarily exist. Changing the oder of the slots
wouldn't change the first material index as necessary.
|
|
When resizing mesh and curves attribute storage, avoid initializing the
new memory for basic types. Also, avoid skipping "no free" layers; all
layers should be reallocated to the new size since they may be accessed.
The semantics introduced in 25237d2625078c6d1 are essential for this
change, because otherwise we don't have a way to construct non-trivial
types in the new memory.
In a basic test of the extrude node, I observed a performance
improvement of about 30%, from 55ms to 42ms.
Differential Revision: https://developer.blender.org/D15818
|
|
This attribute is still read and written in the legacy format which
puts it inside of `MPoly`. Missed in f1c0249f34c4171ec.
|
|
As described in T95966, the goal is to move to a "struct of arrays"
approach rather than gathering an arbitrary set of data in hard-coded
structs. This has performance benefits, but also code complexity
benefits (this patch removes plenty of code, though the boilerplate
for the new operators outweighs that here).
To mirror the internal change, the options for storing mesh bevel
weights are converted into operators that add or remove the layer,
like for some other layers.
The most complex change is to the solidify modifier, where bevel
weights had special handling. Other than that, most changes are
removing clearing of the weights, boilerplate for the add/remove
operators, and removing the manual transfer of bevel weights
in bmesh - mesh conversion.
Eventually bevel weights can become a fully generic attribute,
but for now this patch aims to avoid most functional changes.
Bevel weights are still written and read from the mesh in the old way,
so neither forward nor backward compatibility are affected. As described
in T95965, writing in the old format will be done until 4.0.
Differential Revision: https://developer.blender.org/D14077
|
|
- Remove "take ownership" argument which was confusing and always true
- The argument made ownership very confusing
- Better to avoid boolean arguments that switch a function's purpose
- Remove "mask" argument which was basically wrong and not used properly
- "EVERYTHING" was used because developers are wary of removing data
- Instead use `CD_MASK_MESH` for its purpose of original mesh data
- Remove use of shallow copied temporary mesh, which is unnecessary now
- Split shape key processing into separate functions and use C++ types
- Copy fields explicitly rather than using memcpy for the whole struct
- Use higher level functions and avoid redundant code
- The whole idea is pretty simple and can be built from standard logic
- Adjust `CustomData` logic to be consistent with "assign" expectations
- Clear the layer data from the source, and moves the anonymous ID
Differential Revision: https://developer.blender.org/D15857
|
|
owner_id pointer.
Also rename the callback. That way, we can keep moving toward a more
generic handling of those embedded IDs (think e.g. about copy code).
|
|
Replace `mesh_attributes`, `mesh_attributes_for_write` and the point
cloud versions with methods on the `Mesh` and `PointCloud` types.
This makes them friendlier to use and improves readability.
Differential Revision: https://developer.blender.org/D15907
|
|
This patch consists of two related fixes. The first is a simple fix for
forward compatibility, setting the Mesh.dvert pointer when writing a
file allows old Blender versions to read vertex groups from newly saved
files.
The second part is a bit uglier and more complex. Normally mesh vertex
group data is read in mesh_blend_read_data, for backward compatibility
with very old files. However, after 05952aa94d33eeb50 the mesh.dvert
pointer was not set, so the data was not read. Reading vertex group
layers when reading custom data is enough to fix that issue. We need to
read the data from *both* places, but BKE_defvert_blend_read cannot run
twice without memory leaks, so first try reading from custom data, then
read the pointer if that fails.
Differential Revision: https://developer.blender.org/D15905
|
|
This adds a new `blender::BitVector` data structure that was requested
a couple of times. It also replaces usages of `BLI_bitmap` in C++ code.
See the comment in `BLI_bit_vector.hh` for more details about the
advantages and disadvantages of using a bit-vector and how the new
data structure compares to `std::vector<bool>` and `BLI_bitmap`.
Differential Revision: https://developer.blender.org/D14006
|
|
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d33eeb50. This aligns better with
existing naming where the shorter names are much more common.
|
|
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7ee, 410a6efb747f). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
|
|
This patch moves material indices from the mesh `MPoly` struct to a
generic integer attribute. The builtin material index was already
exposed in geometry nodes, but this makes it a "proper" attribute
accessible with Python and visible in the "Attributes" panel.
The goals of the refactor are code simplification and memory and
performance improvements, mainly because the attribute doesn't have
to be stored and processed if there are no materials. However, until
4.0, material indices will still be read and written in the old
format, meaning there may be a temporary increase in memory usage.
Further notes:
* Completely removing the `MPoly.mat_nr` after 4.0 may require
changes to DNA or introducing a new `MPoly` type.
* Geometry nodes regression tests didn't look at material indices,
so the change reveals a bug in the realize instances node that I fixed.
* Access to material indices from the RNA `MeshPolygon` type is slower
with this patch. The `material_index` attribute can be used instead.
* Cycles is changed to read from the attribute instead.
* BMesh isn't changed in this patch. Theoretically it could be though,
to save 2 bytes per face when less than two materials are used.
* Eventually we could use a 16 bit integer attribute type instead.
Ref T95967
Differential Revision: https://developer.blender.org/D15675
|
|
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
|
|
|
|
Before 8c25889bb67db4c, subsurf face center tags were stored in each
vertex, so they were always copied to duplicate meshes. Now they are
stored in runtime data though, so they need to be copied explicitly.
The function name "reset_on_copy" is a bit awkward here, so the
tags are copied by the caller.
|
|
|
|
We don't convert to the old mesh format when writing undo steps to
avoid overhead. So we can't skip writing the hide attributes then.
|
|
* Flip the logic to first detect if we are dealing with an unmodified mesh
in editmode. And then if not, detect if we need a mapping or not.
* runtime.is_original is only valid for the bmesh wrapper. Rename it to clarify
that and only check it when the mesh is a bmesh wrapper.
* Remove MR_EXTRACT_MAPPED and instead check only for the existence of the
origindex arrays. Previously it would sometimes access those arrays without
MR_EXTRACT_MAPPED set, which according to a comment means they are invalid.
Differential Revision: https://developer.blender.org/D15676
|
|
This commit moves the hide status of mesh vertices, edges, and faces
from the `ME_FLAG` to optional generic boolean attributes. Storing this
data as generic attributes can significantly simplify and improve code,
as described in T95965.
The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`,
using the attribute name semantics discussed in T97452. 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 by default,
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 the hide status is used. When the flags are removed
completely, requirements will decrease when hiding is unused.
Further notes:
* Some code can be further simplified to skip some processing when the
hide attributes don't exist.
* The data is still stored in flags for `BMesh`, necessitating some
complexity in the conversion to and from `Mesh`.
* Access to the "hide" property of mesh elements in RNA is slower.
The separate boolean arrays should be used where possible.
Ref T95965
Differential Revision: https://developer.blender.org/D14685
|
|
|
|
A mesh wrapper might be being accessed for read-only from one thread
while another thread converts the wrapper type to something else.
The proposes solution is to defer assignment of the mesh wrapper
type until the wrapper is fully converted. The good thing about this
approach is that it does not introduce extra synchronization (and,
potentially, evaluation pipeline stalls). The downside is that it
might not work with all possible wrapper types in the future. If a
wrapper type which does not clear data separation is ever added in
the future we will re-consider the threading safety then.
Unfortunately, some changes outside of the mesh wrapper file are
to be made to allow "incremental" construction of the mesh prior
changing its wrapper type.
Unfortunately, there is no simplified file which demonstrates the
issue. It was investigated using Heist production file checked at
the revision 1228: `pro/lib/char/einar/einar.shading.blend`. The
repro case is simple: tab into edit mode, possibly few times.
The gist is that there several surface deform and shrinkwrap
modifiers which uses the same target. While one of them is building
BVH tree (which changes wrapper type) the other one accesses it for
read-only via `BKE_mesh_wrapper_vert_coords_copy_with_mat4()`.
Differential Revision: https://developer.blender.org/D15424
|
|
Curves that are attached to a surface can now follow the surface when
it is modified using shape keys or modifiers (but not when the original
surface is deformed in edit or sculpt mode).
The surface is allowed to be changed in any way that keeps uv maps
intact. So deformation is allowed, but also some topology changes like
subdivision.
The following features are added:
* A new `Deform Curves on Surface` node, which deforms curves with
attachment information based on the surface object and uv map set
in the properties panel.
* A new `Add Rest Position` checkbox in the shape keys panel. When checked,
a new `rest_position` vector attribute is added to the mesh before shape
keys and modifiers are applied. This is necessary to support proper
deformation of the curves, but can also be used for other purposes.
* The `Add > Curve > Empty Hair` operator now sets up a simple geometry
nodes setup that deforms the hair. It also makes sure that the rest
position attribute is added to the surface.
* A new `Object (Attach Curves to Surface)` operator in the `Set Parent To`
(ctrl+P) menu, which attaches existing curves to the surface and sets the
surface object as parent.
Limitations:
* Sculpting the procedurally deformed curves will be implemented separately.
* The `Deform Curves on Surface` node is not generic and can only be used
for one specific purpose currently. We plan to generalize this more in the
future by adding support by exposing more inputs and/or by turning it into
a node group.
Differential Revision: https://developer.blender.org/D14864
|
|
It's helpful to make the separation of legacy data formats explicit,
because it declutters actively changed code and makes it clear which
areas do not follow Blender's current design. In this case I separated
the `MFace`/"tessface" conversion code into a separate blenkernel
.cc file and header. This also makes refactoring to remove these
functions simpler because they're easier to find.
In the future, conversions to the `MLoopUV` type and `MVert`
can be implemented here for the same reasons (see T95965).
Differential Revision: https://developer.blender.org/D15396
|
|
We store various lazily calculated caches on meshes, some of which
depend on the vertex positions staying the same. The current API to
invalidate these caches is a bit confusing. With an explicit set of
functions modeled after the functions in `BKE_node_tree_update.h`,
it becomes clear which function to call. This may become more
important if more lazy caches are added in the future.
Differential Revision: https://developer.blender.org/D14760
|
|
|
|
Previously the function had a fair amount of ugly boilerplate to avoid
allocating the temporary layers array, and then free it if necessary.
`blender::Vector` solves that problem more elegantly. Passing a span,
using references in a few cases, and using a switch statement also make
the functions simpler.
This refactoring is in preparation for D14583 and D14685.
Differential Revision: https://developer.blender.org/D15011
|
|
Replace some `if/else if` chains by proper `switch` statement.
Replace some `BLI_assert(0)` calls by `BLI_assert_unreachable()` ones.
|
|
Add a property to the **Shade Smooth** operator to quickly enable the Mesh `use_auto_smooth` option.
The `Angle` property is exposed in the **Adjust Last Operation** panel to make it easy to tweak on multiple objects without having to go to the Properties editor.
The operator is exposed in the `Object` menu and `Object Context Menu`.
=== Demo ===
{F13066173, size=full}
Regarding the implementation, there are multiple ways to go about this (like making a whole new operator altogether), but I think a property is the cleanest/simplest.
I imagine there are simpler ways to achieve this without duplicating the `use_auto_smooth` property in the operator itself (getting it from the Mesh props?), but I couldn't find other operators doing something similar.
Reviewed By: #modeling, mont29
Differential Revision: https://developer.blender.org/D14894
|
|
Implementing removal of anonymous attributes with `GeometryComponent`
instead of `Mesh` makes it more reusable for other types like curves.
|
|
The "PROP" in the name reflects its generic status, and removing
"LOOP" makes sense because it is no longer associated with just
mesh face corners. In general the goal is to remove extra semantic
meaning from the custom data types.
|
|
This is mostly a cleanup to avoid hardcoding the eager calculation of
normals it isn't necessary, by reducing calls to `BKE_mesh_calc_normals`
and by removing calls to `BKE_mesh_normals_tag_dirty` when the mesh
is newly created and already has dirty normals anyway. This reduces
boilerplate code and makes the "dirty by default" state more clear.
Any regressions from this commit should be easy to fix, though the
lazy calculation is solid enough that none are expected.
|
|
Solves compilation warning with Clang, and moves manipulation with
DNA structures to the designed way for C++.
The tests and few other places are update to the new code by Jacques.
Ref T96847
Maniphest Tasks: T96847
Differential Revision: https://developer.blender.org/D14625
|
|
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
|
|
Reserve "filename" when only the name component is used.
|
|
Currently there is a "calc_face_normal" argument to mesh to bmesh
conversion, but vertex normals had always implicitly inherited whatever
dirty state the mesh input's vertex normals were in. Probably they were
most often assumed to not be dirty, but this was never really correct in
the general case.
Ever since the refactor to move vertex normals out of mesh vertices,
cfa53e0fbeed7178c7, the copying logic has been explicit: copy the
normals when they are not dirty. But it turns out that more control is
needed, and sometimes normals should be calculated for the resulting
BMesh.
This commit adds an option to the conversion to calculate vertex
normals, true by default. In almost all places except the decimate
and edge split modifiers, I just copied the value of the
"calc_face_normals" argument.
Differential Revision: https://developer.blender.org/D14406
|
|
Normals aren't stored in custom data anymore, nor are they stored in
MVert for comparisons.
|
|
These were only set in two places. One was related to "tessellated loop
normal", and the other derived corner normals. The values were never
checked though, after 59343ee1627f4c369. The handling of dirty face
corner normals is clearly problematic, but in the future it should be
handled like the normal layers on the other domains instead.
Ref D14154, T95839
|
|
|
|
Currently, when normals are calculated for a const mesh, a custom data
layer might be added if it doesn't already exist. Adding a custom data
layer to a mesh is not thread-safe, so this can be a problem in some
situations.
This commit moves derived mesh normals for polygons and
vertices out of `CustomData` to `Mesh_Runtime`. Most of the
hard work for this was already done by rBcfa53e0fbeed7178.
Some changes to logic elsewhere are necessary/helpful:
- No need to call both `BKE_mesh_runtime_clear_cache` and
`BKE_mesh_normals_tag_dirty`, since the former also does the latter.
- Cleanup/simplify mesh conversion and copying since normals are
handled with other runtime data.
Storing these normals like other runtime data clarifies their status
as derived data, meaning custom data moves more towards storing
original/editable data. This means normals won't automatically benefit
from the planned copy-on-write refactor (T95845), so it will have to be
added manually like for the other runtime data.
Differential Revision: https://developer.blender.org/D14154
|
|
|
