The internal API call to refresh remote data wasn't returning
the resulting data, making it inconvenient to refresh & access
remote meta-data from a single repository.
- Fix an unhandled exception listing a repository with no remote data.
- Exclude dot-files from being listed when generating a repository.
- Fix missing import (in an unlikely corner case) when accessing
tags before the repository data was initialized.
- Fix refresh refreshing the remote not updating the
internal remote meta-data.
- Suppress warnings in tests caused by default repositories
(now removed before resting).
Allow assigning integer values beyond int32 range to float/double
IDProperties. Extract the py object value into a temporary int64 value
in these cases.
These two lights have a second culling pass that
uses some shapes defined in view space.
These shapes need to have their handedness flipped
otherwise the test fails.
Fix#122614
Conceptually, these are the same as IDProps used for regular dynamic RNA
data (should have been done that way from the beginning). At least make
them statically typed, to avoid all kind of issues when the IDProp type
change and does not match expectations from the geometry nodes anymore.
Ref. #122743.
Pull Request: https://projects.blender.org/blender/blender/pulls/122891
All IDProperties generated as part of 'storage backend' for dynamic RNA
properties are now statically typed.
Also adds some basic unittests for the new statically typed IDProperty
system, based on py-defined RNA data.
Ref. #122743.
This implements (most of) the proposal in #122743:
* Add a new `IDP_FLAG_STATIC_TYPE` IDProperty flag.
* Update `BPy_IDProperty_Map_ValidateAndCreate` and related to never
change an existing property type if statically typed.
The biggest change happens in bpy assignement code, since instead of
replacing the old exisitng property by a newly created one, and copying
over a few settings, now the old property is kept if possible, and a new
one is only created if needed.
And in case the existing property is statically typed, if it cannot be
re-used to store the given value, and error is reported and it remains
unchanged.
`IDP_ARRAY` is also supported for basic numeric types, so 'vector'
properties and such work as expected. Lentgh is considered as part of
the static type (i.e. one can only assign a 3 components py sequence to
a 3-len array property, etc.).
Such in-place update is not yet implemented for `IDP_IDPARRAY` and
`IDP_GROUP` types. While important (especially the group one), they are
not that critical for the current issues related to changing IDProperty
types.
Variable `leftColor` is added to global variable `overlay_edit_smooth_color_iface` in current version.
In result it is added to every following shader using `overlay_edit_smooth_color_iface`.
Pull Request: https://projects.blender.org/blender/blender/pulls/122803
The hidden socket in the Viewer is not shown when a new link to it is created.
This is because the hidden property of the socket is not updated when a new
link to it is created.
Fixing it by simply manually update the property after a new link is created.
Pull Request: https://projects.blender.org/blender/blender/pulls/120503
This could happen for non manifold meshes (like a water plane)
when using the accurate method.
If last hit in the volume ray is a frontface, we now consider
everything behind it in volume.
I didn't think the BMesh extraction mode could arrive at the case where
only loose edges are requested, but turns out it can because of the
mesh wrapper system where the evaluated mesh is actually a BMesh with
deformed positions.
`num_distribution` in `KernelIntegrator` has type `int`, which holds a
maximal value of 2147483647. However, when computing the distribution,
`size_t` is used, which can go beyond this value and result in a
negative value when converted to `int`.
This PR handles this case as an error, stops rendering and suggests
alternative solutions.
Also early return when `use_light_tree`. The block was there because
`num_distribution` was needed for light tree before bfd1836861.
Pull Request: https://projects.blender.org/blender/blender/pulls/123177
Related to #119999 and #122059.
In case the _source_ PropertyRNA was unset (i.e. its underlying
IDProperty storage did not exist), the copy operation would silently
fail.
In fact, the existing code handling IDProperties separately in
`RNA_property_copy` was pretty bad, since it would also bypass all the
RNA 'setting value' code (like custom setters, update handling).
Turns out, liboverride RNA apply code can already handle all of these
cases, so simply pass the raw 'unresolved' RNA property to it, and
remove all this special handling code from `RNA_property_copy`, solves
all the issues.
Reorder `Action::assign_id()` so that there is a clear "unassign any
previously-assigned binding" step first, and then a clear "assign the new
binding" step. Previously these were a bit too much intertwined.
Also `animrig::unassign_binding()` now simply calls into `Action::assign_id()`
instead of having somewhat overlapping responsibilities.
Finally the RNA setter for `AnimData.action_binding_handle` is changed
to always call `Action::assign_id()` for both assigning and unassigning
the handle. This ensures the API is properly used, instead of modifying
properties directly.
Pull Request: https://projects.blender.org/blender/blender/pulls/123184
Make `Binding.name` the 'RNA name property' of Action Bindings. This
ensures that the name property is unique (within the Action), and also
used for `action.bindings.keys()` and `action.bindings['BindingName']`.
The issue was that when applying the keyingsets
`Whole Character` and `LocRotScale & Custom Properties` the
enum property of a rigify rig was not keyed.
The reason it was not keyed was just because
it was not specified in the compatible types in the keying set.
The fix is to just add `bpy.types.EnumProperty` to the list.
Pull Request: https://projects.blender.org/blender/blender/pulls/122377
