| Age | Commit message (Collapse) | Author |
|---|
|
This separation between reader and writer code is part of Milesone 2 of
T73363.
In this commit the reader and writer classes are separated into their
own files, any `#include` and `using` statements are cleaned up, and
some separator comments have been removed.
No functional changes.
|
|
The `convert_matrix()` function just converts between the Alembic and
Blender matrix data types, and doesn't do any coordinate system conversion.
To clarify this, the function has now been renamed to
`convert_matrix_datatype()`.
I also moved the implementations next to each other in the source file,
so that it's visible that there are actually two of them.
No functional changes.
|
|
The Alembic importer now works with local coordinates. Previously, the
importer converted transformations from Alembic to world coordinates
before processing them further; this processing often included
re-converting to local coordinates. This change made it possible to
remove some code that assumed that a child transform was only read after
its parent transform.
Blender's Alembic code follows the Maya convention, where in the zero
orientation the camera looks forward instead of down. This extra
rotation is now handled more consistently, and now also properly handles
children of cameras. This fixes T73269.
Unit tests were added to at least ensure that the importer and exporter
are compatible with each other, and that static and animated camera
transforms are handled in the same way.
|
|
Note that `BKE_library.h`/`library.c` were renamed to
`BKE_lib_id.h`/`lib_id.c` to avoid having a too generic name here.
Part of T72604.
|
|
When the result isn't used, prefer post increment/decrement
(already used nearly everywhere in Blender).
|
|
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
|
|
Leave the reader to be created on the CoW object in the depsgraph evaluation,
don't assign the one used for importing to the original object.
|
|
* 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
|
|
Similar to what is done e.g. in AbcMeshReader::read_mesh()...
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
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.
|
|
|
|
|
|
Also remove doxy comments for licenses and add missing GPL header.
|
|
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.
|
|
Those can now solely be found in the ExportSettings object.
|
|
|
|
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.
|
|
|
|
Alembic's "inherits transform" flag wasn't taken into account when
constructing the parent object relations.
|
|
|
|
|
|
# Conflicts:
# source/blender/alembic/intern/abc_exporter.cc
|
|
Duplicating an imported object didn't increment the cache reader's refcount,
whereas removing the duplicate did decrement it. This caused problems.
|
|
|
|
This reverts commit 099816587a0e064fb6a52c82a737ae8814cf21df. It had some
unforseen side-effects that should be investigated first.
|
|
|
|
No longer passing time as float and constructing ISampleSelectors all
over the place. Instead, just construct an ISampleSelector once and
pass it along.
|
|
# Conflicts:
# source/blender/alembic/intern/abc_exporter.h
# source/blender/alembic/intern/abc_util.cc
|
|
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.
|
|
|
|
|
|
matrix
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.
|
|
object
Also added a bit better error reporting, instead of silently ignoring
invalid Alembic data.
|
|
|
|
|
|
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
|
|
By performing the Z-up to Y-up conversion, the change in sign of the
Z-coordinate swaps "minimum" and "maximum".
|
|
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.
|
|
frames.
|
|
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
|
