Alembic\USD: Full fidelity animation data for non-geometry properties #124555

New Issue

Jesse Yurkovich · 2024-07-11T22:27:33+02:00

Jesse Yurkovich commented

2024-07-11 22:27:33 +02:00

Context

The current animation import capability of Alembic and USD importers is heavily geared toward use of the Mesh Sequence Cache modifier and Transform Cache constraint. Over time, and as USD matured and gained further traction, we are now accumulating many more scenarios which don't quite fit into the current cache based capability and approach.

Existing Tasks and PRs

[1] #54050
[2] #69046

Problem

There are two general problems associated with the current machinery used by both Alembic and USD importers. Much of this stems from the Mesh Sequence Cache in that it only supports various Mesh and Curve attributes. See [2] above for further notes on the topic.

Animated, non-geometry, object properties are only imported statically and any time-varying behavior will be ignored.

Examples include

Animated camera focal length, depth of field focal distance, and depth of field F-Stops
Animated light intensity, color, and size
Animated material properties
Animated prim/object visibility settings

Baked data vs. Editable data - The problem with only having a Cache-based workflow

Alembic, being a format created specifically to contain pre-baked data, lends itself well to opaque cache workflows. Whether through the Mesh Sequence Cache, or a hypothetical system where animated properties have their F-Curve data loaded directly from a cache file rather than being evaluated each frame, editing the data was never intended. The main purpose here was always to only load the smallest amount of data possible, and evaluate it as quickly as possible, for only the current frame being viewed or rendered.

USD is different. Like Alembic, it can serve as a container for pre-baked data, but it can also serve as a general interchange format where editing and composing changes "over" existing data is possible. In that world, being able to interact with, and change, individual keyframes and f-curves is desired and expected.

Some USD data (Skeletons/bones) is already being loaded directly into f-curve/actions today for similar reasons. Additionally, other formats like FBX and glTF have mostly chosen to import f-curve data directly as well, skipping caching workflows altogether.

Choices to consider

Do we explore a system like what's was mentioned in [2] further?
Do we forgo a caching system for animated properties entirely and instead author the f-curve on the relevant properties directly?
Do we need an "Un-Bake cache to f-curve" Operator to help solve problem 2 for cases where the cache is used today?
Caching is important for the efficiency reasons noted above. But could we un-bake the cache and turn it into f-curves as an Operator? This would allow the use of Caches by default while enabling the user to turn it into editable data at a time of their choosing later.

Decision needed

<which choices to plan and investigate further>

## Context The current animation import capability of Alembic and USD importers is heavily geared toward use of the Mesh Sequence Cache modifier and Transform Cache constraint. Over time, and as USD matured and gained further traction, we are now accumulating many more scenarios which don't quite fit into the current cache based capability and approach. #### Existing Tasks and PRs [1] https://projects.blender.org/blender/blender/issues/54050 [2] https://projects.blender.org/blender/blender/issues/69046 ## Problem There are two general problems associated with the current machinery used by both Alembic and USD importers. Much of this stems from the Mesh Sequence Cache in that it only supports various Mesh and Curve attributes. See [2] above for further notes on the topic. #### Animated, non-geometry, object properties are only imported statically and any time-varying behavior will be ignored. Examples include - Animated camera focal length, depth of field focal distance, and depth of field F-Stops - Animated light intensity, color, and size - Animated material properties - Animated prim/object visibility settings #### Baked data vs. Editable data - The problem with only having a Cache-based workflow Alembic, being a format created specifically to contain pre-baked data, lends itself well to opaque cache workflows. Whether through the Mesh Sequence Cache, or a hypothetical system where animated properties have their F-Curve data loaded directly from a cache file rather than being evaluated each frame, editing the data was never intended. The main purpose here was always to only load the smallest amount of data possible, and evaluate it as quickly as possible, for only the current frame being viewed or rendered. USD is different. Like Alembic, it can serve as a container for pre-baked data, but it can also serve as a general interchange format where editing and composing changes "over" existing data is possible. In that world, being able to interact with, and change, individual keyframes and f-curves is desired and expected. Some USD data (Skeletons/bones) is already being loaded directly into f-curve/actions today for similar reasons. Additionally, other formats like FBX and glTF have mostly chosen to import f-curve data directly as well, skipping caching workflows altogether. ## Choices to consider - Do we explore a system like what's was mentioned in [2] further? - Do we forgo a caching system for animated properties entirely and instead author the f-curve on the relevant properties directly? - Do we need an "Un-Bake cache to f-curve" Operator to help solve problem 2 for cases where the cache is used today? Caching is important for the efficiency reasons noted above. But could we un-bake the cache and turn it into f-curves as an Operator? This would allow the use of Caches by default while enabling the user to turn it into editable data at a time of their choosing later. ## Decision needed `<which choices to plan and investigate further>`

Jesse Yurkovich added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Alembic\USD: Full fidelity animation data for non-geometry properties #124555