Investigation into #126306 showed that the texture tab shown would actually be
for the active image paint brush, but people used it to set up a texture for
the fluid modifier settings anyway. Now properly register the texture user for
the UI, so the texture properties tab will always be displayed when there is a
fluid modifier with a "Flow" fluid type.
Main issue is that fluid modifiers weren't handled by the
`BKE_modifiers_foreach_tex_link()` iterator.
While this could be handled as another special case in
`buttons_texture_modifier_foreach()`, I updated the texture-link iterators to
support texture properties that are not directly stored in the modifier, but in
some nested data. Seems like this should be supported generally. It's enabled
here by passing a pointer-property pair, rather than just a property name.
Pull Request: https://projects.blender.org/blender/blender/pulls/126893
Implementing part of design outlined in #126087.
- VSE thumbnail cache has a new implementation, hopefully simpler
and easier to understand.
- Instead of cache key being a VSE strip, frame index, plus
complicated logic for cache items linking etc.,
- The cache is keyed by media file path (if multiple strips
use the same input file, they will share cache entries), frame
index within media file, and any extra data (e.g. steam index
for multi-steam videos)
- Much reduced cache flickering and strange/weird thumbnail choices.
- Likewise, thumbnails no longer disappear-and-reload on operations
like Undo, dragging new video strip into timeline, or F12 render.
- Thumbnails now load faster.
- Images use dedicated/faster thumbnail loading routines when a
format can do that (e.g. JPG and EXR can).
- Movies reuse ffmpeg decoding context for neighboring strips
that use the same file (as often happens when cutting footage)
- Thumbnail requests are processed on several threads now too.
Images and more detail in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126405
When unsibdivide ran with quads that share shared two edges,
only one of the loops attached to the vertex would have its grid
initialized (multiple times), skipping the other loops grid calculation
and leaking memory.
Hidden geometry caused an eternal loop in the un-subdivide internal
logic.
Also fix the un-subdivide operator leaving an invalid selection,
where faces where unselected while all their edges were selected.
Brushes that were verified to be impacted by this:
* Clay
* Smooth
* Cloth
Brushes that were verified to not be impacted:
* Draw
* Blob
There is some dependency within the brush code that expects that the
`ss.deform_cos` variable is not updated during the middle of the stroke.
This commit only deals with fixing the immediate user-facing issue, for
a longer-term or more comprehensive fix, it is likely that these values
should not be touched at all inside the `sculpt_update_object` function
but should instead be initialized somewhere else so that the lifecycle
is more obvious and maintainable.
Pull Request: https://projects.blender.org/blender/blender/pulls/126803
ID usages of embedded data would be refcounted twice when copying their
owner ID.
Also did cleanup on naming, since proper names of these IDs is
'embedded', not the old 'private' one.
In order to make per-BVH-node overhead smaller and also to improve
type safety and code clarity, split the `pbvh::Node` struct into four classes:
a base class, and a class for each sculpt geometry type.
The size of a mesh BVH node changes from 408 to 176 bytes. For multires
the nodes are smaller at 96 bytes. This gives us leeway to make nodes smaller
to benefit more from spacial locality, etc. It also just reduces memory usage.
Using a `std::variant` makes the change quite simple actually. For the few
places that actually need to process the node types separately given their
different types, we use `std::visit`. Elsewhere we use `IndexMask` to retrieve
selections of nodes from the vector instead, though most code will be
refactored to that pattern separately. The new function `search_nodes`
is the equivalent of the existing `gather_nodes` that returns an `IndexMask`
instead of a vector of node pointers.
Part of #118145.
Pull Request: https://projects.blender.org/blender/blender/pulls/126873
Add Metallic BSDF Node to the shader editor.
This node can primarily be used to create more realistic looking
metallic materials than the existing Glossy BSDF node.
This commit does not add any new closures to Cycles, it simply exposes
existing closures that were previous hard to access on their own.
- Exposes the F82 fresnel type that is currently used by the
metallic component of the Principled BSDF. Results should match
between the Metallic BSDF and Principled BSDF when using the same
settings.
- Exposes the Physical Conductor fresnel type that was previously
limited to custom OSL scripts. The Conductor fresnel type accepts
IOR and Extinction coefficients to define the appearance of the
material based off real life measurements.
EEVEE only supports the F82 fresnel type with internal code to convert
the the physical conductor inputs in to a colour format for F82,
which can lead to noticeable rendering differences with
some configurations.
Pull Request: https://projects.blender.org/blender/blender/pulls/114958
The issue was that the forward compatibility saving code was setting the
group's `channels` listbase to point at the forward-compatible fcurve
listbase, but the `channels` listbase wasn't later getting cleared when
loading the groups as part of a layered action. In fact, the listbase
pointers were being completely ignored in that case because they aren't
relevant to groups on layered actions, and therefore weren't getting
remapped to the new correct memory addresses of the fcurves.
The end result was that after loading, the group's `channels` listbase
would be non-null and pointing to invalid memory, and there are some
code paths that then try to use that listbase, resulting in a segfault.
This commit fixes the issue by ensuring that the groups' `channels`
listbases are cleared when loading them as part of a layered action.
Additionally, we now also clear them after they're set during
forward-compatibly saving, the lack of which wasn't immediately
causing problems but was nevertheless incorrect.
Pull Request: https://projects.blender.org/blender/blender/pulls/126834
Part of #118145.
In order to reduce the purview of the sculpt BVH tree and clarify its
responsibility, replace the geometry back pointer with just passing
the BMesh pointer as an argument where necessary or retrieving it
from the object instead.
True for both `Graph` and `Dopesheet` views in the MCE.
For all other time-based editors, the main region (`RGN_TYPE_WINDOW`) is
of interest to be tagged for syncing `V2D_VIEWSYNC_SCREEN_TIME`. In the
case of the Movie Clip Editor however, the `Graph` and `Dopesheet`
regions in question are of type `RGN_TYPE_PREVIEW`.
So to resolve, we have to take this into account in view2d_sync RNA code
NOTE: this PR does not add versioning code, so any "falsely" tagged
`Graph` and `Dopesheet` view will "loose" the setting (will have to be
enabled again on the "right" region), this could be added though -- it
would be impossible to tell **which** view exactly, so on each
`RGN_TYPE_WINDOW` encountered, we'd have to then tag **both** `Graph`
and `Dopesheet` afaict
Pull Request: https://projects.blender.org/blender/blender/pulls/126785
Mainly changes some UI-internal structs allocation, and the Panel
runtime custom data storage.
These changes from C-style alloc/free to C++ new/delete are a step
towards making PointerRNA non-trivial (part of #122431).
Pull Request: https://projects.blender.org/blender/blender/pulls/126698
And same for the `copy_layout` function. These functions do not free any
potentially existing data in destination, but expect it to be uninitialized.
Hopefully these new names will make it more clear and avoid bugs like #122160.
`CustomData_copy` expects uninitialized destination customdata, so in
case the destination has been previously initialized, it needs to be
freed with `CustomData_free` first.
Also added related comments to the BKE CustomData API.
Pull Request: https://projects.blender.org/blender/blender/pulls/126794
The functions were allocating arrays of `T *` rather than `T`, and
then were reinterpret-casting to the correct type afterwards. This
coincidentally worked at the current call sites because `T` was always
a pointer type anyway, but the code was logically incorrect and wouldn't
work if anyone tried to use them with a non-pointer `T`.
This commit fixes this by correctly allocating an array of `T` instead,
and removing the unnecessary cast.
Pull Request: https://projects.blender.org/blender/blender/pulls/126656
Current default tool is "sample" which is a bit odd, and coupled with
the fact that the toolbar is hidden by default, this can be confusing
to new users, leading them to believe tweak/select tools are not
supported for the VSE preview.
This change:
- Sets "box select" as the default tool for the Preview
- Makes both Preview and Timeline toolbars shown by default
Pull Request: https://projects.blender.org/blender/blender/pulls/126336
Previously we often passed an empty `FunctionRef` to the generic
`search_gather` function. The plan is to refactor `search_gather`
to return an `IndexMask` along with storing leaf nodes in a separate
array. Splitting access to all leaf nodes to a separate function simplifies
this process and makes code more expressive too.
Part of #118145.
Pull Request: https://projects.blender.org/blender/blender/pulls/126667
When there is a deform modifier or shape keys, currently the evaluated
position array is copied to a duplicate array on the sculpt PBVH tree.
Historically most code has used this array directly, so the code has
been a bit confusing, but conceptually this is just supposed to be
the evaluated positions.
Instead of editing the BVH tree position array while sculpting, we
can edit the arrays on the evaluated mesh directly-- or the original
mesh when there are no deform modifiers.
Removing this array reduces memory usage and plays better with implicit
sharing since we don't need to unshare the attribute just to store a
mutable copy.
The remaining non-ideal part is sculpt mode's use of a specialized
crazy-space function `BKE_crazyspace_build_sculpt` for building the
evaluated position array rather than using the general system for
retrieving deformed mesh data, `BKE_object_get_mesh_deform_eval`.
This should be replaced at some point.
This change makes clear a few simplifications for sculpt normals
recomputation, because we can store the normals for all cases as
a shared cache, unifying the code paths for original and deformed
normals.
Part of #118145.
Pull Request: https://projects.blender.org/blender/blender/pulls/126382
This PR adds channel groups (also known as fcurve groups or action groups) to
layered actions. For layered actions, these groups belong to the `ChannelBag`s
and can vary by bag.
From a user perspective, the goal is for these to function just like channel
groups from legacy actions. However, internally they are implemented a little
differently: legacy actions store both channel groups and fcurves in a listbase,
and groups indicate what fcurves are in them with a listbase that points
directly into the larger fcurve listbase. Layered actions, on the other hand,
store both fcurves and channel groups in an array, and groups indicate what
fcurves are in them by indexing into the fcurve array.
Despite taking this different approach, we still reuse the `bActionGroup` struct
for the new channel groups, just adding the necessary fields for index-based
fcurve membership as described above.
This PR does not implement all of the functionality needed to reach feature
parity with legacy action channel groups, but implements the main core and gets
them basically working.
It's easier to list the things that *haven't* been implemented yet:
- Operators for letting the user manually create/remove/move channel groups.
- Keyframe selection in the action/dopesheet editor on channel group rows
themselves are not yet working correctly.
- Handling channel groups in legacy/layered action conversion operators.
- Making the legacy `action.groups` property work on single-layer-single-strip
layered actions.
Those are left for future PRs. Other than that, in theory everything should be
working now.
Pull Request: https://projects.blender.org/blender/blender/pulls/125774
Blender doesn't read meta data of images in case they were packed, which
make things like image Cryptomatte fail. This is because the image
loading code didn't specify meta data reading for packed images, but did
for normal images.
To fix this, we also specify meta data reading for packed images. And
while at it, move all common IB flags in the same like to avoid such
differences in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/126602
Adds the ability to connect and disconnect strips in the VSE.
- Connected strips have an icon indicating their status, and attempting
to select one connected strip selects all other connected strips in
that chain.
- If the user attempts to connect a strip that is already connected to
other strips, that strip will disconnect itself from others before
connecting to new strips.
- Preview selection also works in bulk if multiple video strips are
connected together in the timeline.
- When adding new strips from the Add menu or the File Browser, strips
from the same file are connected by default. There's an option to
turn this off in Editing > Video Sequencer user preferences.
- It is possible to individually tweak strips/handles and ignore
connections with Alt+Click.
- This shortcut overrides the old keymap item for "Linked Handle"
selection. The property still exists if people want to use that
shortcut for its old purpose.
- To make sure that connections remain valid even after duplication,
I've added a condition to `seq_new_fix_links_recursive` that also
updates connections using the `seq->tmp` var. (A note -- I've updated
the comment for this field in `DNA_sequence_types.h` because the var
is only used for duplication now. It was once present in
`select_more_less_seq__internal` to be used for linked selection but
is gone now).
- There are also functions to cut one-way links and make sure that
all strips are bidirectionally connected after duplicating.
Pull Request: https://projects.blender.org/blender/blender/pulls/124333
Part of #118145.
The maximum and minumum edge length were stored in the BVH tree.
That's unnecessary since the source of truth is elsewhere and the values
are only used during remeshing operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/126571
This is just not supported, and typically not doable from Blender UI
(since embedded IDs won't be listed in ID template list).
Add asserts to IDProp code itself, and checks & error reports in
relevant BPY and RNA setters.
Changes similar to f9c6fe30db.
- Calculate node bounds after building the tree.
- Calculate node visibility after building the tree.
- Avoid redundant normals recalculation. They are already calculated
when first building the dynamic topology BMesh.
- Avoid clearing the default node flags.
Use the default constructor of `Node` to set the default new flag value.
Remove the normals update flag which was added in f9c6fe30db.
This should avoid recalculating all the normals after just building the
BVH tree.
Rather than retrieving the data from the BVH. This opens up the
possibility that the BVH building produces a slightly different
data structure that's then converted to the final format in a
separate pass.
Use the same method for retrieving "all nodes" that we do elsewhere.
Even though this requires a temporary vector, it makes it an easier
target for optimization later and makes the sculpt BVH iteration
easier to refactor in the meantime.
Issue found here at the studio in some production files using dirty
hacks. Ideally we could fully forbid such assignement in BPY/RNA API
too, but there is no 'proper' way to achieve this without this dirty
hack currenlty.
So instead, check for this case and print a nice error about it for now.
Previously, the inferencing result was only stored in the socket shape.
However, that was conflicting with experiments where the socket shape and
the field state was not related.
Code executed in `BLO_read_do_version_after_setup` would not update in
any ways the info in link/append context data.
NOTE: this could potentially be extended to other code in this 'complex
do version' area. However, other versionning did not cause issues
apparently so far, so would rather until such changes are proven needed.
