Multishot workflows and how to properly gather shots datas

Community USD
1

Hi everyone, super pumped to be here ! I’m currently working on a lot of tests and r&d here at UNIT Image on Solaris to assess our future options and it’s so far very promising and a ton of fun.

I’ve been currently trying to wrap my head around multi shot workflows, mainly into what would be the best approach to grab the data, let it live through the stage, and switch it at will. And so far I haven’t found that many leads or answers, although I really need to dig into all those awesome presentations shared over the various working groups.

Here are the current options/questions I was looking at and wondering about.

  • Should I import a bunch of prims with the datas on them, like range, shot name etc
  • Could this be just one and the shots added as variants on it ?
  • Maybe something clever that seems to be the way solaris would like it is to have a bunch of layers at hand with the actual range and some metadata and switch them at will ? or mute the others ?
    Sorry if this is very very generic and all seems like some crazy ideas thrown in there.
    Thanks a lot in advance !
1 Like
2

Have you looked into the Edit Context Options LOP in Houdini to edit Context Options.

One of the example uses is “Shot Name” and as it describes:

This can be particularly useful when you’re using the same HIP file to render multiple shots. You can set up variables with shot-specific values, and change the variables when you change which shot you’re working on.

It is Houdini Solaris specific as far as I know and isn’t necessarily “USD” native logic.

As far as I know, the context options basically influence the behavior to ‘upstream’ LOP nodes in your graph. So you could e.g. view your graph from the context of sh010, sh020, sh030, etc. with e.g. on that switch redefining what frame ranges or resolution might be used for that particular shot. You can also define HIP scene wide context options which get stored with the file.

3

Hi Alex,

There is no right answer to this question. Several methods are applicable.
But the simplest way, IMO, is to load the various shot usd layerStacks as separate sublayer nodes, all connected into a switch node that is driven by a context option. It could also be a single sublayer node with the context option being inserted in it’s file parameter if all the shot usd files have the same location and no version number. Or use an custom HDA to load the proper usd file per shot based on the context option.

Then, by changing the context option manually in the Context Options Editor, it loads a different shot inside the node graph. Make sure this button is activated. It will update the playbar range automatically from the range defined inside the usd file.

20240315-144442
20240315-144442123×512 47.7 KB

If you prefer to have all shots appended in the timeline, you can set the time offset parameter in the sublayer nodes and use the Edit Context Options LOP in time based mode. It’s tedious to set by hand but a script can do it nicely. This way, when the play head reaches a certain frame, it swiches the context option which triggers the right usd file to be loaded and all the right switches in your node graph.

Here is a screenshot of a simple setup for a sequence of 7 shots.

20240315-150640
20240315-150640480×777 73.7 KB

All shots are loaded at the top. Then all lights are added for all the shot in a common trunk. Any other override could be added there.
Then shots are spread into branches for shot overrides. Only the shots with overrides need their own branch, all other shots cen be connected to the fallback input of the switch.
Then everything is brought back into a common trunk for defining the render settings, AOVs and the collections, which can be used to create the render passes/layers.
Finally, branches are created for passes with their respective overrides.

In this example, the number of shots is pretty low so we created a Render ROP per shot under each pass. Each ROP is setup with the right context option inside it so it always renders the right shot. For larger number of shots, a PDG setup could be required.

So, inside the usd files themselves, you only need to set the time range. The rest happens in Solaris. The key is to use context options and switch LOPs in “by name” mode.
20240315-150940

F

2 Likes
4

Oh and one additional point. In our setup, we use a Render Settings Edit LOP under each sublayer at the top. This is used to set the camera for each shot, and all other parameters are set to “do nothing”. In the viewport, you can choose the Render Settings camera and it will always update when you change shot, even if the names of the cameras are completely different.
20240315-151521

This is super useful!
F

1 Like
5

Well thank you very very much, ton of good infos ! Yeah I was on the track of sublayers, and I was at the moment loading a single one with just a context option variable. Having those range locked on the layers seems like a great way to me especially with that solaris viewport option to adapt. So glad I seems to be on a good way to keep going.
I have some more homeworks to do then, thanks again for taking the time to write me such an extensive overview !

6

Yeah, that is super-cool, @flord ! I just wanted to note that if this kind of workflow/construction is one you’d want to use throughout a pipeline, it should be possible to encode/preserve the idea of “shot context/selection in a multi-shot document” directly in the created USD by using USD Expression Variables on your subLayer statements, though likely some work would be needed in Solaris to make that happen. The parts you wouldn’t get in the resulting exported multi-shot scene would be:

  • any knobs/switches for setting the UsdEditTarget appropriately for each of the different kinds of general or shot-specific edits you mentioned
  • automatic switching between shots based on a current playback frame… that’d be each app’s responsibility

At Pixar we have also reached a need for pushing into this Dreamworks proposal for a Scene schema from several years ago, which could facilitate a different way of organizing a multi-shot scene, allowing all shots to be present at once on the multi-shot stage. We hope to start that work later this year.

2 Likes
7

I didn’t know about usd expression variables at all, as you say maybe a bit though for now to use that but that’s one more option in any case ! And still a good concept to grasp, thanks Sebastian !
And I’ll be watching that scene schema progress then

8

Yes, this is the right forum - it’s just that usd-interest had amassed alot of knowledge, which unfortunately was not indexable by google and other webcrawlers.