Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSybren A. Stüvel <sybren@blender.org>2020-09-11 15:06:13 +0300
committerSybren A. Stüvel <sybren@blender.org>2020-09-14 13:49:27 +0300
commitee97add4c404a414addab5cbb6107fac002da77a (patch)
treef6a7adadf1ee27470b3a53dd9b247078f83a3af1 /source/blender/io/alembic/exporter/abc_writer_points.cc
parentb8a25bbd8a400b52de150a08c041e2f6f2a9dce1 (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_points.cc')
-rw-r--r--source/blender/io/alembic/exporter/abc_writer_points.cc5
1 files changed, 5 insertions, 0 deletions
diff --git a/source/blender/io/alembic/exporter/abc_writer_points.cc b/source/blender/io/alembic/exporter/abc_writer_points.cc
index 83d33577b3b..557f580e8aa 100644
--- a/source/blender/io/alembic/exporter/abc_writer_points.cc
+++ b/source/blender/io/alembic/exporter/abc_writer_points.cc
@@ -58,6 +58,11 @@ Alembic::Abc::OObject ABCPointsWriter::get_alembic_object() const
return abc_points_;
}
+Alembic::Abc::OCompoundProperty ABCPointsWriter::abc_prop_for_custom_props()
+{
+ return abc_schema_prop_for_custom_props(abc_points_schema_);
+}
+
bool ABCPointsWriter::is_supported(const HierarchyContext *context) const
{
return ELEM(context->particle_system->part->type,