Heyja,

Heyja from H19.0 I'm used to this working and am a little confused what 19.5 is doing here. In 19.0 if I put an expression on a parameter and put a cache lop after it would bake the timesamples for that attribute. I could then simply safe that into a single frame usd and since the timesamples were cached I could simply load that single frame usd and it had the animation baked into it.

I can't share screenshots but my example is
1) cube LOP with $F expression on rotateY
2) cache LOP with Always Cache All Frames on and framerange set to 101/400/1

if I right click the cache lop and display the active layer I can then see the timesamples baked in.
Putting a usd_rop LOP after, set it to render current frame and flatten implicit layers I'll cache it out but the resulting usd will not have those timesamples baked in. This did work in 19.0 and was incredibly handy. For the most part it really gave me trust that what I cache out matches what I set as the input.

How do I get the behavior of 19.0 back?

thanks,
Florens

found the issue. I didn't even question the default expression on the cache lop and assumed it would just go by first and last frame in the playbar. turns out it's @ropstart and @ropend which then makes sense that these values change if my out rop only exports a single frame. Killing the expression fixes it.

We hear you on this. The introduction of @ropstart and @ropend were an attempt to reduce the creation and storage of useless extraneous time samples when saving USD layers to disk. But there were unintended consequences with the impact on cooking and recooking when using a ROP. So we came up with an alternative solution that leaves it to the ROP to trim out time samples outside the requested bounds. This allowed us to revert the various uses of ropstart/ropend to go back to $FSTART/$FEND (or equivalently @fstart/@fend) and avoid these cooking issues without losing the benefits we were aiming for with ropstart/ropend.

Note that these are all just node default parm values, so existing hip files will continue to use whatever range variables were saved in the hip file. With H20 you can change these in existing hip files, and new hip files/nodes will use the new approach with the best of both worlds.