This fixes the glitching hairs described in T56408, T63534, and possibly
also T63534.
The fix consists of returning the original mesh (i.e. as visible in edit
mode) when constructing the ORCO mesh. This allows a static set of
coordinates to be used when computing the child hair positions.
The original mesh is only returned when it has the same topology (at
least same number of vertices, loops, and polys. It's up the author of
the Alembic file to ensure stable geometry when it's desired to be
compatible with Blender's hair system.
Reviewers: mont29, brecht
Differential Revision: https://developer.blender.org/D5492
Meshroom writes two hierarchies to Alembic, one rooted at
`/mvgRoot/mvgCameras` and the other at `/mvgRoot/mvgCamerasUndefined`.
These paths have no schema definition, and thus are ignored by Blender.
The cameras themselves have those schemaless paths as parent, and have
their transforms marked as "inherited", e.g. relative to their parent.
As these cameras have no valid parent, there is no Blender object to use
to convert their local matrices to world matrices, and Blender just
decided to reset them to the unit matrix.
Now "inherited" transforms without a parent in Blender are interpreted
as world transforms. Reparenting those objects to a Blender object will
re-interpret the transforms as local to the parent again.
The w-component of the translation column of the scaled matrix wasn't
set to 1.0, which, apart from being incorrect, caused drawing problems.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5290
* The cache file datablock is now evaluated as part of the dependency graph,
creating/freeing the Alembic file handle matching the current frame.
Modifiers and constraints depend on this evaluation.
* Cache file handles and readers now only exist on COW datablocks, never the
original ones.
* Object data paths are flushed back to the original for the user interface.
* The cache file keeps a list of all readers associated with its handle, and
automatically frees them when the handle is freed. This kind of sharing of
data across datablocks is weak but we have no better mechanism for it.
Fix T62720: Alembic sequences not working and crashing
Differential Revision: https://developer.blender.org/D4774
The Alembic importer can now deal with XForm-less objects. Apparently
MeshLab exports point clouds without parent transformation matrix (XForm in
Alembic-speak). We shouldn't warn about this, but handle it properly
instead.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
The depsgraph was always created within a fixed evaluation context. Passing
both risks the depsgraph and evaluation context not matching, and it
complicates the Python API where we'd have to expose both which is not so
easy to understand.
This also removes the global evaluation context in main, which assumed there
to be a single active scene and view layer.
Differential Revision: https://developer.blender.org/D3152
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
No longer passing time as float and constructing ISampleSelectors all
over the place. Instead, just construct an ISampleSelector once and
pass it along.
Previously, a GHash was used to store a flattened mapping of parent
information based on the Alembic hierarchy, and then that hash was used to
set parent pointers on Blender objects. This resulted in errors and
some duplicate objects. The new approach stores parent pointers while
traversing the Alembic hierarchy, which means that there is much more
information about the actual context of the Alembic object itself,
producing a more stable import.
There was a problem with parent-child relations not getting set up
correctly when an Alembic object was both the transform for a mesh object
and the parent of other mesh objects.
convert_matrix() now only converts from Imath::M44d to float[4][4] (taking
different camera orientations into account). Import-time scaling is now
performed by the caller.
Also renamed AbcObjectReader::readObjectMatrix to
setupObjectTransform, as it does more than just reading the object
matrix; it also sets up an object constraint if the Alembic Xform is
animated.
The idea is to have a system where we properly log error messages and
let the users know that errors occured redirecting them to the console
for explanations. This is only implemented for the exporter since the
importer already has similar functionalities; however they shall
ultimately be unified in some way.
Reviewers: sybren, dfelinto
Differential Revision: https://developer.blender.org/D2541
Most of them are harmless implicit conversions (e.g. Alembic deals with
doubles for storing time information when Blender uses both ints and
floats/doubles) or class/struct mismatch on forward declarations.
constraints.
This avoids traversing the archive everytime object data is needed and
gives an overall consistent ~2x speedup here with files containing
between 136 and 500 Alembic objects. Also this somewhat nicely de-
duplicates code between data creation (upon import) and data streaming
(modifiers and constraints).
The only worying part is what happens when a CacheFile is deleted and/or
has its path changed. For now, we traverse the whole scene and for each
object using the CacheFile we free the pointer and NULL-ify it (see
BKE_cachefile_clean), but at some point this should be re-considered and
make use of the dependency graph.
All in all, this patch adds an Alembic importer, an Alembic exporter,
and a new CacheFile data block which, for now, wraps around an Alembic
archive. This data block is made available through a new modifier ("Mesh
Sequence Cache") as well as a new constraint ("Transform Cache") to
somewhat properly support respectively geometric and transformation data
streaming from alembic caches.
A more in-depth documentation is to be found on the wiki, as well as a
guide to compile alembic: https://wiki.blender.org/index.php/
User:Kevindietrich/AlembicBasicIo.
Many thanks to everyone involved in this little project, and huge shout
out to "cgstrive" for the thorough testings with Maya, 3ds Max, Houdini
and Realflow as well as @fjuhec, @jensverwiebe and @jasperge for the
custom builds and compile fixes.
Reviewers: sergey, campbellbarton, mont29
Reviewed By: sergey, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D2060