No functional changes.
Move the following keyframing functions to the animrig folder
* `insert_keyframe_direct`
* `insert_keyframe`
* `delete_keyframe`
* `clear_keyframe`
In order to disentangle the code I had to move the following as well
* `delete_keyframe_fcurve`
* `visualkey_can_use`
* `visualkey_get_values`
In order to sort the functions I made 3 files (and their header counterparts)
* fcurve.cc
* keyframing.cc
* visualkey.cc
The following functions I made public so they won't get duplicated
* `update_autoflags_fcurve_direct`
* `ANIM_setting_get_rna_values`
There are public keyframing functions that
I left in the editors/animation/keyframing.cc file
I'd like to limit the scope of this refactor, and then
clean up the moved functions before moving even more over
Part of #113278
Pull Request: https://projects.blender.org/blender/blender/pulls/113503
This patch immediately realizes the scale and rotation components of
transformations at the point of transform nodes. The translate component is
still delayed and only realized when really needed to avoid clipping.
Transformed results are always realized in an expanded domain that avoids
clipping due to rotation or scaling. The size of the transformed domain is
clipped to the GPU texture size limit for now until we have support for huge
textures, that limit is typically 16k.
A potential optimization is to join all consecutive transform and realize
operations into a single realize operation.
Fixes#112332.
Pull Request: https://projects.blender.org/blender/blender/pulls/112332
The push constant `double_sided` and `Surfel.double_sided` collided. Due
to the macros that the vulkan backend is creating it isn't possible to
use the same attribute name as an existing push constant.
Pull Request: https://projects.blender.org/blender/blender/pulls/113576
The OpenGL extension `GL_ARB_shader_viewport_layer_array` wasn't turned
off when starting blender with `--debug-gpu-force-workarounds`. Although
all known supported platforms support this extension and we haven't seen
any failures with it, it was mentioned to be phased out as we consider
it to be a core extension, which it isn't.
This PR will enable the workaround for this extension and remove the
extension from the phase out list.
Pull Request: https://projects.blender.org/blender/blender/pulls/113572
- Rename Indirect Lighting panel to Light Probe
and split options per probe type.
- Rename Probe to Light Probe in the world panel.
- Move the Ambient Occlusion distance to view
layer.
- Rename the Ambient Occlusion tab to Horizon
Scan (waiting for a better name).
- Split Sampling panel into viewport and render
sub-panels.
- Rename Volumetrics to Volumes to match Cycles.
- Split light threshold to new Lights panel.
- Simplify shadow panel option names.
- Rename Viewport Denoising in Temporal Reprojection.
- Move Motion Blur panel above the film panel.
- Use / instead of & in raytracing panel.
- Fix graying out of raytracing denoise options.
Pull Request: https://projects.blender.org/blender/blender/pulls/113522
I had to do a huge refactor in order to do this.
The way ReflectionProbe were referencing the UBO
data was conflicting with the way EEVEE-Next
object should behave.
So like light, shadow and irradiance grids, every
probe is synced with it's GPU data as base struct
and the data is just copied into the UBO
when using `set_view`.
To simplify many parts of the reflection probe
code, I isolated the atlas coordinate of a probe
to its own struct that can be easily copied.
Pull Request: https://projects.blender.org/blender/blender/pulls/113518
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
Remove the selection attributes on the non-selected domains, since they
will be automatically filled by domain interopolation anyway. Arguably
this should be fixed in a more general way, either by ensuring they are
always on the expected domains or more gracefully handling the case
when they aren't at a lower level. But for this node, for now this is
a simpler approach.
Updated CacheReader_open_usd_object() to issue a warning and
return early if the given object path does not refer to a
valid prim on the USD stage, to avoid crashing when attempting
to create a reader from an invalid prim.
Pull Request: https://projects.blender.org/blender/blender/pulls/113524
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
