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!

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!

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.

leoYfver
Thank you both for this thread, its been very informative and being able to switch cameras and bake the animation to the usd is something we have been looking into also.

I'll check back to see if you get anywhere with this, I'm curious how your setup works and maybe by sheer luck I'd be able to help if I get time to look into it.

One more note regarding my setup, I had some transforms acting as parents to some cameras. Those had the default $OS description which will cause problems. They'll need to have their names set to the same, and I believe that was the last puzzle piece to get it to work.

robp_sidefx

RumbleMonk
Alright, maybe last question - I moved my cameras from my massive file into this one and set caching etc as per your file. I even brought in the cameras only into your file to make sure I hadn't missed anything but while the cameras switch correctly they seem to be zooming in differently when comparing the live cam data to the cached cam data.

I've attached 2 images showing frame 700 after caching the camera, then switching it on and off. Some cameras seem to be ok, some less so.

Yes ... so there's one more "gotcha": when we cache USD stages, we can only combine *time samples*. If you only author default values , we don't convert these to time samples (so as to keep the USD size & processing cost low), but this means if you have a time-varying default value, bad things will happen.

In your scene, I see that the camera's aperture and clipping planes aren't consistent from one camera to the next.

I'm looking into more elegant solutions to deal with these workflows but, in the interim, you can do something to "trick" Houdini by changing, for example, your horizontal aperture from "41.345" to "41.345 + $F*0". This will evaluate to the same value, but will force Houdini to treat this as animated, and generate time samples that can then be stitched together.

Note you'll have to do this on all the cameras. Every attribute that differs between the cameras *must* be represented using USD time samples for the caching to merge them.

Ah! I'm honestly not even sure why I did that but I'm glad I did as it gave me this valuable additional info. I figured this setup would have its little pitfalls but think you sorted them all out for me. I'll either do just this (checked, works) or setup the cameras with the same values unless animated.

You probably have more elegant solutions but making sure all static values are re-evaluated upstream if the switch input has changed would be a welcome fix.

Big thanks!

Dronson
I would love to see....NURBS. SideFX please add NURBS functionality to H20! )

After several years in Alias Autostudio (really old software) i dream of mix power parametric surfaces (surf. evaluations, precision, g2 and g3 blending and etc) and power of houdini tools.

Autodesk Dynamo - absolute shame ))

Seeing as I doubt Houdini will ever catch up when it comes to direct modeling I too would love to see it introduce parametric modeling. What's out there right now (Rhino/Moi3d/Autodesk's stuff) doesn't seem to gain traction in games/animation/vfx, while parametric is a much better suited way of working for some tasks. Blender's modeling stack with all its addons leveraging it and Modo's meshFusion sits somewhere in-between the two imo, but they're still far from a replacement. I've work in all industries mentioned above but not seen a single person use a CAD software, even for car modeling. It's quite nuts.. but I get it, the CAD-type softwares out there take a while to learn and are often not very intuitive for a modeler used to something like Blender or old-schoolers still using Maya for modeling.

I hadn't even considered this in Houdini, but makes a lot of sense for SideFX to pursue. Would love to see it!

robp_sidefx

RumbleMonk
I'm wondering how Houdini then figures out the correct motion blur samples for frame 26, which is the first frame of the second camera. That second camera would look at 25.75 and 26.25 for the motion blur samples, but if the two camera layers are treated "as representing different time samples of the same entity and combine them as desired" why does Houdini not grab the transform of frame 25.75 from camera1 and the transform of frame 26.25 from camera2, and essentially render a very wrong motion blur on frame 26 as a result?

That's an excellent question, and ties in with the change I made to the Cache LOPs in your scene (specifically setting it to "Cache Current Frame Only" and, more importantly, enabling "Subframe Sampling"). With the LOPs set up like that, when we're on frame N we will cache time samples for N-0.25, N, N+0.25. This means on frame 25, we'll get the left camera generating 24.75, 25.00, 25.25. On frame 26 we'll get the right camera generating 25.75, 26.00, 26.25.

Note that this works because the Cache LOPs come *before* the Switch LOP. On frame 26, the Switch only considers the right input. Upstream to the right, the Cache LOP can do as it sees fit (i.e., cook & cache at any time), which is how it is this right camera that ends up generating the 25.75 time sample. If the Cache came *after* the Switch LOP, then when it tried to cache 25.75 the Switch would divert it to the left and then for 26.25 to the right. You (probably) could work around this by setting the Switch's transition time to be 25.5 (rather than 26).

Regardless how you setup the caching, it's definitely important to have samples that bracket the range of the camera shutter. By this I mean if you changed your camera's shutter from (-0.25,0.25) to (-0.5,0.0) to slightly offset the motion in time, the renderer would query USD for time data at 25.5 which, since it wasn't explicitly cached, would be interpolated by blending the 25.25 and 25.75 samples - giving you "a very wrong motion blur" indeed.

Does that make sense?

This makes plenty of sense, absolutely. Thanks once again Rob. Awesome.

Alright, maybe last question - I moved my cameras from my massive file into this one and set caching etc as per your file. I even brought in the cameras only into your file to make sure I hadn't missed anything but while the cameras switch correctly they seem to be zooming in differently when comparing the live cam data to the cached cam data.

I've attached 2 images showing frame 700 after caching the camera, then switching it on and off. Some cameras seem to be ok, some less so.

It looks like some sort of film back issue, but that's not part of the cameras getting cached.. or maybe the focal length doesn't get looked at in the same way as the transforms inside the configurelayer node? One step closer, would love to hear your take on this one as well if you have a moment.

