Forums Solaris and Karma Looping USD VDB Volumes Behaving Strangely [SOLVED]

Looping USD VDB Volumes Behaving Strangely [SOLVED]

   2177   11   1
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Hello Wizards! I've done a search through the Solaris and Karma forums here and have found some info that does help me, but not all the way through my troubles.

I'll include as much info as I can here and of course, the .hip files and supporting cache.

I have a 71 frame looping VDB smoke sim that I've cached out making sure to add the correct USD configure 'Import Path Prefix' and 'Sample Frame' attributes.


I've loaded that .bgeo cache into LOPs with a Geometry Clip Sequence node and set the 'Clip Primitive Path', 'Start Frame' 'End Frame' and 'Loop Frames' settings.

I've then re-export that as a single small USD file that references the previously exported .bgeo sequence.


I've setup my LOP network as follows:


The reference node brings in the USD file:


..and the Instancer successfully scatters the instanced smoke caches:


Inside the Instancer node I've made sure to setup the correct frameoffset attributes per point:
f@frameoffset = (rand(@ptnum)*71 + @Frame)%71;

..and then after the Instancer I'm using the Retime Instances node randomly set the frame offset of each instance:


All plays nicely until further down the timeline (and at rendertime) where the instances stop in place, freeze, or jump back to another frame. The instances do not loop.

This has been a pretty tough setup for me to get this far on. I'd love some insight into what might be wrong. Any ideas?

.zip attached with hip file and caches
Edited by GlennimusPrime - 2024年6月4日 19:44:49

Attachments:
Screen Shot 2024-05-22 at 2.38.41 PM.png (135.8 KB)
Screen Shot 2024-05-22 at 2.40.45 PM.png (90.3 KB)
Screen Shot 2024-05-22 at 2.43.33 PM.png (22.3 KB)
Screen Shot 2024-05-22 at 2.44.57 PM.png (65.6 KB)
Screen Shot 2024-05-22 at 2.46.00 PM.png (165.3 KB)
Screen Shot 2024-05-22 at 2.46.57 PM.png (151.8 KB)
Screen Shot 2024-05-22 at 2.48.43 PM.png (195.2 KB)
usd_instancing.zip (4.1 MB)

 Report
User Avatar
mtucker
スタッフ
4525 posts
Joined: 7月 2005
Offline
 
The issue is that nowhere in this setup (that I can see) have you done anything to actually make the smoke "loop". The most obvious place to do this would be in Geometry Clip Sequence LOP which has controls for looping. In USD, even when using value clips, looping never happens "automatically". You must always explicitly author a long animation with looping built in for the maximum duration that you may want to loop over.

That said, another common mistake you've made here is to use a value clips to loop a volume simulation. Volumes are the absolute simplest primitive in all of USD, and derive no benefits from being embedded in a value clip (I've ranted about this in a couple other threads so I won't go into it again). But I'd recommend just using a Volume LOP instead of a Geometry Clip Sequence LOP. Set the volume LOP's volume file path to a simple expression that will do the looping for you, like 'foo.`$F % 71 + 1`.bgeo.sc', and author a nice long 2000 frame loop like this. This should cook quickly enough that you probably don't need to write this out to disk as a USD file as you've done with the value clip, but of course you can if you'd like.
 Report
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Thanks for your reply mtucker.

mtucker
The issue is that nowhere in this setup (that I can see) have you done anything to actually make the smoke "loop". The most obvious place to do this would be in Geometry Clip Sequence LOP which has controls for looping. In USD, even when using value clips, looping never happens "automatically". You must always explicitly author a long animation with looping built in for the maximum duration that you may want to loop over.
The first step in LOPs was setting the length and loop of the pre-cached smoke.

I can see this looping correctly in LOPs once this setting had been applied, so had guessed that this info would follow through when exporting as USD.

Further down the chain, the reference LOP is bringing that USD back in, and does seem to loop past the original length of 71 frames, but then stops at frame 130. Why loop past 71 frames, but then stop at 130?

mtucker
That said, another common mistake you've made here is to use a value clips to loop a volume simulation. Volumes are the absolute simplest primitive in all of USD, and derive no benefits from being embedded in a value clip
This has been a learning exercise for me and from what little info I found here, on Odforce and the Sidefx Discord channels, it sounded like making use of the usd configure SOP and setting the start and end frames on the geometry clip sequence LOP was required in helping LOPs work out which frame the cache needed to play back at the correct time. If that is not the case like you say, that's one additional step I shouldn't need to take in order to get this working, which is great. A smaller network is a faster one right?

I'll look into looping the smoke volume another way and see if I can get this working as you say. This is a simple test for a much larger scene and saving disk space is a high priority for us. Ideally we would like to make use of that single tiny usd export file to hold all the necessary data to loop the smoke once brought back into LOPs.

**See my next post down on how this was solved**
Edited by GlennimusPrime - 2024年5月22日 21:42:27

Attachments:
Screen Shot 2024-05-23 at 9.15.49 AM.png (16.6 KB)

 Report
User Avatar
npetit
スタッフ
413 posts
Joined: 2月 2008
Offline
 
A couple of things to note.

The first issue is your load_bgeo_as_geoclip Geometry Clip Sequence LOP is set to sample frame range for frames 1-143.
This will limit your loops to run within that range only. So anything with a negative frame offset will start frozen, and anything with a positive frame offset will end frozen for as many frames at the end. If you extend your timeline to frame 200, you'll see the imported volumes stop playing after frame 143.

Set the range on the node to -500-500 and since all the time samples will be baked for that range, you only need to cook 1 frame of that usd, no need for any more than that.

On the Retime Instance LOP, the frameoffset specifies a static offset. For example, you want to delay an instance by 5 frames, you'd set the frame offset to -5. Animating it doesn't work as the LOP is heavily optimised to minimize the expensive process of creating references, and will kill performance.

