Getting current frame time

I’m looking to see how one can get the current frame time from the USD scene into the Hydra delegate?

Ideally something like HdSceneDelegate::GetTime() that would let me query the current time frame.
It seems like HdPrMan does something like this for Houdini but it looks up a Houdini specific attribute: houdini:frame but it would be nice to have something generic.

Any pointers would be appreciated. Cheers

USD is timeless, (cue dad joke), it records all the samples at all the times, the current time is an external concept, one slid a slider in the UI, or you are recording frames at certain times.

For example, if you are using the UsdImaginingGLEngine you stuff the time you want to evaluate into the UsdImagingGLRenderParams struct you pass at render time.

Hey Nick,
Thanks for the info. I wonder if the param names are something we could standardize, even if just by a stated convention?

It would help a ton if each hydra delegate didn’t have to account for the range of host specific struct/attributes like hdprman has to with Houdini:frame.

e.g if I had a hydra delegate , then even though Hydra abstracts the scene to renderer interface, you still need to target each DCC/host app independently. Granted, you might have to do that for other specific properties, but time feels like one that could be relatively standardized?

I can imagine the time value being interesting in the context of a single render call, and if you are not within a render, the time might be reported as a sentinel indicating that it’s unavailable.

In guessing you want the time, when you are rendering, only.

yeah I think that sounds like a solid solution. I’m not sure what other contexts one might use Hydra for other than rendering though?

Without speculating about use cases, imagine a dcc where one might open several windows all with an independent timeline. Imagine that the windows each update on an unknown schedule subject to window system rules so there is no known ordering between their updates. Globally, there is consequently no one application time. Even if you say it is the focused window, there’s huge amounts of assumption that would underlie even that. Hence the suggestion that time can only be read during the context of an individual render invocation.

I’d have to dig, but I wonder if that particular value is actually already available somehow.

Ah that’s fair. I guess in that scenario Hydra is more of an abstract scene accessor.

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.

Would that address your issue?

Hey Tom, I think that would do the trick. We’re basically hitting the same scenarios.