The title is pretty self-explanatory: this change brings support of
displaying HDR content in the sequencer preview. Before this change
it was clamped to the 0..1 range, now it is unclamped sRGB, similar
to how image editor, viewport, and nodes backdrop works.
The general idea is to draw the sequencer content on a non-overlay
frame-buffer and tag viewport as having non-standard input color
space as the sequencer operates in a different space.
The way it is done mimics what happens from the draw manager side
for the nodes backdrop, but bypassing the image engine. Partially
because the image engine expects the Image data-block to be displayed,
but also because of performance: there are a lot of things going on
like float buffer creation, clamping etc. Overall the image engine is
not fast enough for the sequencer needs.
Code-side changes that worth mentioning to highlight the overall
direction for the possible future refactors in the area:
- Decouple arguments from the scene: editing, render data, color
management etc are now passed as individual arguments.
This is an anticipation of story tools project where this data
might be coming from a different place.
- Move the entire preview region drawing to sequencer_preview_draw.cc
Previously logic was split across sequencer_preview_draw.cc and
space_sequencer.cc which was quite tricky to know what should go
where.
- Split functions which had boolean argument to define their behavior
into individual functions.
Generally if a function has boolean argument used in a way
if(foo) { do_something_(); } else { do_something_else() }
it is a good indication that the function is to be split.
Pull Request: https://projects.blender.org/blender/blender/pulls/138094
It always was functionality which got committed without proper review
by the module or UI/UX team. It has all sort of UX problems, but it is
also something that will be tricky to support for HDR drawing.
To brings things to a more manageable state the functionality is now
removed.
Adds custom knots support to Split operator. Works very well if the
selection starts and ends with clamped control points (knots repeated
`order - 1` times). In other cases some geometry is lost compared to
the original curve.
Pull Request: https://projects.blender.org/blender/blender/pulls/138230
On Windows and Mac (and with certain backends on Linux), Blender would
always appear to be playing back audio even if there was no timeline
playback. This would sometimes prevent devices from going to sleep or
going into lower power state modes when idling.
For the affected audio backends, we now automatically close the audio
backend after 30 seconds of inactivity.
Pull Request: https://projects.blender.org/blender/blender/pulls/136845
This is caused by the pointcloud attribute header not being added
to the volume shader.
The fix is to make volume shaders not require volume attribute
for geometry types that do not support it.
Pull Request: https://projects.blender.org/blender/blender/pulls/138212
Allows basic support for using `namespace X {}` and `X::symbol`
syntax.
Benefit:
- More sharing possible with host C++ code.
- Isolation of symbols when including shader files as C++.
Requirements:
- Nesting must be done using `namespace A::B{}` rather than
`namespace A{ namespace B {}}`, which is unsupported.
- No support for `using namespace`.
- Support of `using X` and `using X = Y` inside of function scope.
- Support of `using X` and `using X = Y` inside of namespace scope.
However, this is only to bring symbols from the same namespace
declared in another block (potentially inside another file).
- Only support namespace elision for symbols defined and used
inside of the same namespace scope.
Note that this is currently limited to blender GLSL files and
not for the shared headers. This is because we need to port a lot
of code to use namespaces before allowing this.
### Follow Up:
Nesting like `namespace A{ namespace B {}}` shouldn't be hard to
support and could be added if needed.
Rel #137446
Pull Request: https://projects.blender.org/blender/blender/pulls/137445
With `MESH_OT` prefix, the shortcut was added to wrong
keymap ("object mode", see: `WM_keymap_guess_opname`).
idname of following operations has been changed, they are
only exposed in sculpt mode UI (also see their poll function:
`geometry_extract_poll`):
- `face_set_extract`
- `paint_mask_extract`
- `paint_mask_slice`
Pull Request: https://projects.blender.org/blender/blender/pulls/133852
Added a new operator `OBJECT_OT_material_slot_remove_all`
that removes all materials from the material slots of selected objects
This was inspired by a request proposal on RCS.
Pull Request: https://projects.blender.org/blender/blender/pulls/138402
This commit update the release note tools to read the crawl delay for
projects.blender.org directly from
https://projects.blender.org/robots.txt instead of relying on a hard
coded value.
A frame label that is hidden by links is not all that helpful.
On the other hand, if a link is partially hidden by a frame label,
that's typically not a problem at all.
This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias
for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled.
Description copied from the patch:
```
/**
* blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API
* of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers
* like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one
* still has to use std::mutex for that case.
*
* The mutex provided by TBB has these properties:
* - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to
* lock the mutex at the same time.
* - In the contended case, it spins a couple of times but then blocks to avoid draining system
* resources by spinning for a long time.
* - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes
* it more feasible to have many smaller mutexes which can improve scalability of algorithms
* compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender.
* - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the
* mutex when there are always more than one threads that try to lock it. In the majority of
* cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not
* guaranteed to be fair either.
*/
```
The performance benchmark suggests that the impact is negilible in almost
all cases. The only benchmarks that show interesting behavior are the once
testing foreach zones in Geometry Nodes. These tests are explicitly testing
overhead, which I still have to reduce over time. So it's not unexpected that
changing the mutex has an impact there. What's interesting is that on macos the
performance improves a lot while on linux it gets worse. Since that overhead
should eventually be removed almost entirely, I don't really consider that
blocking.
Links:
* Documentation of different mutex flavors in TBB:
https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html
* Older implementation of a similar mutex by me:
https://archive.blender.org/developer/differential/0016/0016711/index.html
* Interesting read regarding how a mutex can be this small:
https://webkit.org/blog/6161/locking-in-webkit/
Pull Request: https://projects.blender.org/blender/blender/pulls/138370
We recently started using blenloader code in blendthumb to avoid having to
reimplement some parts of .blend file parsing. While this works, it has the side
effect that on Windows referencing blenloader code increased the binary size of
blendthumb from < 1MB to ~75 MB. That happens because this dependency drags
along lots of other code which effectively is unused, but the compiler is unable
to remove it.
There didn't seem to be a simple solution to make msvc optimize the unused code
away. This patch solves the issue by extracting the shared code into a separate
`blenloader_core` module which does not depend on the rest of Blender (except
blenlib). Therefore, using this new module in blendthumb does not drag along all
the other dependencies, bring its file size back down.
In the future, more code may be moved from blenloader to blenloader_core, but
for now I extracted these two headers:
* `BLO_core_bhead.hh`: Various `BHead` types and related parsing functions.
* `BLO_core_blend_header.hh`: Parsing of the header at the beginning of .blend
files.
Pull Request: https://projects.blender.org/blender/blender/pulls/138371
This is loosely related to #136285, which allows changing numerical
values while in text entry mode. Outside of that, just hovering over
numerical inputs we are currently able to increment and decrement by
Ctrl + Mouse Wheel. This works for integers, floats, sliders. Current
code also allows cycling through expanded enums. This PR extends that
so Ctrl + Mouse Wheel also changes toggles and checkboxes and also
changes values inside of strings.
---
[2/4] Don't increment string if blank
---
[3/4] Use dynamic strings.
---
[4/4] Use ui_but_string_get_ex and ui_but_string_get_dynamic
Ref: !138344
While the function `ED_view3d_dist_range_get` was meant to calculate
the range for `RegionView3D::dist` the minimum value was often clamped
by the clip-start instead.
Move this into a function and improve doc-strings in this area
to clarify the conventions viewport zoom is expected to follow.
- Rename `ED_view3d_dist_range_get` to `ED_view3d_dist_soft_range_get`
since it's not an error when the `dist` is outside this range.
- Return `Bounds<float>` instead of taking a return argument.
- Take a `use_persp_range` argument to avoid re-assigning
the minimum in some cases.
- Add `ED_view3d_dist_soft_min_get` since it's common for
only the minimum to be used (replace inline `v3d->clip_start * 1.5f`).
This converts the public uiLayoutPanelPropWithBoolHeader function to an
object oriented API (`uiLayout::panel_prop_with_bool_header`), following
similar changes to the uiLayout API.
Pull Request: https://projects.blender.org/blender/blender/pulls/138523
Several small improvements to the layout of the search menu:
* Avoid the separator arrow on highlighted items being cutoff
* Properly center and prevent overlap of the scroll indicator
arrows at the top and bottom
* Improve robustness with different zoom levels
* Overall more unified spacing and margins
This patch was originally authored by Yevgeny Makarov (@jenkm).
Pull Request: https://projects.blender.org/blender/blender/pulls/112422
When not all the meshes referenced by the instances recursively
are realized because of the limit of the depth input, and those
meshes have vertex groups, a crash is possible because of an
un-checked VectorSet lookup. `all_meshes_info.order` includes
all meshes regardless of the depth and mask arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/138519
Check for both `CF_TEXT` and `CF_UNICODETEXT` in
`GHOST_DropTargetWin32::getGhostType` because, unlike for the clipboard,
Windows does not synthesize `CF_TEXT` from `CF_UNICODETEXT` and vice
versa for drag and drop operations. Since `getGhostData` already
supports `CF_UNICODETEXT`, this is all that's necessary to make it work.
I encountered this issue when trying to drag text from Notepad++ into
Blender's text editor.
Pull Request: https://projects.blender.org/blender/blender/pulls/138524
The size of preview images while dragging from File or Asset Browser is
currently related to the size that they are shown in the thumbnail
lists, sort of, but also based on the column size and with an incorrect
scaling. This PR just makes them a consistent size while dragging,
regardless of their thumbnail size.
Pull Request: https://projects.blender.org/blender/blender/pulls/138350
Patch #137802 made VSE zoom levels constant when resizing the area,
choosing to also align the V2D to the left when horizontally resizing.
This had the added side-effect of causing zooming to be left-aligned. The
fix was attempted in #138041 (and subsequent commit 385a8a4d6a).
However, the versioning code to add the fix (`V2D_ZOOM_IGNORE_KEEPOFS` flag)
was included in the original versioning block instead of a new one. This
meant that newly saved files during the bug did not get the fix applied.
Fix by moving that flag application to a new versioning block.
Pull Request: https://projects.blender.org/blender/blender/pulls/138424
The GLSL processor appears to dislike a member named "select" when a function named "select" exists.
The member has been renamed to object_select to avoid collisions.
Pull Request: https://projects.blender.org/blender/blender/pulls/138466
Now results are similar under different time steps. Additionally it is
now working correctly with different time scale, where smoke lifetime
is proportional to time scale.
Pull Request: https://projects.blender.org/blender/blender/pulls/138347
These attributes are handled specifically in execute_instances_tasks
anyway so the generic code path doesn't make sense. Referencing
those attributes is incorrect since the temporary geometry set built
for collections goes out of scope after foreach_geometry_in_reference.
Part of #138279
Pull Request: https://projects.blender.org/blender/blender/pulls/138508
