The `INSERTKEY_XYZ_TO_RGB` flag on `datablock.keyframe_insert()` in
Blender's Python API was changed to do nothing in #115297 and #119625,
in favor of determining fcurve coloring exclusively from user preferences.
This PR removes that now-useless `INSERTKEY_XYZ_TO_RGB` flag entirely.
Pull Request: https://projects.blender.org/blender/blender/pulls/147262
Python API functions would both report an error through CLOG and throw an
exception. However this is a problem when --debug-exit-on-error is used,
as tests and other scripts will not have the opportunity to catch the exception
before Blender exits.
Now don't print such reports through CLOG. Note that these usages of
BKE_reports_init have their print level set to error, so were already not
printing info and warning reports (which is not something we generally
want Python API calls to do, they should be silent).
Ref #146256
Pull Request: https://projects.blender.org/blender/blender/pulls/146801
* Replace G.quiet by CLG_quiet_set/get
* CLOG_INFO_NOCHECK prints are now suppressed when quiet, these were
typically inside a if (!G.quiet) conditional already.
* Change some prints for blend files, color management and rendering to
use CLOG, that were previously using if (!G.quiet) printf().
Pull Request: https://projects.blender.org/blender/blender/pulls/143138
- `bpy_struct.id_data` - provide a type.
- `bpy_struct` - add missing return types to
`bpy_struct.get`, `bpy_struct.pop`, `bpy_struct.path_resolve`.
- `bpy_struct` - add missing argument types to some methods.
- `bpy_struct` - provide explicit `/` and `*` in signatures to make it
clear which arguments are positional / keyword-only.
Ref !141334
Symptoms were drivers still being active while others seemingly
disabled. Indices in the RNA path up to the `ANIM_remove_driver` call
are correct, so it is not entirely clear to me why this goes wrong, but
forcing an update by tagging animation resolves the issue.
NOTE from @dr.sybren : Without this fix, the old copy-for-evaluation
is still there, which still has the driver (because it's a copy)
NOTE: seems we are not handling ND_FCURVES_ORDER anywhere?
Pull Request: https://projects.blender.org/blender/blender/pulls/138490
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
When using clangd or running clang-tidy on headers there are
currently many errors. These are noisy in IDEs, make auto fixes
impossible, and break features like code completion, refactoring
and navigation.
This makes source/blender headers work by themselves, which is
generally the goal anyway. But #includes and forward declarations
were often incomplete.
* Add #includes and forward declarations
* Add IWYU pragma: export in a few places
* Remove some unused #includes (but there are many more)
* Tweak ShaderCreateInfo macros to work better with clangd
Some types of headers still have errors, these could be fixed or
worked around with more investigation. Mostly preprocessor
template headers like NOD_static_types.h.
Note that that disabling WITH_UNITY_BUILD is required for clangd to
work properly, otherwise compile_commands.json does not contain
the information for the relevant source files.
For more details see the developer docs:
https://developer.blender.org/docs/handbook/tooling/clangd/
Pull Request: https://projects.blender.org/blender/blender/pulls/132608
Replace plain-text type information with the type syntax used
for Python's type annotations as it's more concise, especially for
callbacks which often didn't include useful type information.
Note that this change only applies to inline doc-strings,
generated doc-strings from RNA need to be updated separately.
Details:
- Many minor corrections were made when "list" was incorrectly used
instead of "sequence".
- Some type information wasn't defined in the doc-strings and has been
added.
- Verbose type info would benefit from support for type aliases.
For now, PointerRNA is made non-trivial by giving explicit default
values to its members.
Besides of BPY python binding code, the change is relatively trivial.
The main change (besides the creation/deletion part) is the replacement
of `memset` by zero-initialized assignment (using `{}`).
makesrna required changes are quite small too.
The big piece of this PR is the refactor of the BPY RNA code.
It essentially brings back allocation and deletion of the BPy_StructRNA,
BPy_Pointer etc. python objects into 'cannonical process', using `__new__`,
and `__init__` callbacks (and there matching CAPI functions).
Existing code was doing very low-level manipulations to create these
data, which is not really easy to understand, and AFAICT incompatible
with handling C++ data that needs to be constructed and destructed.
Unfortunately, similar change in destruction code (using `__del__` and
matching `tp_finalize` CAPI callback) is not possible, because of technical
low-level implementation details in CPython (see [1] for details).
`std::optional` pointer management is used to encapsulate PointerRNA
data. This allows to keep control on _when_ actual RNA creation is done,
and to have a safe destruction in `tp_dealloc` callbacks.
Note that a critical change in Blender's Python API will be that classes
inherinting from `bpy_struct` etc. will now have to properly call the
base class `__new__` and/or `__init__`if they define them.
Implements #122431.
[1] https://discuss.python.org/t/cpython-usage-of-tp-finalize-in-c-defined-static-types-with-no-custom-tp-dealloc/64100
While copying this used to be very cheap, this will soon be less
trivial.
Note that there are many more places where this type of cleanup will be
needed.
No functional changes intended.
This simplifies the arguments for the `delete_keyframe` function.
The `bAction *` was always a `nullptr` so I just removed it.
The rna path char array and the array index were merged into the `RNAPath` struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/125479
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
The issue was that the Python keyframing code was already resolving the
RNA path fully to the owning ID, but then erroneously passing the
non-ID RNA pointer (in this case the sound sequence pointer) to the
keyframing code with that fully resolved path.
Notably, it wasn't just the VSE keyframing that was broken: keying any
non-ID structs via the Python API was broken. A good example is pose
bones: the Python keyframing code was resolving e.g. "location" on
the bone to "pose.bones["Bone"].location", but then passing that
path along with the pose bone struct to the keyframing code. Since
that fully resolved path of course doesn't exist on the bone itself,
keying would fail.
This fixes it by simply passing the owning ID's RNA pointer instead,
which it should have been doing in the first place.
Pull Request: https://projects.blender.org/blender/blender/pulls/123719
The goal of this PR is to merge `insert_keyframe()` and `insert_key_rna()` into
a single function, `insert_keyframes()`, that fully accommodates the
functionality of both. This results in a bit of a mega function, which isn't
great, but it centralizes a lot of otherwise redundant keyframing code so it
only needs to be changed in one place in the future.
Future PRs can work to reduce the "mega" aspect of this function, stripping it
down to its core functionality and eliminating left over incidental redundancy
(e.g. passing both `scene_frame` and `anim_eval_context`).
As a wonderful side effect, this PR also makes layered action keyframing work in
most of the remaining places left over from #121661, such as buttons, the
dopesheet, the graph editor, etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/122053
Just for the `pyrna_struct_keyframe_insert()` function, reduce the
reporting level of keyframe insertion failures from `RPT_ERROR` to
`RPT_WARNING`. This prevents the conversion of these reports to a Python
exception.
`CombinedKeyingResult::generate_reports()` now accepts an option
argument `report_level`, so that the caller is in control over the type
of reports it generates.
Previously only errors were converted to exceptions; warnings were
implicitly cleared and never displayed. To avoid these 'keyframe
insertion failure' reports from becoming invisible, the
`pyrna_struct_keyframe_insert()` function now sends any warnings to
stdout (unless there were errors, in which case the old
error-to-exception behaviour is still there).
Pull Request: https://projects.blender.org/blender/blender/pulls/122827
The type for `bpy_struct.keyframe_insert()`'s `options` parameter was
instead applied to a non-existent `flag` parameter.
The description and type for `mathutils.Vector.Repeat()`'s `vector`
parameter was instead applied to a non-existent `tuple` parameter.
Also fix a reference to `BMElemeSeq` instead of `BMElemSeq`.
Ref: !122734
The insert key function in `animrig/keyframing.cc` took a `ReportList`
argument which it used to print messages in case of failures.
Instead this now returns a `CombinedKeyingResult` and the caller is
responsible for creating reports out of that.
To make that simpler the `ID` argument has been changed from a pointer to a reference.
The calling functions now make sure that it's not a `nullptr`.
This has the effect that there will be less messages printed in the Info panel when e.g. inserting keys with a keyingset.
This still doesn't make an error message pop up though.
Related to #119776
Pull Request: https://projects.blender.org/blender/blender/pulls/120784
Add an optional keyword argument `keytype` to the
`rna_struct.keyframe_insert()` function.
This makes it possible to set the new key's type. The code for this was
almost all in place, the only thing that was missing was the RNA
wrapper, which is what this commit adds.
Example: `bpy.context.object.keyframe_insert("location",
keytype='JITTER')`
There is no backward compatibility issue here, because the argument is
optional and defaults to the previously hardcoded value of `KEYFRAME`.
Pull Request: https://projects.blender.org/blender/blender/pulls/120578
No functional changes intended.
The `insert_keyframe` function had a `bAction` argument that could be
a `nullptr`. If it was a `nullptr` it would be queried from the `ID`.
However in all cases where it is passed it is also gotten from the `ID`, making
the argument redundant.
This PR removes the argument to simplify the function.
Pull Request: https://projects.blender.org/blender/blender/pulls/119742
Bring back the `INSERTKEY_XYZ_TO_RGB` enum item for the
`keyframe_insert()` function (it was removed in 30b0c5b225). This way
any Python code that targets Blender 4.x can safely pass this flag,
without having to check specific Blender versions.
Note that the flag is implemented as a no-op, as the behaviour change
introduced in 30b0c5b225 (just looking at the user preference) is still
retained. The purpose of this commit is simply to avoid the `ValueError`
exception that would otherwise be raised.
This should also fix Rigify report blender/blender-addons#105241.
Pull Request: https://projects.blender.org/blender/blender/pulls/119625
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
This significantly simplifies memory management, mostly by avoiding
the need to free the memory manually. It may also improve performance,
since std::string has an inline buffer that can prevent heap
allocations and it stores the size.
Pull Request: https://projects.blender.org/blender/blender/pulls/117695
No functional changes expected.
Before this PR the keyframing code was aware of driver specifics
and changed the frame where a key is inserted to the current driver value.
This is now changed so that the calling code needs to know where on the
FCurve the key should be inserted. This removes the need for the
`INSERTKEY_DRIVER` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/116823
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
There are a couple of functions that create rna pointers. For example
`RNA_main_pointer_create` and `RNA_pointer_create`. Currently, those
take an output parameter `r_ptr` as last argument. This patch changes
it so that the functions actually return a` PointerRNA` instead of using
the output parameters.
This has a few benefits:
* Output parameters should only be used when there is an actual benefit.
Otherwise, one should default to returning the value.
* It's simpler to use the API in the large majority of cases (note that this
patch reduces the number of lines of code).
* It allows the `PointerRNA` to be const on the call-site, if that is desired.
No performance regression has been measured in production files.
If one of these functions happened to be called in a hot loop where
there is a regression, the solution should be to use an inline function
there which allows the compiler to optimize it even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/111976
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
