| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Regression since 2.80, see: T71434
|
|
|
|
This commit adds a new command line argument --debug-ghost and
makes it so X11 errors happening during context initialization
are only printed when this new flag is sued.
There is no need to flood users with errors when their GPU is
not supporting latest OpenGL version. Or, at a very minimum,
the error must be more meaning full.
Differential Revision: https://developer.blender.org/D6057
|
|
|
|
|
|
|
|
|
|
Using the release versions gave unpredictable results when
the msvc debugger was attached for some developers.
|
|
2.79 also did this [select the new instances] which was useful.
2.79 also kept the instancer selected [this patch deselects]
Reviewed By: mont29
Maniphest Tasks: T68191
Differential Revision: https://developer.blender.org/D6233
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D6260
|
|
This only frees brush_rng and random_tex_array when they were actually
previously allocated.
In a unit test (see D6246) I want to be able to partially start Blender
so that I can load a blend file. To prevent memory leaks, I also want to
be able to release memory, which currently requires calling
`BKE_blender_free()`. This unconditionally calls `RE_texture_rng_exit()`
and `BKE_brush_system_exit()`, which now crash on freeing `NULL`. This
patch fixes that.
Allocation (`BKE_brush_system_init()`) and freeing
(`BKE_brush_system_exit()`) are done asymmetrically. The allocation
functions are called from `main()` in the creator module, but the
freeing is done by `BKE_blender_free()` the Window Manager. Ideally we
symmetrise this and initialise Blender from outside the window manager
(so that the initialisation can be done without WM and Python too), but
for now I'm happy when things don't crash.
Reviewed by: sergey via pair programming
|
|
|
|
The render view window was never closed actually, just moved behind the
main window. It's properly closed now.
It should also behave more like expected when there already is a
temporary window open (e.g. Preferences).
|
|
This patch includes a modifiers that developed for NPR rendering.
- MultiStroke modifier that generates multiple strokes around the original ones.
Differential Revision: https://developer.blender.org/D5795
|
|
|
|
|
|
Causes undo push in sculpt mode, see: T71434
|
|
Causes undo push in sculpt mode, see: T71434
|
|
|
|
|
|
|
|
This commit includes all changes listed in T71366 except for the 2 column toolbar layout.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D6225
|
|
|
|
This is a workaround for T58473 to avoid likely event of ruining
sculpted data.
Differential Revision: https://developer.blender.org/D6244
|
|
|
|
Add a check to wm.radial_control so undo steps are only added
to properties that have undo enabled (as is done with number buttons).
|
|
|
|
|
|
|
|
The root of the issue goes to the discontinuity between the way how
mesh_calc_modifiers() and BKE_sculpt_multires_active() works.
At some point detection of original data usage by a modifier got
broken: the mesh_final based check is unreliable because deform-only
modifiers will create mesh_final for the connectivity information.
This made it so modifier stack evaluation would skip multires
evaluation, but the sculpt code will assume the multires is properly
applied.
This change makes it an explicit check about whether there are any
non-deform-only modifiers applied.
Pair programming and review together with Bastien, thanks!
|
|
There was a discontinuity between how deform-only modifiers are applied
for the case when result deform mesh is requested and when it is not.
Namely, the input mesh will always be guaranteed to present in the
former case, but not in the latter.
This change makes it so input mesh to deform-only modifiers is always
at consistent state.
Pair programming and review together with Bastien, thanks!
|
|
This changes integrates code signing steps into a buildbot worker
process.
The configuration requires having a separate machine running with
a shared folder access between the signing machine and worker machine.
Actual signing is happening as a "POST-INSTALL" script run by CMake,
which allows to sign any binary which ends up in the final bundle.
Additionally, such way allows to avoid signing binaries in the build
folder (if we were signing as a built process, which iwas another
alternative).
Such complexity is needed on platforms which are using CPack to
generate final bundle: CPack runs INSTALL target into its own location,
so it is useless to run signing on a folder which is considered INSTALL
by the buildbot worker.
There is a signing script which can be used as a standalone tool,
making it possible to hook up signing for macOS's bundler.
There is a dummy Linux signer implementation, which can be activated
by returning True from mock_codesign in linux_code_signer.py.
Main purpose of this signer is to give an ability to develop the
scripts on Linux environment, without going to Windows VM.
The code is based on D6036 from Nathan Letwory.
Differential Revision: https://developer.blender.org/D6216
|
|
|
|
|
|
The heap on windows is single threaded causing it to lag behind linux in performance in allocation heavy multithreaded scenarios, BVH building is a prime example.
See https://developer.blender.org/D6218 for benchmark results
for testing with the allocator enabled/disabled you can set the environment variable TBB_MALLOC_DISABLE_REPLACEMENT=1 to disable the TBB allocator.
Reviewed By: @sergey
Differential Revision: https://developer.blender.org/D6218
|
|
PaintCurve data ID data wasn't being remapped.
Error in initial undo refactor.
|
|
Error in 309cd047ef46f
|
|
|
|
Typo in rBf5e0dfe59c7e.
Showed when creating a new default scene.
Maniphest Tasks: T71508
Differential Revision: https://developer.blender.org/D6229
|
|
|
