Corrects incorrect usages of the word 'loose' when 'lose' was required.
Differential Revision: https://developer.blender.org/D9243
Reviewed by Campbell Barton
Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
Note that possibility to pass the new ID pointer as parameter was kept,
as this is needed for some rather specific cases (like in depsgraph/COW,
when copying into already allocated memory).
Part of T71219.
colors
If the mesh was constant, no check was done if there were animated
vertex colors and thus creation of a MeshSequenceCache modifier was
skipped.
Thx @sybren for feedback!
Maniphest Tasks: T81330
Differential Revision: https://developer.blender.org/D9057
Add an option to disable Alembic vertex interpolation.
Bump subversion from 5 to 6.
Alembic stores mesh samples at specific time keys; when a frame in
Blender maps to a timecode between two samples, Blender will interpolate
the mesh vertex positions. This interpolation only happens when the mesh
has a constant topology, but sometimes this was not detected properly
when the vertices change order, but the number of mesh elements remains
the same. This would result in a mesh with jumbled up vertices (T71981).
With this patch, users have the ability to disable vertex interpolation.
An alternative would be to have better detection of topology changes,
but that that'll cause a considerable slowdown.
Maniphest Tasks: T71981
Differential Revision: https://developer.blender.org/D9041
Compare mesh loop count with number of loop normals before reading the
loop normals.
Houdini doesn't always write the correct loop normals to Alembic. When a
mesh is animated and then replaced by a fluid simulation, Houdini will
still write the original mesh's loop normals, but the mesh
verts/loops/polys are from the simulation. In such cases the normals
cannot be mapped to the mesh, so it's better to ignore them.
Write custom properties (aka ID properties) to Alembic, to the
`.userProperties` compound property.
Manifest Task: https://developer.blender.org/T50725
Scalar properties (so single-value/non-array properties) are written as
single-element array properties to Alembic. This is also what's done by
Houdini and Maya exporters, so it seems to be the standard way of doing
things. It also simplifies the implementation.
Two-dimensional arrays are flattened by concatenating all the numbers
into a single array. This is because ID properties have a limited type
system. This means that a 3x3 "matrix" could just as well be a list of
three 3D vectors.
Alembic has two container properties to store custom data:
- `.userProperties`, which is meant for properties that aren't
necessarily understood by other software packages, and
- `.arbGeomParams`, which can contain the same kind of data as
`.userProperties`, but can also specify that these vary per face of a
mesh. This property is mostly intended for renderers.
Most industry packages write their custom data to `.arbGeomParams`.
However, given their goals I feel that `.userProperties` is the more
appropriate one for Blender's ID Properties.
The code is a bit more involved than I would have liked. An
`ABCAbstractWriter` has a `uniqueptr` to its `CustomPropertiesExporter`,
but the `CustomPropertiesExporter` also has a pointer back to its owning
`ABCAbstractWriter`. It's the latter pointer that I'm not too happy
with, but it has a reason. Getting the aforementioned `.userProperties`
from the Alembic library will automatically create it if it doesn't
exist already. If it's not used to actually add custom properties to, it
will crash the Alembic CLI tools (and maybe others too). This is what
the pointer back to the `ABCAbstractWriter` is used for: to get the
`.userProperties` at the last moment, when it's 100% sure at least one
custom property will be written.
Differential Revision: https://developer.blender.org/D8869
Reviewed by: sergey, dbystedt
This is the refactoring part of D8805 (should be no functional changes).
- exposes pose-related part of former 'get_constraints()' from
interface_templates.c to new ED_object_pose_constraint_list
- rename ED_object_constraint_list_from_context -->
ED_object_constraint_active_list
Also clarify comments on both of these.
ref T80464
ref https://developer.blender.org/D8805
Add support for object data instancing. This is used when the objects
are instances, for example when duplicated by a particle system, or
instanced by the duplication system (collection-duplicating empties,
vertex/face duplis, etc.)
Since Alembic already deduplicates data, this doesn't make the resulting
Alembic files any smaller. They will be faster to write, though, when
there is a lot of instanced geometry, as the deduplication system won't
have to do any comparisons.
This instancing support is still limited, in the sense that only object
data is instanced and all transforms are still written explicitly. A
future improvement could be to support instancing entire collection
hierarchies.
Blender's Alembic importer has no understanding of these Alembic
instances yet, and will thus happily duplicate the data on import.
The USD Alembic plugin seems to have problems understanding the
instancing. There might also be other software with similar issues.
Because of this, instancing can be turned off in the exporter (it's on
by default).
Split `ABCHierarchyIterator::get_alembic_parent()` into two functions:
- For a given export path, find the Alembic object
- Ensure that that object is usable as parent object (Alembic uses a
specific 'top' object as parent to indicate "no parent").
The new function is `public` as it will be used in an upcoming feature,
and is required to be public then.
No functional changes.
Split the `ABCHierarchyIterator::create_data_writer()` function into two
functions. This is to prepare for the creation of writers not just by
object type, but also by goal, for example writers that reference other
Alembic data instead of writing their own (i.e. instancing).
No functional changes.
Extract the mesh instancing code from the mesh writing function into a
generic 'mark as instance' function on the abstract USD writer. This will
help in supporting non-mesh instances.
No functional changes.
Remove the hack for library initialisation; this is no longer necessary
as the required information can be passed to the USD library after its
static initialisers have run.
This new approach is compatible with both the patched and original USD
library. This means that platform maintainers don't need to rebuild the
USD library until the next upgrade.
Manifest Task: https://developer.blender.org/T80320
Initialize the USD library when used (instead of at startup), so that
this can happen inside the IO/USD module. This makes calls to the USD
library local to Blender's USD code.
Note that failure to find the USD JSON files will now only be reported
when the USD exporter is used, and not on every startup of Blender.
This is the first step in cleaning up the way Blender patches and
initialises the USD library.
Manifest Task: https://developer.blender.org/T80320
Need to make sure node factories are initialized prior to the dependency
graph allocation.
The regression was initially introduced in 5b021dff41
Thanks Brecht for testing!
Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
The fix for T75936 made it possible to export invisible objects to
Alembic. This commit applies the same approach to the USD exporter.
The USD and Alembic code is slightly different in terms of where in the
exported file the visibility attribute is stored. In USD the visibility
is used to prune the scene graph, and thus there are only two options:
"hidden" and "inherited". Setting the visiblity of a node in the scene
graph to "hidden" immediately hides all its children. To allow hidden
parents with visible children, the visibility is stored on the object
data (so the geometry/camera/lamp/etc) instead.
Add a test that checks invisible objects are iterated over by the
`IO::AbstractHierarchyIterator` class, when a suitable depsgraph is given.
No functional changes.
Add a new depsgraph builder class that includes invisible objects and
use that in the Alembic exporter.
Alembic supports three options for visibility, "visible", "inherited",
and "hidden". This means that parents can be hidden and still have
visible children (contrary to USD, where invisibility is used to prune
an entire scene graph subtree). Because of this, the visibility is
stored on the transform node, as that represents the Object in Blender
and thus keeps the Alembic file as close to Blender's own structure as
possible.
Reviewed By: Sergey
Differential Revision: https://developer.blender.org/D8595
And make them part of the blender_test runner. The one exception is blenlib
performance tests, which we don't want to run by default. They remain in their
own executable.
Differential Revision: https://developer.blender.org/D8498
