NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
The preview template (`UILayout.template_preview()`) to display previews
for materials, textures or similar would only work correctly in the
Properties editor. This had explicit logic to trigger rerendering on
changes. When displaying such previews elsewhere (e.g. in the 3D View
sidebar), the only way to have changes reflected would be by resizing
the preview.
This fix makes sure such previews are tagged as dirty and refreshed on
changes to the underlying ID. We do this the same way as tagging the ID
previews as dirty, through a function called by the dependency graph for
such updates.
Pull Request: https://projects.blender.org/blender/blender/pulls/129641
Part of the brush assets project followups, see #116337.
Based on feedback, it seems important to indicate to the user when a brush has
unsaved changes.
There's no reliable updating mechanism we can use or hook into here, except for
RNA "update" callbacks. Brush data gets changed in many places in code, the only
way to do this seems manual tagging every time a brush property gets changed.
This PR introduces `BKE_brush_tag_unsaved_changes()` for this. I spent some time
going through all brush properties to ensure changes call the tagging function.
A known limitation with this will be that changes to dependencies won't be
indicated in the brush. E.g. Changing the texture attached to a brush won't make
the brush be indicated as changed.
The UI to indicate the changed brushes is being discussed still, see #128846.
Pull Request: https://projects.blender.org/blender/blender/pulls/128845
IMB_scale modifies the input image. But some places in code needed to keep
original input intact, so what they did was a sequence of IMB_dupImBuf+IMB_scale
Add IMB_scale_into_new function and use that in several obvious places:
- movieclip_build_proxy_ibuf
- icon_copy_rect
- seq_proxy_build_frame
Rebuilding proxies for VSE image sequences with 94 4K resolution EXR images
(on Ryzen 5950X/Win10/VS2022): 13.4 -> 10.3 seconds.
Pull Request: https://projects.blender.org/blender/blender/pulls/128752
Because we're moving to layered actions, which don't store their
fcurves in a list base, we need to update the places that assume the old
listbase-based structure.
This commit addresses the low-hanging fruit where code was previously
using the `LISTBASE_FOREACH` macro on a listbase of fcurves and it was
fairly obvious how to correctly update the code with minimal changes.
Other cases that either weren't immediately obvious or required
non-trivial code changes (or both) have been left for future PRs.
Additionally, uses of the list base that didn't use `LISTBASE_FOREACH`
were not investigated as part of this PR, whether trivial to update or
not.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/127920
Add support for slotted Actions to the NLA evaluation code.
This also affects the pose library code and the Action Constraint. These
both share some Action evaluation logic with the NLA. They now
explicitly looks at only the first Action slot. The Action Constraint will
have to be updated to have an explicit slot selector, but that's for another
commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/127425
Move the functions
* `BKE_pose_apply_action_selected_bones`
* `BKE_pose_apply_action_all_bones`
* and `BKE_pose_apply_action_blend`
out of the blender kernel and into animrig.
This will allow solving #126969 without having to include
animrig code in the blender kernel.
Pull Request: https://projects.blender.org/blender/blender/pulls/126978
In this case, the `PoseBackup` created by
`action_preview_render_prepare` wasnt cleaned up properly (because
`action_preview_render` was earlied out).
So to resolve, call `action_preview_render_cleanup` as well when
earlying out)
Pull Request: https://projects.blender.org/blender/blender/pulls/127067
Caused by 03ae57dd8b
Custom preview operator uses `lib_id_preview_editing_poll`. To enable
this operator in UI, move the new condition to `lib_id_generate_preview_poll`
poll function so adding custom preview to unsupported type would
still be possible.
Co-authored-by: Julian Eisel
Pull Request: https://projects.blender.org/blender/blender/pulls/126874
The preview rendering would fall back to the shader preview rendering
pipeline, which is not suitable for objects. Instead, don't render any
preview (use an empty preview) for such object types. This case could be
handled a bit nicer by the code triggering the preview rendering (e.g.
the "Render Active Object" operator poll could return false), but
keeping that separate from fixing the lower level logic to ensure crash
free behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/126235
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
API: merged IMB_scalefastImBuf, IMB_scaleImBuf, IMB_scaleImBuf_threaded
into one function IMB_scale with enum IMBScaleFilter {Nearest, Bilinear, Box}
and bool "threaded" param.
Performance:
- Box filtering (nee IMB_scaleImBuf) can be multi-threaded now.
- Nearest filtering (nee IMB_scalefastImBuf) can be multi-threaded now.
Also fix performance regression on float images caused by fix in #126234
- Bilinear filtering (nee IMB_scaleImBuf_threaded) is several times faster now.
Correctness:
- Nearest and Box filtering: no longer loses half of edge pixels when scaling
up.
- Box: fixed garbage results (and possible out of bounds reads) for non-4
channel float images.
- Bilinear: no longer shifts image when scaling up.
- Bilinear: properly filters when scaling down by 2x2.
Test coverage:
- Add gtest coverage for various IMB_scale modes.
- Add a IMB_performance_test performance test, ran manually.
More details, images and performance numbers in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126390
Prevent VSE cache returning image when running render job.
Previously, before render job was started, cache was cleared, but since
disk cache is not cleared, it returned an image. Now cache is not
cleared, but it does not return or store images when rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/125947
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
When (de)selecting the active material, use the active slot
falling back to the first-used slot (for non-active objects).
Resolve regression in [0].
Ref !125948
[0]: 296d05060d
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
Fairly trivial conversion, since there is no complex handling of
dependencies currently in that case.
NOTE: Also fixes the 'not copying any material' issue also present in
4.2 (at least), but the proper way. For reference, see !125003 for a fix
for code using the deprecated partial write API.
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
Since 7b0ea0f1b4, brushes use the asset system and previews are stored
in the asset source blend files. The bundled ones are part of the
essentials asset library, see
`release/datafiles/assets/publis/brushes/essentials_brushes.blend`.
Note that this doesn't remove the toolbar icons for these brushes yet.
Initially reviewed in (but this commit contains further changes missing
in the PR):
https://projects.blender.org/blender/blender/pulls/123842
Also see 06be295946.
These aren't all cases, but a few that I found by addding a static
assert in `MEM_new` so that it fails for trivially constructible types.
This was the case when the slot index in the active object is greater
than the available slots of other selected objects.
Code was trying to avoid searching all materials by using
`BKE_object_material_get` to get an appropriate index (an addition to
D4441 added in 6b39dc7672). That function has the behavior of clamping
if a target index is greater than the available slots (for good
reasons), so we cant rely on the slot index being the same if
`BKE_object_material_get` finds a material. So in essence, this is not
what we want to use in this case.
Now use the much simpler `BKE_object_material_index_get` to get the
index [this might be less performant in certain scenarios, dont think
this is critical though and correctness should beat performance here]
Pull Request: https://projects.blender.org/blender/blender/pulls/123718
Basically this tries to make the API to stop and kill jobs more explicit &
consistent, so intent is expressed clearly & behavior as expected.
- Remove use of the job start callback address as identifier for the job.
6887dea786 already removed this pattern from the jobs system internals, this
commit also removes it from the API.
- Make stop & kill API and implementation consistent. E.g. don't stop/kill jobs
by either owner **or** type/callback in one function, and by owner (if
provided) **and** type/callback in another. Causes some small behavior
changes, documented inline.
- Use the same job type and API for all preview render jobs (change by Brecht).
There doesn't seem to be a need for the separated types, in fact the
separation might have caused some issues earlier (and added code complexity).
- Add/improve function documentation.
This does actually have subtle behavior changes that are known, see PR, but
they were investigated carefully and seem like implementing wanted behavior.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/123086
`Copy Material to Selected` now sets the `Link` type of the selected objects to match those of the active object.
Without this, it changes the underlying material slots on the mesh data block, which is probably not what the user intends. With the new behavior, it now changes the selected objects to use object-linked materials.
Pull Request: https://projects.blender.org/blender/blender/pulls/122579
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
- Add a report to explain why allocation fails and display
the current limit.
- Add heuristic to avoid out of memory issue.
- Remove the delay property that did not do anything
right now.
- Reduce default clip end by half.
Fix#121916
Pull Request: https://projects.blender.org/blender/blender/pulls/122572
For the brush assets, this mechanism makes brush, texture, node tree and
image datablocks editable even when library linked.
This commit should introduce no functional change yet, as the code to
actually tag such libraries as editable will come later.
* These libraries and their datablocks are preserved when loading a new
blend file, much like the UI can be preserved.
* Operators that create new datablocks to be assigned to such datablocks
will put the datablocks in the same library immediately. This was
implemented for datablocks relevant for brush assets.
* RNA does not allow assignment of pointers from such linked datablocks
to local datablocks.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121920
Using a non-virtual derived struct for polymorphism is error prone,
especially combined with the requirements of DNA. Instead, use a
separately allocated runtime struct as done for many other DNA structs.
In a followup commit, the remaining runtime members of `PreviewImage`
could be moved to the new runtime struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/121509
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
The new/experimental, layered `Animation` data-block is merged with the
existing `bAction` data-block.
The `Animation` data-block is considerably newer than `bAction`, so the
supporting code that was written for it is also more modern. When moving
that code into `bAction`, I chose to keep the modernity where possible,
and thus some of the old code has been updated as well. Things like
preferring references over pointers.
The `Animation` data-block is now gone from DNA, the main database, etc.
As this was still an experimental feature, there is no versioning code
to convert any of that to Actions.
The DNA struct `bAction` now has a C++ wrapper `animrig::Action`, that
can be obtained via `some_action->wrap()`.
`animrig::Action` has functions `is_empty()`, `is_action_legacy()`, and
`is_action_layered()`. They **all** return `true` when the Action is
empty, as in that case none of the data that makes an action either
'legacy' or 'layered' is there.
The 'animation filtering' code (for showing things in the dope sheet,
graph editor, etc) that I wrote for `Animation` is intentionally kept
around. These types now target 'layered actions' and the
already-existing ones 'legacy actions'. A future PR may merge these two
together, but given how much work it was to add something new there, I'd
rather wait until the dust has settled on this commit.
There are plenty of variables (and some comments) named `anim` or
`animation` that now are of type `animrig::Action`. I haven't renamed
them all, to keep the noise level low in this commit (it's already big
enough). This can be done in a followup, non-functional PR.
Related task: #121355
Pull Request: https://projects.blender.org/blender/blender/pulls/121357
BLF_buffer was trying to accept "how many colors channels in output
image?" argument and doing math with it, but in the lowest level code
was always writing out full 4 channels for each pixel.
All the call sites would ever call it with argument of 4 however, and
that is why no one noticed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/121630
