Commit Graph

7 Commits

Author SHA1 Message Date
269c184ac9 Cleanup: IO, renamed delete_object_writer()release_writer()
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.
2020-07-21 14:10:42 +02:00
70b1c09d7a IO: Fix bug exporting dupli parent/child relations
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
2020-07-07 13:01:07 +02:00
2917df21ad Alembic: new exporter based on the USD exporter structure
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
2020-06-30 11:38:46 +02:00
3ceb9faf1a Cleanup: IO, made some functions in AbstractHierarchyIterator protected
These functions are not needed in the public interface, only by the
`AbstractHierarchyIterator` class and its subclasses.

No functional changes.
2020-06-19 16:43:27 +02:00
0ae7883d7d IO: ensure export path and export name are always consistent
Before this, there was one code path that set `context.export_path`, and
a different code path for `context.export_name`, allowing the two to
diverge.

Keeping track of the export path of the export parent (which can be, but
is not always, the Blender parent object) also allows a concrete
subclass of `AbstractHierarchyIterator` to find the `AbstractWriter` for
the export parent. In case of exporting to Alembic this is important, as
it's not possible to simply give the Alembic library the full export
path of an object like we do in the Universal Scene Description (USD)
exporter; Alembic needs the C++ object of the parent.
2020-06-19 10:17:41 +02:00
69c3d9804f IO: Allow exporting a subset of the writers
This is in order to prepare for compatibility with the Alembic exporter.
That exporter is capable of writing object transforms and object data at
different (sub)frames.

The rename from `created_writers` to `used_writers` is necessary, as not
all created writers will be actually used in each iteration.

The Universal Scene Description (USD) exporter does not make use of
this.

Reviewed By: mont29

Differential Revision: https://developer.blender.org/D7670
2020-06-19 10:17:41 +02:00
084c5d6c7e IO: Move Abstract Hierarchy Iterator into io/common
The goal of the `AbstractHierarchyIterator` class (and supporting
classes) was to use it in different exporters. It shouldn't be part of
the USD module + namespace any more, now that it will also be used in
the upcoming Alembic exporter rewrite.

The source files are moved into `io/common`, which is compiled & linked
into a new library `bf_io_common`. The unittests are still inside the
`tests/gtests/usd` directory. They should be moved to a separate test
module too, but that will be delayed until after T73268 has been
resolved.

Reviewed By: mont29

Differential Revision: https://developer.blender.org/D7669
2020-06-19 10:17:41 +02:00