The problem was that the screen space size of the brush was not updated.
This was not fully noticeable because the radius control operator was using
a not working scale correction.
The solution remove the scale correction and just update the brush size.
Note: This update currently happens when the cursor is drawn.
Pull Request: https://projects.blender.org/blender/blender/pulls/126773
Followup to 682161283e.
This type better reflects the intention of a read-only string reference,
and `std::string` should usually be used for owning string variables
only.
The tool-tip generated for FileHandler drag-n-drop may be obtained from a
different context where the dropbox poll function is invoked, which could
generated an incorrect tool-tip since FileHandlers are polled again in a wrong
context.
This can be solved by ensuring the same context is used, however the tool-tip
could be drawn in different windows.
To avoid undefined tool-tips , this generates the tool-tip in place when the
dropbox poll function is invoked.
Pull Request: https://projects.blender.org/blender/blender/pulls/125037
Due to rounding errors in `wm_gesture_straightline_do_angle_snap`, it
could give out a snapped result that's meant to be 45 degrees but does
not have equal X/Y distances after converted to integer. Since 45
degrees can be used to make a equal length structure, it's best to make
sure that resulting X/Y values are the same if the angle is multiple of
45 degrees.
This fix would be effective for all tools that uses this "straight line
gizmo".
Pull Request: https://projects.blender.org/blender/blender/pulls/128683
Due to rounding errors in `wm_gesture_straightline_do_angle_snap`, it
could give out a snapped result that's meant to be 45 degrees but does
not have equal X/Y distances after converted to integer. Since 45
degrees can be used to make a equal length structure, it's best to make
sure that resulting X/Y values are the same if the angle is multiple of
45 degrees.
This fix would be effective for all tools that uses this "straight line
gizmo".
Pull Request: https://projects.blender.org/blender/blender/pulls/128683
Second part to fix#128420.
On startup, the Blender File Outliner mode would show empty libraries
linked, pointing to the brush essentials files. This was because some
grease pencil versioning code would call
`BKE_paint_ensure_from_paintmode()`, which would link in the default
brushes. Then a bit later, brush assets versioning code would remove
local brushes from the default starup file, so the library link became
empty.
Initializing paint data shouldn't necessarily include importing default
brushes. In an earlier version I made this optional with a boolean, but
it's easy enough to separate out entirely.
Now `BKE_paint_ensure()` just initializes paint data, and
`BKE_paint_brushes_ensure()` has to be called to ensure that active
brushes are available.
Pull Request: https://projects.blender.org/blender/blender/pulls/128801
Replace 'over-allocation' by a standard `blender::Vector` storage for
the `wmGizmoProperty` target properties of the gizmo. This simplifies code somewhat, and
makes the code ready to manage non-trivial types of data.
Explicit default values are also given to all data of `wmGizmoProperty`,
as it appears that the default constructor will not nullify values in
the (trivial) embedded `custom_func` struct.
NOTE: There is much more that could be done in the wmGizmo area to make
it use modern C++ features. The scope of this refactor is strictly
limited to allowing C++ construction/destruction of the wmGizmoProperty
data, as it embeds a PointerRNA pointer that will soon become
a non-trivial C++ struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/128763
Blender crashes when opening a file that has an interactive compositor
active, while also having a script that invokes the compositor upon file
load.
This is caused by the same system GPU context being active in two
threads at the same time, which happens when the GPU context for the
compositor is created in the main thread, it is made current during
creation, but it is not reset to the main GPU context of the drawable
because it is null. So when the GPU compositor actually executes, it
makes the GPU context current again but in its own thread, causing a
BadAccess error in X11 and potentially other window systems.
The reason why the drawable is nullptr is because it is reset in the
existing window manager when opening a new file while Blender is open,
but it is never initialized for the new window manager. The drawable
info should be moved from the old window manager to the new window
manager in wm_file_read_setup_wm_use_new, but it is preemptively reset
by the wm_window_clear_drawable call before it it is moved. This is done
in wm_file_read_setup_wm_substitute_old_window.
So to fix this, we move wm_window_clear_drawable after the code block
where wm_file_read_setup_wm_substitute_old_window gets called.
This renames the mode identifiers to be consistent with e.g. the context mode identifiers and other names used for the new Grease Pencil.
For `object.mode`:
* `PAINT_GPENCIL` -> `PAINT_GREASE_PENCIL`
* `SCULPT_GPENCIL` -> `SCULPT_GREASE_PENCIL`
* `VERTEX_GPENCIL` -> `VERTEX_GREASE_PENCIL`
* `WEIGHT_GPENCIL` -> `WEIGHT_GREASE_PENCIL`
For the internal `ob->mode` flag:
* `OB_MODE_PAINT_GPENCIL_LEGACY` -> `OB_MODE_PAINT_GREASE_PENCIL`
* `OB_MODE_SCULPT_GPENCIL_LEGACY` -> `OB_MODE_SCULPT_GREASE_PENCIL`
* `OB_MODE_VERTEX_GPENCIL_LEGACY` -> `OB_MODE_VERTEX_GREASE_PENCIL`
* `OB_MODE_WEIGHT_GPENCIL_LEGACY` -> `OB_MODE_WEIGHT_GREASE_PENCIL`
Resolves#127374.
Pull Request: https://projects.blender.org/blender/blender/pulls/128604
Removes many of the operators, panels, and menus used exclusively by Grease Pencil v2 that are no longer needed in v3.
No functional changes are expected.
Some operators are still used by the annotations system and have to be kept around. These may be renamed in future.
Pull Request: https://projects.blender.org/blender/blender/pulls/128521
The `pre` handler is called after blender internal code is done populating
the link/append context with data to be processed, and before this data
starts being linked from library files.
The `post` handler is called after blender is done linking, and
potentailly appending and/or instantiating, the requested data and all
of their dependencies.
Both handlers are called with a single argument, the link/append
context.
An new RNA sets of wrappers have been added to expose relevant info from
these internal C++ structures.
NOTE: !113658 is very similar (but tied to asset drag & drop), whereas
this PR is more general (these could probably live hand-in-hand / side-
by-side).
Implements #122357
Pull Request: https://projects.blender.org/blender/blender/pulls/128279
-----------------
Some quick py example code:
```python
import bpy
def my_handler_pre(lapp_context):
print("About to {}:\n\t".format("link" if "LINK" in lapp_context.options else "append"),
"\n\t".join("{} '{}', from libs ['{}']".format(item.id_type, item.name,
"', '".join([l.filepath for l in item.source_libraries]))
for item in lapp_context.import_items))
def my_handler_post(lapp_context):
print("{}:\n\t".format("Linked" if "LINK" in lapp_context.options else "Appended"),
"\n\t".join("{} '{}', from lib '{}'".format(item.id.id_type, item.id.name, item.source_library.filepath)
for item in lapp_context.import_items))
bpy.app.handlers.link_append_pre.append(my_handler_pre)
bpy.app.handlers.link_append_post.append(my_handler_post)
```
As discussed in #128066, we want that activating a brush makes sure the
most appropriate tool is activated. For example activating an eraser
brush should activate an eraser tool, if available. This makes the
tool and brush binding two ways, which is more clear. Plus it means that
users don't have to care about tools at all if they don't want to, they
can just keep switching brushes and Blender takes care of the tool.
Implementation wise, this works by letting a Python operator lookup a
tool for a given brush type name, when activating a brush.
Design Task: https://projects.blender.org/blender/blender/issues/128066
When attempting to load a blend file that is not found or otherwise
invalid we are currently showing an (ugly) popup menu report and then
clearing the item from the Recent Files list. Clearing the list could
be unwanted in the case of files that are temporarily offline. And we
now have the ability to only clear "Items not found" using the "Clear
Recent Files List" operator. This PR removes that clearing.
Pull Request: https://projects.blender.org/blender/blender/pulls/127882
We'd first set the brush, then change tools, which would again set the
brush to what it was before (switching tools tries to remember its last
used brush). Instead, switch the brush after switching the tool.
Also added a brush API check to test if the brush is valid for the
current mode, so that we don't end up switching tools in that case. This
matches previous behavior where this would be checked as part of setting
the brush already, causing the function to early exit before the tool is
changed.
Getting the active tool from context doesn't work exactly when executed
from the properties editor, which shows the active tool settings of the
3D view. Make the brush tool code fallback to the active tool from the
3D view, so it can be called from the properties.
Order of operations was wrong: First, the new tool has to be activated
(or at least identified) before we can tell which tool (or more precise,
which brush type) to update the brush binding for.
When I was learning VSE code, MAXSEQ constant (a preprocessor define!) was
confusing. It makes it sound like it is "max sequences", but it is actually
"max channels". So rename it to SEQ_MAX_CHANNELS and make it C++ constexpr int
instead of preprocessor macro.
Pull Request: https://projects.blender.org/blender/blender/pulls/128024
Allows users to override the auto detection for GPU
selection. Normally the GPU selection is done by looping
over the order Vulkan provides and finding the highest
performing device based on its type (discrete, integrated,
software).
However users might have multiple discrete cards and want
to switch between them. Or developers want to validate other
GPUs without rebooting.
This PR adds the ability to override the auto detection
for the vulkan backend.
**Future improvements**:
- This PR does not include a command line option. This can be added
later for render farms.
Pull Request: https://projects.blender.org/blender/blender/pulls/127860
Design: https://projects.blender.org/blender/blender/issues/126032
The brush assets project merged all brush based tools into a single, "Brush"
tool. After feedback, we want to bring back some of the previous brush based
tools. For example in grease pencil draw mode, not having an eraser or fill tool
available, and having to go through all the brush assets instead made the
workflow more cumbersome, and features less discoverable (an eraser tool in the
toolbar is quite easy to find, a brush deep down in the asset library may not
be).
With this commit we can add back some tools for specific brush types in sculpt &
paint modes. The follow up commit will start with the eraser and fill tools for
grease pencil draw mode, but more tools in other modes are expected to follow.
For every brush type that has a tool in the toolbar, the last used brush is
remembered. This is the biggest part of the changes here.
Brush asset popups will only show the brushes supported by the active tool for
now. The permanent asset shelf region displays all brushes. Activating a brush
that isn't compatible with the current tool will also activate the general
"Brush" tool, but while the brush tool is active we never switch to another one
(e.g. activating an eraser brush will keep the "Brush" tool active). All this
might change after further feedback.
Pull Request: https://projects.blender.org/blender/blender/pulls/125449
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
The behavior was unintentionally changed in 2858c3b287. This patch brings back
the old behavior when dragging objects/collections from the asset browser into
the 3d view, while still keeping the loose-data-instantiation separate from the
core import code.
The `view3d_ob_drop_copy_external_asset` and `view3d_collection_drop_copy_external_asset`
functions are turned to their old state before the refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/127452
Implements a simple splash screen notice displayed if an x86/Intel macOS
Blender build is ran on an Apple Silicon Mac to warn against reduced
performance.
On the technical side of things, this adds a function that detects if
the current process is currently running through Rosetta using `sysctl`.
Implementation wise, I tried to keep this function contained in a single
conditional preprocessor macro block in the same file for simplicity.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/124382
When we create a new window at run time, we request that it be placed
at a specific size and location, but afterward we ask the OS for
details about where it was actually made and then update the window's
size and position with the correct information. Unfortunately when we
open a window when loading a blend file we do most of this, but only
update the size from the OS, not the position. There are times a window
will need to be placed somewhere different than we request and so the
window posx and posy will be incorrect until we move or resize it. This
is more likely to happen on Macs, but is possible on any platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/127819
98c92b9033 disabled refreshing for the redo popup, since that requires
passing an operator pointer to the UI to holding on to it while the popup is
visible. Usually operators are short lived and shouldn't be held by the UI, to
avoid dangling pointer accesses. In this case it's fine though, because the
operator will be kept alive in the window manager.
Partially reverts 98c92b9033, and adds a comment to note this special case.
Fixes: #126521, #127561
Pull Request: https://projects.blender.org/blender/blender/pulls/127795
Parallel shader compilation introduced `GPU_shader_cache_dir_clear_old`.
The implementation was specific to OpenGL and could not be overwritten
by other backends. This PR improves the implementation so the backend
can have its own implementation.
This is needed for upcoming changes to the Vulkan backend where we
want to use similar mechanisms to speed up shader compilation and caching.
Pull Request: https://projects.blender.org/blender/blender/pulls/127680
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(..).
