Endian switching when loading 64bit blend files on a 64bit system was
crashing as the endian switching is only applicable when loading
on 32 bit systems.
This crash goes back to 2.7x, it looks like this never worked
all the way back to the first commit.
Regular rendering uses a custom blend mode, but render passes renders to
2 separate textures. This wasn't configured correctly inside the
fragment shaders. This patch adds a switch to configure the fragment
shader with the correct attachments.
Backport to Blender 2.83.
Reviewed By: Clément Foucault
Differential Revision: https://developer.blender.org/D9038
Calling PyEval_ReleaseLock() was crashing with Python 3.9
because it accessed the NULL pointer set by PyThreadState_Swap().
This happened when calling ViewLayer.update() for example.
While the existing logic could be fixed by swapping the thread-state
back before calling PyEval_ReleaseLock(), this depends on functions
which are tagged to be removed by v4.0.
Replace use of deprecated functions by calling PyEval_SaveThread(),
instead of inlining the logic, using _PyThreadState_UncheckedGet()
to prevent Python aborting.
The call to PyEval_ThreadsInitialized has been removed
as threads are now initialized with Python.
This could be replaced with Py_IsInitialized() however it doesn't look
like this is necessary.
This is compatible with Python 3.7 & 3.9.
The logic of `BKE_sculpt_update_object_for_edit` was not correct. such
low-level functions should typically never preform depsgraph evaluation
themselves, they should be able to rely on getting a fully evaluated
depsgraph and just get needed data from there.
Supporting that required fixing other broken code higher in the
callstack, namely:
* `ED_object_sculptmode_enter_ex` was freeing evaluated data, for no
valid reason it would seem.
* `sculpt_undosys_step_decode` was ensuring an evaluated depsgraph
**before** calling `ED_object_mode_generic_exit`, which would
invalidate a lot of evaluated data.
Note that it is fairly difficult to track down all code paths leading to
`BKE_sculpt_update_object_for_edit`, so there may be still cases where
this gets called with improperly evaluated depsgraph.
Reviewed By: sergey
Maniphest Tasks: T81854
Differential Revision: https://developer.blender.org/D9270
This lets add-on authors avoid false positive leaks when exiting.
In particular GPUShaders's although it applies to any PyObject that
stores memory allocated by guarded-alloc.
While this does add overhead on exit, on my system it's
under 1/100th of a second with all addons enabled.
See: T71362
This was caused by a wrong flag equality check when in xray mode because
the xray mode was masking the effect option flags that are not supported
in this mode. This means the never passed and the TAA was reset before
every redraw, leading to infinite rendering.
The example file in T81218 has a driver that maps a bone's X-location to
the number of BBone segments. This caused a dependency cycle, which
resulted in bad thread serialisation, which caused the crash.
This patch breaks the dependency cycle `BONE_LOCAL` →
`DRIVER(bones["Bone"].bbone_segments)` → `BONE_LOCAL`. The 'Driver Data'
relation now points to `BONE_SEGMENTS` when the driven property starts
with `bbone_`.
Differential Revision: https://developer.blender.org/D9122
The output layout was wrong and it's a mistery why it works on most
implementations since it's clearly a wrong usage.
Thanks @sebbas for helping narrowing down the issue.
Warp & weight vertex-group editing modifiers miscalculated vertex weight
inversion, the weights were multiplied before being subtracted from 1.
Ref D8241
Object in the 2.7x file is on no layer at all, while this is not really
expected nor considered valid, better to cope with the case gracefully
than crash.
To be backported to 2.90 and 2.83.
On systems with 512kb stack this happened at around 13k points.
This happened at times with grease-pencil, although callers that
frequently use complex polygons should be using BLI_polyfill_calc_arena.
RNA diffing code was not dealing properly valid NULL PointerRNA (like
the empty texture slots of a ParticleSettings e.g., which were cause of
crash in that report).
To be backported to 2.90 and 2.83.
During undo/redo read code is expected to clear the `OB_MODE_EDIT`
bitflag of `Object.mode`, for some reasons.
This was not done anymore for re-used Objects, we need to add a special
handling case for that too.
Should be backported to 2.90 and 2.83 (will probably not be straight
forward for the latter).
Entering edit-mode after creating shape keys on a blank mesh would crash.
Regression in 9b9f84b317 which prevented initializing empty
shape keys when there is no shape key offset data available.
This prevents Blender from crashing when switching
to rendered view and the grid_data is NULL in the
lightcache (due to possible corruption), by switching
to the fallback lightcache. The fix extends the solution
for possible corruption in the cube_data as well.
Fix T79737
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D8835
The state of the passes was not set back after the first sample.
This is a simpler fix than rBecfbc5fb55d5 which needs the new draw manager
features from 2.90.
custom split normals data
Clearing custom split normals would get rid of the CD_CUSTOMLOOPNORMAL
layer - but editing data `lnor_spacearr` would be kept.
Adding a CD_CUSTOMLOOPNORMAL layer (if none exists yet) should be done
in `edbm_average_normals_exec` / `BKE_editmesh_lnorspace_update` /
`BM_lnorspace_update` / `BM_lnorspacearr_store`. The thing is that if
the editing data `lnor_spacearr` would still be valid after `Clear
Custom Split Normals Data`, blender would happily call
`BM_lnorspace_rebuild` instead. Doing that without a CD_CUSTOMLOOPNORMAL
layer is asking for trouble.
Now clear lnor_spacearr on `Clear Custom Split Normals Data` as well.
Thx @mont29 for feedback here.
Maniphest Tasks: T80159
Differential Revision: https://developer.blender.org/D8730
If a different object was active, clicking on a linked armature's pose
in the Outliner would enter Pose Mode for it.
This would actually cause a failed assert, but in release builds the
armature would just enter pose mode.
Steps to reproduce were:
* Link in armature object
* Activate a different object
* In the Outliner, un-collapse the armature object
* Activate Pose Mode by clicking on its pose there
Problem is again with the embedded data, we want to make those local
together with their owner ID, but sometimes we are actually dealing with
copies here, which are inheritently already local.
Code did not considered that possibility before, leading to access to a
NULL `lib` pointer.
This should also be back-ported to 2.83 LTS release.
Maniphest Tasks: T80104
Differential Revision: https://developer.blender.org/D8731
Issue was with our dear posebones again... when applying overrides we
keep the same address/pointer for the IDs themselves, (which avoids us
the need to remap their usages), but their inner data is often
re-allocated.
Therefore, we need once again to go over armature objects and invalidate
their posebone pointers.
This should also be back-ported to Blender LTS 2.83.
Maniphest Tasks: T80078
Differential Revision: https://developer.blender.org/D8734
Checks to preserve the active spline on duplication
required an active vertex too.
Now having no active vertex doesn't prevent duplicate
from keeping the spline active.
Reviewed by: @mano-wii
Ref D8729
This skips the subdivision operation if the mesh has no loops, avoiding
the crash.
Reviewed By: sergey
Maniphest Tasks: T80039
Differential Revision: https://developer.blender.org/D8696
Use invert_m4_m4_safe_ortho when joining objects so zero scaled axis
doesn't cause all points to be scaled to zero.
Instead geometry is left un-scaled on degenerate axes.
Report a warning in this case since users may want to adjust the
active objects scale.
Unlike invert_m4_m4_safe, this calculates zeroed axes.
Useful when we need to use the inverse of an objects matrix,
keeping the valid axis, only filling in the zeroed ones.
