In `calc_curve_deform` a factor is calculated without checking if
the divisior is zero or close to zero. This patch adds the missing
checks and sets the factor to zero if the division shouldn't be
computed.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D9645
Looks like prior to the introduction of mantaflow, the former
SmokeModifierData always had a domain initialized (even if its type was
set to None). Since mataflow, the FluidModifierData type needs to be set
to MOD_FLUID_TYPE_DOMAIN (otherwise domain is invalid)
Maniphest Tasks: T82729
Differential Revision: https://developer.blender.org/D9644
This was reported in the form of the eyedropper of the 'Parent' property
creating a custom property 'parent' if self was picked.
Problem arises when certain checks for setting rna pointer properties
failed (for example: the PROP_ID_SELF_CHECK check) and then a different
code path was entered (which was only meant for IDProperties).
Problem was introduced in rBa7b3047cefcb.
To solve, now first enter the branch for rna-based pointer properties,
then perform the sanity-checks (and if these fail: dont enter the other
unrelated codepath but instead do nothing)
Maniphest Tasks: T83055
Differential Revision: https://developer.blender.org/D9652
Pass codesign errors (if any) from codesign buildbot server to the
buildbot worker, so that the latter one can abort build process if
the error happens. This solves issues when non-properly-notarized
DMG package gets uploaded to the buildbot website.
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.
Buildbot has multiple cuda versions installed. Master selects the right
cuda version based on the architecture that is compiled. {D9179}.
When building BlenderLTS it defaults to CUDA 11.1 what isn't able to
compile `sm_30` architecture. This patch selects CUDA 10.1 as default.
Script create_msix_package.py will download the ZIP file
from the given URL. It will create the MSIX package
with the version number and publisher ID given.
Strongly recommended are the path to a valid PFX file, and the
password to use that PFX file. These are needed for signing
the resulting MSIX package. The signing step is optional though,
but the resulting MSIX package cannot be installed outside of the
Microsoft Store
Example
set VERSION=2.83.2.0
set URL=https://download.blender.org/release/Blender2.83/blender-2.83.2-windows64.zip
set PUBID=CN=PUBIDHERE
set PFX=X:\path\to\cert.pfx
set PFXPW=pwhere
python create_msix_package.py --version %VERSION% --url %URL% --publisher %PUBID% --pfx %PFX% --password %PFXPW%
Requirements:
* Python default from the Microsoft Store should do (3.8)
* requests can be installed with `pip install requests`
Note that for an LTS release that gets uploaded to its own LTS application release
in the store you need to specify the `--lts` switch on the command-line to the script.
Upon completion there will be a file with the
name blender-2.83.2.0-windows64.msix. In case PFX file and its password were
given on the command line MSIX package will also be signed for the Microsoft Store.
Related Wiki page: https://wiki.blender.org/wiki/Process/Release_On_Windows_Store
Reviewed By: jbakker
Maniphest Tasks: T77348, T79356
Differential Revision: https://developer.blender.org/D8310
On user level this fixes dead-lock of OpenCL render on Intel Iris GPUs.
Note that this patch does not include change in the logic which allows
or disallows OpenCL platforms to be used, that will happen after the
kernel fix is known to be fine for the currently officially supported
platforms.
The dead-lock was caused by wrong usage of memory barriers: as per the
OpenCL specification the barrier is to be executed by the entire work
group. This means, that the following code is invalid:
void foo() {
if (some_condition) {
return;
}
barrier(CLK_LOCAL_MEM_FENCE);
}
void bar() {
foo();
}
The Cycles code was mentioning this as an invalid code on CPU, while in
fact this is invalid as per specification. From the implementation side
this change removes the ifdefs around the CPU-only barrier logic, and
is implementing similar logic in the shader setup kernel.
Tested on NUC8i7HVK NUC.
The root cause of the dead-lock was identified by Max Dmitrichenko.
There is no measurable difference in performance of currently supported
OpenCL platforms.
Differential Revision: https://developer.blender.org/D9039
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.
Was missing a dedicated entry for LMB select, this is to be consistent
with how it is done for meshes.
Maniphest Tasks: T80905
Differential Revision: https://developer.blender.org/D8935
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.
