Ok, so it seems like I my value clip didnt get created correctly. I have fixed it in this scene, could you take a look if you can reproduce now?

Ah, yes, now I see it with that updated scene. Will log a bug to investigate further.

robp_sidefx
Yes ... so there's one more "gotcha"

I'm wondering if there's another "gotcha" lurking around somewhere... so I've added + $F * 0 in more places than I think is needed (even after bezier(), which should really not be needed, but I guess shows I'm pulling my hair out once again). I've also added it to 'enable look at' which are also driven by curves, but just in case stepped curves for some reason weren't evaluated properly.

There's now a mismatch between "live" and cached data around frame 5970 despite me ensuring the setups for each camera are identical and curves existing on all frames. I've drilled it down to the highlighted camera's 'enable look at'. If one simply switches (using "live" data) it on and off no difference is seen. I have to remove the curve from that checkbox, and only then do I see a difference when switching it on and off. It being off now also matches the cached data.. but I of course want it on.

Are binary things like checkedboxes looked at differently by Houdini's USD caching?

Cheers.

RumbleMonk
I'm wondering if there's another "gotcha" lurking around somewhere...
Are binary things like checkedboxes looked at differently by Houdini's USD caching?

It's a pretty safe bet that there's always another gotcha.

Good sleuthing to track it down to the "Enable Look At". That is indeed the issue. If you look at the Scene Graph Details, you'll see that /cameras/camera has two xformOp:transform entries for all the cameras except this one (which has a third - xformOp:transform:lookat). This in turn means that the xformOpOrder attribute has a different length from one camera to the next, but it's being authored using default values (not time samples), and so the caching can't handle this animated length.

There's possibly a way to force xformOpOrder to be time sampled, but the alternative is to ensure all the cameras are using the same number (and names) for their transformation stack.

Between the cameras and their respective Cache LOPs, you can insert a Python LOP with the following:


Give it a spin and let me know!

- Rob

robp_sidefx
Give it a spin and let me know!

- Rob

Gave it a spin, a confirmed two thumbs up!

I was going to ask if I could just bake the camera's xform down if the checkbox was a hassle, but seems like that is what your solution is anyway.

Just to be clear; You're merging xform:transform + xform:transform:foofoo (ie the parent transform above the camera) + xform:transform:lookat back into the xform:transform, then removing the tokens so that xformOpOrder now only includes a single token xformOp:transform - ie baking down all the transforms *per frame*.

If that's a yes from you, does that mean the previous fix of adding '+ $F * 0' to any attribute ever animated on any camera is no longer needed, seeing as the python snippet is evaluated per frame, and assumingly doesn't care if an attr is static or not?

Thanks, as always!

RumbleMonk
does that mean the previous fix of adding '+ $F * 0' to any attribute ever animated on any camera is no longer needed

I'm going to cheat and say "try it ... if it works, then it works"

robp_sidefx

RumbleMonk
does that mean the previous fix of adding '+ $F * 0' to any attribute ever animated on any camera is no longer needed

I'm going to cheat and say "try it ... if it works, then it works"

Cheating is my middle name, didn't get time to test this out this morning but will do! Hopefully no more gotchas at this point, and I've learnt a thing or two about troubleshooting USD here to push my project forwards so fingers crossed!

leoYfver
I hit a bit of a snag. It seem like my usd file is fine but when rendering through husk i dont get animated cameras

We managed to track this down to a subtle bug in USD which was an unfortunate combination of the Value Clips approach you used and the way we add layers at render time for procedurals.

On the USD side, the issue is fixed in v23.02, so a future release of Houdini will absorb the fix "for free". For H19.5, I've made a change in 19.5.557 which should improve things (possibly not perfectly, but it seems to work for your test scene).

thanks rob! really aprreciate this and for the fast and clear respons!

Will take a while until we try a new update in production but will try to test at home atleast.

Regards Alexis