| Age | Commit message (Collapse) | Author |
|---|
|
|
|
In anticipation of UV Copy+Paste, we need fast access to indices
of unique UvElements. Can also be used to improve performance and
simplify code for UV Sculpt tools and UV Stitch.
No user visible changes expected.
Maniphest Tasks: T77911
See also: D16278
|
|
Currently there are both "EDGERENDER" and "EDGEDRAW" flags, which are
almost always used together. Both are runtime data and not exposed to
RNA, used to skip drawing some edges after the subdivision surface
modifier. The render flag is a relic of the Blender internal renderer.
This commit removes the render flag and replaces its uses with the
draw flag.
|
|
Part of T102224
|
|
The goal is to improve clarity and readability, without
introducing big design changes.
Follows the recent obmat to object_to_world refactor: the
similar naming is used, and it is a run-time only rename,
meaning, there is no affect on .blend files.
This patch does not touch the redundant inversions. Those
can be removed in almost (if not all) cases, but it would
be the best to do it as a separate change.
Differential Revision: https://developer.blender.org/D16367
|
|
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
|
|
|
|
BKE_sculpt_mask_layers_ensure now takes a depsgraph argument and
will evaluate the depsgraph if a multires mask layer is added.
This is necassary to update the multires runtime data so that
pbvh knows it has a grids mask layer.
Also added code to update pbvh->gridkey.
|
|
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
|
|
|
|
|
|
This indexes the "objects" array, so rename 'b' and 'base_index'
to 'ob_index'.
|
|
The crash was caused by [0] however knife-project functionality has been
incorrect since [1] which would loop over each edit-mode object and run
the knife project function which operated on all edit-mode objects too.
- Resolve the crash by postponing face-tessellation recalculation
until the knife tool has cut all objects
- Objects occluding each other is now supported
(an old TODO and something that was never supported).
[0]: 690ecaae208d5f72217c165621d0d036e4029e86
[1]: 6e77afe6ec7b6a73f218f1fef264758abcbc778a
|
|
|
|
To allow moving mesh runtime data to C++ (D16180).
|
|
|
|
Also remove unnecessary struct keywords in C++ files.
|
|
- Active Track (NLA vs movie clip)
- New (file)
- Object Index (loop cut)
- Object Index (render pass)
- Proxy Storage (sequence)
- Rim (Solidify modifier)
- Roughness (particle children)
- Spaces (text whitespace)
- Out (sequencer wipe transition)
Also make new asset tag name translatable.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D16067
|
|
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
|
|
Also replace "dm" for evaluated mesh in some comments.
|
|
|
|
In preparation for moving mesh runtime data out of DNA.
|
|
|
|
To use function style cast '(unsigned char)x' can't be replaced by
'unsigned char(x)'.
|
|
|
|
Correction of U.dpi to hold actual monitor DPI. Simplify font sizing by
omitting DPI as API argument, always using 72 internally.
See D15961 for more details.
Differential Revision: https://developer.blender.org/D15961
Reviewed by Campbell Barton
|
|
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
|
|
|
|
|
|
|
|
Disambiguate:
- Lower / Upper (case)
- Spray (ocean modifier)
- Keep Original (clip, grease pencil, object)
- Screen [space] (inside some enum items, mostly)
- Cast Shadow ("shadow that is cast", not "to cast a shadow")
Extract:
- Line Art Light Reference Near and Far
- Mesh vertex attribute domain: Vertex
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D15938
|
|
Whether faces are hidden and face sets are orthogonal concepts, but
currently sculpt mode stores them together in the face set array.
This means that if anything is hidden, there must be face sets,
and if there are face sets, we have to keep track of what is hidden.
In other words, it adds a bunch of redundant work and state tracking.
On the user level it's nice that face sets and hiding are consistent,
but we don't need to store them together to accomplish that.
This commit uses the `".hide_poly"` attribute from rB2480b55f216c to
read and change hiding in sculpt mode. Face sets don't need to be
negative anymore, and a bunch of "face set <-> hide status" conversion
can be removed. Plus some other benefits:
- We don't need to allocate either array quite as much.
- The hide status can be read from 1/4 the memory as face sets.
- Updates when entering or exiting sculpt mode can be removed.
- More opportunities for early-outs when nothing is hidden.
- Separating concerns makes sculpt code more obvious.
- It will be easier to convert face sets into a generic int attribute.
Differential Revision: https://developer.blender.org/D15950
|
|
When a change happens which invalidates view layers the syncing will be postponed until the first usage.
This will improve importing or adding many objects in a single operation/script.
`BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing
`BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection`
or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`.
Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a
view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be
reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out.
This patch has been added to discuss the details and consequences of the current approach. For clarity
the call to BKE_view_layer_ensure_sync is placed close to the getters.
In the future this could be placed in more strategical places to reduce the number of calls or improve
performance. Finding those strategical places isn't that clear. When multiple operations are grouped
in a single script you might want to always check for resync.
Some areas found that can be improved. This list isn't complete.
These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer.
The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce
performance compared to master, but will be fixed by the additional patches.
**Object duplication**
During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled
the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate
and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}).
**Object add**
`BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the
view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`).
We should make the selection and activation optional. This would make it possible to add multiple objects
without having to resync per object.
**Postpone Activate Base**
Setting the basact is done in many locations. They follow a rule as after an action find the base and set
the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which
base will be set in the basact during the next sync, reducing the times resyncing needs to happen.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15885
|
|
Related to {D15885} that requires scene parameter
to be added in many places. To speed up the review process
the adding of the scene parameter was added in a separate
patch.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15930
|
|
An edge can be marked BM_ELEM_SEAM, which means the UV co-ordinates
on either side of the edge are actually independent, even if they
happen to currently have the same value.
This commit optionally add support for UV Seams when computing islands.
Affects UV sculpt tools, individual origins, UV stitch and changing
UV selection modes etc.
Required for upcoming packing refactor which requires seam support
when computing islands.
Differential Revision: https://developer.blender.org/D15875
|
|
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
|
|
|
|
|
|
Caused by {rBf1c0249f34c4}
This is what (I think) went wrong in the above commit:
- `join_mesh_single` was writing material indices to the custom data /
attribute of the source mesh
- the `polyofs` of each mesh that was joined was not taken into account
Now, instead of using the AttributeWriter on a particular mesh, use the
CustomData (`pdata`) - that is constantly changed during joining -
directly for writing.
Otherwise we end up writing into customdata that has not been "extended"
yet (even if we use the destination mesh).
Also note that even on the destination mesh, CustomData would be freed
anyways after all calls to `join_mesh_single` took place, to be replaced
with the mentioned `pdata` which should be the single customdata to
write to here.
When doing this (writing to `pdata`), we also need to take into account
the poly offset of each contributing mesh.
Maniphest Tasks: T100822
Differential Revision: https://developer.blender.org/D15878
|
|
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
|
|
Follows existing naming for the most part, also use "num" as a suffix
in some instances (following our naming conventions).
|
|
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.
|
|
The only real difference between `GPU_SHADER_2D_UNIFORM_COLOR` and
`GPU_SHADER_3D_UNIFORM_COLOR` is that in the vertex shader the 2D
version uses `vec4(pos, 0.0, 1.0)` and the 3D version uses
`vec4(pos, 1.0)`.
But VBOs with 2D attributes work perfectly in shaders that use 3D
attributes. Components not specified are filled with components from
`vec4(0.0, 0.0, 0.0, 1.0)`.
So there is no real benefit to having two different shader versions.
This will simplify porting shaders to python as it will not be
necessary to use a 3D and a 2D version of the shaders.
In python the new name for '2D_UNIFORM_COLOR'' and '3D_UNIFORM_COLOR'
is 'UNIFORM_COLOR', but the old names still work for backward
compatibility.
Differential Revision: https://developer.blender.org/D15836
|
|
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 is a cleanup required before refactoring the view layer syncing
process {T73411}.
* Remove FIRSTBASE.
* Remove LASTBASE.
* Remove BASACT.
* Remove OBEDIT_FROM_WORKSPACE.
* Replace OBACT with BKE_view_layer_active_object.
* Replace OBEDIT_FROM_VIEW_LAYER with BKE_view_layer_edit_object.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15799
|
|
|
|
|
