Blender Git Loki

GPencil: Add option to append only active material

Merge branch 'blender-v2.93-release'

Fix T88030: operator showing options it shouldnt

Caused by {rB0d9f79b163ee}.

IDP_SyncGroupTypes was now syncing from src to src (leading to
unexpected operator properties).

Assume this is rather critical, dont know the part of the code well, but
above commit clearly shows a change from 'dest->data.group' to 'src-
>data.group' which shouldnt be there.

Maniphest Tasks: T88030

Differential Revision: https://developer.blender.org/D11171

Merge branch 'master' into greasepencil-object

Updated addons_contrib submodule.

The addons_contrib submodule is now tracking the umm_add_on branch.

Don't git checkout master for submodules.

Removing this logic as it doesn't allow for submodules that
track non-master branches. Also, not pulling latest in
the submodules so local and teamcity builds match.

Merge remote-tracking branch 'origin/master' into asset-browser-snap-dragging

Fix T88058: Hover+return doesn't accept 0 as input

When the user hovered over a number input field, pressed Enter and then
typed in '0', confirming the input would always cancel the action. This
is because in this particular case `ui_textedit_begin` is called
instead of `ui_numedit_begin`. This function will not set
`data->startvalue` (leaving it at `0`) which will then trigger the
cancel in `ui_apply_but_NUM` which checks if the input changed (by
comparing the entered value with `data->startvalue`).

The fix makes sure that when `ui_textedit_begin` is called on a number
button, the `data->startvalue` is set correctly like in
`ui_numedit_begin`.

Breaking commit: rBSeb06ccc32462beaacbb114d6d0e450b6fc911047

Note: This also affects pressing tab to move to a new number field and
entering '0'. The fix will also cover this case.

Reviewed By: Severin, #user_interface

Maniphest Tasks: T88058

Differential Revision: https://developer.blender.org/D11168

Merge remote-tracking branch 'origin/master' into asset-browser-poselib

Alembic export: export UV maps on every frame

Export UV maps to Alembic on every frame. This makes the export of UV
maps consistent with mesh normals. In the case of static UV maps it may
cause a slight slowdown (since they're exported on every frame now), but
due to the deduplication performed by the Alembic library, the resulting
files will be the same size anyway.

Thanks to @CodyWinch for providing the solution to the problem, and
writing the original patch D8397.

Differential Revision: https://developer.blender.org/D8397

LineArt: Fix merge conflicts.

LineArt: Smoothing chains before angle splitting.

Alembic Procedural: precompute vertex normals

This precomputes vertex normals in the procedural and caches them in case none
are found in the archive. This only applies to polygon meshes, as subdivision
meshes are yet to be subdivided, so it is useless to do this computation.

The goal here is to speed up data updates between frames, as computing normals
shows up in profiles even for large objects. This saves around 16% of update time
for a production file.

Fix wrong tracking curves after changing clip offset

The issue was caused by frame start/offset change triggering clip
reload, which was happening with a hardcoded scene frame index of 1,
which could be outside of the actual clip frames.

Solved by removing source change tag from the frame start/offset
update. The source doesn't really change: the resolution will stay
the same, as well as media type, its duration. So the tag was not
needed.

Movieclip: Use first clip frame for size detection

Using scene frame 1 is not reliable in cases when there is a
frame offset is involved. Using frame 1 seems more reliable,
although might still fail under certain circumstances.

More reliable fix would require a deeper change in the data
structure and the logic about frame loading and size detection.

WM: disable idle event handling timer when simulating events

Cleanup: spelling

Fix T87926: Transform menu has operators guaranteed to not pass poll in certain modes

Reported for ops.transform.vertex_warp and ops.transform.vertex_random.
Polling will check with ED_transverts_check_obedit, if we know it will
fail e.g. for pose mode, we can do the same check in the UI already.

Maniphest Tasks: T87926

Differential Revision: https://developer.blender.org/D11128

Fix T88005: GPencil inverse fill leaves unwanted line at viewport edge.

There was a function to set 2 pixels wide for inverse filling, but this must not be done in the borders of the image.

Now, the borders are checked before set 2 pixels.

Geometry Nodes: Initial basic curve data support

This patch adds initial curve support to geometry nodes. Currently
there is only one node available, the "Curve to Mesh" node, T87428.

However, the aim of the changes here is larger than just supporting
curve data in nodes-- it also uses the opportunity to add better spline
data structures, intended to replace the existing curve evaluation code.
The curve code in Blender is quite old, and it's generally regarded as
some of the messiest, hardest-to-understand code as well. The classes
in `BKE_spline.hh` aim to be faster, more extensible, and much more
easily understandable. Further explanation can be found in comments in
that file.

Initial builtin spline attributes are supported-- reading and writing
from the `cyclic` and `resolution` attributes works with any of the
attribute nodes. Also, only Z-up normal calculation is implemented
at the moment, and tilts do not apply yet.

**Limitations**
- For now, you must bring curves into the node tree with an "Object
Info" node. Changes to the curve modifier stack will come later.
- Converting to a mesh is necessary to visualize the curve data.

Further progress can be tracked in: T87245
Higher level design document: https://wiki.blender.org/wiki/Modules/Physics_Nodes/Projects/EverythingNodes/CurveNodes

Differential Revision: https://developer.blender.org/D11091