Each duplicated (a.k.a. instanced) object has a Persistent ID, which
identifies a dupli within the context of its duplicator. This ID
consists of several numbers when there are nested duplis (for example a
mesh instancing empties on its vertices, where each empty instances a
collection). When exporting to Alembic/USD, these are used to uniquely
name the duplicated objects in the export.
This commit reverses the order of the persistent ID numbers, so that the
first number identifies the first level of recursion. This produces
trees like this:
ABC
`--Triangle
|--Triangle
|--Empty-1
| `--Pole-1-0
| |--Pole
| `--Block-1-1
| `--Block
|--Empty
| `--Pole-0
| |--Pole
| `--Block-1
| `--Block
|--Empty-2
| `--Pole-2-0
| |--Pole
| `--Block-2-1
| `--Block
`--Empty-0
`--Pole-0-0
|--Pole
`--Block-0-1
`--Block
It is now clearer that `Pole-2-0` and `Block-2-1` are instanced by
`Empty-2`. Before this commit, they would have been named `Pole-0-2` and
`Block-1-2`.
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
This is just a change in `AbstractHierarchyIterator::debug_print_export_graph()`
to aid in debugging. It'll make it possible to distinguish between
different duplicates of the same object.
No functional changes to Blender itself.
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
Thanks @mont29 for this patch.
This creates an explicit undo step after the Alembic importer has finished
running. This is necessary when the importer runs as a background job.
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.
The important distinction for the linker flags is not between GCC and Clang,
but between the macOS and Linux.
Differential Revision: https://developer.blender.org/D8023
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.
Blender now always exports transforms as as "inheriting", as Blender has
no concept of parenting without inheriting the transform.
Previously only objects with an actual parent were marked as
"inheriting", and parentless objects as "non-inheriting". However,
certain packages (for example USD's Alembic plugin) are incompatible
with non-inheriting transforms and will completely ignore such
transforms, placing all such objects at the world origin.
When importing non-inheriting transforms from Alembic, Blender will
break the parent-child relation and thus force the child to (correctly)
interpret the transform as world matrix.
Other types already had spaces, periods, and colons replaced by
underscores. The upcoming Alembic exporter (based on the
`AbstractHierarcyIterator` class) will be more consistent and apply the
same naming rules everywhere. This is in preparation for that change.
The `get_…_name()` functions in `abc_util.{cc,h}` will be removed then.
Previously the Alembic exporter exported a mesh object to
`{object.name}/{object.name}Shape`. Now it exports to
`{object.name}/{mesh.name}` instead. The same change also applies to
other object data types.
Note that the code now is a bit hackish, as `m_name` is set even in
cases where it isn't used. This hackishness was already there, though,
but it's now just more visible. This will all be cleaned up when the
Alembic exporter is ported to use the `AbstractHierarchyImporter`
structure of the Universal Scene Description (USD) exporter.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D7672
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.
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
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
Using enum type itself in implementations, and uint in headers (as using
enums types in headers is a pain when enum are not defined and used in a
single same header file...).
Alembic is not a single file format, it can be stored in two different
ways: Ogawa and HDF5. Ogawa replaced HDF5 and is smaller and much faster
(4-25x) to read ([source](http://exocortex.com/blog/alembic_is_about_to_get_really_fast)).
As long as Blender has had Alembic support, it has never supported the
HDF5 format in any release. There is a build option `WITH_ALEMBIC_HDF5`
that can be used to enable HDF5 support in your own build. This commit
removes this build option and the code that it manages.
In the years that I have been maintainer of Blender's Alembic code, I
only remember getting a request to support HDF5 once, and that was to
support very old software that has likely since then been updated to
support Ogawa. Ubuntu and Fedora also seem to bundle Blender without
HDF5 support.
This decision was discussed on
[DevTalk](https://devtalk.blender.org/t/alembic-hdf5-support-completely-remove)
where someone also mentioned that there is a tool available that can
convert HDF5 files to the Ogawa format.
- BKE_lattice_deform_data_create was init_latt_deform.
- BKE_lattice_deform_data_destroy was end_latt_deform.
- BKE_lattice_deform_data_eval_co was calc_latt_deform.
The material binding API that we used was removed in the Universal Scene
Description library version 20.02. Using this new API, the code is
compatible with both USD 19.11 and 20.02.
- ED_object_constraint_list_from_constraint was get_constraint_lb
- ED_object_constraint_list_from_context was get_active_constraints
- ED_object_constraint_active_get was get_active_constraint
- ED_object_constraint_active_set was ED_object_constraint_set_active
The file subversion is no longer used in the Python API or user interface,
and is now internal to Blender.
User interface, Python API and file I/O metadata now use more consistent
formatting for version numbers. Official releases use "2.83.0", "2.83.1",
and releases under development use "2.90.0 Alpha", "2.90.0 Beta".
Some Python add-ons may need to lower the Blender version in bl_info to
(2, 83, 0) or (2, 90, 0) if they used a subversion number higher than 0.
https://wiki.blender.org/wiki/Reference/Release_Notes/2.83/Python_API#Compatibility
This change is in preparation of LTS releases, and also brings us more
in line with semantic versioning.
Fixes T76058.
Differential Revision: https://developer.blender.org/D7748
This was caused by a side-effect of our exporting code's memory
management (Alembic considers data "written" and "final" when its C++
objects go out of scope) in combination with my change in
rB65574463fa2d. I removed an "only export UVs on the first frame" clause
because it was unclear why this restriction was there. As it turns out,
it breaks the export of the 2nd and subsequent UV maps on an animated
mesh. Effectively, on every frame the Alembic library thought we want to
create a new UV map, instead of continuing to write a new frame of data
to the existing one.
This is resolved by keeping a reference to the C++ objects for the UV
maps in memory while the exporter is running.
It is not impossible that the number of knots is stored wrong in the
file (for example, it will be 1 knot only).
This change fixes bad memory allocation and bad memory access in such
cases. It also fixes strict compiler warning which was mentioning that
the allocation size is wrong),
There isn't really the correct way of dealing with such situation, so
simply fall back to Blender's knots calculation.
Differential Revision: https://developer.blender.org/D7765
