For anyone who has ever worked in VFX you’ve probably encountered the pain of retime and repo workflows. I am curious if anyone has any insights into how to make this smoother in USD than in Alembic pipelines.
Retime’s are usually applied to the curve data and a new set of curves are produced for the camera. How do you handle this in your pipeline?
The retime curve data often comes from Nuke or another compositing application or could be produced by a camera rig in a 3D application. Do you express this data on the stage somewhere? I.e a RetimeAPI single apply schema? Or a Retime prim type?
How do you handle reposition data?
Many projects have many different formats (camera sensors) and different extraction processes to go from the full camera sensor to the delivery format (some shows are even crazy enough to have different delivery formats per shot)…
Is it also an API schema applied to a Camera prim? Or a relationship to a new prim type?
Or do you store that data in its own prim type? Or not at all?
The UsdGeomCamera doesn’t have attributes for post scale or roll from what I have seen. How then are more complicated translate, rotate and scale repo’s done?
Has anyone extended the Camera schema and implemented new features in Hydra to deal with roll and scale?
Will OpenExec help in anyway in the future to avoid having to bake retime and repo data? Or am I off my rocker here?
Would love to hear from people who have implemented working solutions for complicated repo & retime workflows around plate based photography.
I don’t have working experience specifically on these problems to share, but I can talk about what is currently and will eventually be available in USD to facilitate natively encoding the data for these features in a way that a) doesn’t require any further processing by clients like Hydra, b) is still extractable/interchangeable.
Retimes
We have less available currently to offer here. The only partially-matching feature is the ability of Value Clips to incorporate a linearly-interpolated timing curve onto the data the clip contains. Bit of an awkward workflow because you need to isolate the camera animation into a separate layer that then gets built into a ClipSet that gets applied to the Camera prim.
In the future, you’d be able to author TimeCode-valued TsSplines as retiming curves, and OpenExec will enable sophisticated spline manipulation, including blending and retiming, with the results just flowing into the existing Camera attributes.
Repositioning.
If the repositioning you’re talking about here is all about affine transformation of the entire Camera prim itself, ou should be able to accomplish all that today using the UsdGeomXformable xformOp features (Camera Is Xformable). Basically, a Camera contains an arbitrary sequence of xformOps, each of which can be any of the primitive transform operations, including insertion of pivots. So you can “add on” additional transformations anywhere in the existing sequence of operators. With the Sparse Array Overides feature coming in 26.02, you’d even be able to add on extra xformOps non-destructively by appending/prepending/inserting operators into xformOpOrder. You can also craft an API schema that names (with relevant names like xformOp:rotateZ:roll) the repositioning ops.