Helps identify the active mesh/armature data, useful for instances or
when dealing with multiple data-blocks per object, as in the Keymesh
add-on.
More details and screenshots in the pull request.
Pull Request: https://projects.blender.org/blender/blender/pulls/133403
The general idea is to store an array of (type, data) pointers of all
PointerRNA ancestors of the current one.
This will help solving cases in our code where the owner (or sometimes
even the owner of the owner) of a random PointerRNA needs to be
accessed. Current solution mainly relies on linear search from the owner
ID, which is sub-optimal at best, and may not even be possible in case a
same data is shared between different owners.
This lead to refactoring quite a bit of existing PointerRNA creation code.
At a high level (i.e. expected usages outside of RNA internals):
* Add `RNA_pointer_create_with_parent` and
`RNA_pointer_create_id_subdata` to create RNA pointers with
ancestors info.
* `RNA_id_pointer_create` and `RNA_main_pointer_create` remain
unchanged, as they should never have ancestors currently.
* Add `RNA_pointer_create_from_ancestor` to re-create a RNA pointer
from the nth ancestor of another PointerRNA.
* Add basic python API to access this new ancestors data.
* Update internal RNA/bpy code to handle ancestors generation in most
common generic cases.
- The most verbose change here is for collection code, as the owner of the
collection property is now passed around, to allow collection items to get
a valid ancestors chain.
Internally:
* `PointerRNA` now has an array of `AncestorPointerRNA` data to store
the ancestors.
* `PointerRNA` now has constructors that take care of setting its data for
most usual cases, including handling of the ancestor array data.
* Pointer type refining has been fully factorized into a small utils,
`rna_pointer_refine`, that is now used from all code doing that operation.
* `rna_pointer_inherit_refine` has been replaced by
`rna_pointer_create_with_ancestors` as the core function taking care of
creating pointers with valid ancestors info.
- Its usage outside of `rna_access` has been essentially reduced to custom
collection lookup callbacks.
Implements #122431.
--------------
Some notes:
* The goal of this commit is _not_ to fully cover all cases creating
PointerRNA that should also store the ancestors' chain info. It only
tackles the most generic code paths (in bpyrna and RNA itself mainly).
The remaining 'missing cases' can be tackle later, as needs be.
* Performances seem to be only marginally affected currently.
* Currently `AncestorPointerRNA` only stores PointerRNA-like data.
This will help `StructPathFunc` callbacks to more efficiently generate
an RNA paths when calling e.g. `RNA_path_from_ID_to_property`, but will
not be enough info to build these paths without these callbacks. And some
cases may still remain fuzzy. We'd have to add thinks like a `PropertyRNA`
pointer, and for RNA collection ones, an index and string identifier, to store
a complete unambiguous 'RNA path' info. This is probably not needed, nor
worth the extra processing and memory footprint, for now.
Pull Request: https://projects.blender.org/blender/blender/pulls/122427
Previous approach was using non-evaluated meshes to find the closest edge from a face index retrieved from the selection buffer.
This can fail though if the mesh is deformed or even altered to not have the same indices anymore (e.g. generating/masking modifiers).
In order to make this work, added `ED_mesh_pick_edge` which switches the selection context to edges directly
and picks from those. No need to map anything back and forth between original and evaluated, the selection buffer contains the original indices already.
Further logic (following the face loop) is untouched (and happens on the original geometry which is fine)
Should go into 4.2 LTS as well
Pull Request: https://projects.blender.org/blender/blender/pulls/132803
The changes from 29356e2bf7
fixed a readability issue with loose wire not being as prominent as
regular surface wireframe.
But also added a regression where the object color wireframe mode
made the object color imperceivable when the object is selected.
This commit fixes the issue by setting the facing factor to 0.5 for
loose wires. This way, both the theme color and object color wireframe
more are blended enough to be distinguishable and still retain the
object color hint.
The issue was that the code did not handle input sockets that are fields
implicitly correctly. It just retrieved a single from them, instead of
treating them as having an unknown value.
Use sub-pixel differentials for bump mapping helps with reducing
artifacts when objects are moving or when textures have high frequency
details.
Currently we scale it by 0.1 because it seems to work good in practice,
we can adjust the value in the future if it turns out to be impractical.
Ref: #122892
Pull Request: https://projects.blender.org/blender/blender/pulls/133991
- Rename dx/dy -> dfdx/dfdy to match the actual computed quantity
- Add template functions to compute dfdx/dfdy on triangles for sharing
among different data types
- Add documentation to some functions
- Some code shuffling that makes it easier to scale dfdx/dfdy in the
future
- Some other trivial changes
Partial fix for #130007.
The catalog tree mutex would be set in `catalog_tree()` and
`invalidate_catalog_tree()`. The former could end up adding catalogs and thus
calling `invalidate_catalog_tree()`, which would attempt to set a mutex that the
caller set already. This seems like a good use-case for `std::recursive_mutex`.
would make sure there's a catalog for each catalog path by calling
`create_missing_catalogs()`
Partial fix for #130007.
The catalog tree mutex would be set in `catalog_tree()` and
`invalidate_catalog_tree()`. The former could end up adding catalogs and thus
calling `invalidate_catalog_tree()`, which would attempt to set a mutex that the
caller set already. This seems like a good use-case for `std::recursive_mutex`.
would make sure there's a catalog for each catalog path by calling
`create_missing_catalogs()`
Logic to ensure finish events were sent wasn't working properly
because processing the events could run before the SPNAV API had
filled the event queue.
Resolve by adding a delay of 100ms, before generating a "finish" event.
For the user this caused the NDOF Guide to flicker while navigating.
The compositor crashes when the user goes into a muted group that has a
viewer node while the backdrop is enabled. The compositor should not
schedule viewer nodes inside muted contexts, so we need to add checks to
prevent this.
Pull Request: https://projects.blender.org/blender/blender/pulls/134093
When active node is clicked again, the image editor does not update and
keeps showing the old image. Always run `ED_space_image_sync`, when
clicked node is image texture node to resolve this issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/133956
`compositor_is_in_use` sets `used_by_compositor` true when GPU device is
selected. This draws render pass warning even when viewport
compositor is disabled. Remove the condition to fix the unintentional
warning. Following function is just used in node drawing, seems safe to
remove then.
Pull Request: https://projects.blender.org/blender/blender/pulls/133753
What is (or isnt) supported here depends on object types (but we were
getting most of the options for all object types):
| **obtype** | **supports Armature modifier** | **supports vertex groups** | **supports envelopes** | **supports automatic weights** |
| -- | -- | -- | -- | -- |
| OB_MESH | yes | yes | yes | yes |
| OB_CURVES_LEGACY | yes | no | yes | no |
| OB_CURVES | no | no | no | no |
| OB_SURF | yes | no | yes | no |
| OB_MBALL | no | no | no | no |
| OB_FONT | yes | no | yes | no |
| OB_VOLUME | no | no | no | no |
| OB_GREASE_PENCIL | yes | yes | yes | yes |
| OB_LATTICE | yes | yes (broken though) | yes | no |
| OB_EMPTY | no | no | no | no |
| OB_SPEAKER | no | no | no | no |
| OB_LIGHTPROBE | no | no | no | no |
| OB_LAMP | no | no | no | no |
| OB_ARMATURE | no | no | no | no |
| OB_POINTCLOUD | no | no | no | no |
This PR does two things:
- tidy up the popup menu we get for parenting (removing non-funtional
options)
- enable "With Empty Groups" for lattices (no reason why this should not
work)
What this PR does not touch:
- the poll function for parenting (since this acts on selected objects,
checking all of them can be a costly operation which should not be part
of a poll function)
Pull Request: https://projects.blender.org/blender/blender/pulls/134037
- Add `type[]` for the `tool_cls` as it's expecting tool type class,
not the instance (similar to #132420)
- Add `set[str]` to `after` type as it's seems to be the way it's used
the most widely, e.g. in "UI Tool Simple" example that comes with Blender:
`bpy.utils.register_tool(MyTool, after={"builtin.scale_cage"}, separator=True, group=True)`
Pull Request: https://projects.blender.org/blender/blender/pulls/133975
Replace ED_view3d_calc_zfac with a matrix multiply because the "zfac"
is never negative and near zero values are set to 1.0.
This makes sense for tools & viewport logic that use the value for
division and don't handle negative values but not for depth comparison.
- Expand on the code-comment regarding tests & WM_capabilities_flag and
move it from the caller into the functions body since this is useful
for other callers, also mention in the doc-string.
- Use a common prefix for `WM_window_decoration_style_*` functions.
- Add a doxy-section for decoration style functions.
With the transition from 4.4 Alpha to 4.4 Beta and 4.5 Alpha, a few
small changes could be made to the "list of bug fixes per release" tool
to make it more reliable:
- 4.5 is added to the list so it can detect reports made from
Blender 4.5.
- Update the example usage to of the script to be the exact arguments
triagers should use for 4.4 Beta and 4.5 Alpha so triagers just need to
copy and paste the arguments to the command line.
With 4.4 Beta and 4.5 Alpha, small updates to the "list of bug fixes
per release" tool could be made to make the script.
