During work on GeometrySet import it was discovered that periodic
(cyclic) bezier curves do not need their first control point repeated
in the actual scene description.
The USD API documentation was a bit unclear on this aspect but this has
been confirmed informally on the AOUSD forum and emperically using
another implementation.
This patch removes the duplicated start point during export.
Pull Request: https://projects.blender.org/blender/blender/pulls/119185
* Only works on machines with a Qualcomm Snapdragon 8cx Gen3 or above.
Older generation devices are not and will not be supported due to
some driver issues
* Requires VS2022 for building.
* Uses new MSVC preprocessor for sse2neon compatibility.
* SIMD is not enabled, waiting on conversion of blenlib to C++.
Ref #119126
Pull Request: https://projects.blender.org/blender/blender/pulls/117036
Reduce dependence on Blender headers as much as possible and move closer
to an include-what-you-use setup.
- Removes unnecessary includes
- Replaces some includes with more appropriate, narrower, substitutes
- Removes unnecessary forward declarations
Pull Request: https://projects.blender.org/blender/blender/pulls/118308
Make both importers work the same way: first building an array
of the new offsets, then comparing the offsets to check if the
topology changed. Previously the USD importer incorrectly
compared curve offsets to USD point counts.
Also:
- Don't unnecessarily set the resolution to the incorrect default.
The default for the curves system is 12. But it's unnecessary to
fill the attribute to the default value anyway.
- Use some helper methods to iterate over all curves.
- Use float literal instead of integer.
- Use cast and `copy_from` for positions copy
- Pass Span by value
Pull Request: https://projects.blender.org/blender/blender/pulls/118829
This rewrites the Alembic and USD data importers to work with and
output GeometrySets instead of Meshes.
The main motivation for this change is to be able to import properly
point clouds, which are currently imported as Meshes, and curves
data, which suffer from a lot of issues due to limitations of
legacy curves structures (fixed by the new curves data-block) and are
also converted to Meshes. Further, for Curves, it will allow importing
arbitrary attributes.
This patch was primarily meant for Alembic, but changes to USD import
were necessary as they share the same modifier.
For Alembic:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Points are imported as PointClouds
For USD:
There should be no behavioral changes for Meshes
Curves are imported as the new Curves object type
Note that the current USD importer does not support loading PointClouds,
so this patch does not add support for it.
For both Alembic and USD, knots arrays are not read anymore, as the new
Curves object does not expose the ability to set them. Improvements can
be made in the future if and when example assets are provided.
This fixes at least the following:
#58704: Animated Alembic curves don't update on render
#112308: Curves have offset animations (alembic / USD)
#118261: wrong motion blur from usd in cycles and reverting to the first
frame when disabeling motion blur
Co-authored-by: Jesse Yurkovich <jesse.y@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/115623
This addresses issue #93052.
Now converting the USD "varying" interpolation type to
the "point" domain type when importing USD attributes.
There have been some inconsistent opinions in the USD
developer community about whether "varying" interpolation
is equivalent to "corner" or "point" domains for meshes.
However, DCCs such as Unity and Houdini assume that the
number of entries for attributes with "varying" interpolation
is the same as the number of points, and this change allows
Blender to import such assets without error.
Pull Request: https://projects.blender.org/blender/blender/pulls/118539
The depsgraph CoW mechanism is a bit of a misnomer. It creates an
evaluated copy for data-blocks regardless of whether the copy will
actually be written to. The point is to have physical separation between
original and evaluated data. This is in contrast to the commonly used
performance improvement of keeping a user count and copying data
implicitly when it needs to be changed. In Blender code we call this
"implicit sharing" instead. Importantly, the dependency graph has no
idea about the _actual_ CoW behavior in Blender.
Renaming this functionality in the despgraph removes some of the
confusion that comes up when talking about this, and will hopefully
make the depsgraph less confusing to understand initially too. Wording
like "the evaluated copy" (as opposed to the original data-block) has
also become common anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118338
If hooks are not unregistered Blender will report a leak on exit.
Store the hooks as unique_ptrs to remove manual memory management and
encapsulate the previous global list inside a function. These changes
ensure that everything is cleaned up on termination.
Also makes a small change to the hook documentation for a missing
`import` statement.
Pull Request: https://projects.blender.org/blender/blender/pulls/118294
Span is preferrable since it's agnostic of the source container,
makes it clearer that there is no ownership, is 8 bytes smaller,
and can be passed by value.
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
Fixed duplicate nodes when converting texture scale/bias and
channel names on material import. This required extending
the node caching to handle cases where a USD shader is converted
to multiple Blender nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/118002
I added a new BLO_userdef_default.h header to contain declarations of
two global variables that are still defined in C files. Use of designated
initializers for large structs make those files harder to change.
Arguably this is a better header for them anyway.
Pull Request: https://projects.blender.org/blender/blender/pulls/118015
This adds the processing required to import and export simple material graphs utilizing the UsdUVTexture outputs channels.
If only r, g or b are specified as output, we hook up a `Separate Color` node and connect the appropriate channel from there.
(if a is specified as output, the Alpha output of an image texture node was used already)
On the export side, we traverse from the socket to the image texture node, and if a `Separate Color` on the way, we are using the channel from there to put on the output.
https://openusd.org/release/spec_usdpreviewsurface.html#texture-reader
Pull Request: https://projects.blender.org/blender/blender/pulls/117901
This header is for 'internal' USD code only (also needed by the hydra
code), and uses references to the USD library itself, so its previous
name was a bit too generic.
First step to move the main public Blender USD API header (`usd.h`) to cpp.
This adds a new `ModifierData.persistent_uid` integer property with the following properties:
* It's unique within the object.
* Match between the original and evaluated object.
* Stable across Blender sessions.
* Stable across renames and reorderings of modifiers.
Potential use-cases:
* Everywhere where we currently use the name as identifier. For example,
`ModifierComputeContext` and `ModifierViewerPathElem`.
* Can be used as part of a key in `IDCacheKey` to support caches that stay
in-tact across undo steps.
* Can be stored in the `SpaceNode` to identify the modifier whose geometry node
tree is currently pinned (this could use the name currently, but that hasn't been
implemented yet).
This new identifier has some overlap with `ModifierData.session_uid`, but there
are some differences:
* `session_uid` is unique within the entire Blender session (except for duplicates
between the original and evaluated data blocks).
* `session_uid` is not stable across Blender sessions.
Especially due to the first difference, it's not immediately obvious that the new
`persistent_uid` can fulfill all use-cases of the existing `session_uid`. Nevertheless,
this seems likely and will be cleaned up separately.
Unfortunately, there is not a single place where modifiers are added to objects currently.
Therefore, there are quite a few places that need to ensure valid identifiers. I tried to catch
all the places, but it's hard to be sure. Therefore, I added an assert in `object_copy_data`
that checks if all identifiers are valid. This way, we should be notified relatively quickly if
issues are caused by invalid identifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/117347
