| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Alembic's "inherits transform" flag wasn't taken into account when
constructing the parent object relations.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It's now less confusing (for example, using nr_of_samples directly,
instead of using 1 / 1 / nr_of_samples). Might also have fixed a bug.
Also added unittests.
|
|
|
|
|
|
This is easier to extend than the if/else if/else chain that was in place,
and allows for somewhat more granular error messages.
|
|
|
|
# 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.
|
|
|
|
|
|
HDF5 Alembic files are not officially supported by Blender. With this
commit, the HDF5 format is detected even when Blender is compiled without
HDF5 support, and the user is given an explanatory error message (rather
than the generic "Could not open Alembic archive for reading".
|
|
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.
|
|
|
|
When the Alembic import is finished, all imported objects are selected.
|
|
The import is always performed on the active LayerCollection. If there
is none, a new one is created.
|
|
# Conflicts:
# source/blender/alembic/intern/abc_exporter.cc
# source/blender/alembic/intern/abc_exporter.h
|
|
The ABC_export and ABC_import functions both take a as_background_job
parameter, and return a boolean.
When as_background_job=true, returns false immediately after scheduling
a background job. This was the old behaviour of this function, which makes
it very hard for scripts to do something with the data after the import
or export completes.
When as_background_job=false, performs the export synchronously, and
returns true when the export was ok, and false if there were any errors.
This allows further processing.
The Scene.alembic_export() function is deprecated, and will be removed from
Blender 2.8 in favour of calling the bpy.ops.wm.alembic_export() operator.
As such, it has been hard-coded to the old background job behaviour.
|
|
The export is still slower than needed, as the particle systems themselves
aren't disabled during the export. It's only the writing to the Alembic
file that's skipped.
|
|
Conflicts:
source/blender/alembic/intern/abc_exporter.cc
|
|
static_cast<int> truncates, so a computed end frame of 99.999999999998
would result in 99, instead of the correct 100.
|
|
# Conflicts:
# source/blender/alembic/intern/abc_exporter.h
# source/blender/alembic/intern/abc_util.cc
|
|
It's possible that cancellation occured between the creation of the reader
and the creation of the Blender object, in which case reader->object()
returns a NULL pointer.
|
|
BKE_libblock_free_us() was called on the object data, which decrements
its user count, after which the same function was called on the object,
which decrements the user count of the object data again. This double
decrement was too much.
|
|
This was necessary, but was only mentioned at gather_object_paths (which
I didn't see earlier). That's now also fixed.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
Alembic is an interchange and caching format, that can contain custom
object schemas. Blender shouldn't crash (because of failing asserts) just
because it doesn't know such an object type.
|
|
|
|
It's a mapping from full path of an Alembic object to an AbcObjectReader*.
The fact that at some point it is used to construct parent-child relations
doesn't matter.
|
|
The importer was guessing whether an Alembic IXform object was part of a
child object, or should be represented as an Empty in Blender. By reversing
the order in which objects are visited, the children can now claim their
parent as part of the same object (so IPolyMesh claims its parent IXform
as part of the same Blender object). This results in much less guesswork.
I've also removed similar guesswork from the code that sets parent pointers,
by simply searching for the parent in a hierarchical way, instead of trying
to predict (again) which IXforms were turned into empties.
Also, visit_object() now actually visits the object -- previously it only
visited its children, and assumed the object it was called on was already
handled by a previous call.
|
|
|
|
These bits became obsolete with the new layer system, so we can
simplify some code around them or avoid existing workarounds which
were trying to keep things working for them.
There are still work needed to be done for on_visible_change to
avoid unnecessary updates, but that can also happen later.
|
|
Conflicts:
source/blender/alembic/intern/abc_exporter.h
|
