Add support for using the Stash (to NLA) and Push Down operators on
empty Actions. In the past years, the NLA has seen stability updates
that ensure strips are at least a single frame long, and with that even
pushing down an empty Action will create a visible (albeit tiny) NLA
strip. There doesn't seem to be a practical reason to disallow this any
more.
Pull Request: https://projects.blender.org/blender/blender/pulls/136604
It is possible to un-assign the action slot from an NLA strip. If then
you enter tweak mode on it and insert keys, a new slot is created on the
Action (so far so good). However, exiting tweak mode did not assign that
slot to the NLA strip, deactivating the animation. This is now solved.
The slot assignment is done when exiting tweak mode because that's
when the whole "sync from assigned Action back to the NLA strip"
happens. Also things like syncing the strip length is done at
tweak-exit, so that seemed like the right place to me to do this too.
Pull Request: https://projects.blender.org/blender/blender/pulls/136601
Update all F-Curves so they have the correct flags (`FCURVE_INT_VALUES`,
`FCURVE_DISCRETE_VALUES`) for the RNA property type that they animate.
The bug that caused these flags to be incorrect (#136347) is already
fixed. This commit ensures that F-Curves that were created while the bug
was in a Blender release are updated to ensure they have the correct
flags.
This is quite important to fix, as otherwise enum properties will
actually be interpolated. Imagine the "fun" when a rig is going
through all the intermediate rotation modes when it was intended to
switch from "Quaternion" to "ZYX".
Even before this commit, these flags were already recomputed on key
insertion (at least the ones through the UI). The versioning code simply
runs this update on all existing F-Curves.
Since this may have some performance impact (doing an RNA path resolve
on all F-Curves on all Actions), the versioning code is only run when
the blend file is from 4.4 or newer, as the bug was introduced in that
release.
Pull Request: https://projects.blender.org/blender/blender/pulls/136512
The issue is caused by the fact that when both compositors are used,
`fftwf_plan_dft_r2c_2d` can end up being called in parallel, which is
only thread-safe if `fftwf_make_planner_thread_safe` is called before.
This is done by `fftw::initialize_float`, but only if the FFTW threading
support library is available. Said library was not detected correctly on
Windows because of a typo, which this change addresses. This should also
make the fog glow faster on Windows because it'll now use multithreaded
FFT as intended.
This change also moves the call to `initialize_float` to the main
function because the FFTW functions it calls are not thread-safe and
because FFTW is also used by Audaspace, which cannot call it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136557
The Glare node currently has a Maximum Highlights input, which has a
special value of 0.0, where the maximum is implicitly set to infinity,
that is, no suppression of highlights happen at that special value. Such
special values are hard to discover and make sliders non-continuous.
To fix this, we introduce a new panel toggle input called Suppress
Highlights, which the user can enable then control the maximum value.
This also have the advantage that the Maximum value is more clear, since
it is now under a panel more clearly named.
This is now possible since the introduction of boolean sockets and node
panel toggle inputs.
Pull Request: https://projects.blender.org/blender/blender/pulls/136309
Apply transform behavior for empties is now consistent.
Applying scale always changes empty size to keep apparent size.
Previously, empty size is only changed when applying scale only.
Pull Request: https://projects.blender.org/blender/blender/pulls/136534
The `motionSampleTime` argument to `create_object` has been unused since
the dawn of time, and it's not expected to be used in the future either.
Remove the clutter.
Pull Request: https://projects.blender.org/blender/blender/pulls/136587
Both values are unused.
* `current_r` is only ever set and never read from
* `previous_r` is only ever read from and is never set, because it is
always empty, it is never unioned with the current `rcti`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136586
This situation is unlikely to happen in practice, as it would require
there to be either no elements in the mesh, or every average translation
to be a 0-length vector.
Pull Request: https://projects.blender.org/blender/blender/pulls/136572
Even though the doc-string notes that they're only used for
function parameters, it looks as if they might be used for
`wmEvent::modifier` and are exposed in a prominent location.
Remove the flags & replace them with a macro that bit-shifts the
existing modifier values which is more clearly intended to be used
with `KeyMapItem_Params`.
Ref !136539
Set the flags on the image buffer when loading an EXR file, so they can be
used when saving.
This also removes IB_halffloat and replaces it by the file options flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/135656
I'm moving this for two (related) reasons:
* It depends a lot on the specifics of `Camera` and `Object` data-blocks.
* It links `Object::object_to_world()` which is not an inline function and thus
easily leads to linker errors. It mostly seems like luck that this is not
breaking our build due to early dead code elimination when linking binaries
which use the blenlib static library such as `msgfmt`.
I found this while working on a compilation tool which would not be as lucky and
has a linker error because of the dependence on `Object::object_to_world`.
Pull Request: https://projects.blender.org/blender/blender/pulls/136547
If you scale down the color pickers to very small sizes the calculation
of the handle size of the value slider will cause it to proportionally
increase as it all approaches zero. This PR just calculates the size in
a better way and clamps it as well. For both the round and square
versions.
Pull Request: https://projects.blender.org/blender/blender/pulls/136566
This patch makes it such that the compositor fallback to using the
order of the inputs to infer the domain priority if no domain priority
is specified. This is more robust since some nodes do not declare their
domain priorities and indirectly rely on the order of insertions in some
containers and thus might fail in the future.
We opt for this as opposed to requiting all nodes to declare their
priorities for code brevity.
This patch adds initial support for implicit inputs in pixel operations.
This is currently a non-functional change but will be used in the
future to support implicit inputs in texture nodes or so.
This works by exposing extra inputs to pixel operation for each of the
supported implicit input types if needed, and linking those inputs to
instances of the ImplicitInputOperation operation.
Only a single implicit input exist for now and we do not differentiate
between any of the implicit inputs type. In order to do that, we need to
refactor how input declarations for implicit inputs happen, since they
are now tied to the Geometry Nodes specifically.
Add support for a 5th modifier key called "hyper",
this is a modifier supported on Wayland & X11 although
other platforms could support an additional modifier too.
Both GNOME and KDE can map CapsLock to Hyper.
Other compositors can use the XKB_DEFAULT_OPTIONS environment variable.
This allows users to have an additional modifier for their own use
that doesn't conflict with other keys.
Ref !136340
Some regions, like toolbars and sidebars, can be dragged open and
closed. But this often doesn't work correctly a second time because
we don't update our saved widths once the area is hidden. This results
in an incorrect offset. This PR just resets the saved widths to zero
when the region is hidden so this doesn't occur. Note that this does
not affect the ability to just click and release on the widget, only
dragging from it.
Pull Request: https://projects.blender.org/blender/blender/pulls/136527
Rename to be more consistent with other Blender keymaps, as well as the
naming convention used in "View Type."
- "SequencerCommon" -> "Video Sequence Editor"
- "SequencerPreview" -> "Preview"
- "Sequencer Timeline Tool" -> "Sequencer Tool"
- "Sequencer Preview Tool" -> "Preview Tool"
There is versioning in place to make sure custom keyconfigs keep working.
Once #131102 goes through, if we would like to rename the "Sequencer"
view type to "Timeline" or "Sequencer Timeline," then we can make the
necessary changes here too.
Pull Request: https://projects.blender.org/blender/blender/pulls/136217
Strip locking was meant to be used with strip transformation only. So
the check, whether strip is locked is removed from hide/unhide operator.
Further it was requested to lock sound strip subframe offset. Since this
is time related property, it was moved to time panel. This also
addresses request to make it more obvious, why the value can't be
changed.
The name of the property was clarified from "Offset" to
"Sound offset", because there are another 2 offsets in the panel.
Finally, when channel is locked, properties in side panel now reflects
this state. This is done by adding RNA get function for `Strip.lock`
property. Function `seq::transform_is_locked` is used instead of
checking `SEQ_LOCK` flag, because it also checks channel state. With
this setup, the lock property can't be disabled while channel is locked.
However strip lock flag will be unset, which can be prevented. (I am not sure which is better. Both are fine in my eyes.)
Pull Request: https://projects.blender.org/blender/blender/pulls/135831
The "slip strip contents" operator in the VSE now can move the strip
keyframes. There is a property to enable keyframe slipping.
The property is disabled by default, mainly because animation is
often used for fade in/out, which would be annoying if it moved with
content.
Pull Request: https://projects.blender.org/blender/blender/pulls/136386
The initial goal of this PR is to avoid creating vertex and index
buffers as part of the "request" phase of the drawing loop. Conflating
requesting and creating index buffers might not sound so bad, but it
ends up significantly complicating the whole process. It is also
incompatible with a future buffer cache that would allow avoiding
re-uploading mesh buffers.
Specifically, this means removing the use of `DRW_vbo_request` and
`DRW_ibo_request` from the mesh batch extraction process. Instead, a
list of buffer types is gathered based on the requested batches. Then
that list is filtered to find the batches that haven't been requested
yet. Overall I find the new process much easier to understand.
A few examples of simplifications this allows are avoiding allocating
`MeshRenderData` on the heap, and the removal of its `use_final_mesh`
member. That's just replaced by passing the necessary information
through the call stack.
Another notable difference is that for meshes, EEVEE's velocity module
now requests a batch that contains the buffer rather than just requesting
the buffer itself. This is just simpler to get working since it doesn't require
a separate code path.
The task graph argument for extraction is unused after this change. It wasn't
used effectively anyway; a simpler method of multithreading extractions is
used in this PR. I didn't remove it completely because it will probably be
repurposed in the next step of this project.
The next step in this project is to replace `MeshBufferList` with a
global cache that's keyed based on the mesh data that compromises each
batch, when possible (i.e. for non edit-mode meshes). This changes above
should be applied to other object types too.
Pull Request: https://projects.blender.org/blender/blender/pulls/135699
Rather than transforming the nodes inside shrinking frames together with
their parent, they are now transformed individually. That way the nodes
are aligned with the grid when snapping and the frame is adjusted by
the automatic resizing.
This makes the grid alignment of nodes is consistent, no matter whether
the node or its parent frame is transformed.
The behavior for manually resized frames is unchanged.
Pull Request: https://projects.blender.org/blender/blender/pulls/136381
This makes it possible to restore previous Blender 4.3 behavior of bump
mapping, where the large filter width was sometimes (ab)used to get a bevel
like effect on stepwise textures.
For bump from the displacement socket, filter width remains fixed at 0.1.
Ref #133991, #135841
Pull Request: https://projects.blender.org/blender/blender/pulls/136465
Resolves#136183
To avoid quadratic worst case runtime when gathering values from
the modifier properties, build a temporary VectorSet of the modifier's
IDProperties. In the file from #136183, this change improves playback
performance by 1.4x for me, from 50 to 70ms.
Ideally IDProperty groups would have constant time lookup on their
own, but that's a much larger change, and this smaller change for just
Geometry Nodes is not so invasive.
Pull Request: https://projects.blender.org/blender/blender/pulls/136463
The crash regression comes from 583e2b7240.
Pass the s_sharedHGLRC directly to wglCreateContextAttribsARB instead
of using wglShareLists.
Context: https://github.com/baldurk/renderdoc/issues/1224
This doesn't only fix the recent regression, but solves all the long
standing issues with Renderdoc on Windows (F12 rendering support,
multiple windows, deferred compilation...).
(Fix suggested by @LazyDodo)
Pull Request: https://projects.blender.org/blender/blender/pulls/136140
Usually we prefer to propogate attributes based on name, even for
conversion between geometry types. Builtin attributes are a common
exception though. The Curve to Points node and the Curve to Mesh node
didn't correctly handle the "custom_normal" attribute, which shouldn't
be propagated. This has only been a problem since custom normals were
converted to a generic attribute on meshes in f9b627d29c.
Pull Request: https://projects.blender.org/blender/blender/pulls/136452
