Blender Git Commit Log

Add transform tools to sequencer & preview mode

Cleanup: Unused vars

Cycles X: Real memory saving when using tiled rendering

The general idea is to delay reading EXR files for until after all
view layers are rendered. Once they are all rendered, BlenderSession
frees up as much memory as possible, and initiates processing of the
on-disk files.

The processing includes reading the file, optional denoising of the
full frame (if the denoising is enabled), and writing the result via
the write callback.

The processing is done as a state-machine which routes specific calls
to a full-frame processing, which allows to re-use same tile write
callback in the software integration.

In order to be able to know which view layer and render view is being
written the API has been extended to write layer and view names. Done
via BufferParams, as layer and view concepts are quite typical for the
EXR files.

The BufferParams also contains all fields needed for buffers access
outside of the scene graph.

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

Fix incorrect origin for gizmo with multi-selection

Fix T91448: GPencil Fill simplify not working in render

The simplify was hardcode to be disabled in render.

Merge branch 'master' into temp-field-visualization

Fix wrong display when rendering multiple view layers in Cycles X

The issue was that the texture used by GPUDisplay was never cleared and
was only used for partial updates.

The actual reasoning of that is a bit more tricky than it looks on a
first glance since the GPUDisplay was re-created together with session
via session_reset so one would think it is weird to have a texture from
previous view layer to appear in the new GPUDisplay. Probably caused by
the fact that OpenGL is the same for all view layers, and texture ID is
happened to be the same.

Anyhow, the way texture is created is considered to have an undefined
behavior by the standard when is attempted to be used without explicit
data assignment.

This change makes it so new texture is always guaranteed to be zeroed
and that the GPU display is cleared when rendering multiple views from
within the same session.

The clearing is done by a GPUDisplay subclass, as the parent does not
know details of how to perform the zeroing. For the CPU the zeroing is
done on a mapped memory, as it makes it easy and does not require any
extra OpenGL requirements.

For the graphics interop things a bit more difficult as attempts to map
texture will make graphics interop to fail out (it really wants to be
an exclusive thing which takes care of the memory mapping). So for the
graphics interop clearing is done when memory is mapped by the interop
implementation.

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

Fix persistent data not allowing to change sample count and time limit

The root cause was that `session->params` were never updated to the new
parameters.

Made it so `session->reset()` will make sure the session is fully up to
date with the desired parameters.

Investigation by @dingto, code by self.

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

Fix pass accessor with 0 samples

Avoid division by zero when calculating scale, and avoid multiplication
by inf later on.

The pixel processing functions are changed so that they return fully
transparent pixel for pixels where number of samples is 0. This allows
to have matched behavior of non-finished tiles with master, without
relying on non-finite math.

The extra condition when calculating scale is inevitable, and hopefully
the pixel processing function's if statement gets folded into it as
well ()due to force-inline).

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

Fix race condition between draw and render threads

Caused crashes like the one William was fixing in the D12498, or the
crash when rendering multiple view layers.

Need to guarantee that the render engine is not freed during drawing,
and that the external engine is not in the middle of re-allocation due
to `update()` which might cause session reset (happens in Cycles).

Had to introduce a separate lock. The reason for this comes from the
fact that we need to acquire the engine early on in the draw manager,
and release it only when drawing is done. However, some other engines
(like overlay) might be requesting ImBuf for the image space, so that
they know dimensions. Such acquisition is guarded by the resultmutex.
This means reusing `resultmutex` for the `RenderEngine::draw()` would
cause a recursive lock.

Not entirely happy with implicit release in the external engine code,
but not sure there is an existing way of making it explicit without
introducing new draw engine callback.

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

Remove commented out code

Fix mirror X/Y not being taken into consideration.

Fix T85564: FCurve modifier zero influence on restrict range borders

When using FModifier `Restrict Frame Range`, the resulting influence was
zero being exactly on `Start` / `End` range borders (so borders were
**exclusive**).
This made it impossible to chain FModifers together (forcing the user to
specify values slightly below the desired border in following
FModifiers).
This is now corrected to be **inclusive** on Start / End range borders.

