ffmpeg internals log a warning when telling it to use more than 16
threads, so cap thread count to that.
Testing the change locally on Ryzen 5950X (where it was using 32
threads previously), capping at 16 is actually faster:
- Playback of one 4K video downsampled at 1080 res:
seq_render_strip_stack average 9.12ms -> 7.83ms
- Playback of two blender 1080p videos: seq_render_strip_stack
average 5.79ms -> 4.94ms
I suspect this might be because this CPU has 16 physical cores
with SMT (so 32 "logical" threads), and depending on the workload
capping at number of physical cores might be better.
Pull Request: https://projects.blender.org/blender/blender/pulls/145665
When panels in node groups were introduced, the interface data of a tree was
moved from `tree.inputs_legacy/outputs_legacy` to `tree.tree_interface`. For
forward compatibility, the old interface was still written. Since Blender 4.5
can read the new format and older versions are not able to open files created in
5.0 directly anymore, it's fine to remove this forward-compatibility code now.
Also fixes#145278.
Pull Request: https://projects.blender.org/blender/blender/pulls/145489
With the changes to area border drawing and the addition of selectable
border width it is possible to get areas that are below header height
while moving them around. This PR just tightens that up so they always
remain at least the minimum height.
Pull Request: https://projects.blender.org/blender/blender/pulls/145704
Flag regions that are only a couple pixels tall as "too small" so they
are not drawn. The previous border drawing overwrote the outer pixels
of the area but the new drawing does not, which can sometimes show a
single line of pixels when the area is minimized to just header height.
Pull Request: https://projects.blender.org/blender/blender/pulls/145696
PR #143513 forgot to grab the scene from `CTX_data_sequencer_scene`
since this was before the sequencer scene patch landed.
So if the scene differed from the sequencer scene it would find the
wrong strips to slip.
This was caused by incorrectly implemented store/restore mechanism for
`move_strips` property. The property was restored to original state
immediately after strip was added when using drag and drop. So when any
other property was modified, on redo the modal move operation would
start.
The store/restore mechanism was removed, because it is possible to only
rely on checking whether invoke function was called by drag event.
The move strips property is now hidden in redo panel, because it does
not make sense to ever change it there. This is done by setting hidden
`skip_move` property and setting `move_strips` property hidden flag.
Another slightly related bug was discovered, that move strips feature
is incompatible with replace selection feature being disabled. So the
property is not drawn when move strips feature is enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/144172
Stored undo step data for position changes in sculpt mode are now
automatically compressed. Compression is run in background threads,
reducing memory consumption during sculpting sessions while adding
little performance overhead.
For testing and benchmarks, memory usage is now available through
`bpy.app.undo_memory_info()`. Undo memory usage is now tracked by the
existing automated benchmark tests. Some changes to the web benchmark
visualization present the data a bit better.
ZSTD compression is run asynchronously in a backround task pool.
Compression is only blocking if the data is requested immediately for
undo/redo.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/141310
This feature works like the select circle in any other modes. The user
can press "C" in preview or timeline and then select or deselect strips
by pressing the left or middle mouse button.
It’s an enhancement for the VSE preview because:
1. It makes it more similar to other editors in Blender
2. This behavior makes it easier to select specific overlapping strips
in preview, that is because the select circle only checks for the
origin of the strip.
Pull Request: https://projects.blender.org/blender/blender/pulls/141422
Now that there are Rec.2100 PQ and HLG displays, the additional HDR option
for video export is redundant. Typically you would now select a HDR display
early on and do all your video editing with it enabled.
For saving a HDR video, the encoding panel will now show the name of the color
space, and warn when the video codec or color depth is incompatible.
Since this is now based on interop IDs for the dislpay color spaces, we can
map more of those to the appropriate CICP code. This works fine for Display P3,
in my tests it looks identical to sRGB except that the wide gamut colors are
preserved.
However Rec.1886 and Rec.2020 are problematic regarding the transfer function,
although the latter at least has the correct primaries now. So it should be
a net improvement and this could be looked at later if anyone wants.
---
Background:
* Rec.1886 and Rec.2020 display color spaces in Blender use gamma 2.4.
* BT.709 trc is almost the same as gamma 2.4, so seems like the correct choice.
* We already write sRGB with BT.709 trc, which seems wrong.
* Yet sRGB matches exactly between Blender display and QuickTime, while
Rec.1886 and Rec.2020 do not.
* Display P3 with BT.709 trc matches sRGB with BT.709 trc, just adding the wide
gamut colors. So that is what is used for now. Also using the sRGB trc the
file is not recognized by QuickTime.
There is apparently a well known "QuickTime gamma shift" issue, where the
interpretation of the BT.709 trc is different than other platforms. And you need
to do workarounds like writing gamma 2.4 metadata outside of CICP to get
things to display properly on macOS.
Not that QuickTime is necessarily the reference we should target, but just to
explain that changing the previous behavior would have consequences, and so
it this commit leaves that unchanged.
Pull Request: https://projects.blender.org/blender/blender/pulls/145373
Like image saving, this may be modified from the scene ImageFormatData
to contain the effective color management settings taking into account
overrides.
For upcoming changes, we will need to know the image buffer colorspace when
starting to write the video instead of only on the first frame.
Pull Request: https://projects.blender.org/blender/blender/pulls/145373
Menus listing assets (which the search menu covers) rely on notifiers to
know when their chached asset catalog tree is invalid and needs
rebuilding. The 3D view notifier listener would not check for the
notifier that is sent when the asset storage was cleared after a file
save.
Pull Request: https://projects.blender.org/blender/blender/pulls/145583
The Movie Distortion node produces artifacts when used with half
precision context. This is because distortion grids require full
precision for high quality results, which this patch does.
Pull Request: https://projects.blender.org/blender/blender/pulls/145640
Some FBX files contain somewhat incorrect relative paths for their
material textures. The old Python importer was "working" only as a side
effect that it was exhaustively searching the subfolder hierarchy.
Try to do a smaller version of that here too: if referenced image
is still not found after trying the regular relative/absolute paths,
try taking longer path parent chains from the absolute path coming
from FBX file, and using that as relative path wrt the FBX file itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/145641
Resolve regression in [0] where name was translated for the name but
not the Python expressions, it's possible to translate both but this
doesn't seem so simple as these functions don't necessarily run at
the same time.
[0]: 6926596174
Checker deselect on circular vertex selections or loops produced
irregular patterns instead of a consistent checker pattern.
Resolve by handling cyclic chains as a special case.
Ref !145465
* Moves the paint cursor pointer to `PaintRuntime`
* Removed the stored runtime color value - this was effectively
hardcoded to a shade of red (255, 100, 100) with an alpha of 128.
The red color was only used for the smooth stroke overlay (the trailing
line) and the alpha value was only ever used for the *Line* stroke type.
Pull Request: https://projects.blender.org/blender/blender/pulls/145371
This commit adds support for users to customize individual pressure
mapping curves for size, strength, and position jitter on a per-brush
basis to improve expression when using drawing tablets. This feature is
already implemented in Grease Pencil, and this PR adds the same
functionality to Texture/Image paint, Vertex/Weight paint, and Sculpt
modes.
The UI and functionality are the same as those in Grease Pencil.
Co-authored-by: Sean Kim <SeanCTKim@protonmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/144428
Build the size for each curve in parallel, then accumulate the sizes
to offsets afterwards. This way it's easy to parallel. Also only count
custom knots for NURBS.
Pull Request: https://projects.blender.org/blender/blender/pulls/145581
The prior change missed that `UvSculpt` brushes have their own isolated
`size` value stored at the `ToolSetting` level and not stored as either
brush assets or on the `UnifiedPaintSettings` struct
Similar to #139813
Pull Request: https://projects.blender.org/blender/blender/pulls/144837
In the vertical list display mode, if only the top part of a file was
scrolled into view, the file wouldn't actually draw. So while scrolling
down the list, the last item would visibly pop up. This wasn't intended,
not drawing these items is just an optimization.
Issue was the offset for the table header (reading something like "Name
| Modified | Size") wasn't accounted for.
Instead of just disabling the cyclic bit of the flag, the code
reset the whole flag to -2 which doesn't really make sense.
It cause a problem because the "custom knots" bit was set
but there weren't any allocated custom knots.
Pull Request: https://projects.blender.org/blender/blender/pulls/145580
Somehow the file in this report ended up with a node pointer that
disagreed with the socket pointer. Since we use the latter for drawing,
that's a better source of truth. This commit adds a versioning step
that corrects the node pointer. If this happens again we may need
to run the versioning again at some point, but that's not clear.
Pull Request: https://projects.blender.org/blender/blender/pulls/145409
Use AncestorPointerRNA to detect when property groups from an add-on
or key-map preference are edited so the preferences are marked as dirty
and saved on exit.
