Removes the SculptPoseIKChain and SculptPoseIKChainSegment structs from
BKE_paint.hh, substituting them for the bare minimum vertex data needed
to draw the overlay using the pose brush.
Moves the needed structs into sculpt_intern.hh, ideally they should be
local to sculpt_pose.cc, but the chain is needed in StrokeCache, so
further refactoring is needed before it can be reduced in scope.
Pull Request: https://projects.blender.org/blender/blender/pulls/126009
There were two issues. One was that the normals VBO wasn't created
with the correct size. The other was that there were empty VBOs created
which can apparently also cause crashes.
Pull Request: https://projects.blender.org/blender/blender/pulls/126041
Moves SculptBoundary out of BKE_paint.hh and into sculpt_intern.hh
Like other cached data, this ideally should not be this exposed, but
reducing its inclusion in any other file that uses BKE_paint.hh is a
good start.
Pull Request: https://projects.blender.org/blender/blender/pulls/126010
Ever since b6a76243cd there was some redundant math
that just ended up with the value 1. Factor that out to simplify the code,
making future refactors cleaner.
SEQ_transform_sequence_can_be_translated, SEQ_transform_single_image_check,
SEQ_can_use_proxy can all trivially take const Sequence argument.
Made SEQ_give_frame_index take const Sequence too, by removing the
"modify seq strobe to be at least 1.0" code. The strobe itself is only
ever used inside the same function, and is already guarded by
"is strobe > 1.0" check.
Original code seems to be coming all the way from 2009 with
commit message "2.5. 12k lines of sequencer back!" (03fc5696dc).
Pull Request: https://projects.blender.org/blender/blender/pulls/126021
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 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.
