These have been removed since 4.0, this is not a pertinent information
to single out anymore.
Also downgrade report about missing obdata to `WARNING`, `ERROR` is a
bit strong for this.
For C/C++ doc-strings should be located in headers,
move function comments into the headers, in some cases merging
with existing doc-strings, in other cases, moving implementation
notes into the function body.
This reverts commit 0a70360eb6. That's
because it caused issue #129366 which is much more serious, and the
cause is not obvious so far. Another fix will be submitted for the
original issue.
Python scripts could perform actions that created notifiers
which would not be handled until the script was complete.
In the case of adding & removing objects a notifier would be created
for adding the object, then cleared when the ID was removed.
This lead to the notifier queue filling up with cleared notifiers
which were included in the search whenever an ID was removed.
The result of this was that adding and removing objects from a script
would become increasingly slower & use more memory.
Resolve by storing the current notifier being handed which isn't freed
(only cleared). The notifier handling loop detects cleared notifiers
and frees them after use.
PR #128051 made some improvements to code by cleaning up properties and
simplifying logic.
However, the default tool in most spaces is box select. By switching to
box select default, there should be more front-facing consistency across
spaces while still retaining near-identical behavior.
This patch would fix the small bug listed in #128671 while keeping the
simplified code benefits from #128051.
Also:
- Move selection keymap items up in the Sequencer (Global) keymap so it
is more visible (similar to Node Editor ordering).
- Split `side_of_frame` property for ctrl press keymap item into a
separate keymap item on ctrl click for both LCS and RCS to avoid
clashing with ctrl+drag for box selects in RCS.
Pull Request: https://projects.blender.org/blender/blender/pulls/129028
Essentially, our current code would not properly remove (dereference)
its python objects matching various RNA data created during execution.
Some cases are fairly trivial to understand (like the lack of handling
of unregstering for our 'startup' operators and UI), other were more
subtle (like unregistered PropertyGroups who would remove/free their RNA
struct definition, without releasing first the potential matching python
object).
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/128899
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
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
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
