Modernize loops by using the `for(type variable : container)` syntax.
Some loops were trivial to fix, whereas others required more attention
to avoid semantic changes. I couldn't address all old-style loops, so
this commit doesn't enable the `modernize-loop-convert` rule.
Although Clang-Tidy's auto-fixer prefers to use `auto` for the loop
variable declaration, I made as many declarations as possible explicit.
To me this increases local readability, as you don't need to fully
understand the container in order to understand the loop variable type.
No functional changes.
Refactor material assignment code such that:
- `build_mat_map()` just returns the built map (instead of relying on
modifying a map passed as parameter),
- `LISTBASE_FOREACH` is used to loop over a `ListBase` (instead of a
hand-crafted for-loop),
- just `return` when not enough material slots can be created (instead
of setting a boolean to false, then doing some useless work, then
checking the boolean),
- reorder some code for clarity, and
- rename `mat_map` to `matname_to_material` so that the semantics are
clearer.
No functional changes.
colors
If the mesh was constant, no check was done if there were animated
vertex colors and thus creation of a MeshSequenceCache modifier was
skipped.
Thx @sybren for feedback!
Maniphest Tasks: T81330
Differential Revision: https://developer.blender.org/D9057
Add an option to disable Alembic vertex interpolation.
Bump subversion from 5 to 6.
Alembic stores mesh samples at specific time keys; when a frame in
Blender maps to a timecode between two samples, Blender will interpolate
the mesh vertex positions. This interpolation only happens when the mesh
has a constant topology, but sometimes this was not detected properly
when the vertices change order, but the number of mesh elements remains
the same. This would result in a mesh with jumbled up vertices (T71981).
With this patch, users have the ability to disable vertex interpolation.
An alternative would be to have better detection of topology changes,
but that that'll cause a considerable slowdown.
Maniphest Tasks: T71981
Differential Revision: https://developer.blender.org/D9041
Compare mesh loop count with number of loop normals before reading the
loop normals.
Houdini doesn't always write the correct loop normals to Alembic. When a
mesh is animated and then replaced by a fluid simulation, Houdini will
still write the original mesh's loop normals, but the mesh
verts/loops/polys are from the simulation. In such cases the normals
cannot be mapped to the mesh, so it's better to ignore them.
The `ABC_INLINE` macro has been in the Alembic code since it was introduced
to Blender in rB61050f75b13e. It basically does the same a `BLI_INLINE`,
though, so there is no need to keep it around.
This commit only moves code into the `blender::io::alembic` namespace,
it does not move `static` functions into an anonymous namespace.
No functional changes.
In the Alembic importer, the animation of UVs and normals was
overlooked; when the mesh geometry is not animated, the entire mesh was
considered constant.
T76132 concerns both the exporting and importing of changing UVs. This
commit fixes the importing.
Even though {T76514} is caused by invalid geometry, and thus technically
constitutes a bug in the software that created the Alembic file, I would
like Blender not to crash on importing such a file.
The error in the Alembic file consists of invalid mesh loops, where
consecutive loops refer to the same vertex. The `BKE_mesh_validate()`
can actually correct these errors, so this commit focuses on two things:
- Letting Blender survive the situation until the mesh is loaded, and
- Detecting the error so that `BKE_mesh_validate()` can be called only
when necessary. This ensures there is only a minimal impact on
performance when loading actually valid data.
Differential Revision: https://developer.blender.org/D7703
Reviewed By: JacquesLucke
Surrounding includes with an 'extern "C"' block is not necessary anymore.
Also that made it harder to add any C++ code to some headers, or include headers
that have "optional" C++ code like `MEM_guardedalloc.h`.
I tested compilation on linux and windows (and got help from @LazyDodo).
If this still breaks compilation due to some linker error, the header containing
the symbol in question is probably missing an 'extern "C"' block.
Differential Revision: https://developer.blender.org/D7653
The long-term goal is to move code out of `abc_util.{h,cc}` into either
files with better, more concrete names, or simply into the one file
where they are used.
No functional changes.
I've added a very minimal mesh validation before the Alembic mesh is actually
converted to a Blender mesh. This prevents a specific crash with an example
file attached to T74200.
This moves the `alembic`, `avi`, `collada`, and `usd` modules into a common
`io` directory.
This also cleans up some `#include "../../{somedir}/{somefile}.h"` by
adding `../../io/{somedir}` to `CMakeLists.txt` and then just using
`#include "{somefile}.h"`.
No functional changes.
