Part of blender/blender!125449.
Since brush assets were merged, the brush asset selector and some other brush
UIs wouldn't show up for the primitive tools. This is addressed now. The
primitive tools use the same brush as the brush tool, although only the draw
brushes will work properly. !125449 addresses this so the primitive tools
remember their own draw brush, separate from the brush tool.
Turns out that these primitive tools were never tagged as using brushes by
setting the `data_block` member (or setting the `'USE_BRUSHES'` option since
b64bf66257). The UI was just hardcoded to display things like the brush selector
for primitive tools. So as far as the tool system knew, these tools did not use
brushes.
Tagging the tools properly exposed some issues that are addressed here (see PR
for details).
Pull Request: https://projects.blender.org/blender/blender/pulls/127204
The previous way of considering tools with the `data_block` member set
as using brushes was rather unclear/confusing, but also a bit outdated
with the brush assets changes. Since then most sculpt/paint modes use a
unified brush tool, there was no tool for every brush type (aka brush
tool) anymore. So now the `data_block` member was just set dynamically to
match the active brush type which is otherwise irrelevant to the tool
system now.
Further, this will become important to bring back some of the tools that
use brushes in grease pencil draw mode, see #116337. For that we want to
keep the unified brush tool, but still allow other tools that only use a
specific brush type. So marking a tool as using brushes should be done
separately from indicating a specific brush type.
Removing/replacing the `data_block` member should happen separately
still, pending further developments (e.g. see #125449).
Pull Request: https://projects.blender.org/blender/blender/pulls/125911
Saving files could take ~3-4 seconds on debug builds because of new
imbuf scaling logic.
Even though debug performance usually isn't much of a consideration,
it gets in the way of development.
Since thumbnails don't require the same accuracy as the sequencer or
compositor, use a faster scaling method that uses a box-filter clamped
to integer bounds & integer math.
In practice the difference between the resulting thumbnails isn't
noticeable in my tests.
For debug build with ASAN this gives a ~25x speedup,
for release builds it gives a ~1.4x speedup which is to be
expected with a more approximate scaling method.
Replace uses of WM_window_native_pixel_x,y with
WM_window_native_pixel_size() which returns an int2 for convenience
and avoids an unnecessary call to GHOST_GetNativePixelSize(..).
On MS-Windows the current frames file set the window title.
Remove this because it's strange to have the title flickering over
each name and the animation player already supports showing the filename
inside the window.
- Clarify misleading logic when the buffer couldn't be allocated.
- Use a utility function to calculate the thumbnail size.
- Calculate the thumbnail size for the on-disk thumbnail
separately (corrects minor rounding error) caused by
scaling the smaller size up.
Add multiple "hand" mouse cursors. These are mostly needed for Mac,
which needs open, close, and pointing hand cursors. This also adds
similar for Windows, but just for completeness and testing.
Pull Request: https://projects.blender.org/blender/blender/pulls/127164
This PR allows users to select a GPU backend.
In the system tab of the user preferences the GPU backend can be selected in the `Display Graphics` panel.
It will require a restart of Blender before the changes become effective.
During startup minimum requirements are checked. Blender will switch automatically
to OpenGL when no compatible Vulkan device could be detected. A dialog will be shown
to inform the user.
The setting of the in the `Display Graphics` panel are still overridden when blender is started
using the `--gpu-backend` option. When starting blender with `--debug-gpu` the backend
detection will print to the console.
See PR for detailed information and screenshots of the UI.
Implements #126504
Pull Request: https://projects.blender.org/blender/blender/pulls/126545
Adds an option to the "Clear Recent Files List" operator to allow it
to remove only items that are not found. By default it clears "All
Items" but this can be changed to "Items Not Found".
Pull Request: https://projects.blender.org/blender/blender/pulls/127024
The term "tool" is historic from before the actual tool system got
introduced. Since then the term was already a bit confusing, because it
wasn't directly related to the tool system, but there was still some
relationship between the two. Now brushes and their types are decoupled
much more from the tool system, with a single "Brush" tool supporting
all kinds of brushes (draw, grab, cloth, smooth, ...).
For a more clear terminology, use "brush type" instead of "tool".
For #126032 we need to write the brush type to the asset metadata (done
in !124618), so we can filter brushes based on the type (so the grease
pencil eraser tool only shows eraser brushes, for example). I'd like to
use future proof names for that to avoid versioning of asset metadata in
future, so I'd rather do the full naming change now.
RNA properties (thus BPY names) are not changed for compatibility
reasons. Can be done in 5.0, see blender/blender#124201.
Pull Request: https://projects.blender.org/blender/blender/pulls/126796
The version text shown over the splash screen image needs to always be
white regardless of the theme. With "Blender Light" this text is black
and almost impossible to read. This PR adds the ability to set a
specific color for labels without icons and does so for the splash
screen.
Pull Request: https://projects.blender.org/blender/blender/pulls/126340
This commit essentially moves allocation of KeyMaps and Operators
PointerRNA data storage to use C++ new/delet, instead of C alloc/free.
Part of the effort to make PointerRNA non-trivial (#122431).
Pull Request: https://projects.blender.org/blender/blender/pulls/126935
Pass the context using const where it makes sense. Had some own code
that called some of these functions, so I had to keep context non-const
there too for no good reason.
Current default tool is "sample" which is a bit odd, and coupled with
the fact that the toolbar is hidden by default, this can be confusing
to new users, leading them to believe tweak/select tools are not
supported for the VSE preview.
This change:
- Sets "box select" as the default tool for the Preview
- Makes both Preview and Timeline toolbars shown by default
Pull Request: https://projects.blender.org/blender/blender/pulls/126336
This changes how the lazy-loading and unloading of volume grids works. With that
it should also fix#124164.
The cache is now moved to a deeper and more global level. This allows reloadable
volume grids to be unloaded automatically when a memory limit is reached. The
previous system for automatically unloading grids only worked in fairly specific
cases and also did not work all that well with caching (parts of) volume
sequences.
At its core, this patch adds a general cache system in `BLI_memory_cache.hh`. It
has a simple interface of the form `get(key, compute_if_not_cached_fn) ->
value`. To avoid growing the cache indefinitly, it uses the new
`BLI_memory_counter.hh` API to detect when the cache size limit is reached. In
this case it can automatically free some cached values. Currently, this uses an
LRU system, where the items that have not been used in a while are removed
first. Other heuristics can be implemented too, but especially for caches for
loading files from disk this works well already.
The new memory cache is internally used by `volume_grid_file_cache.cc` for
loading individual volume grids and their simplified variants. It could
potentially also be used to cache which grids are stored in a file.
Additionally, it can potentially also be used as caching layer in more places
like loading bakes or in import geometry nodes. It's not clear yet whether this
will need an extension to the API which currently is fairly minimal.
To allow different systems to use the same memory cache, it has to support
arbitrary identifiers for the cached data. Therefore, this patch also introduces
`GenericKey`, which is an abstract base class for any kind of key that is
comparable, hashable and copyable.
The implementation of the cache currently relies on a new `ConcurrentMap`
data-structure which is a thin wrapper around `tbb::concurrent_hash_map` with a
fallback implementation for when `tbb` is not available. This data structure
allows concurrent reads and writes to the cache. Note that adding data to the
cache is still serialized because of the memory counting.
The size of the cache depends on the `memory_cache_limit` property that's
already shown in the user preferences. While it has a generic name, it's
currently only used by the VSE which is currently using the `MEM_CacheLimiter`
API which has a similar purpose but seems to be less automatic, thread-safe and
also has no idea of implicit-sharing. It also seems to be designed in a way
where one is expected to create multiple "cache limiters" each of which has its
own limit. Longer term, we should probably strive towards unifying these
systems, which seems feasible but a bit out of scope right now. While it's not
ideal that these cache systems don't use a shared memory limit, it's essentially
what we already have for all cache systems in Blender, so it's nothing new.
Some tests for lazy-loading had to be removed because this behavior is more
implicit now and is not as easily observable from the outside.
Pull Request: https://projects.blender.org/blender/blender/pulls/126411
API: merged IMB_scalefastImBuf, IMB_scaleImBuf, IMB_scaleImBuf_threaded
into one function IMB_scale with enum IMBScaleFilter {Nearest, Bilinear, Box}
and bool "threaded" param.
Performance:
- Box filtering (nee IMB_scaleImBuf) can be multi-threaded now.
- Nearest filtering (nee IMB_scalefastImBuf) can be multi-threaded now.
Also fix performance regression on float images caused by fix in #126234
- Bilinear filtering (nee IMB_scaleImBuf_threaded) is several times faster now.
Correctness:
- Nearest and Box filtering: no longer loses half of edge pixels when scaling
up.
- Box: fixed garbage results (and possible out of bounds reads) for non-4
channel float images.
- Bilinear: no longer shifts image when scaling up.
- Bilinear: properly filters when scaling down by 2x2.
Test coverage:
- Add gtest coverage for various IMB_scale modes.
- Add a IMB_performance_test performance test, ran manually.
More details, images and performance numbers in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126390
The reasoning in the comment applies to "Save as..." as well, because
the destination file becomes the active one and opened data and active
file on disk match.
When saving a copy the active file is not updated, so existing
compatibility issues would remain.
Pull Request: https://projects.blender.org/blender/blender/pulls/126266
When the operator was introduced, the program specified the immediate
mode program GPU_SHADER_3D_UNIFORM_COLOR but did not bind a particular
value. This leads to the color used for this circle changing depending
on the last color bound when drawing.
This change makes the color of the circle white, as initially intended,
and adds a darker outline to improve readability.
Pull Request: https://projects.blender.org/blender/blender/pulls/126259
For the times we need to obtain the bitmap of an SVG icon, send these
through the new theme coloring callback if they are multi-color. This
removes some code duplication by adding a new function that gets an
imBuf from SVG Icon. This allows, for "About" logo, Dialog icons, and
file system icons the optional ability to use a single SVG source file
that works as both monochrome (themed by text color) or multicolor with
internal parts themed.
Pull Request: https://projects.blender.org/blender/blender/pulls/126215
When we draw SVG icons we have an optional argument that specifies to
treat it as multicolor. This PR allows doing the same thing when
requesting a bitmap from an icon. This is only currently done for
Dialog boxes and the About screen. The purpose of this isn't really
to allow multicolor dialog icons, but to get to the point where a
single SVG source file could be used as monochrome (changing the one
color with text color) or multi-color (changing internal colors with
themes) without needing multiple copies of the source file
Pull Request: https://projects.blender.org/blender/blender/pulls/126193
This PR corrects some mistakes in the conversion between RGBA bitmaps
created when rasterizing SVG icons and the monochrome coverage maps
when displaying these in a single color. This only occurs when we need
a bitmap from an icon for About screen and for dialogs. The bitmap
from NanoSVG is already premultiplied so don't do it again. When
converting from coverage map to RGBA use map value for all components
rather than FFF for colors. When converting to coverage map from RGBA
use perceptual grayscale level of color, not just alpha value.
Pull Request: https://projects.blender.org/blender/blender/pulls/126192
The WM API has WM_window_pixels_{x,y,coords}` functions that returns the
window size/point coordinate in the host native pixel size.
As "pixels" in itself doesn't really mean anything the intent of
these functions wasn't really clear. To clarify this, this commit
renames their prefix from `WM_window_pixels_` to
`WM_window_native_pixel_`.
Pull Request: https://projects.blender.org/blender/blender/pulls/125994
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
When appending e.g. an object, it's generally expected that it is not just
appended but also added to the active collection. Something similar happens for
adding collections, or just geometry like a mesh data-block. This is called
"loose data instantiation" in the source code.
Which data is instantiated and how depends on context. Generally, it's best to
first do the low-level link or append operation and only afterwards do the
instantiation at a higher level where more context is known. For example, when
dragging an object asset into the 3D view, it's expected that the object is
added to the active collection. When dragging a node group into the node editor
that uses an object internally (e.g. as mesh storage), not so much.
This patch adds a new `BKE_blendfile_link_append_instantiate_loose` method that
does the "default instantiation", i.e. the one we want to happen when using the
general link/append operator to import data. Instead of calling this directly
from low level `BKE_blendfile_append`, it's now called in `wm_link_append_exec`
(and other places where desired).
Furthermore, `view3d_ob_drop_copy_external_asset` does not use this anymore, but
explicitly adds only the dragged object to the active collection. Some places,
e.g. when linking/appending using the Python API, don't do any instantiation at
all. They didn't do this before either, but it was way less obvious (it used
`BLO_library_link_params_init` instead of
`BLO_library_link_params_init_with_context`). Now there is always an explicit
call to do instantiation in higher level code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125814
When dragging an area from one window to another, the target location
was out by the monitor dot-pitch on macOS Retina displays. This commit
fixes this by converting the window position coordinates to the display
native pixel size via a new `WM_window_pixels_coords` API function.
Pull Request: https://projects.blender.org/blender/blender/pulls/125926
The RNA path that is generated for Editor properties were mostly
incomplete (e.g. the viewport overlay settings).
- in python tooltips
- from the `Copy (Full) Data Path` operator
- python methods `path_from_id`, `path_resolve` returned incomplete paths
Since a space (editor) is ultimately owned by the screen, we now add the
missing "areas[x].spaces[x]" subpath to any editor.
Nested structs (like the viewport overlay) also need to include this
subpath.
Some editor related structs are not tied to a single space though (and
these cases are therefor not resolved yet):
- Dopesheet is referenced from SpaceGraph, SpaceAction and SpaceNla
- View3DShading is referenced from SpaceView3D but render engines as
well
- FileSelectParams / FileAssetSelectParams / FileAssetSelectIDFilter
need more investigation
NOTE: in case of the VSE, to make this work this also changes the
overlays to be tied to SpaceSeq (the only editor using them)
NOTE: since the above is now in place, adding VSE overlay props to Quick
favourites is now made possible as well (was a leftover from !116604)
Fixes#124527, #113489
Pull Request: https://projects.blender.org/blender/blender/pulls/125365
This tries to keep to the spirit of task of #124511. Title bar shows
a more detailed version string, while status bar shows more compactly.
"LTS" is included in the long form when defined. Patch version shown
in both detailed and long form but only if non-zero. "Alpha", "Beta",
"Release Candidate" included in long form, but uses " a", " b", " RC"
for short form.
Pull Request: https://projects.blender.org/blender/blender/pulls/125332
