Camera keyframes NOT exported as USD

I have noticed that camera keyframes are not exported as USD.
If I animate an object, export it as USD, import it again, I can still see the keyframes.
Which is not the case for the camera.

And I have noticed in the code that it’s just using the export time stamp instead of exporting for the whole animation time.

Which I found here:

void USDCameraWriter::do_write(HierarchyContext &context)
{
  pxr::UsdTimeCode timecode = get_export_time_code();

And then that timecode is used for all the attributes.

Is that actually the case or is there another way to export camera keyframes? If so, is that a planned feature? Or does it exist on another branch/fork?

What I’m expecting is:

  1. See camera animations when exporting/importing to another project.
  2. Get the correct values when I call UsdGeomCamera::GetCamera(const UsdTimeCode&) for different points in time when I read it with the USD library.

The version I’m using right now is close to the latest main:

version: 4.1.0 Alpha, branch: main, commit date: 2023-10-03 18:31, hash: 660d8de7e4c5, type: Release
build date: 2023-10-04, 00:03:38
platform: ‘Linux-5.14.21-150500.53-default-x86_64-with-glibc2.31’

Import of camera animation (besides the object transform) is not supported, that’s a known limitation. Export works as far as I know. You can confirm that by exporting a .usda file and checking the contents.

The relevant issue is:

Ok I can see the exporting working now. It’s just the importing that doesn’t work.

But also it’s exporting every single frame and not just the key frames. I suppose that’s because the interpolation is customized and USD doesn’t support all interpolation methods?

My mistake was that I didn’t notice the animation starts from 0 and ends at 0. Somehow that was the default.

It’s exporting every frame because that is the most straightforward way to get correct results. In principle someone could implement a special case for when it’s known that the interpolation type is supported by USD, there are no f-curve modifiers, no NLA blending, no drivers, no Python scripts, etc.

2 Likes