When appending e.g. an object, it's generally expected that it is not just
appended but also added to the active collection. Something similar happens for
adding collections, or just geometry like a mesh data-block. This is called
"loose data instantiation" in the source code.
Which data is instantiated and how depends on context. Generally, it's best to
first do the low-level link or append operation and only afterwards do the
instantiation at a higher level where more context is known. For example, when
dragging an object asset into the 3D view, it's expected that the object is
added to the active collection. When dragging a node group into the node editor
that uses an object internally (e.g. as mesh storage), not so much.
This patch adds a new `BKE_blendfile_link_append_instantiate_loose` method that
does the "default instantiation", i.e. the one we want to happen when using the
general link/append operator to import data. Instead of calling this directly
from low level `BKE_blendfile_append`, it's now called in `wm_link_append_exec`
(and other places where desired).
Furthermore, `view3d_ob_drop_copy_external_asset` does not use this anymore, but
explicitly adds only the dragged object to the active collection. Some places,
e.g. when linking/appending using the Python API, don't do any instantiation at
all. They didn't do this before either, but it was way less obvious (it used
`BLO_library_link_params_init` instead of
`BLO_library_link_params_init_with_context`). Now there is always an explicit
call to do instantiation in higher level code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125814
This fixes an issue with `finalize_commands`, simplify
packing inside `Draw` command struct and remove the vertex
length limitation, replacing it with instance count limit
which is less likely to be used.
Part of #118145.
Replaces any calls with a call to SCULPT_vertex_co_get and the active
vertex. Eventually we don't want to support this particular method of
retrieving position data, but for now this makes the uses of the
active_vertex field more clear.
Pull Request: https://projects.blender.org/blender/blender/pulls/125998
This is getting in the way of refactoring to the BVH. It hasn't been
working for over a year and we want to reevaluate the approach
before committing to this anyway.
While docking, dragging into the source area allows split. Holding Ctrl
causes snapping just like when not docking. This PR just includes this
in the status bar keymap info while doing so.
Pull Request: https://projects.blender.org/blender/blender/pulls/125990
With the icons changes we no longer need any extra spacing between icon
and text. And negative space for the narrow mouse icons can be 0.5.
Simplifies it a bit and makes it slightly tighter.
Pull Request: https://projects.blender.org/blender/blender/pulls/125987
When using the USD export method with Hydra storm[1], problems can occur
because of how this was integrated alongside the direct Hydra method.
The direct hydra support was initially added in Blender 4.0 and the USD
option was integrated at the same time in order to provide a mechanism
for comparison and double-checking each implementation.
In the context of this bug, for Viewport previews and renders, the Hydra
engine is initially triggered and executed as part of an "engine update"
call from the various v3d draw managers. During this call the USD export
is attempted.
For sub-d meshes the USD export machinery will, by default, attempt to
apply the correct Subdivision Scheme attribute to mesh data. That means
it will export the unsubdivided base mesh with an attribute letting the
downstream receiver of the data know they should do the subdivision on
their own. This subdivision scheme support was added in 4.1.
However, in order to do this, USD must first disable the Subdivision
modifiers in Blender before exporting the mesh. Disabling modifiers
triggers depsgraph processing and, unfortunately, this processing will
also trigger an "engine update" for Hydra... again.
Reentrancy is not supported here. See stack trace in original bug.
So, instead, change the USD export option to output a subdivided mesh to
begin with. This has the following ramifications:
- Viewport material preview and render modes no longer crash when sub-d
is used
- While F12/final renders did not crash, changing this option will now
properly render the subdivided geometry when using the USD export
method. Allowing our USD / Hydra render tests to align more closely.
The direct Hydra option was already pre-subdividing mesh data anyhow.
This will require updating the USD reference render images.
- The underlying integration issue is not fixed. Triggering a USD export
inside the "engine update" call path seems error-prone and can lead to
similar issues in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/125840
- Avoid doing anything when no axes are disabled.
- Avoid matrix multiplication when local space orientation is used.
- Combine enabled axes for cloth forces and mesh filter translations.
Part of #118145.
Apply the brush refactor to the remaining part of the cloth brush.
Factor some of the forces calculations into common functions
shared between the implementations for the three geometry types.
Also change the cloth filter a bit to ease sharing code with the brush.
The `deformation_pos` array expects values to be set, not appended to to
prevent too much energy from being added to the simulation.
Additionally, the cloth simulation target expects the original
coordinates to not be updated every step of the brush to perform the
deformation.
Pull Request: https://projects.blender.org/blender/blender/pulls/125982
Temporary results are essentially results with a default reference count
of 1, so we default to 1 for all results and set the initial reference
count differently as need.
Covers OS detection, CPU architecture, bitness, and compiler family.
The goal of this change is to provide easier to use and remember checks
for these things. For example, with this change code like
```
#ifdef _WIN32
...
#elif defined(__APPLE__) || defined(__FreeBSD__) || defined(__NetBSD__) || \
defined(__OpenBSD__)
..
#endif
```
becomes
```
#if OS_WIN
...
#elif OS_MAC || OS_BSD
...
#endif
```
The code is originally based on build_config.h from Chromium, which was
first modified for Libmv, then to some other projects, and now is
adopted for Blender itself.
The checks are relying on the -Wundef to provide hint of cases when an
include is missing prior to the platform-specific checks.
This change only introduces possibility of cleaner checks and does not
start actual refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/118908
Add a toggle for Fast GI Approximation in the header of the panel,
following Cycles layout.
Move the `Max Roughness` setting inside the panel, and rename to
Threshold.
Since Fast GI Approximation only has any effect when Threshold/
Max Roughness is below the max (1.0), gray out the rest of the
panel when at that value.
Co-authored-by: Clément FOUCAULT <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/125452
This reverts commit 780dc67f6d.
The patch caused a performance regression when inserting many
keys via python, as is done with the "Whole Character"
keying set.
Regression report: #125888
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
The issue was caused by blender/blender@f3b393a74a
Before that commit, the keylist would be built including 1 keyframe
outside the range on each side (if there was one).
After that those would be ignored, leading to the following issue
Fixes#125861
The fix is to ensure the keylist is built with 1 key outside the given range.
Pull Request: https://projects.blender.org/blender/blender/pulls/125807
Checks in this operator were simply not handling liboverrides properly.
Also refactored that code, grouping & refining checks and error
reports, add comment about why there is specific weird undo handling,
improve variable namings, remove non-sensical assumptions and code
regarding orig/eval objects, etc.
In 4.2, Alembic points are imported as PointCloud objects instead of as
mesh vertices.
The code inside Mesh Sequence Cache which converts geometry into a
bounding-box mesh when using Render Procedurals needed to be updated
to support PointCloud objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/125846
The operator redo seems to behave the same before and after this
change. Conceptually there should always be data in the current
undo node since the operator pushes undo nodes when it starts.
That shouldn't be any different between redo and normal execution.
If this turns out to be necessary, it can be added back and the code
can be improved to show why it's actually necessary.
When dragging an area from one window to another, the target location
was out by the monitor dot-pitch on macOS Retina displays. This commit
fixes this by converting the window position coordinates to the display
native pixel size via a new `WM_window_pixels_coords` API function.
Pull Request: https://projects.blender.org/blender/blender/pulls/125926
Part of #118145.
At a high level, the process for a boundary brush works as follows:
* On the first step of a symmetry pass, initialize data in the
`StrokeCache`
* Initializes propagation steps and relative brush factors on each
element of the mesh
* Initializes specialized per-vertex data for certain brushes
* Grab original position data
* Apply mask & automask values to precalculated vertex-sized factor
array
* Filter verts that are "uninitialized" by the initial pass
* Filter verts outside of the symmetry area
* Calculate the deformation-specific transform
* Apply this transform either to the mesh directly or to the cloth
simulation
Of the deformation types, *Expand*, *Inflate*, *Grab*, and *Smooth*
behave similarly to one another (applying a displacement), and *Bend*
and *Twist* behave similarly (applying an angular displacement).
Unfortunately, as is, this PR introduces a lot of extra, duplicated
code. Most of the brushes are similar in their behavior, but differ
slightly enough to make abstractions difficult. One potential path
forward could be to create custom classes to hold or specify necessary
data and use virtual functions on a per-node level to avoid doing this
in a hot loop.
Pull Request: https://projects.blender.org/blender/blender/pulls/125845
Outliner Data API allows browsing most of Blender's data, including in
other areas and spaces. If an area being browsed is the non-active
data (previous space) belonging to Properties, its runtime can be
null and therefore its search_string. This PR just handles this
situation by checking for null runtime. Despite the bug report, I
don't think this should go into 4.2 - maybe back-ported to a later
point release.
Pull Request: https://projects.blender.org/blender/blender/pulls/124374
Part of #118145.
- Specialize the algorithm for each geometry type.
- Store the cache in an array instead of an attribute. Attributes are
meant to store user-edited data, not derived data like caches.
- Calculate the island IDs with a parallel disjoint set instead of a
flood-fill algorithm.
- Avoid storing the island ID array if there is only one island, saving
1 byte per vertex.
Pull Request: https://projects.blender.org/blender/blender/pulls/125907
Part of #118145.
This adds a bunch of duplication, but it significantly simplifies the
next step of specializing each filter operation per geometry type.
That will reduce some of the logic duplication too by extracting
it to separate shared functions.
