The options on the Cache LOP in 19.5 are a bit different from 19.0. What is the new equivalent for the old "Rolling Window of Frames" + "Before/After/Inc" behavior?

I assume it would be Subframe sampling

try setting it to -2 2 and samples to 5 to hopefully get cached samples at -2, -1, 0, 1, 2 around current frame, etc;
but again, only assuming from looking at the node

I think the motion blur lop is meant to be the new clean way to set up the rolling frame equivalent.

Motion Blur LOP seems to be just a wrapper around Cache LOP with the same settings for rolling frame window (subframe sampling)

It seems to be adding Resample Transforms option which sounds a little bit odd as it seems like resampling already quantized motion samples into more samples
Why is that necessary, shouldn't every renderer be able to do such interpolation adhoc?
since it doesn't sound like it's evaluating the stage at those finer steps, just interpolating already limited samples from Cache LOP or am I misunderstanding?

EDIT: also as a quick observation the math to compute central difference velocity seems to be wrong, submitted a bug, but in meantime its better to avoid central difference mode

EDIT2:

sidefx changelog
19.5.348
Fixed bug computing central difference velocities in the Motion Blur LOP. This node now uses a SOP Modify and the Trail SOP, which is both faster and should match other cases where the Trail SOP is used to compute velocity

tamte
Why is that necessary, shouldn't every renderer be able to do such interpolation adhoc?
since it doesn't sound like it's evaluating the stage at those finer steps, just interpolating already limited samples from Cache LOP or am I misunderstanding?

Renderers don't get the chance to. Hydra evaluates interpolated time samples and sends those to the renderer. I'm guessing this way, the renderer can be sent good samples with proper interpolation instead of relying on hydra which is known to be wrong.

jsmack
Hydra evaluates interpolated time samples and sends those to the renderer. I'm guessing this way, the renderer can be sent good samples with proper interpolation instead of relying on hydra which is known to be wrong.

how does renderer then further interpolates those samples? are you saying it doesn't?
wouldn't that make all motion blur sampling setting on renderer redundant if it can't interpolate timesamples it got from hydra itself?

tamte

jsmack
Hydra evaluates interpolated time samples and sends those to the renderer. I'm guessing this way, the renderer can be sent good samples with proper interpolation instead of relying on hydra which is known to be wrong.

how does renderer then further interpolates those samples? are you saying it doesn't?
wouldn't that make all motion blur sampling setting on renderer redundant if it can't interpolate timesamples it got from hydra itself?

it can interpolate the samples from hydra, but the samples from hydra are themselves already interpolated without any way to control it.

Motion Blur in 2022. So simple.

Tim Crowson
Motion Blur in 2022. So simple.

reconstructing a 4D continuous function from discrete samples is never simple, especially when those samples are two or three layers of abstraction removed from you.

That's my point. It's 2022 and MB is still difficult.

It mostly feels like we have subpart workarounds for things that worked great in Mantra
MB interpolation is just one thing out of too many

But I still can't understand why interpolating in LOPs between cached samples and baking those interpolated samples is necessary, there is seemingly no new info gained from it

tamte
It mostly feels like we have subpart workarounds for things that worked great in Mantra
MB interpolation is just one thing out of too many

But I still can't understand why interpolating in LOPs between cached samples and baking those interpolated samples is necessary, there is seemingly no new info gained from it

so you can feed the renderer 'good' samples to interpolate. Hydra only does linear interpolation.

jsmack
Hydra only does linear interpolation.

so
- Cache LOP creates discrete timesamples (A)

- the Resample Transform node linearly interpolates those (A) timesamples and produces more inbetweens (B), it doesn't evaluate stage at more granular steps so (B) are theoretically just unnecessary data
it also does just linear interpolation between closest timesamples (no cubic or subd)
however it does slerp transforms, which is correct for matrices

- so it sounds like you are saying that Hydra is in a way between renderer getting timesampes directly and does additional interpolation (maybe based on renderers mb settings?) to provide to the renderer
so by saying Hydra doing just linear interpolation you mean it does per component matrix interpolation instead of slerp? (both are linear, but the first one obviously wrong)

if that's the case then it sounds like Hydra interpolatin even (B) will not be exactly correct if they dont align
having to have them aligned sounds super painful especially for already precached usds

so it sounds indeed like a workaround until Hydra gets fixed or bypassed by renderers for interpolation of timesamples

tamte
if that's the case then it sounds like Hydra interpolatin even (B) will not be exactly correct if they dont align
having to have them aligned sounds super painful especially for already precached usds

yes. It's the same as writing ifds. When you write an ifd, the transforms in your scene are compute at the time sample of the ifd--so it aligns with the shutter. In the case of ifds though, there is only one layer--the renderer gets the samples directly. Creating the timesamples in the usd to align with the shutter is a way to bypass hydra's interpolation.

to me it looks like the transform samples are interpolated from already limited cache samples

So if I want overall 2 time samples to not waste memory on deformation samples

But I want 30 xform samples, if the transform samples are interpolated from those 2 cached samples it's gonna miss all the unique movement in-between if the motion is defined procedurally in lops etc

It doesn't sound like IFD in that regard
I feel like there should be inherently different timesamples steps for caching and also writing out xforms compared to other values

Just resampling xforms doesn't make that much sense to me, it really sounds like only working around broken Hydra interpolation, but it's not gonna capture fast moving objects at specified steps

If you are authoring your transforms in LOPs, the best solution is to use the subsampling controls on the Transform and Edit Properties LOPs. Then you really do get the full-fidelity subframe time samples without having to cache every prim in the scene, and you only get the subframe sampling on the objects that need it.

The Resample Transforms LOP is indeed designed to get around the poor job hydra (and even USD itself) does when interpolating transformation matrices. This LOP uses a much better method for calculating the interpolation. As you point out though, it is still just interpolation. But at least you can get reasonable looking blur on helicopter blades and other quickly spinning objects when all you have is a USD file with inadequately time sampled transforms already baked in.

thanks Mark, I didn't know about separate sampling options on Transform or Edit Properties, it's good to know that different properties can be set to sample differently without having to write them to disk at different rates first