How would one go about retiming a usd file?
I've referenced a usd and then tried to use a timeshift lop but it doesn't seem to have any effect.
The usd has some animated geometry (animated xforms not deforming geo) and I want it to play for a certain number of frames before freezing for the rest of the shot.
Retime USD
3873 16 4
-
- pixelninja
- Member
- 29 posts
- Joined: March 2017
- Offline
-
- mtucker
- Staff
- 4438 posts
- Joined: July 2005
- Offline
-
- pixelninja
- Member
- 29 posts
- Joined: March 2017
- Offline
Thanks!
It seems like the primpattern parameter is a little finicky and I just wasn't putting in a path it liked.
For crag: "/crag/*" doesn't work but "/crag/geo/*" does.
In my case only "*" works. I tried targeting a particular scope in my component ("/componentname/geo/*") and it does nothing. I've probably just made a bad component.
For future reference: Is it possible to use this to retime particles or deforming geo too? A quick test seems to indicate no but I could just be missing something or doing something wrong.
It seems like the primpattern parameter is a little finicky and I just wasn't putting in a path it liked.
For crag: "/crag/*" doesn't work but "/crag/geo/*" does.
In my case only "*" works. I tried targeting a particular scope in my component ("/componentname/geo/*") and it does nothing. I've probably just made a bad component.
For future reference: Is it possible to use this to retime particles or deforming geo too? A quick test seems to indicate no but I could just be missing something or doing something wrong.
Edited by pixelninja - March 27, 2023 17:31:50
-
- spektra
- Member
- 25 posts
- Joined: June 2022
- Offline
/crag/* is only targeting the geo and mat scopes. /crag/** in that case would target any levels of hierarchy.
https://www.sidefx.com/docs/houdini/solaris/pattern.html [www.sidefx.com]
https://www.sidefx.com/docs/houdini/solaris/pattern.html [www.sidefx.com]
-
- pixelninja
- Member
- 29 posts
- Joined: March 2017
- Offline
-
- pixelninja
- Member
- 29 posts
- Joined: March 2017
- Offline
Just in case anyone else runs into the same issue I figured out why my particle test didn't work.
I had packed the particles so that I could bring it into lops alongside other geo in the sop import with prim path attributes.
This caused the particle geo to be converted to a usd instance. Meaning that in order to retime it you'd need a retime instances lop instead of a timeshift.
I had packed the particles so that I could bring it into lops alongside other geo in the sop import with prim path attributes.
This caused the particle geo to be converted to a usd instance. Meaning that in order to retime it you'd need a retime instances lop instead of a timeshift.
-
- mtucker
- Staff
- 4438 posts
- Joined: July 2005
- Offline
You could also have set the SOP Import to import packed prims as "Create Xforms: instead of "Create NativeInstance". Retime instances is more useful for cases where you actually have multiple instances of the same animated geometry, and you want to provide some variation in the playback speed/offset across a set of instances. The Timeshift LOP provides more control, and if you've just got one "instance" you don't lose any performance or memory efficiency by simply not using instancing.
-
- pixelninja
- Member
- 29 posts
- Joined: March 2017
- Offline
-
- fadjo
- Member
- 4 posts
- Joined: March 2016
- Offline
-
- npetit
- Staff
- 357 posts
- Joined: Feb. 2008
- Offline
That should work, and you can see that adding a cache LOP gets the camera to reflect the retime - this looks like a bug.
In the meantime, if you want to retime any particular prim instead of the entire stage, you can do it fairly easily with a Python LOP - you just need to make sure there are timesamples available on the attribs that need retiming.
In the meantime, if you want to retime any particular prim instead of the entire stage, you can do it fairly easily with a Python LOP - you just need to make sure there are timesamples available on the attribs that need retiming.
-
- GrahamDClark
- Member
- 51 posts
- Joined: July 2005
- Offline
Thanks Nick and Mark, I tried a ridiculously slow and super dumb thought exercise with for loop lops that at least worked, then saw this thread and your answers and tried to mod Nicks code to usd retime by attrib. Any recommendations to make it better/more correct?
I would drive the 'timey' attribute by distance or something. And so I think I excluded 'timey' from being also updated in the python. It still gets slow on lots of stuff. Could I vex it for speed?
I would drive the 'timey' attribute by distance or something. And so I think I excluded 'timey' from being also updated in the python. It still gets slow on lots of stuff. Could I vex it for speed?
Edited by GrahamDClark - April 18, 2023 02:44:59
-
- npetit
- Staff
- 357 posts
- Joined: Feb. 2008
- Offline
fadjo
Hello, Is there a way to retime cameras too?
Actually, I spoke too soon. After talking to Mark and looking into the hip file a bit more in depth, the timeshift is doing what it's supposed to, and only offsetting the time samples on the specified prims. The problem is the transform for the camera is coming from its
/camparent which has been omitted from the list of prims to retime. If you add /camto the timeshift LOP's primitives parm, you'll have the camera motion retimed as expected. Now, looking at the viewport after the timeshift LOP, it looks like the whole stage is being retimed - however the time samples that are being displayed are for different frames - but having only 1 time sample on the stage at the current time, that's what's being displayed.
Writing the sequence of frames to disk will fix that, or, dropping a cache LOP either before or after the timeshift LOP will ensure the correct thing is being displayed in the viewport since more timesamples are available.
-
- npetit
- Staff
- 357 posts
- Joined: Feb. 2008
- Offline
GrahamDClark
Any recommendations to make it better/more correct?
I would drive the 'timey' attribute by distance or something. And so I think I excluded 'timey' from being also updated in the python. It still gets slow on lots of stuff.
The only thing I'd change in your code is the
if timey is not None: frame = curFrame * node.evalParm("timescale") - timey
and replace it with
frame = curFrame * node.evalParm("timescale") - (timey if timey != None else node.evalParm("frameoffset"))
this is to ensure you reuse the frame offset from the parm if timey doesn't exist on the current prim as opposed to whatever the last prim with a valid timey attrib set your frame variable to.
Otherwise, if you know you have all the timesamples you care about, you could make the python LOP non-time dependent by grabbing all the timesamples on the animated attribs, deleting them from the attrib and re-applying them with the time offset - this would avoid having you invoke hou.frame(). This is only really an option if the input node isn't time-dependent - you'd get a bigger initial hit but then scrubbing the timeline would be free since the python LOP won't be time-dependent and its result cached.
GrahamDClark
Could I vex it for speed?
You could use VEX, using
usd_attrib(<stage>, string primpath, string name, float timecode);
-
- GrahamDClark
- Member
- 51 posts
- Joined: July 2005
- Offline
-
- nicolaas.tanghe
- Member
- 44 posts
- Joined: March 2023
- Offline
Hello evryone.
I have been running into issues with trying to retime instances and i figured I`d ask here.
the problem is that when i try to retime the instances, they only play when they are at timespeed 1 total.
WHen i try to recreate with a simpler geo and animation it sometimes works .
i`d realy apreciate it if someone could help me out.
I have been running into issues with trying to retime instances and i figured I`d ask here.
the problem is that when i try to retime the instances, they only play when they are at timespeed 1 total.
WHen i try to recreate with a simpler geo and animation it sometimes works .
i`d realy apreciate it if someone could help me out.
-
- npetit
- Staff
- 357 posts
- Joined: Feb. 2008
- Offline
The problem you're having is the timescale applied to animation that happens at frames so large will shift the animation greatly.
For example, if you have animation between frames 1000 and 1200, with a timescale of 0.5, the animation will now exist between frames 500 and 600. So you need to apply a frame offset to compensate for that.
The way the retime works is it first applies the timescale to the animation and then adds the frame offset.
In your hipfile, if you set the frame range start to 1 and scroll the timeline from 1 to 1500, you'll see all the retimed instances flap their wings, however, nowhere within your current frame range.
You have animation from frame 1008 to frame 1048, if you want the timescaled retime to happen within that frame range, set the global frame offset to 0 and the global time scale to 1 to simplify things and change the wrangle to:
For example, if you have animation between frames 1000 and 1200, with a timescale of 0.5, the animation will now exist between frames 500 and 600. So you need to apply a frame offset to compensate for that.
The way the retime works is it first applies the timescale to the animation and then adds the frame offset.
In your hipfile, if you set the frame range start to 1 and scroll the timeline from 1 to 1500, you'll see all the retimed instances flap their wings, however, nowhere within your current frame range.
You have animation from frame 1008 to frame 1048, if you want the timescaled retime to happen within that frame range, set the global frame offset to 0 and the global time scale to 1 to simplify things and change the wrangle to:
f@timescale = rand(@ptnum); f@rand = -1008 + (1008 * f@timescale);
-
- nicolaas.tanghe
- Member
- 44 posts
- Joined: March 2023
- Offline
-
- Quick Links