- Only calculate the necessary normals based on smooth/flat/mixed shading
- Use cached face normals instead of computing them
- Use a `VectorSet` for deduplication instead of a `Map`
- Deduplicate vertex normals and store indices in separate loops
- Avoid unnecessary duplication of face normal indices
- Inline simple function for slicing index span
Export time (ms) of 1.8m vertex mesh:
| Normals Domain | Before | After |
| --------------- | ------ | ----- |
| Face (flat) | 559 | 469 |
| Vertex (smooth) | 659 | 466 |
| Corner (mixed) | 656 | 640 |
The change of using normals from different domains and using a
VectorSet for de-duplication change the order of normals in the OBJ
files. Other than that, the results should be unchanged.
Fixes#117510
Pull Request: https://projects.blender.org/blender/blender/pulls/117522
Remove the need for the `calc_vertex_coords` function by combining
the scale into the existing transform needed to export vertex positions
in global space. This simplifies code and may slightly improve performance
(I only observed a few percent difference in the positions export, which is
not a slower part of the export).
- Use Span where ownership is unnecessary
- Use Array when dynamic growth is unnecessary
- Use Vector in all other cases
Also remove unnecessary namespace specification.
Straightforward change from usage of iostream to CLOG.
Using CLOG unifies info/warning/error logging under a common
infrastructure that provides facilities for standardized filtering,
categorization, and printing. It also removes direct dependencies on
`<iostream>` which can be detrimental to compile times.
Pull Request: https://projects.blender.org/blender/blender/pulls/117429
`BKE_object_get_pre_modified_mesh` returns curve object data, later
accessing non-existing edge/face data triggered the crash.
`apply_modifiers` seems valid for mesh data only.
Pull Request: https://projects.blender.org/blender/blender/pulls/117471
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
There's been feedback that placing them inside a Scope better aligns
with other DCCs and makes some aspects of tooling more consistent in the
ecosystem.
Note: it was not a spec violation to have the typeless def that we used
before.
Pull Request: https://projects.blender.org/blender/blender/pulls/116460
The previous commit introduced a new `RPT_()` macro to translate
strings which are not tooltips or regular interface elements, but
longer reports or statuses.
This commit uses the new macro to translate many strings all over the
UI.
Most of it is a simple replace from `TIP_()` or `IFACE_()` to
`RPT_()`, but there are some additional changes:
- A few translations inside `BKE_report()` are removed altogether
because they are already handled by the translation system.
- Messages inside `UI_but_disable()` are no longer translated
manually, but they are handled by a new regex in the translation
system.
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
Pull Request: https://projects.blender.org/blender/blender/pulls/116804
This fixes an issue where a CacheFile was always created for the USD
file, causing USD_create_handle() to be called unnecessarily even if the
USD does not have animating meshes or transforms.
This bug would sometimes result in the stage remaining open in a
CacheArchiveHandle after import (because the CacheFile is never
freed), preventing the USD from being reloaded from disk.
The cache file is now accessible to readers through an
ImportSettings::get_cache_file function wrapper which creates a
CacheFile as needed, the first time the function is called.
The allocated CacheFile pointer is now stored in a new
ImportJobData::cache_file member.
Pull Request: https://projects.blender.org/blender/blender/pulls/116242
Change to map the USD "varying" interpolation type to Blender's
"Corner" domain type when importing mesh attributes. This fixes
value count mismatch errors when importing USD attributes with
varying interpolation.
Note that, for meshes, "varying" and "faceVarying" interpolation
are essentially the same in practice.
Pull Request: https://projects.blender.org/blender/blender/pulls/116955
The same is done for other geometry types. This allows us to use C++ types in
the run-time data more easily and avoids dumping runtime data into .blend files.
Pull Request: https://projects.blender.org/blender/blender/pulls/116840
Blender's cameras don't have specific resolution configured to them,
instead they use the scene's resolution.
This is a problem when exporting a camera using Alembic. Other software
(like Houdini) expects the resolution parameters on the camera itself.
So now store the scene's resolution on each camera that is exported.
Since this is not part of the concept of a camera in alembic itself,
export these as `userProperties` in a way other software can read this.
Fixes#116375
Pull Request: https://projects.blender.org/blender/blender/pulls/116782
Bone collection visibility now respects their hierarchy.
A bone collection is only visible when it is marked as visible and all
its ancestors (so parents, greatparents, etc.) are visible. Root bone
collections have no ancestors by definition, and only consider their own
visibility.
The effective ancestors' visibility is stored on each bone collection,
in its `BONE_COLLECTION_ANCESTORS_VISIBLE` flag. This makes it possible
to determine the effective visibility from just the flags of the bone
collection itself.
The `BONE_COLLECTION_ANCESTORS_VISIBLE` flag is now stored, with the
other flags, in `BoneCollection::flags`. This means that it's stored in
DNA, even though it's derived data and should actually be stored in a
runtime struct. However, `BoneCollection` doesn't have any runtime
struct yet, and I don't feel that the introduction of this flag is a
good enough reason to introduce that just yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/116784
This is reusing the generic system from 128eb6cbe9 which at that time
was only done for the mesh reader and is now done for the point reader
as well.
This allows for rendering with proper motion blur for alembic points
(which of course are still imported as meshes - were just lacking the
velocity attribute) when directly rendering as points in Cycles.
Came up in #109185 (where instancing is used - which is still not
supported, this patch is just for direct point rendering in Cycles).
Unsure about the status of https://archive.blender.org/developer/D11591
but until that lands, having velocities for points sounds useful enough
to support this now.
Fixes#95945
Pull Request: https://projects.blender.org/blender/blender/pulls/116749
Bundling many tests in a single binary reduces build time and disk space
usage, but is less convenient for running individual tests command line
as filter flags need to be used.
This adds WITH_TESTS_SINGLE_BINARY to generate one executable file per
source file. Note that enabling this option requires a significant amount
of disk space.
Due to refactoring, the resulting ctest names are a bit different than
before. The number of tests is also a bit different depending if this
option is used, as one uses gtests discovery and the other is organized
purely by filename, which isn't always 1:1.
Co-authored-by: Sergey Sharybin <sergey@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/114604
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
New functionality to export armatures and shape keys as USD
skeletons and blend shapes.
Added "Armature", "Only Deform Bones" and "Shape Key" USD export options.
Added USDArmatureWriter class.
Extended USDMeshWriter to write skinned meshes for binding
with skeletons and 'neutral' meshes with blend shape targets.
Specifically, when exporting an armature, a skinned mesh is written
in its pre-modified rest position. When exporting to blend shapes,
a mesh with shape keys is saved with its vertices in the shape key
basis shape position.
Added USDHierarchyIterator::process_usd_skel() function to
finish processing skeleton and blend shape export after the
writer instances completed writing. This is necessary because
some of the export operations require processing multiple prims
at once.
Extended USDTransformWriter::do_write() to write transforms
sparsely, to avoid saving redundant transform values when exporting
armatures.
Added a create_skel_roots() function, called on the stage at the
end of the export. This function attempts to ensure that skinned
prims and skeletons are encapsulated under SkelRoot primitives,
which is required in USD for correct skinning behavior.
When exporting blend shape animations for multiple meshes bound
to a single skeleton, we need to merge the blend shape time samples
of the different meshes into a single animation primitive at the end
of the export. This requires some tricky book keeping, where the weight
time samples for a given mesh are initially saved by the mesh writer to a
temporary attribute on the mesh and are later copied to the animation
primitive as one of the final steps.
When writing blend shapes and skinned meshes, the pre-modified mesh
is exported. This is to ensure that the number of blend shape offsets
matches the number of points, and so that the skinned mesh is saved in
its rest position.
Because the pre-modified mesh must be exported, modifiers in addition
to Armature modifiers will not be applied. This still allows the round trip
UsdSkel -> Blender -> UsdSkel, but some additional setup might be
required to export to UsdSkel when there are multiple modifiers (for
example, applying mirroring modifiers that precede the armature
modifier).
Exporting bendy bones or absolute shape keys isn't currently
supported.
Co-authored-by: Charles Wardlaw <charleswardlaw@noreply.localhost>
Pull Request: https://projects.blender.org/blender/blender/pulls/111931
