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
During stage load we first look for Prototype prims which are used for
instancing. However, if the instancer itself at the root of that
Prototype hierarchy would later be excluded because of either purpose or
visibility checks, the Prototypes would still be processed. These would
correctly be imported but would end up orphaned because nothing would
later add them to the view layer. Code expecting these objects to be
found within the scene would then fail.
In Animal Logic ALab this situation played out where there was a
`/root/instancer` prim with purpose "render" and we proceeded to load
the prims under the `/root/instancer/Prototypes/...` hierarchy. Since we
were attempting to load just the "proxy" purpose, the `/root/instancer`
was later excluded and the orphaning of those prototypes happened.
The change here moves `collect_point_instancer_proto_paths` to a method
of `USDStageReader` so it can now access `include_by_purpose` and
`include_by_visibility`. And these are now used to prevent unnecessary
Prototype loading.
Pull Request: https://projects.blender.org/blender/blender/pulls/128564
USD has the concept of material "purposes" which allows different
materials to be associated for a prim and gives special meaning to them.
These are somewhat similar to display purposes, which we already allow
to be chosen, but are distinct concepts. This PR adds an option for
Import allowing the user to chose which material purpose to load.
Blender currently attempts to load purposes automatically. It starts
with "allPurpose" and then moves to "preview" and "full" in that order.
This behavior is now changed and the automated search is removed to
instead give the user control which purpose to load. Additionally, USD
already has its own fallback behavior during material resolution[1]:
- When given "full" it will first check "full" and fallback to
"allPurpose" if not found. An additional, Blender-specific fallback
to "preview" is also implemented here upon request.
- When given "preview" it will first check "preview" and fallback to
"allPurpose" if not found
- When given "allPurpose", it will only check "allPurpose"
I have opt'd to keep this behavior directly as-is to not introduce
differences that may surprise those already familiar with USD elsewhere.
Additionally, I've set Blender's default import purpose to "full" to
ensure we're loading in the highest quality assets first. Though this
has the obvious risk that "full" assets tend to be quite heavy. We can
change to "preview" if this proves too problematic later.
This does not change how Blender exports materials. Blender always uses
the "allPurpose" binding when writing its USD files.
--------
[1] USD docs:
https://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#detailshttps://openusd.org/release/api/class_usd_shade_material_binding_a_p_i.html#UsdShadeMaterialBindingAPI_MaterialResolution
Pull Request: https://projects.blender.org/blender/blender/pulls/128206
When using the `create_collection` parameter during import, the newly
created Collection would be assigned a fake user which isn't necessary
and caused the user count to be 2 instead of the more natural 1 here.
Remove the fake user and add test coverage for the scenario in general.
Pull Request: https://projects.blender.org/blender/blender/pulls/128348
Wrong `points_num` when resizing the `CurvesGeometry`.
Otherwise, any attriute span will have wrong size, this triggers crash
when writing value in these attribute spans.
Pull Request: https://projects.blender.org/blender/blender/pulls/128472
When attempting to cache a generated image, the ImageFormatData's
view_settings would inadvertently be leaked due to the settings being
assigned a different set of values without first being free'd.
Additionally, there was another missed free from an early return a bit
later in the same function.
Pull Request: https://projects.blender.org/blender/blender/pulls/128229
This improve the API in multiple aspects:
* No need for an additional `lookup` call to get the current attribute. This
would internally iterate over all attributes again. This leads to O(n^2)
behavior. Note that there are still other reasons for O(n^2) behavior when
processing attributes (where n is the number of attributes).
* Remove the need to return a value from the iteration code to indicate that the
iteration should continue. This is now the default behavior. The iteration can
still be stopped by calling `iter.stop()`.
* Easier access to `is_builtin` property.
* Iterator callback only has a single parameter instead of two (of which one is
sometimes unused).
Pull Request: https://projects.blender.org/blender/blender/pulls/128128
Color primvars/attributes were historically treated as a special case
for both import and export. This was mostly done to align with how
painting and viewport display works in Blender. Export would generally
ignore color attributes except when they were found on a Mesh's Point or
FaceCorner domains. And import went out of its way to map incoming color
primvars to the FaceCorner domain in more situations than necessary.
To facilitate better roundtripping in Blender<=>USD workflows, and to
reduce code duplication, this PR teaches the common attribute utilities
how to handle color types. The color attributes will now work on all
relevant Mesh and Curve domains.
There were tests in place for this already but they were set to verify
the inverse state, i.e. the technically broken state, until this could
be fixed.
There remains one special case: "displayColor" primvars and attributes.
The "displayColor" is a special primvar in USD and is the de-facto way
to set a simple viewport color in that ecosystem. It must also be a
color3f type. In order to not regress import, if a "displayColor"
primvar is found on the Face domain we will map it to FaceCorner instead
so it can be displayed in the viewport; which has been the case for the
past several releases. We can drop this special-case if/when Blender can
display Face colors through the Viewport Shading "Attribute" color type.
Additionally, Blender will export this, and only this, color attribute
as a color3f.
Note: As was the case prior to this PR, the following 2 discrepancies
still prevent "perfect" round-trips:
- USD does not have an equivalent to Blender's byte colors; they are
treated as float during IO
- Blender does not have an equivalent to USD's color3 types; they are
treated as color4 during IO
Pull Request: https://projects.blender.org/blender/blender/pulls/127784
The collada export code was directly using `action->curves` in its
export code, which doesn't work with slotted actions. This commit
updates that code to use wrapper functions that provide access to the
correct fcurves regardless of whether the action is slotted or not.
Note that the import code has not yet been updated, and is left for
a future PR.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/128061
Because we're moving to layered actions, which don't store their
fcurves in a list base, we need to update the places that assume the old
listbase-based structure.
This commit addresses the low-hanging fruit where code was previously
using the `LISTBASE_FOREACH` macro on a listbase of fcurves and it was
fairly obvious how to correctly update the code with minimal changes.
Other cases that either weren't immediately obvious or required
non-trivial code changes (or both) have been left for future PRs.
Additionally, uses of the list base that didn't use `LISTBASE_FOREACH`
were not investigated as part of this PR, whether trivial to update or
not.
Ref: #123424
Pull Request: https://projects.blender.org/blender/blender/pulls/127920
- Use `lookup_or_add_for_write_only_span` in more places
- Use `copy_from` when reading in positions for the few readers where
this wasn't already being done
- Remove manual memory management when processing corner normals
Pull Request: https://projects.blender.org/blender/blender/pulls/128043
To match what the previous Python STL importer was doing, and what
the documentation / tooltips say is happening, the imported mesh
faces should be marked as sharp. Do that.
Export Blender Point Clouds as `UsdGeomPoints` primitives.
Summary
- Adds the `USDPointsWriter` class
- Adds tests to ensure that animated positions, velocities, radii, and
regular attributes are all written correctly (in a sparse format)
- Adds a new `export_points` operator property, mirroring the existing
`import_points` option
Pull Request: https://projects.blender.org/blender/blender/pulls/126389
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
Remove old version guards relating to USD versions prior to 2111 which
released in Nov 2021.
The oldest supported version of Blender, 3.3 LTS which goes end of life
this month, was already using USD version 2203 released in March 2022.
Additionally, these guards give the illusion that compiling with old
versions prior to 2111 might work, which is neither guaranteed nor
tested for at this point.
Pull Request: https://projects.blender.org/blender/blender/pulls/127380
`frame_at()` returns previous keyframe of which the drawing is visible
at current framec. When previous keyframe is selected, all the intermediate frames
till iteration reach the next keyframe are also exported.
To fix this, look inside `frames()` map instead of `frame_at()`.
Pull Request: https://projects.blender.org/blender/blender/pulls/126779
USD Skeletons (armatures) are joint-based rather than bone-based in
construction. This means that there's no native bone concept nor is
there any bone lengths. Currently, Blender's USD import uses an
estimation, roughly corresponding to the average distance between
joints in the entire Skeleton, to set the bone length in situations
where it's not obvious that 2 joints are directly connected. This is
imperfect but shouldn't affect actual functioning of the rig.
For armatures coming from external software this is probably the best we
can do. However, for armatures originating from Blender, we can use a
custom primvar to store the bone lengths directly. This allows Blender
armatures to be exported and re-imported in much better fidelity.
This is superior to prior techniques, like those employed by FBX, which
alter the actual Skeleton, inserting extra joints where unnecessary. Not
only is this detrimental when using these files in external software,
but it's still imperfect when importing back into Blender too.
Pull Request: https://projects.blender.org/blender/blender/pulls/126954
This introduces the concept of an #AttributeFilter. It's used to tell a geometry
algorithm which attributes it should process/propagate and which can be ignored.
We already had something similar before named
`AnonymousAttributePropagationInfo`. However, as the name implies, this was
specific to anonymous attributes. This had some downsides:
* A lot of code had to be aware of the concept of anonymous attributes even if
it did nothing special with anonymous attributes.
* For non-anonymous attributes we often had a separate `Set<std::string> skip`
parameter. It's not nice to have to pass two kinds of filters around and to
have to construct a `Set<std::string>` in many cases.
`AttributeFilter` solves both of these downsides.
Technically, `AttributeFilter` could also just be a `FunctionRef<bool(StringRef
attribute_name)>`, but that also has some issues:
* The `bool` return value is often ambiguous, i.e. it's not clear if it means
that the attribute should be processed or not. Using an enum works better.
* Passing function refs around and combining them works, but can very easily
lead to dangling references.
* The default value of a `FunctionRef` is "empty", i.e. it can't be called. It's
generally more nice to not have a special case for the default value. Now the
default `AttributeFilter` propagates all attributes without any extra handling
on the call-site.
Pull Request: https://projects.blender.org/blender/blender/pulls/127155
Previously, the `AttributeIDRef` wrapper was needed because it also had to
contain a pointer to an `AnonymousAttributeID`. However, since
b279a6d703 this is not necessary anymore.
Therefore we can use "raw" `StringRef` now which reduces the mental overhead
when working with attributes and also simplifies code.
Pull Request: https://projects.blender.org/blender/blender/pulls/127140
If a USD python hook throws an exception during processing, the USD
stage ptr is "leaked" because the destructor is not called on the
argument class we pass into the python call.
This leak prevents the stage from reaching a reference count of 0 later
and the file is kept open. All attempts to use the same USD file again
will be met with the following error:
`Coding Error: in _CreateNew at line 617 of C:\db\build\S\VS1564R\build\usd\src\external_usd\pxr\usd\sdf\layer.cpp -- A layer already exists with identifier 'path.usda'`
Instead of passing our class into the call normally, which boost::python
would see as needing to make a copy, use a `ref` instead, bypassing the
problem.
Additional details and repro in the PR. Test coverage to follow.
Pull Request: https://projects.blender.org/blender/blender/pulls/126298
And same for the `copy_layout` function. These functions do not free any
potentially existing data in destination, but expect it to be uninitialized.
Hopefully these new names will make it more clear and avoid bugs like #122160.
