This enables material displacement for UsdPreviewSurface import and
export. Scenarios are limited by what's supported by the preview surface
itself. Namely only Object Space displacement can be used (no vector
displacement)[1] and the Midlevel and Scale parameters are maintained by
adjusting the scale-bias on the image texture controlling the Height
(this means that Midlevel and Scale must be constants).
Hydra/MaterialX support is more complicated. First, there is a bug which
prevents scalar displacment from working correctly and that needs USD
2408+ for the fix[2]. Second, is that there's an open question about
which coordinate system to use for MaterialX's vector displacement maps.
Lastly, Hydra GL does not render displacement, making verification using
only Blender impossible[3]. As a result, this PR only makes MaterialX
"ready" for support, but stops short of actually connecting the final
piece of the node graph until more of the above can be sorted out.
Tests are added which cover:
- Variations of Midlevel and Scale values
- A constant Height setup
- Negative scenarios checking that only Object space is supported
and that midlevel and scale need to be constants
[1] https://openusd.org/release/spec_usdpreviewsurface.html
[2] https://github.com/PixarAnimationStudios/OpenUSD/issues/3325
[3] https://forum.aousd.org/t/materialx-displacement-hydra-storm/1098/2
Pull Request: https://projects.blender.org/blender/blender/pulls/128909
In March 2022 this was added as a provision to check/guard the build if
external folks were compiling without USD "Imaging" support [1]
In Feb 2023 code was added which ended up depending on "Imaging"
unconditionally (and probably more at this point) [2]
Since we haven't heard this being a problem so far, and because the USD
build option is enabled by default, let's just remove it.
The test which was added is also removed because the main import/export
code serves as the compile test, and the python test code serves as a
much more sufficient check of actual functionality.
[1] https://archive.blender.org/developer/D14456
[2] Commit `72a85d976a5781a21166356b24668b8c48d51690`
Pull Request: https://projects.blender.org/blender/blender/pulls/129733
Removes the last remaining, direct, usage of streams inside USD.
CLOG is not used here because there's no way to have a trace be "always
printed," even if using a log-level of -1 or similar.
Pull Request: https://projects.blender.org/blender/blender/pulls/129702
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.
The existing Volume export, which already supports VDB file sequences
and static volumes created inside Blender, is now extended to handle
dynamically created and modified volumes. This allows scenarios where a
Volume Displace modifier is placed over-top an existing VDB sequence or
when Geometry Nodes is used to create animated volumes procedurally.
Detection of what counts as animation is simplistic and mimics what has
been used for Meshes. Essentially if there are any modifiers on the
volume we assume that the volume is "varying" in some way. This can lead
to situations where new volume files are written unnecessarily.
Volume import was also adjusted to correctly set the sequence "offset"
value. This is required to properly handle the case when a VDB sequence
begins animating at a different frame than what's implied by the file
name. For example, a VDB file sequence with file names containing 14-19
but the user wants to animate on frames 8-13 instead.
Tests are added which cover:
- Animated VDB file sequences
- Animated Mesh To Volume where the mesh has been animated
- Animated Volume Displacement where displacement settings are animated
- Animated Volumes created with a Geometry Nodes simulation
----
New test data has been checked in: `tests/data/usd/usd_volumes.blend` and files inside `tests/data/usd/volume-data/`
Pull Request: https://projects.blender.org/blender/blender/pulls/128907
It was difficult to notice, but we weren't making use of the
`USDPrimReader::valid()` API calls during import.
In many(all?) cases this was fine as we would check the validity during
`read_object_data` or similar anyhow. Rather than just removing the API
entirely, this patch attempts to use it and has the following design:
- Where ever and whenever a reader is created, in addition to checking
null, we should now also check for `valid()` This happens in
`usd_capi_import` and `usd_reader_stage`.
- The `valid()` call is intended to check just the USD object status.
Blender object checks are handled elsewhere (same as they are
currently) since these objects are often not available at the time of
the call to `valid()`
This has the benefit that we at least know that USD is valid before our
heavy reading code ever starts executing. Some duplicate checks are now
removed.
Pull Request: https://projects.blender.org/blender/blender/pulls/129181
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
