Some types were documented in bpy.types aren't accessible there.
For now, disable documenting types from add-ons and some types from
bl_operators, bl_ui... since these are mostly for internal use.
`WS_CHILD` is a different kind of child window that what we define as
child window. See http://forums.codeguru.com/showthread.php?491604.
Setting this style flag seems to mess things up a bit in our
configuration. The name bar is actually being overlapped by the Windows
task bar then. Not totally sure why this happens, but I think it's
because windows with the `WS_CHILD` style are positioned relative to the
parent, not the desktop (screen without taskbar). So it uses the full
space available when maximized, which isn't clipped by the taskbar
anymore.
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
The script requires Python 3.7 as a very minimum, and CentOS is
only 3.6.
On macOC there was an access to a None object, due to missing
implementation of code signer on this platform.
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
When using OpenCL with Cycles the rendering time increased substantial.
After doing some tests the bottleneck was found in 4d voronoi and 2d and
3d smooth voronoi.
This change will hide these behind a specific compile directive so the
speed will improve.
AMD RX480 + BMW scene
2.80 (3:10)
2.81 (5:48)
2.81 excluding 4d voronoi+2d/3d smooth (3:50)
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D6231
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
