Blender Git Commit Log

Fix T89033: segfault reordering animation channels

Fix segmentation fault that can occur when reordering animation
channels.

Under some specific conditions, the list "act->curves" is empty in the
"join_groups_action_temp" function. In particular, this happens when a
scene contains an action that has not been pushed down, and with no
keyframe in it.

Reviewed By: sybren

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

Nodes: cache socket identifier to index mapping

While this preprocessing does take some time upfront,
it avoids longer lookup later on, especially as nodes get
more sockets.

It's probably possible to make this more efficient in some cases
but this is good enough for now.

adaptive_cloth: ui: add remesh option within shape

UV : Pack islands to correct/specified UDIM

Adds 2 features to the pack islands operator

* Packing selected UVs to the closest UDIM
* Packing selected UVs to user specified UDIM

Performance: Use parallel range for ImBuf scanline processor.

Scanline processor did its own heurestic what didn't scale well when
having a multiple cores. In stead of using our own code this patch will
leave it to TBB to determine how to split the scanlines over the
available threads.

Performance of the IMB_transform before this change was 0.002123s, with
this change 0.001601s. This change increases performance in other areas
as well including color management conversions.

Reviewed By: zeddb

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

Sequencer: Do not redraw during playback.

When using large sequences including audio the drawing of the audio on
top of the strip takes a lot of time. This effects the playback
performance heavily.

During the animation playback performance there was a solution for this
by only drawing the playhead overlay. This was reverted for the sequence
editor as it didn't update the color strips when they were animated.

This patch checks if there are animated color strips if so the full
screen is redrawn, otherwise only the playhead is redrawn.

Reviewed By: ISS

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

Refactor: use 'BLI_task_parallel_range' in Draw Cache

One drawback to trying to predict the number of threads that will be
used in the `task_graph` is that we are only sure of the number when the
threads are running.

Using `BLI_task_parallel_range` allows the driver to
choose the best thread distribution through `parallel_reduce`.

The benefit is most evident on hardware with fewer cores.

This is the result on an 4-core laptop:
||before:|after:
|---|---|---|
|large_mesh_editing:|Average: 5.203638 FPS|Average: 5.398925 FPS
||rdata 15ms iter 43ms (frame 193ms)|rdata 14ms iter 36ms (frame 187ms)

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

Refactor: Draw Cache: use 'BLI_task_parallel_range'

This is an adaptation of {D11488}.

A disadvantage of manually setting the iter ranges per thread is that
we don't know how many threads are running in the background and so we
don't know how to best distribute the ranges.

To solve this limitation we can use `parallel_reduce` and thus let the
driver choose the best distribution of ranges among the threads.

This proved to be especially beneficial for computers with few cores.

**Benchmarking:**
Here's the result on an 4-core laptop:
||master:|PATCH:
|---|---|---|
|large_mesh_editing:|Average: 5.203638 FPS|Average: 5.398925 FPS
||rdata 15ms iter 43ms (frame 193ms)|rdata 14ms iter 36ms (frame 187ms)

Here's the result on an 8-core PC:
||master:|PATCH:
|---|---|---|
|large_mesh_editing:|Average: 15.267482 FPS|Average: 15.906881 FPS
||rdata 9ms iter 28ms (frame 65ms)|rdata 9ms iter 25ms (frame 63ms)
|large_mesh_editing_ledge: |Average: 15.145966 FPS|Average: 15.520474 FPS
||rdata 9ms iter 29ms (frame 65ms)|rdata 9ms iter 25ms (frame 64ms)
|looptris_test:|Average: 4.001917 FPS|Average: 4.061105 FPS
||rdata 12ms iter 90ms (frame 236ms)|rdata 12ms iter 87ms (frame 230ms)
|subdiv_mesh_cage_and_final:|Average: 1.917769 FPS|Average: 1.971790 FPS
||rdata 7ms iter 37ms (frame 261ms)|rdata 7ms iter 31ms (frame 258ms)
||rdata 7ms iter 38ms (frame 252ms)|rdata 7ms iter 33ms (frame 249ms)
|subdiv_mesh_final_only:|Average: 6.387240 FPS|Average: 6.591251 FPS
||rdata 3ms iter 25ms (frame 151ms)|rdata 3ms iter 16ms (frame 145ms)
|subdiv_mesh_final_only_ledge:|Average: 6.247393 FPS|Average: 6.596024 FPS
||rdata 3ms iter 26ms (frame 158ms)|rdata 3ms iter 16ms (frame 148ms)

**Notes:**
- The improvement can only be noticed if all extracts are multithreaded.
- This patch touches different areas of the code, so it can be split into another patch if the idea is accepted.

These screenshots show how threads behave in a quadcore:
Master:
{F10164664}
Patch:
{F10164666}

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

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

Merge branch 'master' into override-recursive-resync

Revert "Add initial `BLI_math_time` with a 'seconds explode' function."

This reverts commit c7e222c5ee5df7dd518d9c1b5d60c2bd70db2d64.

Nodes: add utilities to check if there are undefined nodes/sockets

Cycles X: Refactor noisy/denoised passes access

The goal is to make it easily to extend denoising support for passes
like light passes and shadow catcher, without need to double-write in
the kernel, and without duplicating pass type for every noisy/denoised
combination.

Avoid double-write of noisy pass in the kernel, introducing an explicit
separation of noisy pass written by the kernel and denoised pass written
by a denoiser.

The idea is to allow marking pass as "please read denoised result of the
type when available". If there is no denoiser configured, then the pass
will access its noisy data (and no data will be allocated for the pass
which is requesting to return denoised result).

It is possible to simplify some of the pass accessing in the denoisers,
as well as possibly avoiding memory allocation. Will look into this as
a followup development related on making denoiser able to denoise any
input.

The positive side is that now there is no need in the denoised pass
film convert kernel.

Should be no functional changes.

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

Revert test changes to `lib_id_test.cc`.

Reset this file to master state.

Merge branch 'master' into xr-controller-support

Fix: VSE search in mpegts files would fail

ffmpeg_generic_seek_workaround did work properly and our start pts
calculation was wrong.

Reviewed By: Richard Antalik

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

Fix: VSE indexer seeking not working correctly

Because of the added sanity checks in rB14508ef100c9 (D11492), seeking
in proxies would not work correctly any more. This is because it wasn't
working as intended before, but in most cases this wouldn't be
noticeable. However now when the sanity checks are tripped it is very
noticeable that something is wrong

The indexer tried to use dts values for time stamps when we used pts in
our decode functions to get the time positions. This would make it
start in the wrong GOP frames when searching. Now that we enforce no
crossing of GOP frames when decoding after seek, this would lead to
issues.

Now we correctly use pts (or dts if pts is not available) and thus we
don't have any seeking issues because of time stamp format missmatch.

Reviewed By: Richard Antalik

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

Fix: VSE timecodes being used even when turned off.

Reviewed By: Richard Antalik

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

Knife: Added orientation locking to knife tool

- Pressing X, Y or Z will lock current cut to corresponding axis.
- Pressing the same key twice will lock to local object axis.
- Scene orientation setting takes priority over this when set to anything other than global. This provides support for custom orientations.

XR: Add axis region, bimanual action flags

The axis flags allow binding actions to certain regions of an input
axis (positive or negative). In this way, two different actions can
be bound to the input path "/input/thumbstick/x" without overlapping.

The bimanual flag signifies that the action depends on inputs from
both of its subaction paths, and both states, if available, will then
be passed to the operator. This will be used in the future for
two-handed navigation and transform.