It was rather a huge chunk of code, which started to become
more harder to maintain with the transition to OpenSubdiv based
implementation. Because of this transition, the compatibility was
also rather on a poor side.
Remove compatibility support for pre-2.50.9 multires.
Ref T77107
Reviewed By: brecht, mont29
Differential Revision: https://developer.blender.org/D9238
Historically the result of the keying node was violating alpha
pre-multiplication rules in Blender: it was simply overriding
the alpha channel of input.
This change makes it so keying node mixes alpha into the input,
which solves the following issues:
- The result is properly pre-multiplied, no need in separate
alpha-convert node anymore.
- Allows to more easily stack keying nodes.
This usecase was never really investigated, but since previously
alpha is always overwritten it was never possible to easily stack
nodes. Now it is at something to be tried.
Unfortunately, this breaks compatibility with existing files, where
alpha-convert node is to be manually removed.
From implementation side this is done as a dedicated operation since
there was no ready-to-use operation. Maybe in the future it might
be replaced with some sort of vector math node.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D9211
This avoids accidents using user-preferences in the main BLF API,
which could cause preferences to be used unintentionally
(such as stamping into renders or creating generated images).
As well as uses of BLF when preferences aren't loaded
such as animation playback.
Selecting an F-Curve handle caused an assertion as well as treating
the key-frame as inactive.
Allow active the keyframe to be active when it's handle is selected,
as is done with bezier curves.
These changes should result in more readable and undestandable code,
especially where while loops were use instead of for loops. They are
not comprehensive, and I skipped wherever the change was not obvious.
In practice, there are only a limited number of operations we need to
use repeat such as navigation, stepping operations that cycle states
and text input.
Now we don't need to disable repeat explicitly when a modal operator
uses checks for a key being held as was needed for 17cb2a6da0.
Repeat is now included in exported keymaps.
Use versioning so existing exported keymaps are loaded properly.
This was caused by unprotected drawing callbacks.
As of 2.91, we require that all python callbacks used for
drawing needs to be safeguarded by `GPU_bgl_end()` to end the
state tracking override.
This was caused by unprotected drawing callbacks.
From 2.91, we now require that all python callbacks used for
drawing needs to be safeguarded by `GPU_bgl_end()` to end the
state tracking override.
This avoid strange discrepency between the general purpose variant and
the specialized glass variant which did not have a way to turn
multi-scatter off.
This patch helps the case of intricate reflections where the
ray does not travel far before intersecting the geometry.
In these cases there could be false negative exclusion of the ray
caused by the backface rejection threshold.
The artifact manifested as lines of different values caused by faillure to
trace the depth buffer correctly.
Adding a ad-hoc value to the step size to mitigate the issue.
Outliners listener (outliner_main_region_listener) needs ND_PARENT
notifier to redraw, the parenting operator only spawned ND_TRANSFORM
(which doesnt do a redraw).
Maniphest Tasks: T81896
Differential Revision: https://developer.blender.org/D9295
shapekeys/modifiers
This was failing for all mask filters (sharpen, grow, invert, clear,
shrink, contrast, smooth) and mask gestures (box, lasso).
Also have to recalc shading, use SCULPT_tag_update_overlays for this.
ref D8956
Maniphest Tasks: T81929
Differential Revision: https://developer.blender.org/D9302
Line gesture use always the right side of the line as active (the area
of the mesh that is going to be modified) by default.
This adds the ability to change the active side when the line gesture is
active by pressing the F key.
This allows more freedom to position the line after starting the
gestures, as it won't be required to cancel the operation or undo if the
line was used in the wrong direction.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D9301
Line gesture use always the right side of the line as active (the area
of the mesh that is going to be modified) by default.
This adds the ability to change the active side when the line gesture is
active by pressing the F key.
This allows more freedom to position the line after starting the
gestures, as it won't be required to cancel the operation or undo if the
line was used in the wrong direction.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D9301
The new preset I made for 2.91 is way more controllable with lower
strength values and does not have the accumulate bug, but until the
brush management is in place to ship multiple versions of the brush,
probably most people expect something closer to the old version to be
the default.
Reviewed By: sergey
Maniphest Tasks: T81901
Differential Revision: https://developer.blender.org/D9289
Swaps the order of the '+' and '-' button in the File Browser file name field,
so that '-' comes first.
For increasing or decreasing a value it makes more sense to have decreasing
first, increasing last. Consistent to how you press on the left side of a
number button for decrease, and right to increase.
However this is inconsistent in another way: Usually we have a '+' button
before a '-' button, but that refers to adding and removing items, not
increasing or decreasing. The icons are also placed in their own buttons then,
making them look more separate.
So the UI Team agreed on accepting that trade-off, see today's meeting notes:
https://devtalk.blender.org/t/2020-10-21-ui-team-upcoming/15849
The pin button should be next to the data-path, which is what it belongs to.
Note that this makes the placement of the search button in the header look
quite off. That is because it's centered to the absolute header width, not the
width of the main region (which is smaller because of the tab region on the
left).
Technically it's correct that way, visually it looks wrong. This will be
addressed in a followup commit.
