When autokeying a property with a driver, the code added
the keyframe into the drivers FCurve.
Judging by the code the intention was to be able to quickly
set up driven keys by modifying the driven value and have that
reflected in the driver curve.
However that idea was blocked by the fact that you can't actually
change the value of a property that is driven.
In addition to that it's quite unexpected and the result is hardly
communicated to the user.
The solution is to not insert keyframes to drivers using the
autokeying system.
Also Fixes#95866
This was discussed in the A&R module meeting
https://devtalk.blender.org/t/2024-01-11-animation-rigging-module-meeting/32888#patch-review-decision-time-5
and the consensus was the feature to set up driven keys would be great,
but since it's not working at all currently it's better to get rid of the bugs.
Pull Request: https://projects.blender.org/blender/blender/pulls/116927
In particular, while Object (un)linking was already tagged in relevant
BKE code, collection (un)linking was not in several cases.
This was (partially) done by user code, though almost never for the
whole hierarchy of parents.
Technically, the tag is done as part of
`collection_object_cache_free_parent_recursive`/`collection_object_cache_free`,
since currently clearing this cache is done everytime to collection
hierarchy or their content is modified.
It also removes `collection_tag_update_parent_recursive`, which was
already doing something similar, but was only called from code
adding/removing objects to collections, and was walking the same parent
hierarchy as `collection_object_cache_free_parent_recursive`.
This commit implements the decision made in #116601, to tag modified
data as close as possible from the code modifying it.
---------------------
This has an impact on deg tagging, which takes over twice as much cycles
with this commit compared to previous code when opening a Pets production
file with several liboverrides (`deggraph_id_tag_update_single_flag` goes
from less than 0.03% to over 0.06%).
The overhead remains extremely low though, and is totally unmeasurable in
global execution timing. Timing of the liboverride processing on opening
the production file also did not show any measurable differences.
Pull Request: https://projects.blender.org/blender/blender/pulls/116986
After defaulting to the Python binary from the precompiled libraries,
what could happen was that an older Python lib folder stuck around because
of pycache files, but there was no actual working Python binary for that
version.
Check for the existence of the binary instead of the lib files to solve it.
Also allow Python 3.10 binary for make update.
The PROP_RAW_BOOLEAN raw type exists, but was only used as a fallback in
bpy_rna.cc#foreach_getset to help construct an input RawArray for
PROP_BOOLEAN properties without raw access.
Using the PROP_RAW_BOOLEAN raw type for PROP_BOOLEAN properties where
possible will make it so that almost all PROP_BOOLEAN properties are
considered compatible with bool buffers in bpy_rna.cc#foreach_getset,
which should simplify efficient access to bool properties of collection
items with bpy_rna.cc#foreach_getset.
Only about 50 PROP_BOOLEAN properties have raw access because most
either don't use #RNA_def_property_boolean_sdna or use a bitmask, which
disables raw access. Even fewer of these properties belong to a
StructRNA used by a collection property with raw access.
PROP_BOOLEAN properties with raw access, but which use a type larger
than a single byte are rarer still, and will remain using their existing
raw type because they cannot have raw access as bool.
Pull Request: https://projects.blender.org/blender/blender/pulls/116673
In the end it was a dummy mistake in own 94e6ab6d71 refactor, which
broke the 'restore on undo' case for ID pointers when the old and new
pointers remain exactly the same.
Many thanks to Campbell (@ideasman42) for investigating and identifying
the actual issue.
Can be convenient to do this from python (e.g. afaict, these preferences
are not used from Application Templates userpref.blend, but could now at
least be configured via the template script __init__.py)
Pull Request: https://projects.blender.org/blender/blender/pulls/116381
Reason is that `.handle_free` and `.handle_sel_free` are never really
defined as RGBA defaults in `U_theme_default` `.space_image` (nor
`.space_clip` and `.space_graph` ) with full alpha (as opposed to the
other handle types).
If we read these with `immUniformThemeColor` then we are ending up with
with zero alpha.
So in the Image Editor or Movie Clip Editor, we only see the grey
"Outline" (if the mask display is set to this - which is by default),
the handles themselves are in visible, making it look like those were
always drawn in grey and the Preference would have no effect.
We also dont really have a preference color defined for free handles
(they are set to black).
So there are two possible solutions:
- [1] come up with a good color, define as RGBA default in
`U_theme_default` and overwrite user Preferences in `do_versions_theme`
(with a version bump)
- [2] read existing Preferences with `immUniformThemeColor3` (instead of
`immUniformThemeColor`) to work around the alpha problem
This patch uses the second (and less disruptive) solution.
Pull Request: https://projects.blender.org/blender/blender/pulls/116898
No functional changes.
Clean up the code by:
* renaming variable `ks` to `keyingset`
* renaming variable `ksi` to `keyingset_info`
* renaming variable `ksp` to `keyingset_path`
* moving variables closer to where they are used
* making variables const if possible
* use `LISTBASE_FOREACH_MUTABLE` where applicable
* Fix comment style
* Remove comments that provide no extra information
Pull Request: https://projects.blender.org/blender/blender/pulls/117062
This PR adds support for specialization constants for the OpenGL
backend. The minimum OpenGL version we are targetting doesn't
have native support for specialization constants. We simulate this
by keeping track of shader programs for each set of specialization
constants that are being used.
Specialization constants can be used to reduce shader complexity
and improve performance as less registry and/or spilling is done.
This requires the ability to recompile GLShaders. In order to do this
we need to keep track of the sources that are used when the shader
was compiled. For static sources we only store references
(`GLSource::source_ref`), for dynamically generated sources we keep
a copy of the source (`GLSource::source`).
When recompiling the shader GLSL source-code is generated for the
constants stored in `Shader::constants`. When compiling the previous
GLSource that contains specialization constants is then replaced
by the new version.
Pull Request: https://projects.blender.org/blender/blender/pulls/116926
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Translation of the UI is currently split into 3 preferences:
interface, tooltips, and new data. The distinction between interface
and tooltips is currently unclear as tooltips also include a lot of
messages not displayed in the actual tooltips on mouse hover.
These include reports to the Info Editor, information in editor
headers and footers, and statuses in panels.
In order to limit the use of `TIP_()` to actual tooltips, this commit
introduces a new preference for this extra information: "Reports".
New translation macros are introduced: `RPT_()` and `CTX_RPT_()`, as
well as their equivalent for the Python API, `pgettext_rpt_()`, to be
imported as `rpt_()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
This patch implements the Vector Blur node for the Realtime Compositor.
The implementation is a direct and mostly identical port of the EEVEE
motion blur implementation with the necessary adjustments to make it
work with the compositor.
The exposed parameters in the node does not match those exposed in
EEVEE, so only the parameters shared between both are currently
implemented. In the future, we should make a decision to either unify
both, or just consider them independent implementations, with the
possibility of sharing the full or part of the code.
Further, it would also make sense to port the implementation to the CPU
compositor, since the new implementation is higher in quality while also
being faster.
The default value of the node shutter setting was changed to 0.25 to
approximately match the default settings of EEVEE and Cycles, since in
their default settings, they evaluate the previous and next frames at
plus and minus 0.25.
Pull Request: https://projects.blender.org/blender/blender/pulls/116977
The ruler code would add new (GP) ID and link it to current scene outside
of any depsgraph tagging and/or undo step writing.
Now always add this 'util' GP data earlier, in a context where there is a clear
undo step written. Also fixes the missing tagging and relations updates.
Pull Request: https://projects.blender.org/blender/blender/pulls/116751
This adds support for rendering the hardness curve attribute.
The attribute cannot be written from within GPv3, but is added when
converting from the legacy Grease Pencil type.
The struct `SpaceText_Runtime` already separates runtime data from
`SpaceText`, however it is still allocated inside `SpaceText`, read and
write file operations still copy this data, but is override on read.
This changes separate allocation of `SpaceText_Runtime` from
`SpaceText`.
Ref !115418
After undo, a depsgraph update could free run-time modifier data.
In the case of the subsurf modifier a reference to this is held
in the meshes run-time data which also needs to be cleared.
When the "before" state of the face set brush gets stored in an undo step
and there is no face set attribute yet, 0 was stored instead of 1. 0 currently
has special meaning and isn't the default white color.
Area for clicking on keys was wider than strip which caused problems.
Instead of finding best strip candidate and then a key, make clickable
area wider, but inside of the strip itself.
These UIs don't display previews, now need to load them.
Currently the UI code doesn't actually know which previews will be
visible, so it loads them all. This adds quite some memory overhead.
Likely fixes#115372.
Pull Request: https://projects.blender.org/blender/blender/pulls/116987
This fixes an issue where a CacheFile was always created for the USD
file, causing USD_create_handle() to be called unnecessarily even if the
USD does not have animating meshes or transforms.
This bug would sometimes result in the stage remaining open in a
CacheArchiveHandle after import (because the CacheFile is never
freed), preventing the USD from being reloaded from disk.
The cache file is now accessible to readers through an
ImportSettings::get_cache_file function wrapper which creates a
CacheFile as needed, the first time the function is called.
The allocated CacheFile pointer is now stored in a new
ImportJobData::cache_file member.
Pull Request: https://projects.blender.org/blender/blender/pulls/116242
This adds a Python API for layout panels that have been introduced in #113584.
Two new methods on `UILayout` are added:
* `.panel(idname, text="...", default_closed=False) -> Optional[UILayout]`
* `.panel_prop(owner, prop_name, text="...") -> Optional[UILayout]`
Both create a panel and return `None` if the panel is collapsed. The difference lies
in how the open-close-state is stored. The first method internally manages the
open-close-state based on the provided identifier. The second one allows for
providing a boolean property that stores whether the panel is open. This is useful
when creating a dynamic of panels and when it is difficult to create a unique idname.
For the `.panel(...)` method, a new internal map on `Panel` is created which keeps
track of all the panel states based on the idname. Currently, there is no mechanism
for freeing any elements once they have been added to the map. This is unlikely to
cause a problem anytime soon, but we might need some kind of garbage collection
in the future.
```python
import bpy
from bpy.props import BoolProperty
class LayoutDemoPanel(bpy.types.Panel):
bl_label = "Layout Panel Demo"
bl_idname = "SCENE_PT_layout_panel"
bl_space_type = 'PROPERTIES'
bl_region_type = 'WINDOW'
bl_context = "scene"
def draw(self, context):
layout = self.layout
scene = context.scene
layout.label(text="Before")
if panel := layout.panel("my_panel_id", text="Hello World", default_closed=False):
panel.label(text="Success")
if panel := layout.panel_prop(scene, "show_demo_panel", text="My Panel"):
panel.prop(scene, "frame_start")
panel.prop(scene, "frame_end")
layout.label(text="After")
bpy.utils.register_class(LayoutDemoPanel)
bpy.types.Scene.show_demo_panel = BoolProperty(default=False)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/116949
Caused bu 5af8b839cf.
This solution tags both mesh positions and normals for update when
drawing happens from the modifier stack evaluation result.
This is needed because the sculpt session modifies original mesh
positions, and the modifier stack is not guaranteed to modify them
further (and hence tag normals for update).
Pull Request: https://projects.blender.org/blender/blender/pulls/117033
