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
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
- 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
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
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
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
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
Newly validates the following:
- Image mapping transforms on import and export
- Typical normal map setups on import and export
- Alpha-clip node setups on import (was already tested for export)
Pull Request: https://projects.blender.org/blender/blender/pulls/126776
The `normal` input on the UsdPreviewSurface is defined as being of type
`normal3f` rather than a plain old `float3` [1].
Found while adding more test coverage for material reading/writing.
The following could also be seen from `usdchecker` when run over files
produced by Blender:
`Incorrect type for /root/_materials/Material/Principled_BSDF.inputs:normal. Expected 'normal3f'; got 'float3'. (fails 'ShaderPropertyTypeConformanceChecker')`
[1] https://openusd.org/release/spec_usdpreviewsurface.html#preview-surface
Pull Request: https://projects.blender.org/blender/blender/pulls/126747
USD Meshes and their UsdGeomSubset prims only support "face" element
types but our importer was not checking to ensure this was the case.
Additionally, we should guard against out of range indices being used
in general.
Both situations will now also print an obvious warning level log
statement allowing technical users to better toubleshoot on their own.
Test coverage will be added separately in the near future to ensure
multi-material scenarios are handled correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/126714
This was a very similar problem to Alembic's #77754 where a background
import can cause issues with Undo in some circumstances.
Mirror what was done for the Alembic fix here now too.
Pull Request: https://projects.blender.org/blender/blender/pulls/126539
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
Fixed two errors when exporting to USD with Instancing enabled:
Ensuring the mesh prototype prim exists before referencing it to
avoid the "Unresolved reference prim path" error messages in the
console.
Adding the Root Prim path prefix to the prototype reference path.
Pull Request: https://projects.blender.org/blender/blender/pulls/126210
While adding test coverage for mesh subdivision surface scenarios, a few
problems were noticed with vertex crease support.
This PR fixes:
- Used incorrect `crease_sharpnesses` instead of `corner_sharpnesses`
- Used incorrect value for an "infinitely sharp" vertex crease
- Unnecessarily wrote out Blender's `crease_vert` attribute as a primvar
Tests are added which validate everything we support.
Pull Request: https://projects.blender.org/blender/blender/pulls/126209
The mesh velocity data was not using the UsdUtilsSparseValueWriter and
was writing out data for all frames even if the velocity didn't change.
Adds test coverage for this scenario as well as other situations where a
MeshSequenceCache (MSC) would be required:
- Ensures that when positions vary a MSC is added
- Ensures that when velocities vary a MSC is added (see blender/blender@c862d40e09)
- Ensures that when attributes vary a MSC is added (see blender/blender@3c394d39f2)
Pull Request: https://projects.blender.org/blender/blender/pulls/126208
When a multi-byte character needed to be turned into a single "_", the
final returned string would be too large in size.
Resize it to the exact number of bytes required and add test coverage.
Pull Request: https://projects.blender.org/blender/blender/pulls/126164
The common code which writes out attribute data was seemingly not
performing the right sequence of calls for the UsdUtilsSparseValueWriter
to actually write sparse data.
See PR for a test file and .usda files produced with 4.1 and now with
this change applied.
Pull Request: https://projects.blender.org/blender/blender/pulls/126113
If velocity attributes are the only thing being animated, we would fail
to add the cache modifier. This prevents velocity attribute data from
being updated as the timeline changes.
This is a rather rare case. Typically if velocity is changing that would
imply the positions of the mesh are also changing, and the positions
will add the modifier correctly in that case.
Pull Request: https://projects.blender.org/blender/blender/pulls/126105
When using the USD export method with Hydra storm[1], problems can occur
because of how this was integrated alongside the direct Hydra method.
The direct hydra support was initially added in Blender 4.0 and the USD
option was integrated at the same time in order to provide a mechanism
for comparison and double-checking each implementation.
In the context of this bug, for Viewport previews and renders, the Hydra
engine is initially triggered and executed as part of an "engine update"
call from the various v3d draw managers. During this call the USD export
is attempted.
For sub-d meshes the USD export machinery will, by default, attempt to
apply the correct Subdivision Scheme attribute to mesh data. That means
it will export the unsubdivided base mesh with an attribute letting the
downstream receiver of the data know they should do the subdivision on
their own. This subdivision scheme support was added in 4.1.
However, in order to do this, USD must first disable the Subdivision
modifiers in Blender before exporting the mesh. Disabling modifiers
triggers depsgraph processing and, unfortunately, this processing will
also trigger an "engine update" for Hydra... again.
Reentrancy is not supported here. See stack trace in original bug.
So, instead, change the USD export option to output a subdivided mesh to
begin with. This has the following ramifications:
- Viewport material preview and render modes no longer crash when sub-d
is used
- While F12/final renders did not crash, changing this option will now
properly render the subdivided geometry when using the USD export
method. Allowing our USD / Hydra render tests to align more closely.
The direct Hydra option was already pre-subdividing mesh data anyhow.
This will require updating the USD reference render images.
- The underlying integration issue is not fixed. Triggering a USD export
inside the "engine update" call path seems error-prone and can lead to
similar issues in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/125840
Apply `const` to variables, arguments, and methods. Also includes a few
variable shadowing changes that were noticed along the way.
All changes should have no user visible effects.
Pull Request: https://projects.blender.org/blender/blender/pulls/125873
