Other format exporters such as FBX and GLTF have the option to bake animations during export, so that bones and objects that are controlled by constraints or drivers are exported correctly:
The Omniverse USD exporter currently lacks such a feature, which sucks because baking animations manually in Blender can be a hassle if you need to iterate a lot on them:
Bake to new action; disable all constraints on all bones; export; delete the action; re-enable constraints; rinse and repeat every time you need to re-export.
As requested by @makowalski, here’s a .blend file that can be used for testing this feature: Omni bone constraints.zip (123.3 KB)
It contains a pre-baked action that can be exported separately and compared against (mind you that baking during export must not overwrite existing animations):
And as it states, the bone’s constraints must be disabled for it to work:
@Im_Ninooo Thank you so much for the example file and description of the issue!
1 Like
@makowalski do you think this feature could make it to the next release or nah?
Probably not the very next release, unfortunately, since this is coming up soon.
You can either bake out all your animation to keyframes first, or the Blender exporter, exports animation if you turn it on. The reason it’s off by default is that most users don’t want that and it generates larger files if folks aren’t careful
1 Like
Hi @Im_Ninooo,
I’m unclear on the ask-- are you looking specifically to have the baked data stored as an Action in the Blender file?
Currently, while exporting animation the system pulls the final calculated position for objects and writes those samples to the USD file. As USD does not currently support animation curves, the values are time-sampled and interpolated on read.
I tested your file and on export, the values are correct and animated playback in Composer looks like it does in Blender:
From my perspective, baking the data down to another action isn’t required as the two scenes look visually the same. Is there a particular use case you had in mind that I’m missing?
1 Like
that’s quite interesting. it indeed does seem to work for simpler setups such as the one I provided (I haven’t actually tested it before, my bad) but the actual setup I use which consists of a main armature (the one I animate) that drives another armature (via ChildOf constraints on each bone) which actually deforms the mesh (and gets exported with it) doesn’t seem to work at all, which is why I requested this to begin with.
I’m actually having a really difficult time finding a consistent reproduction of the issue. I have created two essentially identical setups which behave differently. I’ll keep trying and report back.
here’s some test files in the meantime (USD files included).
inconsistent file, two essentially identical setups, one works, the other doesn’t:
OmniConstraintTestInconsistent.zip (133.7 KB)
none of these seem to work:
OmniConstraintTestNoneWork.zip (123.6 KB)
I really don’t know how the original example file I sent worked at all. I’m unable to reproduce a setup from scratch that works.
@cwardlaw have you tried any of the files above?