When writing to a property that doesn't exist e.g. `frame.drawing.strokes.test = 42`
no exception would be raised and it would silently fail.
The fix defines the `__slots__` on the classes explicitly which then raises an exception
if the user tries to write something that wasn't previously defined.
Pull Request: https://projects.blender.org/blender/blender/pulls/129047
When e.g. executing `drawing.strokes[0].softness = 3`, the API would
always create a new attribute `softness` even if that attribute existed
already.
The issue was that the code was using the `.get(value, fallback)` syntax
but the `fallback` expression is always evaluated by python.
The fix removes the use of the `fallback` and uses a simple `if/else` to
check if the attribute doesn't exist yet and only then create it.
Pull Request: https://projects.blender.org/blender/blender/pulls/129044
Part of the brush assets project followups, see #116337.
Based on feedback, it seems important to indicate to the user when a brush has
unsaved changes.
There's no reliable updating mechanism we can use or hook into here, except for
RNA "update" callbacks. Brush data gets changed in many places in code, the only
way to do this seems manual tagging every time a brush property gets changed.
This PR introduces `BKE_brush_tag_unsaved_changes()` for this. I spent some time
going through all brush properties to ensure changes call the tagging function.
A known limitation with this will be that changes to dependencies won't be
indicated in the brush. E.g. Changing the texture attached to a brush won't make
the brush be indicated as changed.
The UI to indicate the changed brushes is being discussed still, see #128846.
Pull Request: https://projects.blender.org/blender/blender/pulls/128845
Building an extension when the manifest didn't define a "type"
would assert instead of reporting the missing field.
Return earlier when there are errors to prevent the assertion.
In essential brush assets, the "Crease" brush was replaced with two
crease brushes ("Crease Polish" and "Crease Sharp"), but the keymap
wasnt respecting that.
So to resolve now point Shift+C to "Crease Polish" (seems closer to what
the former "Crease" brush was.
Pull Request: https://projects.blender.org/blender/blender/pulls/128765
In a Curves (not Curve) object, the MeshSequenceCache modifier is not
available from the "Add Modifier" dropdown.
However, the Alembic importer adds such a modifier onto the Curves
objects it creates. It is also possible to transfer such a modifier from
another object, regardless of its type.
Thus, this seems not to be an issue of compatibility of the modifier
with the Curves object type, but an UI/UX oversight.
`BKE_object_support_modifier_type_check` already has a correct check for
this, so just adding CURVES support to the appropriate menu.
Same is true for the POINTCLOUD type, so adding that as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/128756
Removes unused GPv2 functions in blenkernel.
Notes:
- Functions for layer masks are still in use, but annotations never
have layer masks in the first place. Would be good to remove the data
structures so we can remove the functions too.
- Some multi-frame edit functions are also still nominally used, but
multi-frame editing is not an active feature for annotations. This
should also be removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128709
The API would return `None` if the number of strokes in the drawing was `0`.
Instead this should return a slice that has a length of 0 to be consistent.
The issue was that the API assumed that the `.selection` attribute
was always on either the point domain for points or the stroke domain
for strokes.
Internally the attribute domain depends on the current selection mode.
To fix the issue, the API now checks for the domain of the attribute
and handles it accordingly.
If the selection attribute is on the `'POINT'` domain:
* Reading the `stroke.select` property will check if *any* of the points of
the stroke are selected and return `True` or `False`.
* Writing to the `stroke.select` property will write `True` or `False` to *all* the
points in the stroke.
Also resolves#128645.
Pull Request: https://projects.blender.org/blender/blender/pulls/128687
Regression in [0] which didn't account for entering paths in the
file selector which would create paths without confirming,
warning that the "confirm" property was missing.
Entering `*.*` would create `_._` for e.g in the users CWD for example.
Ref !128568
[0]: 6dd0f6627e.
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
The `paint.brush_colors_flip` option was not exposed in the vertex color
panel.
This adds the toggle in the panel and also adds the keymap `X` to flip
the colors.
The tint color and panel was not used consistently.
In Vertex Paint mode we're using the unified paint settings,
but in Draw mode, we only use the brush color for tinting.
This fixes the issue by using the unified paint settings
for all the uses of the vertex color.
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
Hides the brush asset shelf by default in weight paint, grease pencil
weight paint and grease pencil vertex paint mode. These only have one
bundled brush per tool available.
After bringing back some tools for brushes in certain modes
(3798852071), we want to hide the asset shelf in modes where there's
only one brush bundled per tool. While having these tools support
brushes can be useful, we don't expect to bundle more brushes soon. So
avoid a mostly empty asset shelf for a single brush by hiding it by
default and keeping it hidden until the user expands it (bf52f6f723 made
it possible to remember the visibility per mode).
Part of #128066 and #116337.
Layer panel (also mask/ transform etc.) and other operators are gone
when properties tab is pinned and gpv3 object is non-active.
To fix this, get grease pencil pointer from `button_context()`
(done in `grease_pencil_context()`).
Continuation of cd476226d8
Pull Request: https://projects.blender.org/blender/blender/pulls/128475
Part of: https://projects.blender.org/blender/blender/issues/128066
Adds a "Filter by Active Tool" option for the brush asset shelves,
enabled by default. If enabled, the asset shelf only shows brushes
matching the brush type of the current tool. If the general "Brush" tool
is active, only brushes that are not covered by another tool are
displayed. The popup brush selector always shows all assets.
The option is stored in the Preferences, toggled in the "Display
Settings" popover of the asset shelf.
Note: This is committed to the 4.3 release branch, which was discussed
in advance.
Pull Request: https://projects.blender.org/blender/blender/pulls/128450
This adds feature parity with Cycles regarding light and shadow liking.
Technically, this extends the GBuffer header to 32 bits, and uses
the top bits to store the object's light set membership index.
The same index is also added to `ObjectInfo` in place of padding bytes.
For shadow linking, the shadow blocker sets bitmask is stored per
tilemap. It is then used during the GPU culling phase to cull objects
that do not belong to the shadow's sets.
Co-authored-by: Clément Foucault <foucault.clem@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/127514
The radial controls to set the brush size were not working in sculpt and
vertex paint mode.
This was because of a collision with the `cyclical_set` operator in edit mode.
The issue was that the poll function for the edit mode keymaps also
passed in sculpt and vertex paint mode.
To solve this, add a keymap for these common selection operators and
separate them from the general edit mode keymap.
Pull Request: https://projects.blender.org/blender/blender/pulls/128542
The paint, sculpt, and vertex-paint modes already have separate context
menu classes from GPv2. The GPv2 classes will be removed, this is just
a small refactor to prevent this change from getting lost in a big
cleanup PR. No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/128530
This should free up references to GPv2 types and operators and should
in turn make their removal easier.
- Remove keymaps for GPv2 operators from `blender_default.py` and
`industry_compatible_data.py`
- Remove keymap poll callback assignment from `gpencil_ops.cc`
- Remove keymap handler registration from `area.cc:ed_default_handlers`
Pull Request: https://projects.blender.org/blender/blender/pulls/128480
On Windows an entire directory may be locked when any files inside it
are opened by another process. This can cause operations that
recursively remove a directory (uninstalling & updating) to fail
with a partially removed extension.
The case of uninstalling was already handled, where failure to remove
a directory would stage the extension for later removal.
In the case of updating however, the user could be left with a broken
(partially removed) extension where some files were removed, as the
directory was locked, the update would fail to extract new files.
Address this issue by renaming the directory before recursive removal.
The following logic has been implemented:
- If any files in the directory are locked, renaming will fail.
So even though the operation fails the extension is left intact.
- If renaming succeeds, it's possible to apply the update.
While it's possible (albeit unlikely) recursive removal fails,
which could be caused by file-system permissions issues corruption or
a process could open a file between rename & removal.
In this case the renamed directory is staged for later removal.
Other changes:
- Resolve a related problem where the user could install an
extension previously staged for removal, now installing an extension
ensured it's not removed later.
This would occur if uninstalling failed, the user resolves
directory-lock, uninstalls again, then re-installs the extension.
- When an extension fails to be removed, don't attempt to remove
user configuration for that extension.
Prefer to keep the extension & it's settings in their "current state"
if it can't be removed.
