Age | Commit message (Collapse) | Author |
|
bf_alembic depends on bf_bmesh, and should therefore be above it.
|
|
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.
|
|
Seems CMake is not happy about changing compiler from script.
|
|
|
|
Rename 'stats_*' to 'protectflag_to_drawflags_*' (was too vague).
Also remove NULL check from gimbal_axis
|
|
Match stats_editbone & stats_pchan behavior to avoid confusion.
|
|
|
|
|
|
|
|
|
|
|
|
Mainly visible for MSVC debug builds and gives about 2x speedup.
|
|
As requested by @sergey.
|
|
The idea is to have a system where we properly log error messages and
let the users know that errors occured redirecting them to the console
for explanations. This is only implemented for the exporter since the
importer already has similar functionalities; however they shall
ultimately be unified in some way.
Reviewers: sybren, dfelinto
Differential Revision: https://developer.blender.org/D2541
|
|
|
|
Odd that issue was never reached before? Looks like it hit in
datablock_idprops branch though...
|
|
This avoids write access happening in non-atomic manner in
Shader::tag_update which modifies the global managers. Even
for 1 byte data types it's quite dangerous.
|
|
|
|
The issue is coming from the fact that float3 is actually 16 bytes aligned
data type and the "padding" was not initialized. This caused memcmp() to
access non-initialized memory.
|