Your help is extremely appreciated by the way, I've spent days trying to figure this out.

Cheers!

Thanks so much!

This seems to be a very simple fix indeed. I think I understand most of this, and the concept of stronger layers explains why this sometimes worked and sometimes did not (at least while rendering without motion blur) as I guess some camera layers just "naturally" overrode the previous camera layer during a camera cut. I have one question though:

You say "When we (Houdini) combine two layer stacks during caching, we compare save paths to find correspondences". I'm wondering how Houdini then figures out the correct motion blur samples for frame 26, which is the first frame of the second camera.

That second camera would look at 25.75 and 26.25 for the motion blur samples, but if the two camera layers are treated "as representing different time samples of the same entity and combine them as desired" why does Houdini not grab the transform of frame 25.75 from camera1 and the transform of frame 26.25 from camera2, and essentially render a very wrong motion blur on frame 26 as a result?

Big thanks again!

robp_sidefx
I can reproduce what you're seeing, will investigate!

Hi again Rob,

If this will be a confirmed bug, would the simplest way to do this to break out a bunch of ROPs instead with merges of each camera leading into each ROP? I'd also of course have to set the frame range per ROP.

I have a 4min long sim with multiple cameras and 20 or so camera cuts. I was hoping to just render it all in one go, so hoping you have a solution still. I also hope this mentioned alternative solution isn't the easiest one.

Thanks.

robp_sidefx
I can reproduce what you're seeing, will investigate!

That's half a success! Eagerly looking forward to any findings!

mtucker
A few questions...
1. What isn't working for you in this file? It seems to be doing what I'd expect...
2. Why are you controlling the switch with an edit context options LOP? There's nothing wrong with it, it just seems like an unnecessary additional node, when you can just animate the switch directly.
3. What is the purpose of the SWITCHING_TO_CACHE_DOES_NOT_WORK switch LOP? You can just put the filecache1 LOP there, and the "Load from Disk" toggle on that LOP effectively does the same thing the second switch is doing.

Thanks for looking into this!

1. The switch works, until I render it. If you run the filecache, then use the switch to check the cache against the 'live' setup you'll see the cached output does not pick up the second camera. The live setup works only in Houdini viewport. Even rendering Karma in the viewport is fine. Rendering to disk does not pick up the second camera, nor does the filecache1 (after you've cached it, obviously ).

2. I tried animating the switch, same problem. I'm not married to a specific solution, I just want a sequencer type USD camera setup with motion blur rendering correctly in stage.

3. The purpose of that switch is for troubleshooting, so it's easy to compare the live setup vs the busted filecache1, which of course I'm expecting to be the same. And again, first camera looks fine, second camera does not get picked up by the cache, which is also not picked up when rendering to disk.

Thanks again.

jsmack

RumbleMonk
Does anyone know how to get this to work? I am switching between the cameras using an editcontextoption node, but animating the switch with keyframes does not make a difference.

I wouldn't expect the switch to be animable. What are you trying to achieve with two cameras and a switch?

I have a large animated setup and would like to work out my cameras inside the same file, essentially I want to use something like a camera sequencer in stage.

The switch1 is animatable by the way, it just doesn't work for me when I either render the frames (rendered frames don't match Houdini viewport), or when I cache the filecache1 node.

To see what I mean you can try caching the filecache1 node, go to the second half of the timeline, set viewport to look through the correct camera (duh), then use the SWITCHING_TO_CACHE_DOES_NOT_WORK switch to compare the live camera setup with the cached camera setup. The cache does not pick up the second camera.

Btw cache1 and cache2, right after the cameras, are just there to get camera motion blur to work.

I'm trying to render a sequence with USD cameras, motion blur and using a switcher.

I kept rendering this and it failed to pickup the camera after the switch, sometimes the image is totally skewed and/or cropped, sometimes the wrong camera get picked up.

So I figured I'd throw a filecache in and render with that, and of course the filecache doesn't pick up the correct cameras either, but at least that's faster to debug than rendering.

But.. I'm still stumped.

Does anyone know how to get this to work? I am switching between the cameras using an editcontextoption node, but animating the switch with keyframes does not make a difference.

Would appreciate any and all help. I've tried for a long time now, am an intermediate USD user but feel free to reply as if I'm a right noob.

Thanks.

Hi,

I have an .hda that allows a Maya user to pick a .bgeo particle sequence. When I use Maya's instancer with custom per particle attributes to randomize e.g scale and object index (if instancing more than 1 mesh) it seems to initially work, but after restarting the Maya session it seems as if these custom per particles attributes aren't used at all anymore.

They are both randomized via a simple creation expression. I'm pretty sure there's something wrong with how Maya connects to the cache that the .hda is loading. Resyncing the asset e.g kills the expressions, but that's something I can stay away from..

Should just loading a particle sequence in Houdini Engine then instancing in Maya with per particles attributes like this work? Do I need to setup all the randomization on the Houdini side instead?

Tried in Maya 2018 and Houdini18.

Thanks.

I've just started to look at Houdini but find the way rotation and translation works a little too pinicky for my liking.

Is there a way to translate in screen space for instance, a la Maya? At the moment I keep having to position an object once for XZ pos and then again in Y to get it in place.

If anyone knows how to make Houdini a little bit closer to Maya when it comes to the simple Xform controls (alt + clicking on handles to lock in axis, alt + click in middle of handles for screen space etc) it'd be great to hear. Or just how to get the Houdini controls to be quicker..?

Thanks!