When drawing on a frame that didn't have a keyframe, but did have a drawing,
Blender would report that there was no drawing to draw on.
The issue was some faulty logic on the invoke of the drawing code.
Now, this properly checks if a new frame needs to be inserted and
only reports an error in case auto-key is off and there is no drawing.
Pull Request: https://projects.blender.org/blender/blender/pulls/116417
The issue occurs when auto-keyframe AND "Only Insert Needed" enabled.
And only when no keyframes have been added yet.
Before the commit that caused the issue, moving an object with `G` would
create only location keyframes. After it would key all.
That is because that commit removed the logic that checks the
`eTfmMode` (Transform mode). That only works as long as there are already
keyframes on the object/bone because the logic needs an
existing value to compare against. In the case where the first keyframe is set,
it would always key everything.
The fix is to bring back the logic that checks the Transform mode and pass
a `Span` of rna paths to the autokeyframe function. This restores the behavior.
This still has the issue that "Only Insert Needed" behaves differently if
keys exist vs inserting the first keys. While this isn't ideal, I don't see a way
to get values of an object/bone before and after the transformation.
We might be able to fix this in a future PR, but for now we restore the
old behavior.
Caused by #115522
Pull Request: https://projects.blender.org/blender/blender/pulls/116219
Combination of two operators by Ares Deveaux
#106524 and #106523
Introduces a new operator "Scale from Neighbor"
that scales selected keyframe segments from either
the left or right keyframe neighbor.
Pressing "D" during modal operation will switch
from which end of the segment the scaling happens.
This is useful to make a section of animation closer to a pose on either side.
Co-authored-by: Ares Deveaux <aresdevo@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/112387
In preparation to the upcoming refactor of the keying set code,
extend the unit tests with more sophisticated
tests for "Insert Available".
This PR tests
* key available using the preference setting with autokeying on an object and a bone
* key available using the keyingset "Available"
Pull Request: https://projects.blender.org/blender/blender/pulls/116327
Add a new normal mode called "Custom" which directly interpolates
a "custom_normal" attribute to the evaluated points for the final
normal. Extend the "Set Curve Normal" node with this mode and
give it the ability to set the custom normal value.
This is intentionally a very basic implementation of custom normals.
In particular, the storage is not rotation invariant. So the normals
are expected to be set procedurally at the end of the modifier stack.
On the other hand, it is very easy to understand and explain.
Pull Request: https://projects.blender.org/blender/blender/pulls/116066
Except for vertex groups and a few older color types, these
are generally replaced by newer generic attribute types.
Also remove some includes of DNA_mesh_types.h, since it's
included indirectly by BKE_mesh.hh currently.
This is the initial implementation for the volume grid sockets that has been
discussed during the November 2023 geometry nodes workshop.
It adds initial support for passing volume grids around in sockets. Furthermore,
it adds two new nodes. Both are initially hidden under the "New Volume Nodes"
experimental option until we have a few mode nodes.
* **Get Named Grid**: Gets or extracts a volume grid from a volume geometry
based on the grid's name.
* **Store Named Grid**: Puts a volume grid back into a volume with a name.
`SocketValueVariant` is extended to support grids besides single values and fields.
Next steps:
* Implement grid socket shape and inferencing (currently, they just look like
single values).
* Add implicit conversions between grid types.
* Implement nodes that operate on the grids (#116021).
* Improved spreadsheet and viewer support.
Links:
* https://devtalk.blender.org/t/volumes-in-geometry-nodes-proposal/31917
* https://devtalk.blender.org/t/2023-11-06-geometry-nodes-workshop-notes/32007#volumes-3
Co-authored-by: Jacques Lucke <jacques@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/115270
Remove most includes of this header inside other headers, to remove unnecessary
indirect includes which can have a impact on compile times. In the future we may
want more dedicated "_fwd.hh" headers, but until then, this sticks with the
solution in existing code.
Unfortunately it isn't yet possible to remove the include from `BKE_geometry_set.hh`.
Each value is now out of the global namespace, so they can be shorter
and easier to read. Most of this commit just adds the necessary casting
and namespace specification. `enum class` can be forward declared since
it has a specified size. We will make use of that in the next commit.
This was added at the start of the project, as a way for the source
library to control what would be overridable by the user of the data
(production files).
The implementation never went beyond the experimental area, and only
exposed in the python API then. The idea has been superseeded by the
'cherry-pick' design, so there is no point in keeping this code any
longer.
This refactors how volume grids are stored with the following new goals in mind:
* Get a **stand-alone volume grid** data structure that can be used by geometry nodes.
Previously, the `VolumeGrid` data structure was tightly coupled with the `Volume` data block.
* Support **implicit sharing of grids and trees**. Previously, it was possible to share data
when multiple `Volume` data blocks loaded grids from the same `.vdb` files but this was
not flexible enough.
* Get a safe API for **lazy-loading and unloading** of grids without requiring explicit calls
to some "load" function all the time.
* Get a safe API for **caching grids from files** that is not coupled to the `Volume` data block.
* Get a **tiered API** for different levels of `openvdb` involvement:
* No `OpenVDB`: Since `WITH_OPENVDB` is optional, it's helpful to have parts of the API that
still work in this case. This makes it possible to write high level code for volumes that does
not require `#ifdef WITH_OPENVDB` checks everywhere. This is in `BKE_volume_grid_fwd.hh`.
* Shallow `OpenVDB`: Code using this API requires `WITH_OPENVDB` checks. However, care
is taken to not include the expensive parts of `OpenVDB` and to use forward declarations as
much as possible. This is in `BKE_volume_grid.hh` and uses `openvdb_fwd.hh`.
* "Full" `OpenVDB`: This API requires more heavy `OpenVDB` includes. Fortunately, it turned
out to be not necessary for the common API. So this is only used for task specific APIs.
At the core of the new API is the `VolumeGridData` type. It's a wrapper around an
`openvdb::Grid` and adds some features on top like implicit sharing, lazy-loading and unloading.
Then there are `GVolumeGrid` and `VolumeGrid` which are containers for a volume grid.
Semantically, each `VolumeGrid` has its own independent grid, but this is cheap due to implicit
sharing. At highest level we currently have the `Volume` data-block which contains a list of
`VolumeGrid`.
```mermaid
flowchart LR
Volume --> VolumeGrid --> VolumeGridData --> openvdb::Grid
```
The loading of `.vdb` files is abstracted away behind the volume file cache API. This API makes
it easy to load and reuse entire files and individual grids from disk. It also supports caching
simplify levels for grids on disk.
An important new concept are the "tree access tokens". Whenever some code wants to work
with an openvdb tree, it has to retrieve an access token from the corresponding `VolumeGridData`.
This access token has to be kept alive for as long as the code works with the grid data. The same
token is valid for read and write access. The purpose of these access tokens is to make it possible
to detect when some code is currently working with the openvdb tree. This allows freeing it if it's
possible to reload it later on (e.g. from disk). It's possible to free a tree that is referenced by
multiple owners, but only no one is actively working with. In some sense, this is similar to the
existing `ImageUser` concept.
The most important new files to read are `BKE_volume_grid.hh` and `BKE_volume_grid_file_cache.hh`.
Most other changes are updates to existing code to use the new API.
Pull Request: https://projects.blender.org/blender/blender/pulls/116315
Form a logic PoV, it makes more sense to have all 'debug' options
disabled as the 'normal' situation.
This commit merely invert the RNA-exposition of two settings (Asset
Indexer and Override auto-resync).
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
Ensure tool keymaps are registered when calling:
bl_keymap_utils.keymap_hierarchy.generate() in background mode.
This is an alternative to !116299 that doesn't require keymap
initialization in background mode.
Thanks to Damien Picard's for reporting & investigating this issue.
With the popularity of dark themes, and the fact that our default theme
is dark, make the initial background color (before the program fully
loads) a darker shade of grey. {0.25f, 0.25f, 0.25f} versus current
{0.55f, 0.55f, 0.55f}. Also set Windows class background brush to the
same color to remove a potential flash.
Pull Request: https://projects.blender.org/blender/blender/pulls/115968
When the Asset shelf is active but hidden, the mouse cursor will give
feedback about a moveable edge above the asset shelf area. This just
alters `region_azone_edge_poll` to check for edges belonging to
regions that hide with a previous region that is now hidden.
Pull Request: https://projects.blender.org/blender/blender/pulls/116233
