| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
The U-resolution of the imported curves was kept at the default value
of 12, which is way too high for imported hair. We export hair at a
fairly high resolution already, so it's not needed to subdivide even
further when importing.
Of course this may have an impact on other curves that do require this
U-resolution to be higher. In that case the resolution can be
increased after importing.
I removed the default nu->orderu = num_verts, as that allowed every
point to influence the entire spline, which was more expensive for the
CPU, and unlikely to be needed. The orderu computations had off-by-one
errors in the curve importer, which are now also fixed. The correct
values are:
- Linear: orderu = 2
- Quadratic: orderu = 3
- Cubic: orderu = 4
These values are also what is stored in the Alembic file for curves of
type kVariableOrder, according to the reference Maya exporter
maya/AbcExport/MayaNurbsCurveWriter.cpp, function
MayaNurbsCurveWriter::write(), in the Alembic source code.
The result is a frame rate increase of roughly 100x (tested with one
100-hair test on one machine, so take with grain of salt).
|
|
|
|
This supports our common character animation workflow, where a character,
its rig, and the custom bone shapes are all part of a group. This group
is then linked into the scene, the rig is proxified and animated. Such
a group can now be exported. Use "Renderable objects only" to prevent
writing the custom bone shapes to the Alembic file.
|
|
static_cast<int> truncates, so a computed end frame of 99.999999999998
would result in 99, instead of the correct 100.
|
|
Previously only a CD_MLOOPUV custom data layer was created. Now we also
create the accompanying CD_MTEXPOLY layer too.
|
|
This exports all objects in world coordinates without parenting.
|
|
The exploreTransform() function already does this check, and the check
isn't necessary when the object type isn't exported anyway.
|
|
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.
|
|
|
|
and more:
Also replaced the bool param "to_yup" with "AbcAxisSwapMode mode", so that
it's more explicit that axes are swapped.
Also added unittests for create_swapped_rotation_matrix.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
Checking precise values of floats is not a good idea.
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
create_transform_matrix(float[4][4]) did mostly the same as
create_transform_matrix(Object *, float[4][4]), but more elegant.
However, the former has some inconsistencies with the latter (which
are now merged and made explicit, turned out one was for z-up→y-up
while the other was for y-up→z-up), and was renamed to
copy_m44_axis_swap(...) to convey its purpose more clearly.
Furthermore, "loc" has been renamed to "trans", as matrices don't
store locations but translations; and more variables now have a src_
or dst_ prefix to denote whether they contain a matrix/vector in the
source or destination axis orientation.
|
|
|
|
This allows in-place conversion between z-up and y-up, by passing the
same variable to both arguments.
|
|
Before this commit something strange happened, as the m_data_name of
an inherit data-less object was used.
|
|
|
|
|
|
|
|
|
|
AbcExporter::createTransformWriter() tries to predict the parent Xform
name, but if it cannot be found has multiple ways of creating it, possibly
under a different name than originally searched for.
|
|
It was set, but never read anywhere.
|
