diff options
author | Sybren A. Stüvel <sybren@blender.org> | 2020-09-11 15:06:13 +0300 |
---|---|---|
committer | Sybren A. Stüvel <sybren@blender.org> | 2020-09-14 13:49:27 +0300 |
commit | ee97add4c404a414addab5cbb6107fac002da77a (patch) | |
tree | f6a7adadf1ee27470b3a53dd9b247078f83a3af1 /source/blender/io/alembic/exporter/abc_writer_mesh.h | |
parent | b8a25bbd8a400b52de150a08c041e2f6f2a9dce1 (diff) |
Alembic export: write custom properties
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
Diffstat (limited to 'source/blender/io/alembic/exporter/abc_writer_mesh.h')
-rw-r--r-- | source/blender/io/alembic/exporter/abc_writer_mesh.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/source/blender/io/alembic/exporter/abc_writer_mesh.h b/source/blender/io/alembic/exporter/abc_writer_mesh.h index 956587df7c0..fdf2d3cc1e3 100644 --- a/source/blender/io/alembic/exporter/abc_writer_mesh.h +++ b/source/blender/io/alembic/exporter/abc_writer_mesh.h @@ -55,6 +55,7 @@ class ABCGenericMeshWriter : public ABCAbstractWriter { virtual void create_alembic_objects(const HierarchyContext *context) override; virtual Alembic::Abc::OObject get_alembic_object() const override; + Alembic::Abc::OCompoundProperty abc_prop_for_custom_props() override; protected: virtual bool is_supported(const HierarchyContext *context) const override; |