The motivation is to keep backward compatibility after deprecating
`material.use_nodes()` and `world.use_nodes`. For example the
following script would behave the same way in 4.5 and 5.0:
```python
mat = bpy.data.materials.new("My new mat")
mat.use_nodes = True
```
Pull Request: https://projects.blender.org/blender/blender/pulls/147052
"Use Nodes" was removed in the compositor to simplify the compositing
workflow. This introduced a slight inconsistency with the Shader Node
Editor.
This PR removes "Use Nodes" for object materials.
For Line Style, no changes are planned (not sure how to preserve
compatibility yet).
This simplifies the state of objects; either they have a material or
they don't.
Backward compatibility:
- If Use Nodes is turned Off, new nodes are added to the node tree to
simulate the same material:
- DNA: Only `use_nodes` is marked deprecated
- Python API:
- `material.use_nodes` is marked deprecated and will be removed in
6.0. Reading it always returns `True` and setting it has no effect.
- `material.diffuse_color`, `material.specular` etc.. Are not used by
EEVEE anymore but are kept because they are used by Workbench.
Forward compatibility:
Always enable 'Use Nodes' when writing blend files.
Known Issues:
Some UI tests are failing on macOS
Pull Request: https://projects.blender.org/blender/blender/pulls/141278
Refactor and revamp import and export of `UsdGeomNurbsCurves` prim
objects.
Fixes#130056, among other things.
Summary of changes and enhancements:
- Export:
- Write out `nurb_weight` attribute as the USD `pointWeights` primvar
- Properly write out cyclic NURBS curves data (* see notes)
- Import:
- Import using the new `Curves` datablock rather than the old `Curve`
- Properly read in cyclic NURBS curves data (* see notes)
- Tries harder to match incoming knot vector to standard `knots_mode`,
will use Custom otherwise
- Support import of all custom primvars and data attached to the prim
(for use with Geometry Nodes etc.) (* see notes)
Tests were added which check a variety of point count, order, knot_mode,
and cyclic combinations (generated through Geometry Nodes). A small
number of hand-crafted curves were used to test the Custom knots_mode
support on import. Additionally, the tests cover the case when there are
multiple curves defined for a single object.
Notes:
- Cyclic NURBS support is reliant on the current, under-spec'd, USD
documentation. Changes may be required in the future if/when the USD
spec is clarified: https://github.com/PixarAnimationStudios/OpenUSD/issues/3740
- Some Cyclic x knots_mode combinations are not correct and would
require more research to determine how to properly address.
- Custom attributes are not imported for Cyclic NURBS curves yet. Those
will require additional work to function correctly and are also
reliant on seeing how the USD spec changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/143970
Blender grid rendering interprets voxel transforms in such a way that the voxel
values are located at the center of a voxel. This is inconsistent with OpenVDB
where the values are located at the lower corners for the purpose or sampling
and related algorithms.
While it is possible to offset grids when communicating with the OpenVDB
library, this is also error-prone and does not add any major advantage.
Every time a grid is passed to OpenVDB we currently have to take care to
transform by half a voxel to ensure correct sampling weights are used that match
the density displayed by the viewport rendering.
This patch changes volume grid generation, conversion, and rendering code so
that grid transforms match the corner-located values in OpenVDB.
- The volume primitive cube node aligns the grid transform with the location of
the first value, which is now also the same as min/max bounds input of the
node.
- Mesh<->Grid conversion does no longer require offsetting grid transform and
mesh vertices respectively by 0.5 voxels.
- Texture space for viewport rendering is offset by half a voxel, so that it
covers the same area as before and voxel centers remain at the same texture
space locations.
Co-authored-by: Brecht Van Lommel <brecht@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/138449
Move the existing USDZ export test from C++ to Python for better
validation. The resulting file is now run through the `usdchecker`
system and we also check the contents of the resulting archive for the
expected texture file. This helped uncover a pathing issue in the
resulting archive where the 'textures' directory was misnamed on win32;
though it was still functional.
Pull Request: https://projects.blender.org/blender/blender/pulls/144176
Adds a Point Instancing exporter based on the existing
USDPointInstancerReader. Covers both round-trip and Blender-native
workflows. Exports 'Instance on Points' setups as USDGeomPointInstancer,
supporting objects, collections, and nested prototypes.
A warning is shown during export if invalid prototype references are
detected. These would occur if an instancer attempts to instance itself.
This feature is currently gated behind an off-by-default export option
(`use_instancing`) as there are still a few cases which can yield
incorrect results.
Further details in the PR.
Ref: #139758
Authored by Apple: Zili (Liz) Zhou
Pull Request: https://projects.blender.org/blender/blender/pulls/139760
Current NURBS evaluation handles corners or sharp angles poorly. Sharp
edges appear when a knot vector value is repeated `order - 1` times.
Users can make sharp corners by creating NURBS curve with `Bezier` knot
mode or by setting `order` to 2 for legacy curves. The problem occurs
because current algorithm takes all the curve's definition interval,
divides it into equal parts and evaluates at those points, but corners
are exactly on repeated knot's. To hit those, the resolution has to be
increased higher than required for the rest of the curve.
The new algorithm divides non zero length intervals between two adjacent
knots into equal parts. This way corners are hit with a resolution of 1.
This does change the evaluated points of NURBS curves, which is why some
test results have to be updated in this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/138565
Add support for the UsdPrimvarReader_TYPE templates for both import and
export. These are used by several USD test assets and support here
represents the last major piece of the UsdPreviewSurface spec to be
implemented.
On import these become `Attribute` nodes and on export the `Attribute`
nodes will become `UsdPrimvarReader_TYPE`'s accordingly.
Import:
- `UsdPrimvarReader_float` and `UsdPrimvarReader_int` will use the `Fac`
output
- `UsdPrimvarReader_float3` and `UsdPrimvarReader_float4` will use the
`Color` output
- `UsdPrimvarReader_vector`, `UsdPrimvarReader_normal`, and
`UsdPrimvarReader_point` will use the `Vector` output
Export (only `Geometry` Attribute types are considered):
- `Fac` will use `UsdPrimvarReader_float`
- `Color` will use `UsdPrimvarReader_float3`
- `Vector` will use `UsdPrimvarReader_vector`
- `Alpha` is not considered
MaterialX note:
Hydra-native support is a bit more involved and will have to be done
separately. Hydra w/USD sync is trivial to implement but those changes
have been left out here.
Pull Request: https://projects.blender.org/blender/blender/pulls/135143
Switch from Standard Surface to OpenPBR as the exported MaterialX surface,
since this is the new standard more renderers are adopting and it more closely
matches the Principled BSDF implementation.
Anisotropy support is improved though still not quite the same, as formulas
are different. Nodes are generated to apply anisotropic rotation to the
tangent vector, as there is no corresponding parameter in OpenPBR.
Fixes#138164
Authored by Apple: Lee Kerley
Pull Request: https://projects.blender.org/blender/blender/pulls/138165
We recently pulled in the upstream patch to address the incorrect
validation error we were experiencing. This was the only test which
previously required the validator to be disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/138289
This change adds MaterialX version information to the exported MaterialX
USD materials.
Details:
In USD 25.02, the MaterialXConfigAPI schema was introduced to allow
recording the MaterialX version used to author a material. When loading
MaterialX documents into USD, this schema is automatically applied and
the associated version attribute is created on the material.
Due to how the MaterialX export works (via copying the composed
MaterialX spec from a temporary stage), the MaterialXConfigAPI needs to
be explicitly applied to the final material being exported.
This change applies this MaterialXConfigAPI schema and copies the
version attribute from the temporary MaterialX stage to the final stage.
Authored by Apple: Dan Knowlton
Co-authored-by: Dan Knowlton <d_knowlton@apple.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/137974
While object names in Blender are already unique, the names themselves
may be "unsafe" for use in the various file formats. During processing
we make the names "safe". However, we did not guarantee that these new
safe names were themselves unique wrt each other. Consider object names
"Test 1" and "Test-1" which both become "Test_1" after being made safe.
These will collide during export; only 1 object would be exported and
it's undefined which object's data would "win".
To rectify this we add another name map to the hierarchy iterator which
is then used to handle collisions as they happen. The map is per-
hierarchy meaning that a name can appear more than once as long as its
under a different hierarchy. E.g.
- `/root/A/X` and another `/root/B/X` is OK
- `/root/A/X` and another `/root/A/X` is NOT OK
Pull Request: https://projects.blender.org/blender/blender/pulls/135418
Unlike the legacy type, the radius isn't included in the bounds for the new
curves type. This hasn't been obvious because the drawing is quite broken
and doesn't use the radius properly.
This commit adds a separate cache for the bounds with the radius, which
is now used by default. The old cache is kept around for backward
compatibility in the bounding box geometry node, where a new
"Use Radius" option accesses the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135584
In order to better interop with the broader Alembic/USD ecosystem, align
the crease values we export with what we believe is expected by native
OpenSubdiv, a 0-10 range.
On import we will translate the native OpenSubdiv range back into
Blender's 0-1 range.
To account for SubD assets produced by Blender before this change, a
compat check is put in place for both Alembic and USD to use the old
methodology when encountering such files. The compat check makes use
of the Blender version we place inside the format's metadata fields. Old
assets loaded into a new Blender will look ok. New assets loaded into an
old Blender would need to be reworked.
Pull Request: https://projects.blender.org/blender/blender/pulls/132582
- There's only a few unit conversion options, just test all of them
- Use reference instead of pointer when passing export settings struct
- Organize scaling struct fields to keep similar options together
Pull Request: https://projects.blender.org/blender/blender/pulls/133774
Refactored USD instancing export to support instanceable references.
With this change, it's now possible to instance object hierarchies and
geometry types other than meshes (e.g., curves, point clouds, etc.).
No longer marking mesh prims as instances in
USDGenericMeshWriter::write_mesh().
USDTransformWriter::do_write() now marks the Xform as instanceable
with a reference to the prototype's Xform when the Blender object is
an instance.
In USDAbstractWriter::mark_as_instance() the target prim is now marked
as instanceable.
Added AbstractHierarchyIterator virtual functions include_data_writers()
and include_child_writers() to allow pruning children of instanceable Xforms
in AbstractHierarchyIterator::make_writers(). These functions return true
in the base class implementation, so that the iterator behavior for Alembic
exports is unaffected. In the USDHierarchyIterator subclass, these functions
are overridden to return false if instancing is enabled and the objects are
instances.
Added virtual function AbstractHierarchyIterator::should_determine_duplication_references()
which returns true if duplication references should be resolved for children
of a given context. This function is overridden in USDHierarchyIterator to
skip processing children of instances, which is more efficient for USD export,
since children of instances are pruned during traversal for writing. For nested
instances where the original prototype is not included in the export, this also
avoids designating a duplicated object parented to an instance as "the original",
which would cause USD errors since defining a prim under an instance
proxy is not allowed.
Extended logic in `AbstractHierarchyIterator::determine_duplication_references()`
to identify prototypes.
Added new function `HierarchyContext::is_prototype()`.
Disallowing merging with parent for instances and prototypes, since
the Xforms cannot be discarded in those cases.
Extended `USDWriterAbstract::ensure_usd_material()` with special logic
to ensure materials for prototype prims are defined in the subtree of the
prototype. This helps ensure the hierarchical encapsulation requirement
for prototypes and is required by certain renderers (e.g., Houdini's Karma)
for instance materials to render.
Added a new `process_scene_graph_instances()` function to ensure
prototypes are exported as abstract prims.
Added python tests test_export_native_instancing_true and
test_export_native_instancing_false.
Pull Request: https://projects.blender.org/blender/blender/pulls/131707
Makes use of recently added test data to ensure proper handling of child
objects, with animated transform constraints, parented to other objects
who also have animated transform constraints.
Also uses the `colored_print` module to better segment the test output.
Pull Request: https://projects.blender.org/blender/blender/pulls/133600
Cleanup and enhance our export of the USD `extent` attribute.
This does the following:
- The existing `author_extents` function now uses recently added common
code to write out the extents attribute
- A new `author_extents` overload allows the use of Blender's native
bounds for the types that support it. We now use this rather than
asking USD to recompute it for us.
- Meshes will now have their extents correctly written during animations
- Curves will now have their extents written as they were not doing so
prior to this PR
- Hair, Lights, Points, and Volumes make use of the `author_extents`
functions now
Since Curves need their extents tested, this PR also moves the test from
C++ to Python. Python tests allow for faster iteration, are more
straightforward to write, and allow usage of the USD validator.
Pull Request: https://projects.blender.org/blender/blender/pulls/132531
Export
Like we do for Mesh and PointCloud, export any "velocity" attribute on
the Point domain as native USD "velocities". While testing, a few
additional blender-internal attributes were discovered being exported
which are now excluded during export.
Import
Add the cache modifier as appropriate when we detect that UsdBasisCurve
data is animated. This includes time-varying positions, widths,
velocities, and general attribute values. Before this PR, only the
positions were considered. And like Export, the native USD "velocities"
attribute is now processed.
Adds test coverage as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/133027
This rescales the whole scene by its root transform to match the same
visual size while not forcing the user to wait for scale to be applied to
each object.
This is requested by studios whose main applications / USD scenes are
in CM, because referencing and payloading scenes from disparate scales
can cause issues at resolution time.
If "Apply Unit Scale Conversion" is unchecked on import, the user now
has the ability to bring the objects in with a scale factor of 1.0, so that the
objects may be edited as if Blender's scene units matches the imported
stage's.
At export time, a "Stage Meters Per Unit" value can be chosen from a list
of common measurements, as well as setting a custom value.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/122804
Until the newer Hair Curves system can fully replace particle hair, add
a small test to ensure this continues to work.
Since the hair is exported as cubic bspline curves, we can also use this
same file to test bspline import now too.
Pull Request: https://projects.blender.org/blender/blender/pulls/131997
While adding tests I found that metaball export has been broken since
Blender 3.4. It would export each metaball geometry twice.
This looks to have been a side effect of a change to `object_dupli.cc`
which no longer sets the `no_draw` flag for metaballs[1]. With the flag
unset we would end up visiting this particular object twice.
Use a direct check for Metaballs now and add test coverage for the
scenario in general.
[1] eaa87101cd
Pull Request: https://projects.blender.org/blender/blender/pulls/131984
Supporting a new on_material_import() USDHook callback.
Also added support for import_texture() and export_texture()
utility functions which can be called from on_material_import() and
on_material_export() Python implementations, respectively.
Pull Request: https://projects.blender.org/blender/blender/pulls/131559
Make use of our sparse value writer in more places. Namely, when using
animated Camera or Light properties, this will prevent a needless stream
of unchanging values being written into the USD file [1]. Skeletons and
armatures benefit too but less so as typically the primary benefit only
applies to the comparatively small `scale` transform attribute, which
typically remains unchanged from frame to frame.
The newly added `set_attribute` common code can, and eventually will, be
used to reduce boilerplate elsewhere where we do the same sparse writing
dance.
Ref #130759
Pull Request: https://projects.blender.org/blender/blender/pulls/131333
Rather than using a default "Anim" name when exporting armature
animations, use the animation's Action name instead. Likewise use the
UsdSkelAnimation name for the Action's name during import.
Blendshapes/shapekeys still use the default "Anim" name as there's no
action for these situations.
Pull Request: https://projects.blender.org/blender/blender/pulls/131021
When EEVEE next removed the Alpha Threshold option a node graph setup
was used instead. Based on a USD test asset[1] the original code was
designed around only using the Image A channel during import to wire
up the nodes. However, the other channels (R, G, or B) are just as
valid.
We now handle this by wiring up the Separate RGB node, that is already
inserted for the scenario in general, to the shader nodes handling the
threshold calculation. Also adds additional test coverage for both
export and import as well.
The Round and LessThan+OneMinus networks remain the only shapes that
will be recognized for the processing.
[1] https://github.com/usd-wg/assets/tree/main/test_assets/AlphaBlendModeTest
Pull Request: https://projects.blender.org/blender/blender/pulls/130346
Adds the option `merge_parent_xform` to the USD export operator and
panels so the transform and shapes are merged into a single USD Prim.
Without the option (existing default), a top-level mesh would be
exported as a top-level `Xform` that has a `Mesh` child:
```
def Xform "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
def Mesh "MyBlenderMeshData"
{
}
}
```
This matches the Blender data model, where a transformable object
contains a geometric shape (like a mesh). This structure is also very
valid in USD, where we don't want to directly instantiate geometric
primitives[1]
However, "since number of prims on a stage is one of the primary factors
that governs how USD scale"[2], to reduce the number of prims in a
stage, geometric primitives *are transformable* themselves (see the
inheritence diagram[3]).
As such, the new export option allows to export geometric primitives
without the parent transform:
```
def Mesh "MyBlenderMeshObject"
{
matrix4d xformOp:transform = ...
}
```
This MR adds a the `is_object_data_context` flag to the
`HierarchyContext` context structure. The point of this change is to
make unambiguous in `USDHierarchyIterator::create_usd_export_context`
the fact that an `object` or a `data` is currently being exported: the
new `merge_parent_xform` option is meaningless for `object`. Only `data`
can be exported with a parent `Xform` or as a child of said `Xform`.
Ideally this flag would not be needed at all: the final USD prim path
*could* be computed in an override of the virtual
`AbstractHierarchyIterator::get_object_data_path` method. However, this
would mean that an `object` and a `data` would have the same export path.
This does not currently play well with
`AbstractHierarchyIterator::ensure_writer`, where `writers` are cached
*by their export path*: it would cache a transform writer, but will skip
the subsequent data writer.
Additionally, another new `is_parent` flag is added to handle the case
where merging the Xform is invalid: objects that are parents to other
objects should remain unmerged as otherwise that would yield invalid USD
files.
[1] https://openusd.org/release/glossary.html#usdglossary-gprim
[2] https://openusd.org/release/glossary.html#usdglossary-instancing
[3] https://openusd.org/release/api/class_usd_geom_xformable.html
Co-authored-by: Odréanne Breton <odreanne.breton@ubisoft.com>
Co-authored-by: Sttevan Carnali Joga <sttevan.carnali-joga@ubisoft.com>
Co-authored-by: Charles Flèche <charles.fleche@ubisoft.com>
While adding test coverage for in-memory and packed texture scenarios, I
found that UDIMs were not being handled correctly in both cases. For
in-memory scenarios the per-tile generated/dirty status was not taken
into account. For packed scenarios the wrong filename substitutions were
being used.
This fixes both of these cases and adds test coverage for these
scenarios now. Both relative and absolute path options are validated.
Note: Both in-memory and packed images behave incorrectly when using the
'KEEP' and 'PRESERVE' texture export modes, so those remain untested
currently. A design on exactly what should happen in these modes is TBD.
Pull Request: https://projects.blender.org/blender/blender/pulls/130391
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
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
Instead of running the ComplianceChecker during just one test, run it
for every export test. A common `export_and_validate` local function is
used in all relevant locations now.
Pull Request: https://projects.blender.org/blender/blender/pulls/128513
This includes tests for a "static" mesh where the materials have been
assigned and are expected to remain the same over time.
The test scenario also includes a "dynamic" mesh where both new faces
and new materials are assigned to the same mesh over time (inspired by
#118754). However, that cannot be tested right now due to missing
features of both the MeshSequenceCache and our USD IO code. No testing
will occur for that case until the features are implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/128341
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
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
Adds test coverage for the USD python hook machinery:
- Ensure processing occurs correctly when returning False or throwing
exceptions from all the hooks
- Validates that the hook arguments are valid (UsdStage, depsgraph, and
material parameters)
- Tests unregister to ensure hooks are fully removed from processing
Pull Request: https://projects.blender.org/blender/blender/pulls/126809
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
Additional coverage for the following scenarios:
- Ensures custom properties are exported and imported correctly
- Ensures that xform op modes and scene orientation options are properly
respected during export
Pull Request: https://projects.blender.org/blender/blender/pulls/126723
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
Support the USD `color4f` (and related) types during import and use this
type when writing out Blender's color attributes.
This roundtrips Blender data correctly and will properly load data from
many more USD files as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/125839
Add an export test to cover some simple animation scenarios that would
have protected against recent bugs:
- A simple object animation (would have prevented `122625`)
- An armature animation (would have prevented `724a674baed`)
- A shape key animation (would have indirectly found `6c5ce883e73`)
Pull Request: https://projects.blender.org/blender/blender/pulls/123458
