When not all links connecting to a multi-input socket are duplicated
with the multi-input, the link position needs to be updated to avoid
the links being offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/122074
Different pipelines standardize on different XForm op setups (T-R-S,
T-orient quat-S, Matrix). Having this options means that this standard
can be chosen at export time instead of having to patch on load.
Speaking from experience, this is a very helpful option.
Co-authored-by: kiki <charles@skeletalstudios.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121627
The main change is avoid storage of redundant data in the subdivision
draw cache, mainly by replacing reverse lookup from subdivided edge to
coarse edge. This way loops are structured as iteration over coarse
edges instead of iteration over subdivided edges with optional behavior
for vertices with matching base mesh faces. With that inversion the
information in the draw cache is trivial (or duplicated from an array
in `MeshRenderData`), so it's all removed, except for the subdivided
loose edge positions. That array is also shrunk though, by not
duplicating positions in between each subdivided edge. Its calculation
is more efficient for the same reason too.
Overall, besides code simplification, the effect should be lower
overhead with loose edges with GPU subdivision. Admittedly this isn't
a very important use case, but it's part of a general refactor trying
to use better data oriented design in this area (#116901).
Pull Request: https://projects.blender.org/blender/blender/pulls/122071
Fixes#107880.
When making a linked asset local, you typically wouldn't want this new
data-block to suddenly be part of the asset libraries this file is in. To the
user it seems like making such a data-block local also implicitly makes it an
asset. Appending an asset already handles this, and clears the asset data by
default.
This patch modifies the `bpy.types.ID.make_local()` method, as well as all
internal calls to the make local functions, so that asset data is cleared by
default. The Python method has a new `clear_asset_data` parameter (optional,
true by default). Maybe this should not be optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/110197
We call the `shadow.end_sync()` another time when running
the baking pipeline so that the sun shadow maps can
use the correct camera setup and scene bounds.
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
* Linked datablocks should not point to local datablocks.
* Main datablocks should not point to non-main datablocks.
This is checked now both in the poll function for UI lists, and in the
pointer assignment code used by the Python API.
This PR implements debug groups in the render graph. Each node contains
a reference to the debug group they belong to. During scheduling the
nodes can be reordered and the correct debug group needs to be
activated.
This is done by keeping track of the current debug group. When a
different debug group is needed, the needed ends/begins are added
to the command buffer.
This mechanism also cleans up debug groups that are not used at all
as they don't have any nodes associated to it.
Pull Request: https://projects.blender.org/blender/blender/pulls/122054
Image's render result might get freed from another thread while the
compositor is running.
Add an utility function which invokes callback on the image's stamp
data from a thread-guarded block.
Ref #118337, #121761
Pull Request: https://projects.blender.org/blender/blender/pulls/121907
Image operation's get_im_buf() function was not thread-safe:
- It had TOCTOU issue around calculating multi-layer indices and
requesting to load the image buffer.
- It accessed render result, render layer and pass pointers without
any thread guards.
This change moves all the logic needed to access the image buffer
into a single function with proper guards around the access. The
result is user-counted, so it is usable in a thread even if another
thread modifies the image.
The is still potential TOCTOU in the compositor since the image is
acquired twice: once from init_execution(), and once from the
determine_canvas(). It could cause issues if image resolution is
changed between these calls. It is still to be looked into.
Ref #118337, #121761
This is avoids reference to data which can potentially be freed from the main
thread while the compositor job is running.
There is still some direct access to RenderResult and access to its layers
and passes in the operation implementation, but is is all internal and will
be worked on later. The purpose of this patch is to avoid unsafe pointers in
the API of the operation.
Should be no functional changes.
Ref #118337, #121761
There are a couple of goals achieved with this change:
- The logic itself is de-duplicated between the Image and Cryptomatte
nodes.
- The logic which accesses render results, images, etc is more local
to the place where it needs to be used. Currently it does not matter
too much, but it allows to properly guard the access to be thread
safe.
Ref #118337, #121761
Allows to modify the user without worrying to store/restore old values,
potentially resolving threading conflicts.
Should be no changes on user level.
Ref #118337, #121761
The `Layer::get_frame_duration_at` was not working for frames
with a fixed duration. While this is not an issue at the
moment (because fixed duration frames are not exposed
yet), this would have been broken in the future.
This fixes the issues, cleans up the code a bit, and also
adds regression tests.
Pull Request: https://projects.blender.org/blender/blender/pulls/122052
This patch implements the Fog Glow Glare node by porting the CPU
implementation, so it is not GPU accelerated and is not expected to be
realtime. However, after d4bf23771d, it is now fast enough to be usable,
see that commit for more information on the implementation.
The only difference is that the kernel part of the convolution is cached
in the realtime compositor, so it should be about 30% faster than CPU
for interactive editing.
In the future, this implementation will be replaced by a proper GPU
implementation, likely based on VkFFT.
Optimize the Fog Glow glare code by making sure TBB is used for
threading, it only uses the needed space for the frequency domain, and
only load the TLD storage once for every threaded invocation.
Previously the VKShaderInterface was constructed twice. This was
due to a limitation of the Shader api. Specialization constants
introduced an Shader::init function which allows to pre-initialize
the shader interface before a shader is finalized.
Pull Request: https://projects.blender.org/blender/blender/pulls/122049
I can't reproduce this on release or debug builds. But from the strack
traces provided in a couple reports, it looks like the runtime pointer
is null. This makes sense because BKE_previewimg_blend_read is not
called here which is what allocates the runtime struct on file read.
To maintain a "valid" PreviewImage in more code and avoid the
complexity of making the runtime pointer optional, just allocate
it in BLO_blendhandle_get_preview_for_id.
There were multiple places in the GPv3 code that assumed that the
frame key is equivalent to the start frame of the frame with that key.
But this is not the case. The `FramesMapKeyT` is either the start frame
*or* the end frame (for frames with fixed duration).
This adds a new function `start_frame_at` that returns the start frame
number of the frame at `frame_number` or -1 if no such frame exists.
One place needed the index into sorted keys (for onion skinning) so
this was replaced with a new function `sorted_keys_index_at`.
With these changes, `Layer::frame_key_at` is now a private method.
Pull Request: https://projects.blender.org/blender/blender/pulls/122045
Because the shapekey editor is trying to have a more fancy UI with
sliders on each "Relative" shapekey value, all other animatible
properties were not drawn.
This patch now makes it possible to easily work with actions that have
non "Relative" keys. Before this was almost impossible as the user could
not see what action they had selected or which non relative keys were in
them as the UI would think that the action was empty.
While working on this I also noticed that there are some other
properties in relative mode that is not in the action editor either
(Range Min/Max). I added a TODO about that in the code as one would
probably want to group those together in a nice way with either
respective shapekey.
Pull Request: https://projects.blender.org/blender/blender/pulls/121829
Other code also uses the suffix `T` to indicate that this is a type.
Note that `FramesMapKeyT` is just an `int` but with a very specific
meaning. Hence the alias to avoid confusions.
Filling an area is typically done with a "Fill"-only material. It should
be possible to fill the same area again (paint "over" the fill stroke)
and get the exact same shape. The draw code for the fill tool, however,
was rendering all strokes with a "Stroke" material, creating a thick
boundary that shrinks the fill area with every iteration.
Image render code for the fill tool now ignores any strokes that don't
have a stroke material.
Pull Request: https://projects.blender.org/blender/blender/pulls/122034
`Weight` & `Threshold` sliders should **not** show in case of `Type` :
`Custom Normal` and **should** show for both `Type` : `Face Area` &
`Type` : `Corner Angle`
In code, it looks like we are gathering `loop_weight` with `val`.
- this is always 1.0 for `EDBM_CLNOR_AVERAGE_LOOP`
- this is taken from `BM_face_calc_area` for
`EDBM_CLNOR_AVERAGE_FACE_AREA`
- this is taken from `BM_loop_calc_face_angle` for
`EDBM_CLNOR_AVERAGE_ANGLE`
Code then compares not equal those values with given threshold, but for
`EDBM_CLNOR_AVERAGE_LOOP` this will never trigger (since all values are
the same), thus `count` is always zero which makes the effective
`n_weight` always 1. So all loop split normals are averaged for a vertex
with the same weight (seems to make sense to me -- at is just plain
average)
Long story short: the condition to show `Weight` & `Threshold` sliders
is just flipped (these only apply for the methods that take neighbor
faces into account).
Pull Request: https://projects.blender.org/blender/blender/pulls/121864
The Sun Beams node produces NaNs when the ray length option is zero.
This is due to zero division in the code, which we avoid by skipping
computation altogether when the ray length is zero.
