This commit changes the raycasting code to store values as the
`ActiveVert` type instead of `PBVHVertRef` to avoid needing to check the
type of the PBVH when retrieving information.
It also fixes a case that did not reset the active vert when performing
a raycast.
Pull Request: https://projects.blender.org/blender/blender/pulls/127000
This commit essentially moves allocation of KeyMaps and Operators
PointerRNA data storage to use C++ new/delet, instead of C alloc/free.
Part of the effort to make PointerRNA non-trivial (#122431).
Pull Request: https://projects.blender.org/blender/blender/pulls/126935
With c20bb31325 the `active_vert` related
methods added a check against the relevant pbvh type. In certain
situations, the PBVH is freed but is not refreshed prior to the cursor
being drawn.
In the long term, we want the PBVH to be owned by the mesh, not the
`SculptSession`, so adding more logic around ensuring depsgraph tags
with PBVH changes to implicitly regenerate the PBVH is a step in the
wrong direction.
Additionally, it doesn't make sense that we don't ensure the PBVH exists
before accessing the `active_vert`, as its context is dependent on the
PBVH.
Therefore, this commit introduces multiple changes:
* Ensures that the PBVH exists prior to doing a raycast or other cursor
related actions
* Removes the checks against the PBVH type in `SculptSession` in
favor of debug asserts to avoid crashes and assist in finding other
situations where the state of the PBVH is ambiguous.
Pull Request: https://projects.blender.org/blender/blender/pulls/126953
This way we can query the brush types, e.g. to filter out eraser brushes
in the brush asset selector while the eraser tool is selected, see
https://projects.blender.org/blender/blender/issues/126032.
Technically a brush may have different brush types depending on the
mode. So we store a type for all supported modes.
Ideally the name of the custom metadata property would match the name of the
properties in RNA. They will match after #126796, the names here are the new
ones, to avoid having to version asset metadata.
Pull Request: https://projects.blender.org/blender/blender/pulls/124618
This node hashes various types into an integer. Note that hashes
cannot generally used as unique identifiers because they are not
guaranteed to be unique. It can be used to generate somewhat
stable randomness though in cases where White Noise does not
offer enough flexibility.
It uses hash functions from BLI_noise.hh. These are also used in
the White Noise node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110769
This adds a new launch argument when building with
renderdoc support. It allows to trigger the capture
of a specific capture scope. This allows selective
capture of some commonly captured parts.
Pull Request: https://projects.blender.org/blender/blender/pulls/126791
The bug was probably harmless in current codebase.
Also added some basic testing of `BKE_main_namemap_get_name` itself,
and not only higher-level ID renaming code.
The issue was that the forward compatibility writing code for channel groups in
layered actions was building a temporary legacy listbase, but was not clearing
it properly afterwards. This was then getting caught by an assert that ensured
that layered-action groups didn't have legacy data in them.
The reason the listbase wasn't getting cleared properly is because the
prev/next listbase pointers were getting cleared using a `LISTBASE_FOREACH`
loop, and thus the loop never progressed past the first item.
Additionally, this mistake wasn't just in the channel groups writing code, but
also the forward compatibility writing code for fcurves.
This fixes the issue in both places by switching the loops to
use`LISTBASE_FOREACH_MUTABLE`.
Based on discussion with @dr.sybren, this also removes the assert that caught
the issue. The situation it guards against is actually completely benign, and
the existence of the assert is contrary to the comments in the forward-compat
writing code explaining why its approach is okay.
Pull Request: https://projects.blender.org/blender/blender/pulls/126970
- Call the data pointers "elems" and the grid indices "grids"
- Remove null check that really shouldn't be necessary
- Use Span and range based for loops
- Use accessor function instead of raw node field access
Use `IndexMask` for a selection of nodes, and remove the temporarily
added type-agnostic functions for PBVH node data access. This change
results in a lot of boilerplate change since all iteration over nodes is
affected, and the proper types for nodes need to be used to access
their data.
Until leaf and inner nodes are split, the `all_leaf_nodes` function has
an unfortunate signature now since it needs to return an `IndexMask`
as well. That should be simplified in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/126944
This implements the `Warning` node that allows node groups to communicate
expectations about input values to the user.
By default, the `Warning` node is only evaluated if the node group that contains
it is evaluated in any way. This is better than always evaluating it, because
that could trigger lots of unnecessary evaluation in parts of the potentially
large node tree which should be ignored. In this basic mode, the output of the
node should not be connected to anything and it must not be in a zone.
For more fine-grained control for when the `Warning` node should be evaluated,
one can use the boolean output which is just a pass-through of the `Show` input.
If this output is used, the `Warning` node will only be evaluated if its output
is used. A simple way to use it is to control a Switch node with it that e.g.
"disables" a specific output when the inputs are invalid. In this case, the
`Warning` node may also be in a zone.
The node allows the user to choose between 3 severity levels: Error, Warning and
Info. Those are the same levels that we use internally. Currently, the error and
warning mode are pretty much the same, but that may change in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/125544
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
