It looks like this specific case never really worked. This wasn't found before,
because in the large majority of cases, execution uses a more optimized code
path instead of this general one.
Pull Request: https://projects.blender.org/blender/blender/pulls/128993
During development of Collection Export, it was noticed that our various
IO formats deal with errors in vastly different ways [1]. The crashes
were all fixed but now the motivating scenario is as follows:
If you setup a Collection Exporter for OBJ, STL, or PLY, and if it
runs into an error during processing, the C++ operator will return
"FINISHED" to the caller but the operator will also RPT_ERROR. This
causes the caller, Collection Export, to indicate "success" to the user
but the RPT_ERROR then causes a UI report that indicates failure.
This PR chooses to use the presence of the RPT_ERROR as indication of
"CANCELLED" operator status and should be safe enough to also apply
to 4.2 LTS.
This aligns with what Python does [2] and with what the new GSoC import
nodes have chosen to do [3]. Though doing this on import isn't quite
correct so this PR does not add that in to the base import operators.
Alembic and USD are better behaved in this scenario already. However,
they have their own quirks to follow-up afterwards.
[1] https://projects.blender.org/blender/blender/issues/117881
[2] https://projects.blender.org/blender/blender/src/branch/main/source/blender/python/intern/bpy_capi_utils.cc#L25
[3] https://projects.blender.org/blender/blender/src/branch/main/source/blender/nodes/geometry/nodes/node_geo_import_obj.cc#L49
Pull Request: https://projects.blender.org/blender/blender/pulls/127525
Any brush that used the `restore_position_from_undo_step` codepath (i.e.
brushes that use `OrigPositionData` to calculate their deformations) had
the possibility to cause artifacts due to the nested tbb parallelization
causing incorrect usage of TLS data.
To fix this we add a call to `threading::isolate_task` to prevent thread
stealing.
Pull Request: https://projects.blender.org/blender/blender/pulls/129020
The brush does not use the value calculated from brush_strength, this
commit silences the assert by just handling the case statement for this
brush type with a static value of 0.0f.
Pull Request: https://projects.blender.org/blender/blender/pulls/128936
Followup to 682161283e.
This type better reflects the intention of a read-only string reference,
and `std::string` should usually be used for owning string variables
only.
The tool-tip generated for FileHandler drag-n-drop may be obtained from a
different context where the dropbox poll function is invoked, which could
generated an incorrect tool-tip since FileHandlers are polled again in a wrong
context.
This can be solved by ensuring the same context is used, however the tool-tip
could be drawn in different windows.
To avoid undefined tool-tips , this generates the tool-tip in place when the
dropbox poll function is invoked.
Pull Request: https://projects.blender.org/blender/blender/pulls/125037
VK_EXT_dynamic_rendering_unused_attachments is required for correct working.
Renderdoc hides this extension, but most platforms do work. However the
Windows Intel driver crashes when using iGPUs; they don't support this
extension at all.
This change does a more strict extension test so drivers that do not
support this extension will fallback to OpenGL. When using renderdoc it
is now allowed to compile blender with `WITH_RENDERDOC=On`.
Future developments are needed to add support for Intel iGPUs on
Windows.
Pull Request: https://projects.blender.org/blender/blender/pulls/128986
Resources are shared, when running multiple contexts on the same thread.
Cycles uses the same context on multiple threads and expected same resources.
This change will introduce a single render graph per context and an updated
resource management. Render graphs are not shared anymore; Resource pools
are still shared, but garbage collection depends on the thread and if
background rendering is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/128983
Cycles uses multiple threads to send commands to the GPU. The current
command buffer structure assumed that all commands from the same context
were send via the same thread. This wasn't the case and could lead to
recording commands to command buffers that are still pending (preparing
commands to send to GPU).
This is fixed by creating a command buffer each time a render graph
submits its work.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128978
When allocating a host visible buffer it could be that the returned
buffer was not host visible and access to the buffer would write to
unallocated memory.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128977
When using cycles in the viewport there it uses render threads and
workers to update the viewport. All threads can record commands to the
queue and needs to be synchronized. This didn't happen leading to
incorrect renders.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128975
Multiple threads can access the same device queue from different
threads. This could happen when doing a cycles preview render, baking
eevee volume probes or generating material previews.
This PR adds a mutex around access to the device queues.
Detected when researching #128608
Pull Request: https://projects.blender.org/blender/blender/pulls/128974
These attributes are not guaranteed to exist. So they should either be used
conditionally, or with a fallback value. The fallback value for the opacity is
obvious, but for the radius it's more tricky. There is not a consistent fallback
value across Blender unfortunately. The one I used here is used in a couple of
places.
Pull Request: https://projects.blender.org/blender/blender/pulls/128847
# Fix 128078, Part I: Fix missing reverse endian switch of Action's `idroot`.
ID type code stored as ints (or shorts) need their endian switch to be
reverted (in case there is endianess conversion) on file read.
Interestingly, this was done for the deprecated IPO data (among others), but
not for the Action one!
NOTE: There is no versioning fix for this mistake, i.e. old files that
were saved from a BE system, then opened and re-saved from a LE system,
will still have totally invalid ID code values. This is not considered
as necessary currently, given that this `idroot` value is only
'informational' and not relied on by any part of the code.
# Fix 128078, Part II: GPv3 conversion code missing animation of Layers' location.
Also add code to the AnimDataConverter to ensure that actions get the
`idroot` matching their new ID owner type in GP data case.
Pull Request: https://projects.blender.org/blender/blender/pulls/128129
The layer/material/vertex group filter properties had already been added but they were
not exposed in the UI. Also the influence panel was missing. Now added in "rna_" function
of the modifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/128973
Depending on from where this functionality was called, it behaved
differently (there are three operators for this).
- from the GE, it uses `get_graph_keyframe_extents` [which falls back to
existing scene (preview) start/end frames if no real extends are found]
- from the NLA, it uses `get_nlastrip_extents`[which falls back to
existing scene start/end frames if no real extends are found]
- elsewhere (and this was reported in #128935) it uses
`get_keyframe_extents` but did not consider if extends were really
found.
The last case lead to startframe being set higher than endframe causing
a crash on playback.
This PR checks the return value of `get_keyframe_extents` [which tells
us if extends were found] and cancels out early.
NOTE: it would probably be nice if the behavior was consistent across
all editors, but since I think the right behavior is to not do anything
if nothing is selected (after all the description is "based on range of
selected keyframes"), I am going for correct behavior of
`ACTION_OT_previewrange_set` but leave the Graph Editor and NLA editor
operators untouched for the time being.
Pull Request: https://projects.blender.org/blender/blender/pulls/128981
Due to rounding errors in `wm_gesture_straightline_do_angle_snap`, it
could give out a snapped result that's meant to be 45 degrees but does
not have equal X/Y distances after converted to integer. Since 45
degrees can be used to make a equal length structure, it's best to make
sure that resulting X/Y values are the same if the angle is multiple of
45 degrees.
This fix would be effective for all tools that uses this "straight line
gizmo".
Pull Request: https://projects.blender.org/blender/blender/pulls/128683
This patch fixes broken connections and effect strips which would arise
in some cases when trying to split connected strips with effects.
This happened in case an effect strip was being split -- first, its
effect chain would be added to a VectorSet of seqs, but then, only the
connected strips of the original seq (in this case the effect strip)
would be added to the VectorSet. Fix by iterating over the entire list
and adding connected strips.
Additionally:
- Add a final SEQ_iterator_set_expand() for SEQ_query_effect_chain() in
case these connected strips had effects themselves.
- Move the seq_edit_split_operation_permitted() check after the entire
chain is evaluated to avoid bugs w/ locked strips being editable
before.
Pull Request: https://projects.blender.org/blender/blender/pulls/128670
The issue was that if the seqslide was cancelled such that the
`new_frame` of the left handle was greater than its previous
right_handle (before the cancel), `SEQ_time_left_handle_frame_set()`
would clamp this value and so the left handle would not properly restore
itself.
Fix by updating both handles at once (right handle first) if both
handles are selected and the cancel jump travels in the right direction.
This also seems to fix the situation where strips w/ both handles
selected would be erroneously detected as overlapping when moving them
rapidly side to side.
Pull Request: https://projects.blender.org/blender/blender/pulls/128740
If points are beind the camera, we don't really want to erase them. This
patch marks invalid coordinates thus preventing them from intersecting
with a eraser.
The reason for using a large value to indicate "invalid coordinate"s are:
- No need to further break down the way we process `src_to_dist` point matching array for `hard_eraser` `soft_eraser`, makes the entire logic much easier.
- No eraser is gonna be touching such a large coordinate of `1e20`.
Technically there's this case where if a segment crosses the near or far clipping plane (to handle this correctly, you'll need to split that segment into two at the clipping plane position and it increases complexity a lot), and then you will have undefined erasing behaviour, however the worse case is that the one segment was completely removed, and in such case I think it's acceptable.
Pull Request: https://projects.blender.org/blender/blender/pulls/128738
PBVH is null when redoing the move operation. To fix this,
update active object data from evaluated object before sending
undo_push.
Also fixed the crash in cache_init() after updating depsgraph
Pull Request: https://projects.blender.org/blender/blender/pulls/128625
Part of the brush assets project followups, see #116337.
Based on feedback, it seems important to indicate to the user when a brush has
unsaved changes.
There's no reliable updating mechanism we can use or hook into here, except for
RNA "update" callbacks. Brush data gets changed in many places in code, the only
way to do this seems manual tagging every time a brush property gets changed.
This PR introduces `BKE_brush_tag_unsaved_changes()` for this. I spent some time
going through all brush properties to ensure changes call the tagging function.
A known limitation with this will be that changes to dependencies won't be
indicated in the brush. E.g. Changing the texture attached to a brush won't make
the brush be indicated as changed.
The UI to indicate the changed brushes is being discussed still, see #128846.
Pull Request: https://projects.blender.org/blender/blender/pulls/128845
While splitting areas the two parts are shown with rounded outlines,
but some of the underlying content can show through in the corners,
spoiling the effect. This PR just erases anything in those corners,
making it look cleaner and rounder.
Accidentally merged to main first with c3ea941273.
If a `DrawGroup` contained both inverted and non-inverted scale
the command generate shader would output the `resource_id`
content at conflicting indices. This is because the number of
instances stored inside the `DrawGroup` are the original
count before multiview. Actually, only `start` was taking the
multi-view count into account.
We cannot modify the value on CPU otherwise it would increase
the instance count for each submission. So the fix is to
pass the view count to the command generate shader and
multiply the instance count where needed.
Fix#128085
Pull Request: https://projects.blender.org/blender/blender/pulls/128854
This is likely caused by local_ray_up being degenerate with
very small radii. This is a temporary fix and should be revisited
later.
The issue is that the real fix is likely to have a higher
performance cost.
Fix#124636
When using OpenGL on Intel ARC the driver reports a max 3d allowed size
of 2048. The volume probe will create a texture that doesn't fit in this
dimension when selecting a probe size of 512 or 1024 MB.
This PR will reshape the volume pool atlas texture until it found a shape
that is optimal and fit on the device. When reshaping selects a different
pool size a warning message will be displayed as it might change the
visual quality.
When reshaping the smallest row size will be selected in order
to improve the occupancy. Reshaping will only happens when a
different setting is set in the `Performance->Memory->Light Probes Volume Pool`.
NOTE: Needs to be backported to 4.2
Pull Request: https://projects.blender.org/blender/blender/pulls/128877
The error message related to shadow updates in `eevee_shadow.cc`
currently contains a typo:
`"Error: Too many shadow updates, some shadow might be incorrect."`
This sentence should use the plural form of "shadows" to correctly
describe the context.
Fixing this typo ensures clarity and correctness in the error message,
providing developers and users with the appropriate feedback when
encountering shadow update issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/128865
Technically a regression in [0] although it matches behavior prior
to v3.3 going back to 2.7x. The fix for #101883 [1] added a check
for the vertex number changing after the number was zeroed,
causing the shape key to be cleared in most cases.
While the handling of shape-keys in OBJECT_OT_convert wasn't well
defined - clearing the shape-key means in the evaluated coordinates
are always used so it is preferable.
Now the operator ensures the old (un-evaluated) shape-key isn't used.
[0]: 0791f53029
[1]: be32882e1c
This commit changes the Clay Strips brush in the following ways:
* Removes hardcoded displacement and scaling of brush matrix
* Applies a falloff to the factor based on the distance to the point in
the brush-local z-axis
This change has the effect of reducing the brush influence on nearby or
other back-facing planes, reducing overall unwanted deformations.
Pull Request: https://projects.blender.org/blender/blender/pulls/128775
The usage of `hide::node_visible_verts` in this function does not work
as intended, as the resulting span is misaligned with the sliced
per-node mask data. To fix this issue, this commit adds a similar helper
function to copy all hidden vert data and applies changes to all of the
node vertices.
Pull Request: https://projects.blender.org/blender/blender/pulls/128828
Object without lightprobe visibility should still
cast shadows during baking. They should only not
bounce indirect lighting.
This is more visible now that shadow linking is supported.
Fix#128812
Tooltips for assets in the asset shelf now don't only display the name,
but also the description saved in the asset's metadata. This is what we
usually do when assets are displayed, for example in the asset browser
or in add menus. Here it was just a small bit of polish that was never
done.
Change the `Action.id_root` RNA definition such that
`Action.bl_rna.properties["id_root"].enum_items` returns all valid
values for that property. This was the Blender 4.2 (and older) behaviour
as well.
The only difference now is that v4.3 adds a new `UNSPECIFIED` enum item,
which is not a valid ID type, but is a valid value for `Action.id_root`.
Some more context:
In Blender 4.2 the `Action.id_root` property was a hard-coded list of
all ID types. To add the `UNSPECIFIED` item in v4.3, this was replaced
by an 'items' callback. The way Blender deals with this by default is
such that querying `Action.bl_rna.properties["id_root"].enum_items`
returns its hard-coded default list, and not the result of that 'items'
callback function.
For Action Slots (which will be released in v4.4 but are already in the
sources as experimental feature), there is a similar property that is
implemented in a way such that its `.enum_items` always returns the
proper list. This commit updates the `Action.id_root` RNA property
definition so that it shares code with `ActionSlot.id_root`, fixing the
reported issue.
Note that the `ActionSlot` type is not exposed to RNA in Blender 4.3,
it's just some internal code that is now shared.
Pull Request: https://projects.blender.org/blender/blender/pulls/128834
The armature modifier calls `BKE_armature_deform_coords_with_mesh` (and
thus `BKE_id_defgroup_list_get`) for legacy curves as well, these are
only "riggable" via envelope weights though (this situation could be
made a bit clearer when parenting -- which is for another commit
though).
So to avoid the (rightful) assert in `BKE_id_defgroup_list_get`, only
call it in case vertex groups are supported (and possibly used later on
-- which is never the case for legacy curves).
Note: this was reported in chat by @LazyDodo because the CurveArmature
test was failing in debug
Pull Request: https://projects.blender.org/blender/blender/pulls/128792
