EEVEE-next has removed the MA_BM_CLIP / alpha_threshold material
properties in favor of using nodes for equivalent functionality. This
changes USD to build and traverse node graphs during import and export
accordingly. Indirectly this allows Cycles to correctly render such
materials now too.
A complicating factor is that the UsdPreviewSurface defines its opacity
threshold using greater-than-equals[1], which Blender does not support
(and for which was technically already incorrect as EEVEE-legacy only
used greater-than for its shaders). Due to this we actually need to use
2 nodes: A less-than, followed by a one-minus invert, to arrive at the
proper value. We'll translate UsdPreviewSurface to this form on Import.
For Export we will look for either this 2-node pattern or a Round
node plugged into Alpha. Looking for Round is a result of the glTF
documentation which recommended the use of this node for thresholds of
0.5[2]. It's a tiny addition that seems reasonable to accommodate.
[1] https://openusd.org/release/spec_usdpreviewsurface.html (search for "opacityThreshold")
[2] https://docs.blender.org/manual/en/4.2/addons/import_export/scene_gltf2.html#alpha-modes
See PR for example images
Pull Request: https://projects.blender.org/blender/blender/pulls/122025
Add support for reading and writing custom `Curves` attributes.
This allows us to roundtrip Blender's Hair grooms containing UVs and
other attribute data. Note that animated attribute values are not
supported with this change.
This will also address #120042
Pull Request: https://projects.blender.org/blender/blender/pulls/121928
This allows for the source of truth data in the Blender scene to remain
untouched while producing triangulated output suitable for game and VR
pipelines, where only triangles are ingested. This addition aligns USD
with some of the other exporters which offer a similar feature.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121274
Prims in a UsdStage can be created directly (def) or as an over. Overs
might not always be desired at import time. This patch adds the ability
to choose whether to load only defined prims (the default behaviour, and
as it exists currently in main). By unchecking this option at import
time, prims created as overs will also be imported.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121321
Added option for filtering types of objects to export. Meshes,
materials, lights, cameras, volumes, and curves are all equally
supported.
This is useful for many situations in which a user might want a
subset of objects from a Collection without wanting to build a
sub-collection or otherwise reorganize their scene. Exporting
Armatures and their animation as UsdSkel objects and UsdSkelAnim
clips, but without meshes, is a good example.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121325
Different pipelines standardize on different XForm op setups (T-R-S,
T-orient quat-S, Matrix). Having this options means that this standard
can be chosen at export time instead of having to patch on load.
Speaking from experience, this is a very helpful option.
Co-authored-by: kiki <charles@skeletalstudios.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121627
This factors out the current set of attribute-to-primvar functions
inside the USD mesh reader/writer so we can use them elsewhere.
These new functions will be used for PointCloud attribute reading and
Curve attribute reading and writing in follow up changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/121145
We were writing out the `inputs:varname` as a `token` instead of
`string` which is incorrect according to the UsdPreviewSurface spec[1].
Apparently it changed with version 2.3[2].
This results in a validation failure in USD 24.05, and maybe 24.03, seen
here:
```
Incorrect type for /root/_materials/Material/UV_Map.inputs:varname. Expected 'string'; got 'token'. (fails 'ShaderPropertyTypeConformanceChecker')
Failed!
```
The fix is a 1-liner but I've changed the surrounding code to use
`std::string` instead of `pxr::TfToken` to reinforce the concept. Our
material reading code is unaffected and was already handling both tokens
and strings.
[1] https://openusd.org/release/spec_usdpreviewsurface.html#primvar-reader
[2] https://openusd.org/release/spec_usdpreviewsurface.html#version-2-3
Pull Request: https://projects.blender.org/blender/blender/pulls/121668
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
If a curve was not using U parameter range of 0..1, the importer
did not properly detect whether the "U endpoint" flag should
be set on it. Fixed that, along with test coverage for the case.
This patch allows the user to choose the Stage Up Axis at export time,
allowing the export to match another target software package. The most
common is reorienting to Y up. The up axis is written to stage metadata
and a top-level orientation is applied to reorient objects in the Stage.
The new orientation is required because the Stage metadata `upAxis` is,
apparently, not used during certain USD composition arcs. The
recomendation is to only use a single `upAxis` throughout the pipeline
and this option here allows files produced by Blender to more easily
conform to the conventions used as needed.
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121226
When moving importers from Python to C++ validation was removed
(from PLY) & disabled by default (STL & OBJ) which re-introduces
crashes reported by users such as #31835.
Enable validation by default because crashes caused by imported data
should be avoided, especially since the crashes may happen later when
users enter edit-mode or run certain editing operations.
This does slow down importing, from testing a 236MB .OBJ it takes around
twice as long to import (~1.5 to ~3 seconds). Although validation can
be optimized to reduce the overhead ad well as run in parallel for
importers that load multiple objects.
The defaults for USD and Alembic remain unchanged since this was never
enabled by default, although we could consider enabling these as well.
This should get all of the tests to pass on Windows ARM64 platforms.
Sadly it needs disabling for hydra/USD stuff as currently it doesn't play nicely with the new preprocessor. @LazyDodo suggested a USD version update may fix this, which is something I can investigate in due course - right now, let's get daily builds up and working :)
Pull Request: https://projects.blender.org/blender/blender/pulls/121361
Remove the one-definition-rule violation due to two `Triangle` types
being used inside the same `blender::io::stl` namespace. Make a small
set of non-functional changes in the surrounding code along the way to
use `const` in more places.
STL had 4(!!) triangle types:
- A `class Triangle` : Used for import, contains indices
- A `struct Triangle` : Used for export, contains verts/normals, the ODR
violation
- A `struct ExportBinaryTriangle` : Used for export but is really the
same as the above type
- A `struct STLBinaryTriangle` : Used for import but was a duplicate
of the above type
Now STL has just 2. The `class Triangle` containing indices during
import and a `struct PackedTriangle` containing the verts/normals for
everything else. The duplicated `BINARY_HEADER_SIZE` constant is now
common as well.
Performance remains the same for both import/export and ascii/binary.
Pull Request: https://projects.blender.org/blender/blender/pulls/121179
Added mesh validation on import as an option.
If bad mesh data is imported, there may be a crash on a switch to edit
mode or similar. This adds an option to validate if a user determines
the file is corrupted, allowing the possibility for data recovery.
This is especially useful for importing files exported from certain CAD
applications.
The option here matches the option that OBJ and Alembic both provide.
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/121054
Blender USD import already supports the displayColor primvar, when it is
specified on Mesh prims. These colors are visible in the viewport when
the viewport shading color type is set to Attribute.
This PR extends this displayColor primvar support to also work with the
various shape prims, such as Box, Sphere, etc.
The original displayColor support was implemented in USDMeshReader.
Because USDShapeReader is a sibling to to USDMeshReader, and
USDShapeReader first converts shapes to a Mesh, we have factored out the
mutually beneficial code from usd_reader_mesh.cc into a new usd_mesh_utils.cc.
For now only the displayColor primvar is supported on shapes, but this
could be easily extended in a future PR.
Authored by Apple: Matt McLin
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/120236
Cleans up the following issues:
- USD arrays were passed by value instead of references
- UsdGeomBasisCurves and UsdGeomNurbsCurves were potentially sliced when
assigning to their parent UsdGeomCurves object in a non-polymorphic way
- Make more parameters and functions const
- Align with how Alembic validates the curve_types and cyclic values
- Standarize CurvesGeometry naming like what was done in 5ed9c8c9dd
(Curves data-block is called "curve_id", CurvesGeometry is called
"curves")
Pull Request: https://projects.blender.org/blender/blender/pulls/120760
During Export, we were accidentally duplicating the `velocity` attribute
data. Once inside the `write_surface_velocity` function (which was
correct) and again while writing out all "custom" attributes inside
`write_custom_data` (which was incorrect). Fixed by excluding the
"velocity" attribute inside `write_custom_data`.
During Import, we were only loading back in those "custom" primvars so
things happened to work, by accident, but only for USD files produced by
Blender. Now we import just the Velocities attribute which should work
with all files.
This should fully address #96182
Pull Request: https://projects.blender.org/blender/blender/pulls/120771
Adding support for converting between Blender custom properties and
USD user-defined custom attributes. Custom attributes on Xforms, many
data types, and materials are all supported for round-tripping.
Please see the USD attributes documentation for more information on
custom attributes.
Properties are exported with a userProperties: namespace for simple
filtering in external apps. This namespace is stripped on import,
but other namespace are allowed to persist.
An "Import Attributes" parameter has been added with options "None" (do
not import attributes), "User" (import attributes in the 'userProperties'
namespace only), "All custom" (import all USD custom attributes, the
default).
An "Export Custom Properties" export option has been added.
The property conversion code handles float, double, string and bool
types, as well as tuples of size 2, 3 and 4. Note that USD quaternions
and arrays of arbitrary length are not yet supported.
There is currently no attempt to set the Blender property subtype based
on the USD type "role" (e.g., specifying Color or XYZ vector subtypes).
This can be addressed in future work.
In addition to exporting custom properties, the original Blender object
and data names are now saved as USD custom string attributes
"userProperties:blender:object_name" and "userProperties:blender:data_name",
respectively, on the corresponding USD prims. This feature is enabled
with the "Author Blender Name" export option.
If a Blender custom string property is named "displayName", it's handled
in a special way on export in that its value is used to set the USD
prim's "displayName" metadata.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Michael Kowalski <makowalski@nvidia.com>
Co-authored-by: Charles Wardlaw <kattkieru@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/118938
Enables the STL and PLY formats for Collection export.
Changes
- Set the export operator on the File handlers
- Plumb through the `collection` property and make use of it while
building the depsgraph
- Skip drawing the "Selection only" and "Batch" mode options when used
with collections
Pull Request: https://projects.blender.org/blender/blender/pulls/120944
Importing `COLLADAFW::MeshPrimitive::LINES` would assert trying to get
the `material_indices` (these are on the Face Domain -- which does not
exist here).
To resolve, early out if we know we handle LINES.
Probably didnt happen before 45cff837bc
Stumbled over this looking into !120737
Pull Request: https://projects.blender.org/blender/blender/pulls/120738
Exposed by 1ea169d90e
Colladas `MeshImporter::mesh_add_edges` is a copy from `mesh_add_edges`
in `source/blender/editors/mesh/mesh_data.cc` (done in 2c05190374 --
there is a comment to deduplicate this into BKE, but this wont be done
in this patch).
However, as time passed there have been additions to the later, namely:
- 353fe610ed (clearing the mesh runtime caches)
- 12becbf0df (altering selection handling, guess this can be ignored
here since collada generally does not seem to select geometry)
So in order to resolve, now also clear the caches for collada as in
353fe610ed (even though just the subset of just `mesh->runtime-
>loose_edges_cache.tag_dirty()` would also be enough).
Pull Request: https://projects.blender.org/blender/blender/pulls/120737
- "Log Encoding with Chroma inset and rotation": add "of primaries" in
the description of the AgX Log color space to better explain the
operation, based on wording in !106355.
- Remove a few double spaces.
- Make Line Art title case everywhere, to convey it's the system /
brand / product name and not the generic concept.
- "Copy Absolute coordinates or Normal vector" -> "of Normal Vector":
typo.
- "Makes a link between selected output in input sockets" ->
"Make...", "output and input": typo.
- "Purge Unused Data From This File" -> "from this": title case as per
HIGs.
- GPencil -> Grease Pencil: no reason to use an abbreviation here.
- "Around Current Frame" -> "Around Frame": actual name of the
onion-skinning method.
- "... (layer height for layer tool, i.e.)" -> "(i.e. the layer height
for the layer tool)": put "i.e." at the start of the sentence.
- Expand description of toe-in stereo camera option.
- "Children collections their parent-collection-specific settings" ->
"Children collections with their...": typo.
- "Generate vertex weights base on..." -> "based on" : typo, lower
case.
- Expand description of GP modifier properties, based on their mesh
counterparts.
- "AEnvelope" -> "Envelope": typo.
- "Falloff type the feather" -> "of the feather": typo.
- "usually make transition as long as effect strip": rephrase.
- "When disabled a users extensions directory is created" -> "a
user's": typo.
- "successfull" -> "successful": typo.
- "Remove all attributes... a single wildcard (*).": remove trailing
".".
- "..., use "Save Preferences."": remove trailing ".".
Some issues reported by Marina Veselkova and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/120649
Support the new Curves object type in Alembic when exporting curve data.
Make corresponding fixes to importing at the same time.
Summary of changes
- Exporter now supports the `Curves` object type during Export
including when using the convert to mesh option
- Exporter will now enforce that only 1 combination of curve type and
periodicity are in a given object [0].
- Catmul-rom basis curves are now supported and will be used for Hair
data [1].
- Bezier curves are exported with their left/right handle data [2].
- Cyclic bezier and nurbs curves should be handled correctly now.
Along the way this required changes on the Import side as well in order
to be complete
- Importer will now load bezier curve handle data correctly
- Importer could fail to set the correct cyclic data on the last spline
of a multi-curve object
See PR for screenshots
[0] See https://github.com/alembic/alembic/blob/master/lib/Alembic/AbcGeom/OCurves.h#L55
Prior to this change the Alembic exporter could write invalid data to
the file in these cases.
[1] Alembics created with the new Curves Hair object with this patch
will not be loadable in prior versions of Blender. The importer does not
handle the curve data correctly and will crash.
[2] There was a long-standing TODO about how to handle bezier curve data
since nothing is documented on Alembic's side. Bezier data wouldn't even
round-trip properly inside Blender itself. On a hunch, because USD was
influenced by certain aspects of Alembic which came before it, I decided
to try writing out the data the same way as USD. That turned out to work
quite well in at least 1 external software so that's what this patch
will use for both import and export.
Pull Request: https://projects.blender.org/blender/blender/pulls/119894
