The operator's description used a format string like:
```
BLI_sprintfN(TIP_("%s %s vertex groups of the active object"),
action_str, target_str)
```
which is almost guaranteed to be impossible to properly localize to
some languages -- I know there are a couple of issues for French
already.
So instead of hoping formatting works, write all possible strings
explicitly, even if it looks stupidly verbose.
We (Dalai, Hans, Falk, Simon and me) decided that the curves edit mode
is useful enough to justify moving it out of experimental now. So far it
supports the following features:
* Various selection tools. The selections are synced with sculpt mode.
* Transform tools.
* Delete curves/points.
More functionality of the old curve edit mode will be ported over in
future releases.
Currently there's no way to assign a geometry node group from the asset
browser to an object as a modifier without first appending/linking it
manually. This patch adds a drag and drop operator that adds a new
modifier and assigns the dragged tree.
Pull Request #104430
As described in #95966, replace the `ME_EDGEDRAW` flag with a bit
vector in mesh runtime data. Currently the the flag is only ever set
to false for the "optimal display" feature of the subdivision surface
modifier. When creating an "original" mesh in the main data-base,
the flag is always supposed to be true.
The bit vector is now created by the modifier only as necessary, and
is cleared for topology-changing operations. This fixes incorrect
interpolation of the flag as noted in #104376. Generally it isn't
possible to interpolate it through topology-changing operations.
After this, only the seam status needs to be removed from edges before
we can replace them with the generic `int2` type (or something similar)
and reduce memory usage by 1/3.
Related:
- 10131a6f62
- 145839aa42
In the future `BM_ELEM_DRAW` could be removed as well. Currently it is
used and aliased by other defines in some non-obvious ways though.
Pull Request #104417
Straightforward port. I took the oportunity to remove some C vector
functions (ex: copy_v2_v2).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Straightforward port. I took the oportunity to remove some C vector
functions (ex: `copy_v2_v2`).
This makes some changes to DRWView to accomodate the alignement
requirements of the float4x4 type.
Also minor changes in comments:
- Reference BLENDER_HISTORY_FILE instead of the literal file-name
(simplifies looking up usage).
- Use usernames in tags, as noted in code-style.
When moving or linking an object to a collection, the report was not
properly translatable. In French for instance, it would give
nonsensical half-translated sentences such as "<Object> moved vers
<collection>", instead of "<Object> déplacé vers <collection>".
Instead, separate the report into the four possible translations (one
or multiple objects, linking or moving). This is very verbose and less
legible, but it ensure the sentences can be properly translated,
including plurals in languages which use grammatical agreement.
In addition, use BKE_collection_ui_name_get() to get the collection
name, because the Scene Collection's name is hardcoded, but it can be
localized.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D17112
Add an `object.modifiers.move()` method, similar to the one
for constraints and some other collections. Currently reordering
modifiers requires using operators, which depend on context.
The implementation is straightforward, except for the need to
make the severity of errors reported by the underlying editor
code into a parameter, so that the new Python API function
reports any problems as Python exceptions, and refactoring
the code to allow aborting a blocked move before making any
changes. I also turn the negative index condition from an assert
into an error.
Differential Revision: https://developer.blender.org/D16966
Add:
- ED_object_in_mode_to_index
- ED_object_in_mode_from_index
Useful for operators that act on a non-active object in multi-edit mode,
so the index can be stored for the operators exec function to read back
the value when redoing an action. Needed to resolve T102680.
This was the case when using the operator outside of the modifiers panel.
Caused by {rBeae36be372a6}.
In above commit, `DT_layer_items` shared both `DT_TYPE_MPROPCOL_LOOP` |
`DT_TYPE_MLOOPCOL_LOOP` in a single EnumPropertyItem value "Colors".
This is a bit unusual, but probably allowed.
As a consequence, checks for specific datatypes would fail when selecting
such EnumPropertyItem:
- `DT_DATATYPE_IS_MULTILAYERS` (uses `ELEM` to check distinct entries --
would return false)
- `BKE_object_data_transfer_dttype_to_srcdst_index` (would return
`DT_MULTILAYER_INDEX_INVALID`)
These places have now been corrected to take these "special" values into
account.
Another issue was that multiple EnumPropertyItems with the same value
could be created in dt_add_vcol_layers() if attributes of the same
domain, but different color types are in play (could lead to crashes)
and that has also been corrected.
Also: above commit did not give the choice of transfering color
attributes from the vertex domain (only face corner attributes could be
chosen), this has now been added. DT_layer_vert_items (used from the
modifier) already had this included so this was only an issue when using
the operator outside of the modifiers panel.
Since we now feature two domains, the single "VCOL" in the enum has been
split into "COLOR_VERTEX" and "COLOR_CORNER". This will break existing
scripts calling bpy.ops.object.datalayout_transfer and will be marked as
a breaking change in the release notes.
NOTE: there is another bug here when attributes of the same domain, but
different color types are in play and you want to transfer just a single
specific layer (but that is for a separate commit)
Maniphest Tasks: T103400
Differential Revision: https://developer.blender.org/D16935
These warnings can reveal errors in logic, so quiet them by checking
if the features are enabled before using variables or by assigning
empty strings in some cases.
- Check CMAKE_THREAD_LIBS_INIT is set before use as CMake docs
note that this may be left unset if it's not needed.
- Remove BOOST/OPENVDB/VULKAN references when disable.
- Define INC_SYS even when empty.
- Remove PNG_INC from freetype (not defined anywhere).
Currently you can retrieve a mutable array from a const CustomData.
That makes code unsafe since the compiler can't check for correctness
itself. Fix that by introducing a separate function to retrieve mutable
arrays from CustomData. The new functions have the `_for_write`
suffix that make the code's intention clearer.
Because it makes retrieving write access an explicit step, this change
also makes proper copy-on-write possible for attributes.
Notes:
- The previous "duplicate referenced layer" functions are redundant
with retrieving layers with write access
- The custom data functions that give a specific index only have
`for_write` to simplify the API
Differential Revision: https://developer.blender.org/D14140
An apostrophe should not be used because it is not a mark of plural,
even for initialisms. This involves mostly comments, but a few UI
messages are affected as well.
Differential Revision: https://developer.blender.org/D16749
Currently the `MLoopUV` struct stores UV coordinates and flags related
to editing UV maps in the UV editor. This patch changes the coordinates
to use the generic 2D vector type, and moves the flags into three
separate boolean attributes. This follows the design in T95965, with
the ultimate intention of simplifying code and improving performance.
Importantly, the change allows exporters and renderers to use UVs
"touched" by geometry nodes, which only creates generic attributes.
It also allows geometry nodes to create "proper" UV maps from scratch,
though only with the Store Named Attribute node for now.
The new design considers any 2D vector attribute on the corner domain
to be a UV map. In the future, they might be distinguished from regular
2D vectors with attribute metadata, which may be helpful because they
are often interpolated differently.
Most of the code changes deal with passing around UV BMesh custom data
offsets and tracking the boolean "sublayers". The boolean layers are
use the following prefixes for attribute names: vert selection: `.vs.`,
edge selection: `.es.`, pinning: `.pn.`. Currently these are short to
avoid using up the maximum length of attribute names. To accommodate
for these 4 extra characters, the name length limit is enlarged to 68
bytes, while the maximum user settable name length is still 64 bytes.
Unfortunately Python/RNA API access to the UV flag data becomes slower.
Accessing the boolean layers directly is be better for performance in
general.
Like the other mesh SoA refactors, backward and forward compatibility
aren't affected, and won't be changed until 4.0. We pay for that by
making mesh reading and writing more expensive with conversions.
Resolves T85962
Differential Revision: https://developer.blender.org/D14365
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
Previously you had to use a workaround with the Object info node to get
evaluated data from the new curves object to an original editable mesh.
This commit makes it so that a curves object can be converted directly
to a mesh object if it has evaluated curves or an evaluated mesh.
Differential Revision: https://developer.blender.org/D16930
Move some functions for transforming a span of vectors to a header
and call them from these functions, just like was done for curves
objects recently.
Resolves T102027, T102026
Differential Revision: https://developer.blender.org/D16883
I missed adding the "convert type/domain to mask" macros.
Also refactor slightly to split the matching attribute test to a
separate function to ease debugging and reduce duplication.
Make the "Clear Motion Paths" operators more intuitive. Previously, the
only way to clear the motion path of the selected object/bone would be
to shift-click the "Clear ALL Motion Paths" button. Now there are two
"X" buttons, one for "selected" and one for "all".
The "Clear Selected" and "Clear All" buttons align with the
corresponding "Update Selected" and "Update All" buttons.
Attributes are unifying around a name-based API, and we would like to
be able to move away from CustomData in the future. This patch moves
the identification of active and fallback (render) color attributes
to strings on the mesh from flags on CustomDataLayer. This also
removes some ugliness used to retrieve these attributes and maintain
the active status.
The design is described more here: T98366
The patch keeps forward compatibility working until 4.0 with
the same method as the mesh struct of array refactors (T95965).
The strings are allowed to not correspond to an attribute, to allow
setting the active/default attribute independently of actually filling
its data. When applying a modifier, if the strings don't match an
attribute, they will be removed.
The realize instances / join node and join operator take the names from
the first / active input mesh. While other heuristics may be helpful
(and could be a future improvement), just using the first is simple
and predictable.
Differential Revision: https://developer.blender.org/D15169
If the resulting geometry from applying a geometry nodes modifier
contains no mesh, give an error message. This gives people something to
search and makes the behavior more purposeful.
Also remove the `modifyMesh` implementation from the geometry nodes
modifier, since it isn't necessary anymore. And remove the existing
"Modifier returned error, skipping apply" message which was cryptic
and redundant if applying returns an actual error message.
Resolves T103229
Differential Revision: https://developer.blender.org/D16782
The function was highly related to the apply modifier operator,
and only used once. This was too specific to be in the blenkernel,
especially in a mesh conversion file.
Recently a new geometry node for splitting edges was added in D16399.
However, there was already a similar implementation in mesh.cc that was
mainly used to fake auto smooth support in Cycles by splitting sharp
edges and edges around sharp faces.
While there are still possibilities for optimization in the new code,
the implementation is safer and simpler, multi-threaded, and aligns
better with development plans for caching topology on Mesh and other
recent developments with attributes.
This patch removes the old code and moves the node implementation to
the geometry module so it can be used in editors and RNA. The "free
loop normals" argument is deprecated now, since it was only an internal
optimization exposed for Cycles.
The new mesh `editors` function creates an `IndexMask` of edges to
split by reusing some of the code from the corner normal calculation.
This change will help to simplify the changes in D16530 and T102858.
Differential Revision: https://developer.blender.org/D16732
Improve a few messages, but mostly fix typos in many areas of the UI.
See inline comments in the differential revisiion for the rationale
behind the various changes.
Differential Revision: https://developer.blender.org/D16716
This just replaces the combined usage of OB_MODE_PAINT_GPENCIL
OB_MODE_SCULPT_GPENCIL
OB_MODE_WEIGHT_GPENCIL
OB_MODE_VERTEX_GPENCIL.
Differential Revision: https://developer.blender.org/D16652
Make it more obvious in the name that an operation is not
cheap, and that the function operates on a tracks from
object and does not need a global tracking structure.
As part of T95966, this patch moves loose edge information out of the
flag on each edge and into a new lazily calculated cache in mesh
runtime data. The number of loose edges is also cached, so further
processing can be skipped completely when there are no loose edges.
Previously the `ME_LOOSEEDGE` flag was updated on a "best effort"
basis. In order to be sure that it was correct, you had to be sure
to call `BKE_mesh_calc_edges_loose` first. Now the loose edge tag
is always correct. It also doesn't have to be calculated eagerly
in various places like the screw modifier where the complexity
wasn't worth the theoretical performance benefit.
The patch also adds a function to eagerly set the number of loose
edges to zero to avoid building the cache. This is used by various
primitive nodes, with the goal of improving drawing performance.
This results in a few ms shaved off extracting draw data for some
large meshes in my tests.
In the Python API, `MeshEdge.is_loose` is no longer editable.
No built-in addons set the value anyway. The upside is that
addons can be sure the data is correct based on the mesh.
**Tests**
There is one test failure in the Python OBJ exporter: `export_obj_cube`
that happens because of existing incorrect versioning. Opening the
file in master, all the edges were set to "loose", which is fixed
by this patch.
Differential Revision: https://developer.blender.org/D16504
The calls in the remesh operator were unnecessary because the mesh is
about to be replaced anyway, and nothing invalidates the caches, and
the call in BMesh -> Mesh conversion was unnecessary because the caches
are cleared at the top of the function already.
The issue was introduced by the optimization of hidden objects and modifiers
in the f12f7800c2.
The solution here detects that either an object is hidden or the modifier is
disabled and does special tricks to ensure the dependencies are evaluated.
This is done by constructing a separate minimal dependency graph needed for
the object on which the modifier is being applied on. This minimal dependency
graph will not perform visibility optimization, making it so modifier
dependencies are ensured to be evaluated.
The downside of such approach is that some dependencies which are not needed
for the modifier are still evaluated. There is no currently an easy way to
avoid this. At least not without introducing possible race conditions with
other dependency graphs.
If the performance of applying modifiers in such cases becomes a problem the
possible solution would be to create a temporary object with a single modifier
so that only minimal set of dependencies is pulled in the minimal dependency
graph.
Differential Revision: https://developer.blender.org/D16421
