Age | Commit message (Collapse) | Author |
|
|
|
AMD 21.1.1 still has the same issues as reported in T82856.
|
|
Building RC builds would parse `BLENDER_VERSION_CYCLE_NUMBER` that
doesn't exist anymore. It was removed by {D7748}.
This change removes it from `buildbot_utils.py`.
|
|
|
|
Dividing the workload by number of tasks in float is imprecise and
lead in some cases to particles not being calculated at all
(example: 20000 particles, 144 tasks).
Switching this calculation to integer makes sure we don't lose count.
Differential Revision: https://developer.blender.org/D10157
|
|
Fixed an issue that was causing the app icon to render with a
'plated' background color in the taskbar and other areas of Windows.
Updated all app icons in Microsoft Store package to match Microsoft's
design recommendations.
Added multiple scales for app icons for high resolution displays.
Added high contrast app icons.
Reviewed By: pablovazquez, jmonteath
Maniphest Tasks: T79356
Differential Revision: https://developer.blender.org/D9681
|
|
Recent commits also updated normals for metaballs, curves and volumetric
objects. This change tags will tag to generate geometry for these new
types.
|
|
The root of the issue was caused by the dependency graph using ID pointer
to map evaluated state from old depsgraph to new one upon relations update.
This was failing when IDs were re-allocated rapidly: was possible that
Object ID's evaluated state assigned to Mesh and vice versa.
Now depsgraph uses Session UUID to identify which IDs to restore evaluated
state to. The session UUID is stored in the IDNode, so that id_orig is not
dereferenced on depsgraph update since the ID might be freed.
The root of the issue is identified by Campbell, original patch was done
by Bastien, thanks! Also thanks to Oliver and Ray and everyone else for
testing!
|
|
Issue appears to be caused by AMD graphics driver later than 20.11.1 and
affects older GPUs (Polaris/FIJI cards). Wireframe drawing uses the same
OpenGL data type for storing normals what is known to be faulty.
This patch enabled storing the normals using GPU_COMP_I16. It also
solves the normals drawing in edit mode for vertex and loop normals.
|
|
This is part two of the fix for T84459.
Issue appears to be caused by AMD graphics driver later than 20.11.1 and
affects older GPUs (Polaris/FIJI cards). Drawing normals in edit mode
uses the same OpenGL data type for storing normals that is known to be
faulty.
This change fixes the face dot normals by using GPU_COMP_I16.
|
|
THe high quality normals work around is enabled for Polaris cards using
the official drivers. Since driver version 2.11.2 they fail to render
using low quality normals.
The detection of polaris cards is done by matching the opengl renderer.
The renderer strings have been extracted from various reports linked to
{T82856} but isn't complete as some reports are missing the exact
renderer as users don't always report via the help menu.
|
|
This change makes it possible for platforms to only support high quality
normal rendering. This is part of {T82856} where current AMD drivers
running on the polaris architecture does not support the low quality
setting due to a driver bug.
In a next commit the work around will be enabled.
|
|
This adds high quality normals for non meshes. These include
* Volumetric Object Wireframe
* Metaballs
* Extracted Curves
* Curves in edit mode
This is in preparation to fix a regression in recent AMD
drivers where the `GL_INT_2_10_10_10_REV` data type isn't
working in Polaris cards.
|
|
Some GPU platforms don't support having more than one underscore in
sequence in an attribute name. This change will remove the underscore
as a possible character when encoding to save names.
|
|
Off by one error in array access.
|
|
Root of the issue was missing management of ID pointers in the cloth
modifier data stored in ParticleSystem for hair physics, in the
'foreach_id' particle system code.
Using modifier's 'foreach_id' code in psys one unfortunately requires
some ugly conversion gymnastics, but this is still better than having
dedicated code for that case.
Note that this is actually a fairly critical issue, fix should be
backported to 2.91.1 should we do it, and to 2.83 LTS as well I think.
|
|
Script tool for automation of Steam build files for tasks like {T77348}
This script automates creation of the Steam files: download of the archives,
extraction of the archives, preparation of the build scripts (VDF files), actual
building of the Steam game files.
Requirements
============
* MacOS machine - Tested on Catalina 10.15.6. Extracting contents from the DMG
archive did not work Windows nor on Linux using 7-zip. All DMG archives tested
failed to be extracted. As such only MacOS is known to work.
* Steam SDK downloaded from SteamWorks - The `steamcmd` is used to generate the
Steam game files. The path to the `steamcmd` is what is actually needed.
* SteamWorks credentials - Needed to log in using `steamcmd`.
* Login to SteamWorks with the `steamcmd` from the command-line at least once -
Needded to ensure the user is properly logged in. On a new machine the user
will have to go through two-factor authentication.
* App ID and Depot IDs - Needed to create the VDF files.
* Python 3.x - 3.7 was tested.
* Base URL - for downloading the archives.
Reviewed By: Jeroen Bakker
Differential Revision: https://developer.blender.org/D8429
|
|
|
|
Version bump
|
|
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
|
|
dynamic paint modifiers
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
|
|
|
|
Besides being incorrect as only the first two bytes should be tested,
searching binary data using `strstr` can easily read past buffer bounds.
|
|
Also clear `gpd_eval` as this wasn't being copied either.
|
|
Zeroed mouse coordinates were being used making projection fail.
|
|
Regression in 0b2d1badecc48.
|
|
|
|
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.
|
|
|
|
Windows would need its own version of those tests, for now just
disabling them on that platform.
|
|
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.
|
|
|
|
Changing options after using select-linked didn't work
when the object being selected wasn't the active object.
|
|
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
|
|
with 1023 symbols crashes Blender.
Usual lack of protection against buffer overflows when manipulating
strings.
Also add some basic tests for `BLI_path_rel`.
|
|
This was happening because the raytrace was not even being performed
due to the tracing line being too small after frustum clipping.
|
|
Missing NULL check in bmesh_kernel_vert_separate.
|
|
This specific pose channel pointer was not handled at all during
rebuilding of poses, meaning that it could end up pointing at some freed
pchan.
|
|
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 external engine in the draw manager wasn't registered correctly.
This did not free the resources after the external engine was used.
|
|
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
|