Before
{F10234864}
After
{F10234865}
Testfile
{F10234866}

In the case of touching open borders (so [frame A frame B] followed by
[frame B frame C]) both modifiers are evaluated (in stack order).
If the later modifier has full influence (and is not additive) this simply
means the result is the same as the later modifier's value.
If influences below 1 are used (or modifiers are additive) both modifier's
values are interpolated/added accordingly.

technical notes:
- this was caused by the introduction of FModifier Influence/BlendIn-Out
in rB185663b52b61.
- for comparison, see other occurrences of
`FMODIFIER_FLAG_RANGERESTRICT`.
- the following conditions in `eval_fmodifier_influence` for blend in/
out have been changed accordingly.

Maniphest Tasks: T85564

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

WM: expose the "any" state of KeyMapItem modifiers

Change KeyMapItem.alt/ctrl/shift/oskey to integer types,
where -1 is used to ignore the modifier when matching key-map items.

It was only possible to set all modifiers to -1 at once from RNA
using the 'any' property.
Afterwards individual modifiers could be set back to true/false.
Although these key-map items could not be exported/imported.

Exposing the values directly avoids the need for cumbersome workarounds.

Fix memleak

Fix "guaranteed" images not loading.
Add `SEQ_FLAG_SKIP_THUMBNAILS` flag to signify that strip did not
produce thumbnail and so should be skipped when drawing.

Sculpt dyntopo: Roughed out skeleton of new brush engine API

Command Lists

* The new system will be based on command lists
generated by (eventually) a node editor.
* For now, the lists will be hardcoded.
* Idea is to make a minimal viable
brush engine that won't cause file breakage
when the upgrade to node-based brushes happen.

Brush Channels

* Wrote new structures and API to wrange
brush parameters: BrushChannel.
* Supports, floats, ints, enums, bitmasks,
with plans for vec3 and vec4.
* This will replace UnifiedPaintStruct,
most of the members of Brush and the
DynTopoSettings struct.
* Brush channels can
be mapped to various input device
channels (e.g. pen pressure); each
mapping has its own associated curve
(CurveMapping instance) and bounds.

Brush channel inheritence chaining

* Brush channels can form inheritence chains
* Channel sets are stored in three places:
in the scene toolsettings, in Brush, and in
individual brush commands.
* Node groups will also have a channel set.
* Channels in each set can be flagged to
inherit from the parent set.
* Inheritence happens in seperate merged
channel sets at runtime. The final
Brush channels live in Brush->channels_final,
while the final command channels live in
BrushCommand->params_final.

Cleanup: remove KM_MOD_SECOND & KM_SHIFT2, KM_CTRL2.. etc

These were added in a1c8543f2acd7086d412cb794b32f96794b00659 (2007)
but never used.
Nor did they have any meaning in practice.

Note that versioning keymap items isn't needed as these values were
never set. The code-paths that set these values also set KM_MOD_FIRST
causing `keymap_event_set` to only ever assign values of 0 or 1.

These flags complicate further exposing KM_ANY (-1)
which is also a valid value for modifiers.

UI: wait for input for operators that depend on cursor location

Support waiting for input so operators that depend on the
cursor location are usable from menus / buttons.

Use an operator type flag which the user interface code checks for,
waiting for input when run from a menu item.

This patch only supports this feature, there are no functional changes.

The motivation for this change is discoverability since some actions
were either hidden or broken when accessed from menus
(where the behavior of the operator depended on the menu location).

In general, waiting for input is *not* an efficient way to access tools,
however there are over 50 operators with a "wait_for_input" property
so this isn't introducing a new kind of interaction,
rather exposing this in a way that does not need to be hard-coded into
each operator, or having modal callbacks added for the sole purpose
of waiting for input.

Besides requiring boiler plate code using a "wait_for_input" property
has the added down-side of preventing key shortcuts from showing.
Only the menu items will enable the property,
causing them not to match key-map items.

Reviewed By: Severin

Ref D12255

UI: split screenshot area into a separate operator

While the screenshot operator showed an "Area" option,
it wasn't usable from the main menu (unless accessed via menu search).

Split screenshot area into an operator that depends on cursor.