Hey loppers,

I feel like I'm fundamentally still not getting a few things with solaris, so excuse me if I'm just going about it arse backwards. Please correct me!

My workflow is to write out a usd file for each shot as it's authored - camera, instanced geo, instanced lights. I'm sublayer-ing those in to another hip which applies materials and light trims for final batch rendering. Standard stuff, I hope.

I want to pass some information along from layout to lighting - such as if the lights should be flickering. Since this goes to disk it's not a candidate for storeparametervalues. Tags essentially.

An attribute wrangle easily adds an attribute to my camera. I can access in another wrangle.

How do I access it in a parameter such as a input parm of the switch LOP?

My guess is python expression, and I've found this: hou.pwd().inputs().stage() on the forum.. which feels like the right path - but where from there? Can't find docs... sorry.

Or is there a much better way of thinking about this?

Thanks!

Dragging and dropping things into the python terminal and using the method completion thing in the python shell I've discovered this incantation:

hou.node("/stage/cam").stage().GetAttributeAtPath("/cameras/s2730_cam.stabshot").Get(0)

Is that the most straightforward way for me to read my attribute?

It's working, so happy days.

Yep, that seems right to me, assuming the data isn't time dependent.

mtucker
Yep, that seems right to me, assuming the data isn't time dependent.

For current use case - no, it's not time dependent. Can imagine they could be in the future. What's the impact on that?

How do I find any docs on that Get() method? I'm passing it an int because that made it work. Is that actually a float time value or something?

Cheers,
r.

There really are no python docs for USD, just the C++ API docs. Fortunately the python API follows the C++ API very closely, in general. So you can look at https://graphics.pixar.com/usd/release/api/class_usd_attribute.html#a9d41bc223be86408ba7d7f74df7c35a9 [graphics.pixar.com] for informatino about the Get method. If the value was animated you'd probably want to do Get($FF).

Ah OK - so once we hit USD defined data types we can find the methods in the pixar docs and make good assumption there's a matching python method. Or that's what I'm hearing. Thanks for the tip!

That said - glancing at those docs doesn't tell me if it would be $FF or $T I'd be passing it. You've told me (thanks) and it's a pretty quick experiment, but I think it's exemplatory of the accessibilty/user-friendlyness of this system. It's tricky to learn from one's home studio - I imagine if I was in a bigger team sharing esoteric tips then understanding would be quicker.

$FF and $T are houdini variables (https://www.sidefx.com/docs/houdini/network/expressions.html) that can be passed to any function/method that accepts a numeric argument, so you're unlikely to find them discussed in the function documentation.

Those variables are specific to houdini, but the units are universal ( time = fps*(frame-1) )

Docs say it's a USDTimeCode which is unit-less. So if it's $F or $TT I guess is determined by the way Solaris is handling things, which sounds like it's frames. I would have expected time.

In USD-speak, Houdini's playbar is showing "time codes". In USD, "frames" is basically a meaningless concept. All that matters is TimeCodes. So time samples in USD at specific TimeCodes are shown at those Frames in Houdini. TimeCodes are not unitless, they are, like Houdini Frames, configurable. In USD they are configured using the "TimeCodesPerSecond" metadata, just like in Houdini they are configured using the FPS value. Solaris tries to keep the USD TCPS and Houdini FPS values in sync, since that's the easiest way to author and consume data.

The one place where USD uses the term "Frames" is in the "FramesPerSecond" metadata, which has nothing to do with the time samples stored in the USD file. It only has to do with the playback rate in a viewer application like usdview or the Houdini viewport. In Houdini this values can be used to drive the "Step" playback option.

Thanks Mark - that illuminating. So a rate can be defined in metadata and that effectively gives USDTimeCodes a unit. if TimeCodesPerSecond = FPS then USDTimeCodes are frames. If TimeCodesPerSecond = 1 then USDTimecodes are seconds. And the key info there is that Solaris syncs USD TCPS to Houdini FPS making it $FF I'd be putting in function calls to reference current place on timeline.

So if LOPs evaluate $FF as floating timecode value instead of global floating frame does it mean that $FF in LOPs is potentially higher precision than the infamous $FF in other contexts? (which causes rounding errors all the times and is better to be avoided)

tamte
So if LOPs evaluate $FF as floating timecode value instead of global floating frame does it mean that $FF in LOPs is potentially higher precision than the infamous $FF in other contexts? (which causes rounding errors all the times and is better to be avoided)

I don't think so. $FF is just an env var to be substituted. I doesn't matter what context. $FF is interpreted as a floating point time code, but the values of $FF is still limited to those that can be represented by the string expansion of $FF.