In the Instancer LOP, change your VEX snippet from 
f@frameoffset = (rand(@ptnum)*71 + @Frame)%71;
to
f@frameoffset = rand(@ptnum)*71;


In your case, your frameoffset looks like the actual frame of the cache you want played back. If you want to control the playback that way you can, it will impact performance though.
On the Retime Instances LOP, select the "Explicit Frame" retime method, and change the Primvar to "frameoffset" so it reads your initial animated frameoffset primvar.
 Report
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Thank you so much npetit, some super helpful info there. Everything seems to be working correctly now.

One of the strangest parts of this for me to understand was needing to set the timeline overlength and also just saving as one single frame usd.

The info on how the instancer LOP works was super helpful too. I had no idea it wanted a static offset amount and not to just read the frameoffset number on a per frame basis.

Here's the hipfile if anyone else is having troubles with a similar setup:
Edited by GlennimusPrime - 2024年5月22日 21:39:25

Attachments:
usd_instancing_v02.zip (4.1 MB)

 Report
User Avatar
npetit
スタッフ
413 posts
Joined: 2月 2008
Offline
 
As Mark said, you don't need the Geometry Clip Sequence for volumes, extra caches and reference LOP. Use a Volume LOP directly with the looping done on the filecache attribute directly.

Here is an updated hip file.

Attachments:
usd_instancing_v03.hiplc (1.5 MB)

 Report
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Your hipfile v03 isn't working for me. It looks fine in the viewport, but the render shows different results unfortunately.

Render frame 1 - Everything starts properly with the random frame offset:


Render frame 142 - All caches come to a halt on the same cache frame:


After more testing, I've only been able to get this working properly with my hipfile v02 version up above.

This only seems to be the case when working with volumes though. I tried a looping .bgeo geometry sequence loaded via a 'geometry clip sequence' node piped directly into the instancer and that looped correctly without the additional caching to usd step.
Edited by GlennimusPrime - 2024年5月23日 20:31:53

Attachments:
Screen Shot 2024-05-23 at 7.24.47 PM.png (99.0 KB)
Screen Shot 2024-05-23 at 7.22.47 PM.png (99.7 KB)

 Report
User Avatar
npetit
スタッフ
413 posts
Joined: 2月 2008
Offline
 
In the usd_instancing_v03.hiplc hipfile, select the "usdrender_rop1" USD Render ROP and under Output > USD Export set the Filter Time Samples parameter to Never.

By default it tries to optimise the output by trimming any time samples outside of the output frame ranges, which unfortunately also trims the required time samples needed for the retimes. By setting it to Never it doesn't do anything with the time samples and your renders will match your viewport.

If you cache the output of the volume LOP with the 2000 time samples to disk first, you can happily ignore this option.
 Report
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Thanks npetit, that last little step has done it.

Setting the 'filter time samples' option set to 'never' in this tiny test shot is doing the trick, but I'd like to ask if this could be a bad idea to do in a very large scene with lots of long heavy volumes on a much larger scale? Just asking, as you say it's a way of optimising the output by trimming unnecessary time samples. In the case of a much larger scene, would it be better practice to first cache the volume LOP to usd with those additional time samples and then leave this 'filter time samples' at the default setting?
 Report
User Avatar
npetit
スタッフ
413 posts
Joined: 2月 2008
Offline
 
GlennimusPrime
In the case of a much larger scene, would it be better practice to first cache the volume LOP to usd with those additional time samples and then leave this 'filter time samples' at the default setting?

Yes, absolutely. Try and contain the excess time samples to the prims that need retiming only, and enable the time sample filtering so as to keep file size down to a minimum.
 Report
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Thanks so much for all the useful information!
I have one last question regarding triggering the start frame of instanced volumes and geometry caches.

I have a working example here of a line of instanced volumes that use the point @frame attribute to explicitly read the correct cache frame using a retime instances LOP. The volumes play with offset starting times from left to right:


When I use a similar technique with geometry (animated particle burst cache) all instances play at the same time.


I've tried this technique using a reference LOP, as well as the same usd geometry cache method from above, but no luck in offsetting the start times of the geometry cache. Only the volumes.

.hipfile v05 attached

Attachments:
Screen Shot 2024-05-28 at 2.54.37 PM.png (95.9 KB)
Screen Shot 2024-05-28 at 2.59.16 PM.png (57.1 KB)
usd_instancing_v05.zip (2.7 MB)

 Report
User Avatar
GlennimusPrime
Member
85 posts
Joined: 6月 2019
Offline
 
Solved with some help over on the Odforce forums.


Offsetting the volume .bgeo sequence is easy enough, as long as the volume LOP Sampling Behaviour is set to the length of the .bgeo smoke cache.


Offsetting the geometry / particle .bgeo sequence has a few more steps.
The Geometry Sequence LOP requires an Import Path Prefix:


The Cache LOP should be set to Always Cache All Frames and the length of the .bgeo sequence should be set:


The Instancer LOP needs the same Prototype Primitive path that has been set on the Geometry Sequence LOP:


.hip file and small .bgeo caches attached for anyone interested.
Edited by GlennimusPrime - 2024年6月4日 19:44:17

Attachments:
Screen Shot 2024-06-05 at 11.32.40 AM.png (145.3 KB)
Screen Shot 2024-06-05 at 11.33.22 AM.png (34.4 KB)
Screen Shot 2024-06-05 at 11.36.32 AM.png (13.5 KB)
Screen Shot 2024-06-05 at 11.37.21 AM.png (42.7 KB)
Screen Shot 2024-06-05 at 11.38.59 AM.png (15.6 KB)
usd_instancing_v07.zip (2.7 MB)

 Report
  • Quick Links