Rotation and scale was done around the wrong center (always around mouse
position) in paint_draw_tex_overlay [on the other hand,
paint_draw_cursor_overlay already got the center right].
Now make the center dependent on UnifiedPaintSettings "draw_anchored".
Maniphest Tasks: T102312
Differential Revision: https://developer.blender.org/D16418
The color-band needs to do some special, rather awkward updating of the
UI state when certain values are changed. As @lichtwerk noted in the
report, this was done to the wrong buttons. Now lookup the proper
buttons, and don't assume that `uiItemR()` only adds a single button
(which often isn't the case).
The new Xcode 14.1 brings the new Apple Clang compiler which
considers sprintf unsafe and geenrates deprecation warnings
suggesting to sue snprintf instead. This only happens for C++
code by default, and C code can still use sprintf without any
warning.
This changes does the following:
- Whenever is trivial replace sprintf() with BLI_snprintf.
- For all other cases use the newly introduced BLI_sprintf
which is a wrapper around sprintf() but without warning.
There is a discouragement note in the BLI_sprintf comment to
suggest use of BLI_snprintf when the size is known.
Differential Revision: https://developer.blender.org/D16410
Avoid accessing freed memory from dynamically allocated EnumPropertyItem
arrays. Rely on the memory being held by the iterator which isn't the
case when it was converted to a tuple.
Function casts hid casting between potentially incompatible type
signatures (using int instead of Py_ssize_t). As it happens this seems
not to have caused any bugs on supported platforms so this change is
mainly for correctness and to avoid problems in the future.
As instances are often generated geometries, we cannot rely on the data
provided by `DupliObject::ob`.
Use `DupliObject::ob_data` when possible.
This required a major refactor in the code as the output variables are
now gathered in context and easier to access.
This is not the case though, the modifier act explicitly on mesh edges,
if no tesselated mesh is provided, it would simpy early out and do
nothing.
Now always disable the "Apply on Spline" option with a tip that this
modifier can only smooth the tesselated curve (not the underlying curve
control points). Similar to rB1a6b51e17502.
Fixes T102060.
Maniphest Tasks: T102060
Differential Revision: https://developer.blender.org/D16386
The operator was acting on non selected items (wasnt checking SpaceFile
bookmarknr for being -1) which could end up removing items even.
Now sanatize this by introducing proper poll (which returns false if
nothing is selected).
Fixes T102014.
Maniphest Tasks: T102014
Differential Revision: https://developer.blender.org/D16385
Regression in [0] needs further investigation
(building docs may crash again).
This effectively reverts [0], however de-duplicating the color-space
enum can be kept.
[0]: 037b771e1a
As described in the comment on `BLI_task_isolate`, deadlocks can happen
when isolation is used with threading primitives that separate spawning tasks
from executing them. All threads are waiting the tasks to complete but no
thread is able to continue working due to task isolation.
The fix is to not pass lazy-threading hints through task isolations. This way
isolated regions can't create new tasks in a scheduler further up the call stack.
This may lead to minor slowdowns because less threading may be used.
It's generally possible to get rid of the slowdown again by sending the
lazy-threading hint before entering the isolated region.
Color space conversion item-function missed checking the context was
NULL to return a static array. This caused freed memory access when
building docs.
Many connected edge loops could result in two edge loops sharing
vertices. This is more of a workaround, the reason for two edge loops
sharing vertices could be prevented some other way.
Add this check since it's a straightforward solution,
furthered investigation noted as a TODO.
BlendType max incorrectly returns the minimum in BLI_color_mix.hh
This differential fixes it to return the maximum.
Maniphest Tasks: T102216
Ref D16364
This fixes T102218, where baked f-curves would display incorrectly when normalized.
This bug was a result of the code making no effort to determine the y-range of baked f-curves, so it fell back to a default that looked horrible.
I've added specific handling for finding the y-range of each f-curve (I extracted this functionality out to a new function, `fcurve_scene_coord_range_get`, for organization purposes). In addition, a minor optimization was made to eliminate redundant range-checks when in preview range mode.
{F13838304}
Reviewed By: sybren
Maniphest Tasks: T102218
Differential Revision: https://developer.blender.org/D16363
This commit reduces the amount of white space generated and keeps parameter documentation of a single line.
This makes the resulting rst files easier to read in the case of debugging.
This was useful while looking into T97464
Regression in [0], however the primary purpose of that code was to
cycle away from the active object (behavior which was intentionally
removed, see: T96752).
This broke weight-paint + pose-selection (Ctrl-LMB)
when the GPU depth picking preference was disabled.
Causing selection to pick the mesh object instead of the pose bones.
This de-selected the armature, making the pose bones unselectable
instead of selecting the pose bone as intended.
Adding the old code back (restricting it to weight-paint mode)
fixes the bug but reintroduces fairly involved logic unnecessarily.
Instead, prioritize bone selecting when in weight-paint & pose mode
(previously this was only done in pose-mode).
[0]: b1908f2e0b
The regression is caused by D13824 0f89bcdbeb.
This fix follows the code from Sybren (D7785) to make object-mode
drivers from shapekey value to work. This intuitively makes sense
since the D13824 made the edit mode evaluation and ownership follow
the object mode more closely.
Differential Revision: https://developer.blender.org/D16380
On Ubuntu 20.04 running X11, there was this message on every Blender startup:
Unable to find 'wl_proxy_marshal_flags' in 'libwayland-client.so.0'.
The reason is that we build against Wayland protocols 1.21, which in turns requires
Wayland on the distribution to be 1.21+, which is not the case on Ubuntu 20.04.
This simply silences the warning. An improvement would be to explain the user that
their Wayland version is too old when neither X11 or Wayland can be found. Though
that's not trivial and a situation with old Wayland and no XWayland seems unlikely
to happen in practice.
Differential Revision: https://developer.blender.org/D16266
Seems to be introduced by 99e5024e97.
The crash is caused by the difference in the expected alignment
of the `uiPopupMenu` which is 16 bytes and the actual alignment
returned by the `MEM_mallocN()` which is 8 bytes due to the memory
head.
Now made it so that `MEM_new()` can be used for types with any
alignment.
Differential Revision: https://developer.blender.org/D16375
* BLENDER_VERSION_CYCLE set to beta
* Update pipeline_config.yaml to point to 3.2 branches and svn tags
* Update and uncomment BLENDER_VERSION in download.cmake
Add a macro that implements something similar to cmake_path's IS_PREFIX
which isn't supported in older versions of CMake.
This caused the build-bot to fail.
C++ doesn't support taking the temporary address of a temporary array,
use inline functions instead.
Also change array joining functions to return the length of the string
instead of returning the pointer (matching BLI_path_join).
