This reverts a part of rBd3960164163c910d5031a8f076c41b39e0a5503d.
It is not a `std::shared_ptr` but a `boost::shared_ptr`.
This could probably be fixed differently, but `NOLINT` is fine now.
Remove DNA headers, using forward declarations where possible.
Also removed duplicate header, header including it's self
and unnecessary inclusion of libc system headers from BKE header.
Write custom properties (aka ID properties) to Alembic, to the
`.userProperties` compound property.
Manifest Task: https://developer.blender.org/T50725
Scalar properties (so single-value/non-array properties) are written as
single-element array properties to Alembic. This is also what's done by
Houdini and Maya exporters, so it seems to be the standard way of doing
things. It also simplifies the implementation.
Two-dimensional arrays are flattened by concatenating all the numbers
into a single array. This is because ID properties have a limited type
system. This means that a 3x3 "matrix" could just as well be a list of
three 3D vectors.
Alembic has two container properties to store custom data:
- `.userProperties`, which is meant for properties that aren't
necessarily understood by other software packages, and
- `.arbGeomParams`, which can contain the same kind of data as
`.userProperties`, but can also specify that these vary per face of a
mesh. This property is mostly intended for renderers.
Most industry packages write their custom data to `.arbGeomParams`.
However, given their goals I feel that `.userProperties` is the more
appropriate one for Blender's ID Properties.
The code is a bit more involved than I would have liked. An
`ABCAbstractWriter` has a `uniqueptr` to its `CustomPropertiesExporter`,
but the `CustomPropertiesExporter` also has a pointer back to its owning
`ABCAbstractWriter`. It's the latter pointer that I'm not too happy
with, but it has a reason. Getting the aforementioned `.userProperties`
from the Alembic library will automatically create it if it doesn't
exist already. If it's not used to actually add custom properties to, it
will crash the Alembic CLI tools (and maybe others too). This is what
the pointer back to the `ABCAbstractWriter` is used for: to get the
`.userProperties` at the last moment, when it's 100% sure at least one
custom property will be written.
Differential Revision: https://developer.blender.org/D8869
Reviewed by: sergey, dbystedt
Add support for object data instancing. This is used when the objects
are instances, for example when duplicated by a particle system, or
instanced by the duplication system (collection-duplicating empties,
vertex/face duplis, etc.)
Since Alembic already deduplicates data, this doesn't make the resulting
Alembic files any smaller. They will be faster to write, though, when
there is a lot of instanced geometry, as the deduplication system won't
have to do any comparisons.
This instancing support is still limited, in the sense that only object
data is instanced and all transforms are still written explicitly. A
future improvement could be to support instancing entire collection
hierarchies.
Blender's Alembic importer has no understanding of these Alembic
instances yet, and will thus happily duplicate the data on import.
The USD Alembic plugin seems to have problems understanding the
instancing. There might also be other software with similar issues.
Because of this, instancing can be turned off in the exporter (it's on
by default).
Split `ABCHierarchyIterator::get_alembic_parent()` into two functions:
- For a given export path, find the Alembic object
- Ensure that that object is usable as parent object (Alembic uses a
specific 'top' object as parent to indicate "no parent").
The new function is `public` as it will be used in an upcoming feature,
and is required to be public then.
No functional changes.
Split the `ABCHierarchyIterator::create_data_writer()` function into two
functions. This is to prepare for the creation of writers not just by
object type, but also by goal, for example writers that reference other
Alembic data instead of writing their own (i.e. instancing).
No functional changes.
Add a new depsgraph builder class that includes invisible objects and
use that in the Alembic exporter.
Alembic supports three options for visibility, "visible", "inherited",
and "hidden". This means that parents can be hidden and still have
visible children (contrary to USD, where invisibility is used to prune
an entire scene graph subtree). Because of this, the visibility is
stored on the transform node, as that represents the Object in Blender
and thus keeps the Alembic file as close to Blender's own structure as
possible.
Reviewed By: Sergey
Differential Revision: https://developer.blender.org/D8595
The root cause was that `BKE_object_moves_in_time()` incorrectly returns
`false` when an object is moved by the physics system.
This also fixes the same issue in the USD exporter.
The function is called for all writers, not just 'object' writers.
Furthermore, it's called by the function `release_writers()`, so now the
name is consistent with that as well.
No functional changes.
Exporting a scene to USD or Alembic would fail when there are multiple
duplicates of parent & child objects, duplicated by the same object. For
example, this happens when such a hierarchy of objects is contained in a
collection, and that collection is instanced multiple times by mesh
vertices. The problem here is that the 'parent' pointer of each
duplicated object points to the real parent; Blender would not figure
out properly which duplicated parent should be used.
This is now resolved by keeping track of the persistent ID of each
duplicated instance, which makes it possible to reconstruct the
parent-child relations of duplicated objects. This does use up some
memory for each dupli, so it could be heavy to export a Spring scene
(with all the pebbles and leaves), but it's only a small addition on top
of the USD/Alembic writer objects that have to be created anyway. At
least with this patch, they're created correctly.
Code-wise, the following changes are made:
- The export graph (that maps export parent to its export children) used
to have as its key (Object, Duplicator). This is insufficient to
correctly distinguish between multiple duplis of the same object by
the same duplicator, so this is now extended to (Object, Duplicator,
Persistent ID). To make this possible, new classes `ObjectIdentifier`
and `PersistentID` are introduced.
- Finding the parent of a duplicated object is done via its persistent
ID. In Python notation, the code first tries to find the parent
instance where `child_persistent_id[1:] == parent_persistent_id[1:]`.
If that fails, the dupli with persistent ID `child_persistent_id[1:]`
is used as parent.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D8233
The Alembic exporter has been restructured by leverages the
`AbstractHierarchyIterator` introduced by the USD exporter. The produced
Alembic files have not changed much (details below), as the Alembic
writing code has simply been moved from the old exporter to the new. How
the export hierarchy is handled changed a lot, though, and also the way
in which transforms are computed. As a result, T71395 is fixed.
Differences between the old and new exporter, in terms of the produced
Alembic file:
- Duplicated objects now have a unique numerical suffix.
- Matrices are computed differently, namely by simply computing the
evaluated transform of the object relative to the evaluated transform
of its export-parent. This fixes {T71395}, but otherwise should
produce the same result as before (but with simpler code).
Compared to the old Alembic exporter, Subdivision modifiers are now
disabled in a cleaner, more efficient way (they are disabled when
exporting with the "Apply Subdivisions" option is unchecked). Previously
the exporter would move to a new frame, disable the modifier, evaluate
the object, and enable the modifier again. This is now done before
exporting starts, and modifiers are only restored when exporting ends.
Some issues with the old Alembic exporter that have NOT been fixed in
this patch:
- Exporting NURBS patches and curves (see T49114 for example).
- Exporting flattened hierarchy in combination with dupli-objects. This
seems to be broken in the old Alembic exporter as well, but nobody
reported this yet.
Differential Revision: https://developer.blender.org/D7664
Reviewed By: Sergey
This commit only moves code into the `blender::io::alembic` namespace,
it does not move `static` functions into an anonymous namespace.
No functional changes.
This moves most of the exporter-related code
from `source/blender/io/alembic/intern`
to `source/blender/io/alembic/exporter`
This is to prepare the Alembic code for the switchover to using
`blender::io::AbstractHierarchyIterator`. When that happens, a few more
files will be added, and having things in a separate 'exporter'
directory makes things less cluttered.
Note that exporting consists of multiple steps (determine export
hierarchy, create Alembic archive, and then write data into it), which
is why the directory is called "exporter", but many of the files are
called "writer".
No functional changes.
