Workflow: Add a simple "turntable" feature in lib to expose for the viewer

[BigRoy]

Add an API entry point to easily set up a "turntable" like view that could be used in conjunction with the #1 render functionality. This way it could become trivial to easily generate a few turntable previews of USD assets via a simple API.

Imagining something like:

from pxr import Usd
from usd_qtpy.lib.usd import setup_turntable, render_stage

stage = Usd.Stage.Open(path)
setup_turntable(stage)  # this might add an extra anonymous layer just for the turntable changes
render_stage(stage, path=output_path)

[Sasbom]

IIRC, I think marmoset did this in a fairly nice way, where you essentially make a special type of camera that spins around the model (because, the model might have animation in it or other sensitive stuff, we might not want to touch it directly)

I have been thinking about how something like this should be visible to the user. Some quick (unrefined) thoughts on implementation

1. Inject a camera into the scene, copying current viewing camera into a layer (optionally temporary, but temp by default)
2. Running a modal dialog, use usd.Gf to generate some rotation matrix, based on exposed parameters (duration, position offset etc)
3. Swivel camera around, baking keys if not temporary
4. Cleanup if nessecary

This way, we can leave the option to actually include a generated turntable camera, which might be a nice bonus for anyone wanting to take their model to a more "proper" rendering environment, and because with this approach we're moving the camera, not the scene, this can be of minimal impact. (no keys in every other prim, all other cameras still functional, etc).

[BigRoy]

I believe @RichardFrangenberg has something similar in Prism Pipeline - maybe he could share a bit about his approach.

I assume it'd be either:

1. Create a camera with a group where the group rotates (or just add two xform ops on the camera prim so that we have one rotating around the center and the other moving it back from the scene in local space)
2. Put all prims under a single root and add pre transform op that performs the rotation.

In both cases we'd prefer to have just a single rotation key instead of baking translating/rotation calculations on the camera prim just for potential nicer interpolation for motion blurs.

---

Just as a reference, here is a somewhat related topic:

• https://forum.aousd.org/t/rotate-viewport-without-moving-camera/931

---

Note:

We have a custom Houdini lookdev kit which does something similar where there's a few frames generated where the lookdev kit's lights rotate and another few frames where the character rotates (but the backdrop remains static). For this particular case there is thus actual interest to only rotate a PART OF the usd file instead of all of the USD stage. So there could also be reasons to not do it with the camera alone.

[Sasbom]

In both cases we'd prefer to have just a single rotation key instead of baking translating/rotation calculations on the camera prim just for potential nicer interpolation for motion blurs.

This sounds MUCH more sane than what I was thinking about. That makes a lot of sense.

We have a custom Houdini lookdev kit which does something similar where there's a few frames generated where the lookdev kit's lights rotate and another few frames where the character rotates (but the backdrop remains static). For this particular case there is thus actual interest to only rotate a PART OF the usd file instead of all of the USD stage. So there could also be reasons to not do it with the camera alone.

If we end up doing something similar and giving the user some options on how they want their turns tabled, then that'd be a lot but a really good "nice to have", just so an artist wouldn't have to jump around in between different software to generate a preview that makes sense for the current usecase.

[BigRoy]

how they want their turns tabled,

Ha - pun intended.