Standardize passing current frame to Hydra Delegates

[dgovil]

Description of Issue

I would like to request a standardized form of passing the current USD Scene sampled time to the Hydra Delegate.
We'd like that as a way to better let a delegate handle image sequences.

This is an issue to continue the request from https://forum.aousd.org/t/getting-current-frame-time/869/9

@tcauchois said there

We have some plans of adding “frame” as a hydra render setting; it would come from the root-level scene file you’re working in (or something) and be available as a substitution for asset paths or shader parameters at the hydra level. Internally, this comes up a lot but almost exclusively in a shading context (e.g. seed for noise), or as a convenience for indexing into movies/flipbooks in texture bindings.

Which is precisely what we'd love to solve

[spiffmon]

I just want to note that "current time" can't really be something authored in the scene, as that would create threading issues if you wanted to process multiple times concurrently. Apologies if I'm misunderstanding the proposal!

[dgovil]

So I mean "whatever time it is that the scene is being sampled at when sent to Hydra"
In the multiple time scenario, each invocation of the delegate would get the respective time.

For example, if my delegate is receiving the scene as it exists on frame 20, and I have a corresponding image sequence, I'd need some way to know that its frame 20 I should be looking up.

HDPRMan piggybacks off of the Houdini:frame attribute when used with Houdini, but it seems like something that could/should be standardized.

[tcauchois]

Note that hdPrman pulls frame preferentially from the "hydra scene globals" datastructure (a cache of info on "/"), as seen here: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/third_party/renderman-26/plugin/hdPrman/renderSettings.cpp#L237 ... This needs to be populated by the app, and UsdImagingGLEngine does so here:

OpenUSD/pxr/usdImaging/usdImagingGL/engine.cpp

Line 1115 in 9b0c13b

sgsi = HdsiSceneGlobalsSceneIndex::New(inputScene);

...

HdPrman also reads Houdini:frame to support SideFX workflows, but the convention we want to standardize is the scene globals one. Let me know if this addresses your issues?

The scene globals approach notably is somewhat out of band, and hdPrman merges this into render settings to populate the renderman "frame" global setting, which can then be queried from OSL. We've separately been discussing possibly adding a "{frame}" substitution in asset paths; you could accomplish this in a scene index manually, but it wouldn't be composition-aware.

[spiffmon]

Yeah, a UsdImagingGLEngine per parallel-processing of the scene (e.g. different viewports showing the scene at different times) seems appropriate, and with no Stage threading issues.

…

On Wed, Dec 4, 2024 at 4:25 PM Tom ***@***.***> wrote: Note that hdPrman pulls frame preferentially from the "hydra scene globals" datastructure (a cache of info on "/"), as seen here: https://github.com/PixarAnimationStudios/OpenUSD/blob/release/third_party/renderman-26/plugin/hdPrman/renderSettings.cpp#L237 ... This needs to be populated by the app, and UsdImagingGLEngine does so here: https://github.com/PixarAnimationStudios/OpenUSD/blob/9b0c13b2efa6233c8a4a4af411833628c5435bde/pxr/usdImaging/usdImagingGL/engine.cpp#L1115 ... HdPrman also reads Houdini:frame to support SideFX workflows, but the convention we want to standardize is the scene globals one. Let me know if this addresses your issues? The scene globals approach notably is somewhat out of band, and hdPrman merges this into render settings to populate the renderman "frame" global setting, which can then be queried from OSL. We've separately been discussing possibly adding a "{frame}" substitution in asset paths; you could accomplish this in a scene index manually, but it wouldn't be composition-aware. — Reply to this email directly, view it on GitHub <#3453 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABPOU2HJEQGK5BNOL2OCULT2D6MQFAVCNFSM6AAAAABTBEQWH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJYHAZDSNJWGE> . You are receiving this because you commented.Message ID: ***@***.***>

[dgovil]

@tcauchois yes I like the scene globals approach. If we could standardize on one system there it would help us switch between different delegates in different apps more easily.

[jesschimein]

Filed as internal issue #USD-10498