The data transfer code stored values not in the `eCustomDataType`
enum in this variable, so the type was incorrect. Instead use a cast
when we expect the value to be a valid enum value.
Face maps were added as a prototype of a new rigging solution during
2.8 development. Their storage is redundant with the newer generic
attribute system (specifically with integer face attributes), and
they were never used much. This commit removes the face map list
and converts the storage to an attribute with the name `face_maps`.
There is nowhere to store the face map names anymore, so those
are not kept.
It probably still makes sense to have a feature like mesh face gizmo
selection for rigging. But the design and implementation woulds likely
have to change significantly, including possibly changing the storage
type, and making use of the generic attribute system instead of a
special type.
See #105317 for more discussion.
Fixes#108730
The call to `CustomData_interp` also interpolated the face corner
topology attributes, which broke the mesh completely. To fix this,
avoid relying on the CustomData API and move the attribute
interpolation to use the attribute API instead. This change also
makes it trivial to support all attribute types in the future.
Also, only retrieve the closest vertex once, instead of doing it
again for every attribute. Combined with building the topology
maps in parallel this approximately doubled the performance
of color attribute propagation in a test with 2 million vertices
and 8 color attributes on both domains (63 to 34 ms).
Pull Request: https://projects.blender.org/blender/blender/pulls/108773
This implements the `VIEW3D_OT_select_box` for the new grease pencil data-block.
Note that this also adds a `get_evaluated_grease_pencil_drawing_deformation` function, but there are TODOs left.
This will have to be updated once the modifier logic is in place.
Pull Request: https://projects.blender.org/blender/blender/pulls/108661
Asset data can now be copied in Python via assignment to
`id.asset_data`, so for example `dest.asset_data = source.asset_data`.
This copies the description, license, author, etc. fields, as well as
the tags and the asset catalog assignment.
This is intended to be used in the pose library, when updating a pose by
simply creating a new asset and having that replace the old one.
This is intentionally taking a copy, even though the above use case
could have sufficed with a higher-level 'move' function. By exposing
this as a copy, it can be used in a wider range of situations, from
whatever Python code wants to use it. This could include copying the
asset data from the active asset to all the other selected ones.
Any pre-existing asset data is freed before the copy is assigned. The
target ID MUST be marked as asset already for the assignment to work.
Assigning `None` to clear the asset status is not allowed. Instead
`.asset_mark()` resp. `.asset_clear()` should be used. This limitation
is in place to simplify the API, and to ensure that there is only one
way in which assets are marked/cleared, making it easier to change the
internals of the asset system without API changes.
Example code:
```python
src = bpy.data.objects['Suzanne']
dst = bpy.data.objects['Cube']
dst.asset_mark()
dst.asset_data = src.asset_data
```
Pull Request: https://projects.blender.org/blender/blender/pulls/108547
This patch implements the Movie Distortion node for the realtime
compositor. The distorted coordinates are computed and cached for a
particular tracking camera distortion parameters. So for expensive
distortion models, the first run will take some time to compute, but
subsequent runs will be fast.
An alternative implementation would be to implement each of the
distortion modes in the shader, but that was decided against for a few
reasons:
1. We want to hide the implementation details of the distortion models,
since it is provided through an external library (Libmv).
2. Some distortion models are expensive to solve accurately, and can be
quite slow to solve each time the shader runs.
3. The typical usage of the node does not involve interactive editing of
the distortion parameters, rather, the parameters are computed during
camera calibration, so caching seems most fitting in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/108230
* Provide render data, node tree and color management directly instead
of going through scene, as these may be modified by the render pipeline.
Also better for cached texture hits this way.
* Change legacy pass type to pass name.
* Skip file output node when not doing final render.
* Gracefully handle incomplete render results.
Pull Request: https://projects.blender.org/blender/blender/pulls/108629
Double underscores didn't communicate that this was deprecated,
and are typically for internal or platform defined identifiers and
shouldn't be used for public API's.
References to data-blocks in a material were stored in-memory and could
crash if the data-blocks referenced by the material no longer existed
when pasting.
Resolve by using a blend-file for material copy/paste, matching how the
clipboard works in the 3D view-port.
Currently there is no support for including indirectly linked
data-blocks when pasting the material. Instead, data-blocks are restored
by name, by inspecting the current file.
This also fixes a crash where the `SpaceNode::nodetree` could point to
freed memory when pasting a material.
Ref !108496.
Includes contributions by @mont29.
---
Fix back-ported to main [0], including fix [1].
[0]: 5177e2f20b
[1]: 64aa96d421
`hair_out_mesh` and `hair_in_mesh` implicitly share edges.
In `hair_create_input_mesh()`, edge data of `hair_in_mesh` needs to be
updated and therefore are copied to a new location. In the subsequent
frames, `psys->clmd->clothObject->edges` won't be updated and point to
freed memory block. Therefore, Blender crashes.
By freeing `hair_out_mesh` first,
1. in `hair_create_input_mesh(),` at least edge data copying is avoided
2. `psys->clmd->clothObject->edges` always points to correct memory
However, since it's possible that similar situation will happen again
by adding another strong user to the same `CustomData` in the future,
it is safer to update `psys->clmd->clothObject->edges` for every frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/108480
The "Fill" message can be either a noun or a verb. This commit
disambiguates the verb usages for translation through various
translation contexts.
The more involved change is in the generation of keymaps from paint
modes. By default, the enums defining brush names are in the default
context, but this commit changes the ones including a "Fill" item to
"Brush". In order to get the same contexts in the keymap, we introduce
a specific function in `paint.cc` to return the appropriate context
depending on the tool.
Issue reported by Gabriel Gazzán (@GabrielGazzan) in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/108561
Fixes armature deformation bug when Preserve Volume is enabled and deforming bones are both rotated and scaled.
The bug happens because Preserve Volume uses Quaternion to interpolate rotations. A bone has 3 parts of data describing its deformation: Quaternion(w,x,y,z) rotation (`quat`), Translation(w,x,y,z) (`trans`), and Scaling(4x4 matrix) (`scale`). To calculate deformed position of a vertex `r`, it will be firstly scaled by `scale`, then rotated and translated by `quat & trans`.
The 4x4 scaling matrix `scale` has a 3x3 part `S33` about scaling and shearing along 3 axes, and a vector part `ST3` that further translate the scaled position. i.e. `scale@r = S33@r + ST3`. This enables scaling about an arbitrary "pivot" (a point `r0` satisfies `scale@r0 = r0`).
However, when blending influence of multiple bones, different bones have different scaling pivot (their head position). Since quaternion rotation and translation/scaling are not commutative operations, this is what I believe causing this bug.
How this is fixed:
Note that the translational part `ST3` of the scaling matrix is redundant in functionality with Translational part `trans` in deformation data. There exists an equivalence transformation that simultaneously change `trans` and `ST3`, while keeping the deformation unchanged.
I applied this equivalence transformation to move the pivot to the vertex that the bones are deforming, before blending multiple bone transformations. Note that now the vertex is the pivot, so scaling transformations will not change its position. Further blending/applying of scaling matrices can be avoided.
Pull Request: https://projects.blender.org/blender/blender/pulls/108134
Code was plainfully buggy, early-out check in
`BKE_undosys_stack_limit_steps_and_memory` was plainfully wrong.
Also added some more logging for memory limiting code.
This commit affects:
* Reading undo steps from memfile (aka 'Global Undo');
* Handling of UI IDs (WindowManager, Workspaces and Screens) when
opening a .blend file.
While no major changes are expected from a user PoV, there may be some
unexpected changes in rare edge-cases. None has been identified so far.
Undo step loading should be marginally faster (`setup_app_data` itself
is 2-3 times faster, as it does not do remapping anymore, which makes the
whole 'read undo step' process about 20% faster - but the most
time-consuming step on undo is the depsgraph processing, which remains
unchanged here).
This commit also solves some bugs (crashes) in some relatively uncommon
cases, like e.g. if the WM had an IDProperty pointing at an object and
UI is not loaded when opening a new .blend file with the 'Load UI' option
enabled (as in previous code on file opening WM ID would never be
remapped).
From a more technical side, this commit aims mainly at cleaning things
up, in preparation for the introduction of new 'no undo, no readfile'
type of handling (as part of the Brush Assets project):
- Prevent WM code from doing (too much) horrible ID 'management' on
its WM when opening a new file. It used to remove current WM from
the Main database, store it in a temporary own list, and then free
it itself...
- Trying to make the complex logic behind WM handling on file reading a
bit more easy to follow, at least way more documented in code.
- Keep the handling of 'IDs being re-used from old Main' in a single
place, as much as possible:
-- Readfile code itself in undo case (because it's more efficient,
and undo case is in a way simpler than actual .blend file
reading case). The whole `blo_lib_link_restore` block of code
is also removed.
-- (Mostly) setup_app_data code in actual file reading case.
- Sanitize the usage of the 'libmap' in readfile code in undo case
(waaaaay too many pointers were added there, which was hiding some
other issues in the related code, and potentially causing (in
rare cases) memory addresses collisions.
Pull Request: https://projects.blender.org/blender/blender/pulls/108016
