Currently object bounds (`object.runtime.bb`) are lazily initialized
when accessed. This access happens from arbitrary threads, and
is unprotected by a mutex. This can cause access to stale data at
best, and crashes at worst. Eager calculation is meant to keep this
working, but it's fragile.
Since e8f4010611, geometry bounds are cached in the geometry
itself, which makes this object-level cache redundant. So, it's clearer
to build the `BoundBox` from those cached bounds and return it by
value, without interacting with the object's cached bounding box.
The code change is is mostly a move from `const BoundBox *` to
`std::optional<BoundBox>`. This is only one step of a larger change
described in #96968. Followup steps would include switching to
a simpler and smaller `Bounds` type, removing redundant object-
level access, and eventually removing `object.runtime.bb`.
Access of bounds from the object for mesh, curves, and point cloud
objects should now be thread-safe. Other object types still lazily
initialize the object `BoundBox` cache since they don't have
a data-level cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/113465
In `makesrna`, generate valid default values for float properties, when those
defaults are positive/negative infinity.
Blender would currently generate the strings `inff` and `-inff`, which are not
valid C++. This PR changes that to `std::numeric_limits<float>::infinity()` and
`-std::numeric_limits<float>::infinity()`.
Context: the layered animation system (see #113594) will have animation layers
with strips on them. It will have the concept of "infinite strips", where from
a user's perspective there aren't even any strips at all, and the layer seems
to directly contain the keys themselves. This is purely a UI distinction
though, where we simply won't draw the outline of infinite strips. Being able
to work with ±∞ as floating point values has clear advantages, as then the
`strip.frame_start` and `strip.frame_end` properties will always "tell the
truth".
This particular change is necessary to allow these values as defaults. It is
not intended that users will have property sliders for these properties when
their value is "infinite" (but rather a button 'make finite' or something along
those lines), so interaction with the UI code will likely be minimal.
Pull Request: https://projects.blender.org/blender/blender/pulls/113854
Changes include:
1. Replace `prop->flag |= PROP_xxx` with
`RNA_def_property_flag(prop, PROP_xxx)`,
use `RNA_def_property_clear_flag` to unset
2. Replace `srna->flag |= STRUCT_xxx` with
`RNA_def_struct_flag(srna, STRUCT_xxx)`,
use `RNA_def_struct_clear_flag` to unset
3. Replace `func->flag |= FUNC_xxx` with
`RNA_def_func_flag(func, FUNC_xxx)`
4. Replace `prop->flag_override |= PROPOVERRIDE_xxx` with
`RNA_def_func_override_flag(prop, PROPOVERRIDE_xxx`
Not changed:
1. Code setting PropertyRNA's `flag_internal` field.
`PropertyFlagIntern` is defined in rna_internal_types.h, while
other flags for PropertyRNA are all defined in RNA_types.hh.
I've tried to define similar flag setting functions for `flag_internal`
(see my commit 5036bd650c in the PR), but build fails with syntax
error. I'm not quite clear about dependencies between the files,
so I keep this part unchanged.
Pull Request: https://projects.blender.org/blender/blender/pulls/113807
In switch-case structure, `PROP_NEVER_NULL` is already set
for String properties. However, the code setting `PROP_EDITABLE`
below was overwriting the flag. Then `PROP_NEVER_NULL` had
to be set for a second time.
Fixed by using proper API function to set these flags, and removed
the redundant second flag setting.
Pull Request: https://projects.blender.org/blender/blender/pulls/113739
This speeds up saving the following production file by about 10%:
`240ms -> 220ms`
`heist/pro/shots/060_fight/060_0080/060_0080.anim.blend`
This is a fairly low hanging fruit. Ideally we wouldn't have to duplicate
the string at all, but changing that is a larger undertaking.
No functional changes
Make the code more readable by doing the following
* rename `BKE_keyingset_free` to `BKE_keyingset_free_paths` since that is what it does
* invert `if` and return early to reduce indentation
* add enum value `MODIFYKEY_SUCCESS` to explicitly state the return value, instead of eModifyKey_Returns(0)
* return `INSERTKEY_NOFLAGS` instead of eInsertKeyFlags(0)
* move variables closer to their usage
Pull Request: https://projects.blender.org/blender/blender/pulls/113666
Regression caused by [0]. Resolve by adding a 'keep_properties' argument
to KeyConfig.update so the key-map items can be restored after the
operators have been reloaded.
[0]: 88a875ec3a
Regression caused by [0]. Resolve by adding a 'keep_properties' argument
to KeyConfig.update so the key-map items can be restored after the
operators have been reloaded.
[0]: 88a875ec3a
Continue allowing spacebar search for all dropdown and context menus,
but also add the ability to allow some menus to have type to search,
like Add Modifiers, Objects, Nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113520
In order to recreate the behavior of some builtin nodes
which have implicit inputs for ID/Index or positions, provide
a hard-coded list of default/unconnected fields for sockets.
The point is to let assets recreate the behavior of builtin
nodes in a simple way that's easy to change in the future if
this becomes a more generalized feature. A hardcoded list
makes this predictable and simple in the meantime.
When the option is set to something besides "Default Value"
it overrides the "Hide Value" option. Otherwise the default
input would conflict with the visible default value button.
This makes it possible to add #109846 as an asset in the
essentials bundle. The design is meant to be easily
extendable for shader nodes, though that isn't included
in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/113175
We had a short discussion on this change. "Grease Pencil Layer" is
just a bit too long, especially in the UI. Even though "Layer" might be
ambiguous, it shouldn't be in the context of geometry nodes. There are
currently no other "Layers" and if there were, using the same domain
name could be fine (just like we reuse the point domain for e.g. vertices
in meshes and control points in curves).
This also renames the internal enum to `ATTR_DOMAIN_LAYER`
Pull Request: https://projects.blender.org/blender/blender/pulls/113589
Update to the new naming convention for `Light Probes`:
`Reflection Cubemap` -> `Sphere`
`Reflection Plane` -> `Plane`
`Irradiance Grid` -> `Volume`
Note that this breaks the Python API (`bpy.types.LightProbe.type`).
Pull Request: https://projects.blender.org/blender/blender/pulls/113452
Caused by 6a49041be3 .
Above commit checks an existing nameproperty for collection items, but
it does so in a way that it only checks the "parent" type. If these are
"subclassed" though, we might not have the nameproperty defined on the
"parent" class (but on the subclass instead).
Code would then error out with e.g. "FreestyleLineStyle.color_modifiers
does not support string lookups".
In the case of the report the following happened.
- linestyle modifiers (`LineStyleModifier`) can be any of:
-- `color_modifiers` / `LineStyleColorModifier`
-- `alpha_modifiers` / `LineStyleAlphaModifier`
-- `thickness_modifiers` / `LineStyleThicknessModifier`
-- `geometry_modifiers` / `LineStyleGeometryModifier`
But all of the above have subtypes, e.g.
`LineStyleColorModifier_AlongStroke`,
`LineStyleColorModifier_DistanceFromCamera`, ...
Currently, the `nameproperty` is not defined e.g. on the
`LineStyleColorModifier` (but instead on the subtypes).
Prior to 6a49041be3 (without
`RNA_property_collection_lookup_string_has_nameprop` in place),
`pyrna_prop_collection_subscript_str` could still actually find the
nameprop because it iterates into the collection and got it on the
actual Item (`LineStyleColorModifier_DistanceFromCamera` instead of
`LineStyleColorModifier`).
So while it might be possible to refine
`RNA_property_collection_lookup_string_has_nameprop` to descend into
subclasses (I didnt find an obvious way though other than scanning all
existing modifiers [not modifier types -- we would need a way to find
all types that inherit from e.g. `LineStyleColorModifier`] which kind of
defeats the purpose of checking this early), this PR moves the name
definition from the subclass to the parent class (so way from
`rna_def_modifier_type_common`) -- and this way,
`RNA_property_collection_lookup_string_has_nameprop` can properly pick
up the nameprop. It does a bit of code duplication though.
Pull Request: https://projects.blender.org/blender/blender/pulls/113290
Making some liboverride local will break/corrupt liboverride hierarchies
in many cases. So that function (or its caller, in some cases) need to
call #BKE_lib_override_library_main_hierarchy_root_ensure to re-validate
(and re-generate if needed) the liboverride hierarchy roots.
This implements the core changes for this design: https://devtalk.blender.org/t/grease-pencil-integration-into-geometry-nodes/31220
The changes include:
* Add `CustomData` for layer attributes
* Add attribute support for the `GreasePencilComponent` to read/write layer attributes. Also introduces a `Layer` domain.
* Implement a `GreasePencilLayerFieldContext` and make `GeometryFieldContext` work with grease pencil layers.
* Implement `Set Position` node for `Grease Pencil`.
Note: These changes are only accessible/visible with the `Grease Pencil 3.0` experimental flag enabled.
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/112535
This PR reuses the scene specific reflection probe resolution for all
reflection light probes in the scene. The target is to have a automatic
detection for the resolution. But as long as we don't have a mechanism
for detection it is better to not introduce a new UI element that will
be removed within the foreseen future.
This setting is currently used by EEVEE and EEVEE-Next. EEVEE supports
resolutions upto 4096px. This will be clamped to 2048 when using
EEVEE-Next.
The motivation for this is that EEVEE-Next will soon replace
EEVEE and 4096 can then be removed from the choices that the user can
made. Adding as separate option could need synchronization, and that
option would also be temporary as it will be removed by the resolution
detection mechanism.
Pull Request: https://projects.blender.org/blender/blender/pulls/113491
This PR is contains the initial capture pipeline for planar probes.
It requires work to generate the correct view to capture and to include
the result during ray tracing. These will be developed in a separate PR.
This PR detects if a planar probe is active in the scene. If this is
the case the planar probe pipeline will be activated. During rendering
this is done by querying the depsgraph, during viewport drawing this
is done during sync. If an planar probe is detected and the pipeline
wasn't activated. The pipeline will be activated and the sampling
will be reset to ensure the pipeline is filled with all objects.
Per object the user can set the visibility of the object in planar
reflections.
For a reflection plane the resolution and clipping offset can be set.
EDIT: Resolution option was removed because too complex to
implement with the little time we have at the moment.
Related to #112966
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/113203
