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
STL/PLY (also Collada) use `BKE_mesh_assign_object` to assign a mesh
(already in main, has a usercount of 1) to a fresh object.
That function does a bunch of (unneeded) things (test modifiers/
materials which is not necessary since these are fresh objects) next to
increasing usercount. Collada steers against this by reducing usercount
again. Other importers such as alembic assign the mesh directly to
object data (which is also what this PR proposes).
Pull Request: https://projects.blender.org/blender/blender/pulls/123558
The callback-based identification was introduced before job types were added in
7b60529517. The job type should be a more predictable/sane way to identify jobs
that should be exclusive. Using anything else is confusing and non-obvious from
the API usage side. In fact it really confused me when working on #123027.
Checked all existing jobs to make sure behavior is unchanged. Found
two issues:
- `WM_JOB_TYPE_OBJECT_SIM_FLUID` is used for both
`fluid_bake_startjob()` and `fluid_free_startjob()`. It makes sense to
me that they would be exclusive though, so leaving it this way
(meaning they are exclusive now).
- Alembic and USD job types were reused, split them up now to not change
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/123033
This was previously attempted in #109518 and reverted in #112234. Now do
both the changes in the mesh and material export, and make it an option
in USD export. Hydra always renamed to "st" and continues to do it.
Fix#122800: Missing textures with MaterialX materials
Pull Request: https://projects.blender.org/blender/blender/pulls/123326
`GpencilIOParams.ob` is set to `CTX_data_active_object` at the beginning
of the export [which is not ensured to be a valid `OB_GPENCIL_LEGACY`
object, non-valid objects are filtered out later in
`create_object_list`]. From this (potential non-greasepencil) object's
data, a "global `bGPdata` is stored in `GpencilIOParams`.
From here, it can only go downwards as `stroke_point_radius_get`,
`export_stroke_to_polyline`, `BKE_gpencil_stroke_perimeter_from_view`
all use this "global" `bGPdata`.
Two possible solutions might exist:
- [1] just cancel the operator if the active object is not a
`OB_GPENCIL_LEGACY` object
- [2] make sure we use corresponding `bGPdata` when iterating over
valid objects to export
This PR chooses [2] since it also seems wrong to always use the
`bGPdata` from the active object for certain calculations when iterating
many objects. For example, the export ignores different values for
`Thickness Scale` on different objects and always takes the value from
the active object, which does not seem to be by design.
NOTE: this changes behavior (see above) but for the better
Pull Request: https://projects.blender.org/blender/blender/pulls/123224
Fixing a bug which was causing forward-slash separators in
skeleton joint paths to be replaced with underscores, resulting in
invalid skeletons.
This was inadevertantly introduced in 9ad2c7df0b. I should
have caught this when I reviewed #122471.
Pull Request: https://projects.blender.org/blender/blender/pulls/123031
The attribute API defined in `attribute.cc` was dependent on
the assumption that `ID`s are always the "direct" owners of attributes.
For Grease Pencil drawings, this is not the case. The Grease Pencil ID
stores the attributes for layers, and the attributes for drawings are stored
in `CurvesGeometry` on the drawings themselves.
In order to make use of `rna_attribute.cc`, we need that API to handle
other types of attribute owners.
This adds an `AttributeOwner` which is basically just a type and a
pointer. We replace the `ID` pointers and pass `AttributeOwner`s instead.
For cases where we have to do a switch based on the type, all the
types are handled and the `default` statment is left out. This ensures
that we get a compiler warning when a new `AttributeOwnerType`
is added.
No functional changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/122765
Allows to import multiple alembic files in single operator call.
When importing multiple alembic files as background job, import progress
will be divided by all files, so if `5` files are imported, each file
will make progress of `20%`. This can be improved if the job text can be
customized to display for example `Import Alembic 1/5` and using 100%
progress status display for each file, but that is out of the scope of
this pr.
The Scene min and max frame are set based on the minimum/maximum frame
ranges detected from all files.
Pull Request: https://projects.blender.org/blender/blender/pulls/121492
This change adds the ability to export MaterialX networks into the resulting
USD layer.
Details:
A new export option has been added to the USD export to enable MaterialX
export. It is off by default currently due to reasons in the caveats
section.
When enabled, it exports the MaterialX shading network alongside the
UsdPreviewSurface network, on the same USD Material. This allows the same
material to be used by renderers that don't support MaterialX, using the
USDPreviewSurface as a fallback. This is similar to setups in other DCC
packages, and matches the format we've used in our Reality Composer Pro
asset library.
It uses the existing MaterialX framework used to generate MaterialX
documents for rendering, to act as the basis for the USD graph. In this
process it also re-uses the existing texture export code as well if provided
and necessary.
Once the MaterialX document is created, use usdMtlx to generate a USD
shading network. Unfortunately, usdMtlx generates a graph that is unlike
what other DCCs that support MaterialX-embedded-in-USD generates. It
generates several extra prim hierarchies, and externalizes all shader
inputs, making them difficult to edit in other MaterialX graph editors.
To workaround this, generate the MaterialX shading network onto a
temporary stage, where we then run various pre-processing steps to prevent
prim collisions and to reflow the paths once they're converted.
The PrimSpecs are then copied over to their new path. The resulting prim
hierarchy matches what many artists we've worked with prefer to work with.
Caveats:
The Export MaterialX check is off by default. When using the Principled
BSDF, the resulting graph is very usable. However, when using some of the
other BSDFs, the shading networks generated by the existing MaterialX
framework in Blender generate some shading graphs that are difficult for
usdview and other DCC's to understand. The graph is still correct, but
because we're trying to prioritize compatibility, the default is off.
In future PRs we can aim to make the graphs for those other BSDFs play
better with other DCCs.
Other Implementation Details:
As part of this commit we've also done the following:
* Place some of the materialx graphs inside a passthrough nodegraph to
avoid node conflicts.
* Better handle some shader output types , and better handle some
conflict cases.
* Moved the ExportTextureFunction to materials.h due to some difficult
to resolve header ordering issues. This has no effect on any runtime code.
* There is a test for the MaterialX export that does some basic checking to
make sure we get an export out the other end that matches our expectations
Authored by Apple: Dhruv Govil
This PR is based on an earlier implementation by Brecht van Lommel , as well
as Brian Savery and his teams' work at AMD to implement the general
MaterialX framework within Blender.
Pull Request: https://projects.blender.org/blender/blender/pulls/122575
Make use of USD's new UTF-8 support to allow our import/export code to
accept and generate appropriate USD files. This has been a long standing
shortcoming since USD's introduction, with incomplete and complicated
DCC-specific workarounds often attempted.
Summary of changes
- Export gets a new "Allow Unicode" option defaulting to "false". The
new Unicode USD files are not backward compatible. DCCs using older
versions of USD (before 24.03) will not be able to load such files so
we want to provide this as an opt-in option for now.
- Every location which used to call either `USDHierarchyIterator::make_valid_name`
or `pxr::TfMakeValidIdentifier` will now go through a new `make_safe_name`
API instead
- Export code is responsible for passing in the `allow_unicode` option
- Import code will always pass in `true` meaning Blender will happily
accept both existing and new Unicode USD files
Strangely, USD does not provide a convenient way of making valid UTF-8
identifiers and they left their old API unchanged. We had to roll our
own per their advice: https://forum.aousd.org/t/how-to-make-a-unicode-identifier-valid/1435
Pull Request: https://projects.blender.org/blender/blender/pulls/122471
