This commit resolves these RNA warnings:
```
offset: "", WARN (bpy.rna): ...\source\blender\python\intern\bpy_rna.c:1505 pyrna_enum_to_py: current value '65536' matches no enum in 'FloatProperty', 'offset', 'subtype'
project_limit: "", WARN (bpy.rna): ...\source\blender\python\intern\bpy_rna.c:1505 pyrna_enum_to_py: current value '65536' matches no enum in 'FloatProperty', 'project_limit', 'subtype'
falloff_radius: "", WARN (bpy.rna): ...\source\blender\python\intern\bpy_rna.c:1505 pyrna_enum_to_py: current value '65567' matches no enum in 'FloatProperty', 'falloff_radius', 'subtype'
```
Add overlay option to disable grid drawing.
Reuse drawing code from other editors (timeline editor)
Add argument `display_minor_lines` to function
`UI_view2d_draw_lines_x__discrete_frames_or_seconds`
This way minor line drawing can be disabled and so it doesn't cause
too much visual noise. Also spacing seems to be too fine, so VSE uses 3x
what is defined in preferences.
Reviewed By: fsiddi, Severin
Differential Revision: https://developer.blender.org/D11790
WITH_CYCLES_DEBUG was used for rendering BVH debugging passes. But since we
mainly use Embree an OptiX now, this information is no longer important.
WITH_CYCLES_DEBUG_NAN will enable additional checks for NaNs and invalid values
in the kernel, for Cycles developers. Previously these asserts where enabled in
all debug builds, but this is too likely to crash Blender in scenes that render
fine regardless of the NaNs. So this is behind a CMake option now.
Fixes T90240
Expand camera effective region to a portion beyond image frame so strokes won't end right at the border.
Reviewed By: Antonio Vazquez (antoniov)
Differential Revision: https://developer.blender.org/D12049
Previously, this option was not exposed in the UI, only for the clip editor.
There were also multiple rna properties that did the same thing for each of the 2D editors.
There was also an issue where the property enum items were the same as the 3d view which didnt make much sense.
Reviewed By: antoniov
Differential Revision: https://developer.blender.org/D12027
Mantflow only supports wavelet noise, thus the parameter with only one option is no longer useful.
Differential Revision: https://developer.blender.org/D6770
This improve the cloth modeling workflow by allowing you to weld only the
edges that are used for the sewing forces.
Reviewed By: mano-wii, weasel
Differential Revision: https://developer.blender.org/D10710
Improves control over the XR reference space by using the stage ref
space (user-defined tracking bounds) instead of local ref space
(position at application launch), if available. Also adds an
"absolute tracking" session option to skip applying eye offsets that
are normally added for placing users exactly at landmarks.
By enabling absolute tracking, users can define the tracking origin
in a way that is not linked to the headset position. Instead, the
tracking values given by the XR runtime are left unadjusted and a
user can manually calibrate an "origin" landmark object to adjust to
their real world space.
Can be useful for applications that use external tracking systems
and those that primarily only need to use controllers and not the
headset (e.g. motion capture).
The absolute tracking option requires an update to the VR
Scene Inspection addon to be accessible by regular users.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D10946
**Changes:**
- New enums correspond to 4 modes: `Stretch`, `Multiply`, `Frame Number` and `Length`.
- "`Multiply Factor`" has been removed;
- Value corresponding to "`use as speed`" enabled is now the value appended to the `Multiply` enum;
- Value corresponding to "`use as speed`" disabled is now the value appended to the `Frame Number` enum;
- Value corresponding to "`Scale to Length`" enabled is now the value appended to the `Length` enum;
- Except `Stretch` each mode has now its respective control values.
Differential Revision: https://developer.blender.org/D11856
This node takes a curve and a point selection and allows you to set the
specified (or all) points left/right or both handles to a given type.
Differential Revision: https://developer.blender.org/D11992
This was an open TODO, I wanted to have code for translating asset
library references from and to enum values in a central place, and
access that in the same way from both the Asset Browser and the
Workspace RNA code.
* Adds own file for the related functions.
* Adds doxygen comments.
* Updates RNA callbacks to properly use these functions.
* Let these functions call each other, avoid duplicating logic.
This new variable was introduced with 7898089de3. We don't usually use
an `active` prefix variable. Plus, this makes the name match the one of
the Asset Browser active library variable, so we can use the
`rna_def_asset_library_reference_common()` helper for both.
This will cause Asset Views to open with the default "Current File"
Asset Library. We could avoid that, but it's a minor issue really.
While the asset-handle design is supposed to be temporary (see
35affaa971), I prefer keeping the fact that it's nothing but a file
entry pointer an implementation detail that is abstracted away. So this
introduces getters for the file data we typically access for
asset-handles.
Note that the current asset-handle design is temporary, see
35affaa971. I still prefer this to be const, as code outside the
asset-list/file-list code should never mess with the file data of an
asset.
The asset handle design is only temporary (see 35affaa971) and this
RNA property is only needed for internal, technical reasons of the asset
view template. So although not nice, at least make it clear in the RNA
property description that this should not be used.
Wording on the UI, slider consistency and material mask switches layout.
Reviewed By: Sebastian Parborg (zeddb)
Differential Revision: http://developer.blender.org/D11839
This node implements shortening each spline in the curve based on
either a length from the start of each spline, or a factor of the
total length of each spline, similar to the "Start & End Mapping"
panel of curve properties.
For Bezier curves, the first and last control points are adjusted
to maintain the shape of the curve, but NURB splines are currently
implicitly converted to poly splines.
The node is implemented to avoid copying where possible, so it outputs
a changed version of the input curve rather than a new one.
Differential Revision: https://developer.blender.org/D11901
`split_multicam` used split operator, where if more strips than
multicam were selected, all would be split, which is undesirable.
Add `Sequence.split()` RNA API function. to split individual strips.
Function accepts `frame` and `split_method arguments`. Returns right
strip after splitting.
In case when strip being split have effects, these will be split too, so
no invalid state should be created.
Selection is not handled, this is by design up to user.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D11926
We need to be more strict about trying to retrieve a list of vertex group
names from objects now, as only three object types support them.
This commit adds a check for vertex group support in a few places, the
data transfer operator/modifier, copying vertex groups to selected
objects, and the vertex group remove and clear functions.
Differential Revision: https://developer.blender.org/D11947
When a vertex group is used to limit the influence of the modifier
to a subset of vertices, binding data for vertices with zero weight
is not needed. This wastes memory, disk space and CPU cycles.
If the vertex group contents is known to be final and constant,
it is reasonable to optimize by only storing data group vertices.
This has to be an option in case the group can change.
Supporting this requires adding a vertex index field and spliting
the vertex count into mesh and bind variants, but both happen to
fit in available padding. The old numverts field is renamed to the
new bound vertex count field to maintain the array length invariant.
Versioning is used to initialize the other new fields.
If a file with sparse binding is opened in an old blender version,
it is corrupted into a non-sparse bind with vertex count mismatch,
preventing the modifier from working until rebind.
Differential Revision: https://developer.blender.org/D11924
The asset view UI template is a mini-version of the Asset Browser that
can be placed in regular layouts, regions or popups. At this point it's
made specifically for placement in vertical layouts, it can be made more
flexible in the future.
Generally the way this is implemented will likely change a lot still as
the asset system evolves.
The Pose Library add-on will use the asset view to display pose
libraries in the 3D View sidebar.
References:
* https://developer.blender.org/T86139
* https://code.blender.org/2021/06/asset-browser-project-update/#what-are-we-building
* https://code.blender.org/2021/05/pose-library-v2-0/#use-from-3d-viewport
Notes:
* Important limitation: Due to the early & WIP implementation of the
asset list, all asset views showing the same library will show the
same assets. That is despite the ID type filter option the template
provides. The first asset view created will determine what's visible.
Of course this should be made to work eventually.
* The template supports passing an activate and a drag operator name.
The former is called when an asset is clicked on (e.g. to apply the
asset) the latter when dragging (e.g. to .blend a pose asset). If no
drag operator is set, regular asset drag & drop will be executed.
* The template returns the properties for both operators (see example
below).
* The argument list for using the template is quite long, but we can't
avoid that currently. The UI list design requires that we pass a
number of RNA or custom properties to work with, that for the Pose
Libraries should be registered at the Pose Library add-on level, not
in core Blender.
* Idea is that Python scripts or add-ons that want to use the asset view
can register custom properties, to hold data like the list of assets,
and the active asset index. Maybe that will change in future and we
can manage these internally.
As an example, the pose library add-on uses it like this:
```
activate_op_props, drag_op_props = layout.template_asset_view(
"pose_assets",
workspace,
"active_asset_library",
wm,
"pose_assets",
workspace,
"active_pose_asset_index",
filter_id_types={"filter_action"},
activate_operator="poselib.apply_pose_asset",
drag_operator="poselib.blend_pose_asset",
)
drag_op_props.release_confirm = True
drag_op_props.flipped = wm.poselib_flipped
activate_op_props.flipped = wm.poselib_flipped
```
So far all UI lists had to be defined in Python, this makes it possible
to define them in C as well. Note that there is a whole bunch of special
handling for the Python API that isn't there for C. I think most
importantly custom properties support, which currently can't be added
for C defined UI lists.
The upcoming asset view UI template will use this, which needs to be
defined in C.
Adds a new file `interface_template_list.cc`, which at this point is
mostly a dummy to have a place for the `ED_uilisttypes_ui()` definition.
I plan a separate cleanup to move the UI-list template to that file.
Makes it possible to create tooltips for UI list rows, which can be
filled in .py scripts, similar to how they can extend other menus. This
is used by the (to be committed) Pose Library add-on to display pose
operations (selecting bones of a pose, blending a pose, etc).
It's important that the Python scripts check if the UI list is the
correct one by checking the list ID.
For this to work, a new `bpy.context.ui_list` can be checked. For
example, the Pose Library add-on does the following check:
```
def is_pose_asset_view() -> bool:
# Important: Must check context first, or the menu is added for every kind of list.
list = getattr(context, "ui_list", None)
if not list or list.bl_idname != "UI_UL_asset_view" or list.list_id != "pose_assets":
return False
if not context.asset_handle:
return False
return True
```
This is more of a first-pass refactor for the UI list template. More
improvements could be done, but that's better done separately. Main
purpose of this is to make the UI list code more manageable and ready
for the asset view template.
No functional changes for users.
* Split the huge template function into more manageable functions, with
clear names and a few structs with high coherency.
* Move runtime data management to the template code, with a free
callback called from BKE. This is UI data and should be managed at
that level.
* Replace boolean arguments with bit-flags (easily extendable and more
readable from the caller).
* Allow passing custom-data to the UI list for callbacks to access.
* Make list grip button for resizing optional.
* Put logic for generating the internal UI list identifier (stored in
.blends) into function. This is a quite important bit and a later
commit adds a related function. Good to have a clear API for this.
* Improve naming, comments, etc.
As part of further cleanups I'd like to move this to an own file.
New function `BKE_pose_apply_action_all_bones()`, which will be
necessary for the upcoming pose library v2.0.
This renames the function `BKE_pose_apply_action` to
`BKE_pose_apply_action_selected_bones`, to reflect that it only works on
selected bones, to contrast it to the new function.
Adds the following to `bpy.types.FileSelectEntry`:
* `id_type`: The data-block type the file represenets, if any.
* `local_id`: The local data-block it represents, if any (assets only).
And the following to `bpy.types.AssetHandle`:
* `local_id`: The local data-block the asset represents, if any.
This kind of information and the references are important for asset related
operators and UIs. They will be used by upcoming Pose Library features.
Implements a basic, WIP version of the asset list. This is needed to
give the asset view UI template asset reading and displaying
functionality.
See:
* Asset System: Data Storage, Reading & UI Access - https://developer.blender.org/T88184
Especially the asset list internals should change. It uses the
File/Asset Browser's `FileList` API, which isn't really meant for access
from outside the File Browser. But as explained in T88184, it does a lot
of the stuff we currently need, so we (Sybren Stüvel and I) decided to
go this route for now. Work on a file-list rewrite which integrates well
with the asset system started in the `asset-system-filelist` branch.
Further includes:
* Operator to reload the asset list.
* New `bpy.types.AssetHandle.get_full_library_path()` function, which
gets the full path of the asset via the asset-list.
* Changes to preview loading to prevent the preview loading job to run
eternally for asset views. File Browsers have this issue too, but
should be fixed separately.
With temporary I mean that this is not intended to be part of the
eventual asset system design. For that we are planning to have an
`AssetRepresentation` instead, see T87235. Once the `AssetList` is
implemented (see T88184), that would be the owner of the asset
representations.
However for the upcoming asset system, asset browser, asset view and
pose library commits we need some kind of asset handle to pass around.
That is what this commit introduces.
Idea is a handle to wrap the `FileDirEntry` representing the asset, and
an API to access its data (currently very small, will be extended in
further commits). So the fact that an asset is currently a file
internally is abstracted away. However: We have to expose it as file in
the Python API, because we can't return the asset-handle directly there,
for reasons explained in the code. So the active asset file is exposed
as `bpy.context.asset_file_handle`.
This per-workspace active asset library will be used by the asset views
later. Note that Asset Browsers have their own active asset library,
overriding the one from the workspace.
As part of this the `FileSelectAssetLibraryUID` type gets replaced by
`AssetLibraryReference` which is on the asset level now, not the
File/Asset Browser level. But some more work is needed to complete that,
which is better done in a separate commit.
This also moves the asset library from/to enum-value logic from RNA to
the editor asset level, which will later be used by the asset view.
Update vertex weights between simulation steps if they have changed.
This allows for animated vertex weights in the cloth sim.
Reviewed By: Sebastian Parborg
Differential Revision: http://developer.blender.org/D11640
This adds id_properties_clear() and id_properties_ensure() functions
to RNA structs. This is meant as an initial change based on discussion
in review of D9697. However, they may be useful in other situations.
The change requires refactoring the internal idproperties callback to
return a pointer to the IDProperty pointer, which actually turns out
to be quite a nice cleanup.
An id_properties attribute could be added in the future potentially.
Differential Revision: https://developer.blender.org/D11908
Non-pointer-like properties that are not editable should never generate
override operations.
While harmless (those would never be applied back anyway), better not
clutter override operations list, and also enjoy the symbolic
performances improvement here.
NOTE: Pointer-like properties (pointers and collections) remain
processed as usual here since they usually imply recursivity. We could
make an exception to the exception for ID pointers, but for now I don't
think this is worth it.
This commit moves the storage of `bDeformGroup` and the active index
to `Mesh`, `Lattice`, and `bGPdata` instead of `Object`. Utility
functions are added to allow easy access to the vertex groups given
an object or an ID.
As explained in T88951, the list of vertex group names is currently
stored separately per object, even though vertex group data is stored
on the geometry. This tends to complicate code and cause bugs,
especially as geometry is created procedurally and tied less closely
to an object.
The "Copy Vertex Groups to Linked" operator is removed, since they
are stored on the geometry anyway.
This patch leaves the object-level python API for vertex groups in
place. Creating a geometry-level RNA API can be a separate step;
the changes in this commit are invasive enough as it is.
Note that opening a file saved in 3.0 in an earlier version means
the vertex groups will not be available.
Differential Revision: https://developer.blender.org/D11689
