Does Solaris respect fps metadata on a layer
2210 1 1-
- jsmack
- Member
- 7741 posts
- Joined: Sept. 2011
- Offline
I noticed that the file “FX_layer.usd” in the example scene structure was authored with time values for the time codes instead of frame numbers. This causes it to play back 24 times too fast. I attempted to ‘fix’ it with a loadlayer and configurelayer to change the framerate metadata to 1 time code per second. This had no effect on playback speed. This raised the question, is the timecode/fps metadata used by lops at all?
-
- mtucker
- Staff
- 4435 posts
- Joined: July 2005
- Offline
My understanding (from reading the descriptions of GetFramesPerSecond and GetTimeCodesPerSecond) is that FPS is a non-binding suggestion to help auto-configure a playbar in a DCC app. We do not surrently make use of that value anywhere in Houdini, but if we did, it would be to drive the Houdini playbar's FPS value when the viewport's “Stage frame range drives playbar range” toggle is turned on. But given the consistency within a show for this value, this hasn't been an issue so far.
The TCPS is, if I'm reading it right, a value that USD should internally be using to scale time code values to seconds. But the more I think about it, the less likely that seems… Because all the USD APIs take UsdTimeCode objects to specify the time, the conversion from “seconds” to “time codes” must be expected to be done by the DCC. At the moment Houdini assume TimeCodes == Frames everywhere, but technically we should probably convert Frame -> Time (using the Houdini playbar FPS, possibly driven by the USD stage FPS), then Time -> Time Codes (driven by the TCPS of the stage we are dealing with).
Of course this doesn't help if you load in a USD file with a TCPS that doesn't match the TCPS of the overall stage. Unless USD takes care of the time scaling in this case, which I'm not sure if it does or not. But USD does provide (and Houdini lets you set) the Time Scale/Time Offset values used when sublayering or referencing a file, so that would be my recommendation right now for cases wher TCPS != FPS: set a Time Scale when loading in these layers such that the scaled TCPS == FPS.
I'll make myself an RFE to investigate this further and see if we should in fact be doing something other than using Frames==TimeCodes, and possibly driving the playbar FPS from the stage FPS if that viewport toggle is turned on. Thanks for bringing this up, and let me know if you think I've missed anything.
The TCPS is, if I'm reading it right, a value that USD should internally be using to scale time code values to seconds. But the more I think about it, the less likely that seems… Because all the USD APIs take UsdTimeCode objects to specify the time, the conversion from “seconds” to “time codes” must be expected to be done by the DCC. At the moment Houdini assume TimeCodes == Frames everywhere, but technically we should probably convert Frame -> Time (using the Houdini playbar FPS, possibly driven by the USD stage FPS), then Time -> Time Codes (driven by the TCPS of the stage we are dealing with).
Of course this doesn't help if you load in a USD file with a TCPS that doesn't match the TCPS of the overall stage. Unless USD takes care of the time scaling in this case, which I'm not sure if it does or not. But USD does provide (and Houdini lets you set) the Time Scale/Time Offset values used when sublayering or referencing a file, so that would be my recommendation right now for cases wher TCPS != FPS: set a Time Scale when loading in these layers such that the scaled TCPS == FPS.
I'll make myself an RFE to investigate this further and see if we should in fact be doing something other than using Frames==TimeCodes, and possibly driving the playbar FPS from the stage FPS if that viewport toggle is turned on. Thanks for bringing this up, and let me know if you think I've missed anything.
-
- Quick Links