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
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
When path to export is in the form if "/some/folder/.stl", any
regular path functions (BLI_path_suffix, BLI_path_extension_replace
etc.) would not treat it as having ".stl" extension, but rather
as a hidden file called ".stl".
And so BLI_path_suffix would turn it into "/some/folder/.stlCube".
To prevent this, detect this exact case when the whole basename
is just ".stl", and remove the ".stl" part before using other path
functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/125179
This continues the cmake modernization effort and introduces support for
allowing our optional dependencies to integrate properly. TBB is added
here as it's proven troublesome to maintain correctly.
Currently the only Blender project which uses the TBB headers directly
is `blenlib`. However, all downstream projects which require blenlib as
their dependency, and wish to properly make use of its threading
facilities, needed to define various TBB items in their CMake files. Not
only is this unnecessary and arcane, but several projects didn't do this
and ended up not using threading as well as producing ODR violations
along the way[1].
This PR makes TBB a modern dependency and exposes it PUBLIC'ly from
`blenlib`. All downstream projects which depend on blenlib will now
receive everything they require from TBB automatically. This includes
the `WITH_TBB` define, the headers, and the library itself.
[1] blender/blender@05241f47f5
Pull Request: https://projects.blender.org/blender/blender/pulls/124916
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
The `WITH_TBB` define needs to be set in order for code using the
various parallel threading helpers [1][2] to actually be multi-threaded.
The affected projects did not have `WITH_TBB` defined and were using the
single-thread variant of all affected APIs.
Additionally, in the case of `EnumerableThreadSpecific`, this results in
an ODR violation where there are 2 versions of the same class linked
into our final binary. One with TBB members and one without.
--------
[1] Namely code using the `BLI_task.hh`, `BLI_sort.hh`, and `BLI_enumerable_thread_specific.hh` headers
[2] `EnumerableThreadSpecific`, `parallel_for_each`, `parallel_reduce`, `parallel_invoke`, `isolate_task`, `parallel_sort`
Pull Request: https://projects.blender.org/blender/blender/pulls/124283
Having both custom vertex normals and the "is the face sharp?"
attribute on a mesh leads to some non-intuitive behaviours. Instead,
make the behaviour more aligned with OBJ format description wording,
which says "When vertex normals are present, they supersede
smoothing groups" (https://paulbourke.net/dataformats/obj/).
Pull Request: https://projects.blender.org/blender/blender/pulls/124366
- Sort add menu alphabetically
- Use forward declaration for GeometrySet again
- Use `this->` to access class methods
- Use `MEM_cnew`
- Fix typo
- Pass Span by value
- Pass MutableSpan instead of Vector &
- Remove unnecessary whitespace
- Use `BLI_SCOPED_DEFER` for freeing non-RAII objects
- Use `is_empty()` instead of `size() == 0`
- Use `GeometrySet::from_mesh` ability to handle null argument
Add a node similar to the STL import node (d1455c4138) that
imports OBJ files, including both meshes and curves. The output consists
of a geometry instance for each mesh/curve in the file.
There are a few improvements to address in the future: Currently the node
has no inputs besides the file path. Options may be exposed in the future.
Materials are also not imported yet, because creating material data-blocks
during evaluation may not be trivial.
This is part of a GSoC project:
https://devtalk.blender.org/t/gsoc-2024-geometry-nodes-file-import-nodes/34482
Pull Request: https://projects.blender.org/blender/blender/pulls/123967
Prevent crash from a mesh created around the time of Blender 4.0 with
bad (negative) material indices on some faces.
The Poly Haven folks were poked to fix the actual asset as well but it's
simple enough for us to clamp in this code path, especially since we
were already doing it for the upper bound.
Pull Request: https://projects.blender.org/blender/blender/pulls/124026
Similar to !124267 and !124261
This normal data is eventually passed into `BKE_mesh_set_custom_normals`
and through to `mesh_normals_corner_custom_set` which expects normals to
actually be normalized per its documentation.
Not doing so would yield meshes with incorrect "sharp" data for affected
edges.
Thx @OmarEmaraDev for the initial patch
Pull Request: https://projects.blender.org/blender/blender/pulls/124336
This normal data is eventually passed into `BKE_mesh_set_custom_normals`
and through to `mesh_normals_corner_custom_set` which expects normals to
actually be normalized per its documentation.
Not doing so would yield meshes with incorrect "sharp" data for affected
edges.
Pull Request: https://projects.blender.org/blender/blender/pulls/124267
Old python STL exporter, as well as other exporters like OBJ,
reverse the face order when object being exported has odd number
of negative scales in the matrix. The C++ STL exporter was lacking
that, resulting in the exported object looking "inside out".
The extra branch inside triangle export inner loop has no measurable
performance impact, probably because it is entirely predictable.
Pull Request: https://projects.blender.org/blender/blender/pulls/124219
Added a new custom_properties_namespace USD export option, to
allow replacing or omitting the current default "userProperties"
namespace prefix.
Note that this option does not apply to names that already have a prefix
(e.g., it would apply to name "bar" but not "foo:bar"). It also does not apply
to the internal Blender "object_name" and "data_name" properties which
always have the prefix "userProperties:blender".
Also added logic to handle ":" namespace delimiters in property names.
Pull Request: https://projects.blender.org/blender/blender/pulls/124067
