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.
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
Fixes the camera and View3D projection used for calculating the rendered
region for SVG/PDF export. Also drastically simplifies this code by
removing unnecessary variables and using an optional transform to
indicate when camera data is actual available.
Also fixes missing layers in export due to incorrect early exit in the
layer loop.
Pull Request: https://projects.blender.org/blender/blender/pulls/126691
The imported GP object should start out in default X/Z plane
orientation. The `EulerXYZ` function expects radians.
Gradient colors are not supported by Grease Pencil. GPv2 was simple
ignoring them and using the `NSVGgradient` pointer as a "color" value,
leading to effectively random colors. GPv3 was outputting black instead,
but that is easy to mistake for a deliberate color. This patch computes
an average gradient color as an approximation, and also generates a
warning for the operator when gradients are encountered.
Using magenta as a visual indicator is also a possibility, but this
proxy color seems to work pretty well.
Pull Request: https://projects.blender.org/blender/blender/pulls/126650
Crash when exporting selected frames due to two different reason.
frame returned by frame_at() can be null, so add a null check
before calling `is_selected()` member function.
After depsgraph update, ob_eval.data changes. So cast it to gease_pencil
every frame to avoid the crash (otherwise grease_pencil will point to
invalid memory).
Pull Request: https://projects.blender.org/blender/blender/pulls/126643
Provide an appropriate fallback during Import of some incorrect Alembic
curve data and write out valid data during our Export as well.
The buggy file in question has 2 problems:
- The curve data is marked as being `kVariableOrder` but provides no
actual `order` data. This is invalid according to Alembic code [1]
- The curve data is also marked as being `kBezierBasis` but the actual
values are most likely not bezier judging from how many elements are
in each curve array
This PR focuses on the first problem and allows the file to load
"correctly" - or at least as correctly as it did prior to Blender 4.2.
If we encounter such a file, we will fallback to interpreting the data
as linear POLY curves. It also ensures that we only use `kVariableOrder`
when needed during Export.
[1] 23f1c76d7c/lib/Alembic/AbcGeom/ICurves.h (L91)
Pull Request: https://projects.blender.org/blender/blender/pulls/126378
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
Lift certain incorrect assumptions about the order of vertices in
an OBJ file when processing vertex colors, which could lead to
missing or randomly permuted colors.
Replaces the list-of-blocks representation, attuned to assumptions
that the verts in an object form a contiguous subrange, with a
flat array better suited for random-access.
Co-authored-by: scurest <scurest@users.noreply.github.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/126065
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
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
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
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
Access each parameter by name instead of depending on ordering.
Also reorder the parameters to better indicate their groupings, making
things a bit easier to see at a glance what is possible to be set.
Pull Request: https://projects.blender.org/blender/blender/pulls/125620
This patch uses the USD AssetResolver to deal with texture paths.
Functionally, adding this patch should make no functional differences in
the way textures are written.
If textures are specified as assets instead of file paths, at current
the file will error on load and the textures will not be assigned. These
should now be processed correctly.
See PR for example file and testing scenarios.
Co-authored-by: kiki <charles@skeletalstudios.com>
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Co-authored-by: Charles Wardlaw <cwardlaw@nvidia.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/122747
