I've got 300k+ flowers that "grow on screen". Currently, in sops I'm using the spread solver, adding @age+=@TimeInc and then controlling the "abcframe" intrinsic after the copy-to-points sop with the age attr. To render, I'm just sop importing. Obviously this is super memory heavy. Things I have tried:

1. retime instances lop. This effectively de-instances all 300k and takes forever to change frames in Solaris. Also, no memory improvement.
2. In sops, using the "usdFrame" intrinsic instead of alembics. No improvements.

Is there a better way to do this directly in Solaris with stitch clips or something?

Cache your animation to USD instead of SOP Import?

eikonoklastes
Cache your animation to USD instead of SOP Import?

I tried this as well. There were no gains just caching to usd. Huge per frame usd files and no speed or ram savings. Unless there's something missing, but I think I tried the different packed prim options.

If you write out one USD file with the animated "grow" for a single instance, you can use the "retime instances" LOP to create a bunch of different time offset values. Even if each instance is a unique offset time, the resulting USD will be a lot smaller.

In general don't use per-frame USD files. When someone says "cache your animation to USD" that means a single USD file with the animation in it (at least if I'm saying it - I don't want to put words in @eikonoklastes's mouth). Use value clips and per-frame USD files only if you know exactly why you are doing it. If you don't know USD well enough to know why it's better in your current situation it almost certainly is not better for your current situation.

Hope that helps!

mtucker
If you write out one USD file with the animated "grow" for a single instance, you can use the "retime instances" LOP to create a bunch of different time offset values. Even if each instance is a unique offset time, the resulting USD will be a lot smaller.

Hope that helps!

@mtucker thanks for the reply. This is exactly what I tried initially and in fact I've recreated a bare-bones example file that I hope is implementing the exact setup you described, where I cache the source geo to usd and the instance points as well. As you can see from my screencap, once I use the retime instances lop, my houdini session locks up for over 10 minutes. And this example is just 60k points. My actual scene file is over 300k points.

I'm really hoping I've missed something here, because even if the usd ends up being smaller, the workflow isn't worth the tradeoff, because the gl(or vulkan) viewport is realtime-ish and I can iterate, address notes, etc and I just sacrifice RAM.

It may depend on the specific needs of the retime

I personally find the whole usd instance retiming very cumbersome and error prone, especially for birthing and dying particles (since prototypes will get messed up as they are not stable between frames at least not without additional undertaking)
And also the node is too slow especially when you need to pick a specific time rather than consistent scale/offset per particle.

Dealing with it in Mantra is way easier, as packed disk sequence primitives allow you to control exact source frame/time per particle with instant feedback and they don't get messed up for changing particle count

Closest technique I got to that was to import each frame of each sequence as a separate static prim with frame number suffix for the prototype sources, then just pick the one per particle thats closest to desired frame
The downside is no interpolation between source frames (which you'd have to quantize anyway to get at least some instancing)
But at least I got much faster per frame feedback and 1 to 1 match with (per integer frame quantized) packed disk sequences in sops, still not ideal and way more hoops to jump through than I'd like

@tamte that's very clever. I can do the static-prim-suffix method. Thanks for sharing.

In your particular case, using a static frame offset is relatively simple and will allow you to (almost) scrub the timeline in realtime using the retime instances LOP. Here's an updated hip file that uses the frameoffset instead of the explicit frame method.

Using an explicit frame for retiming instances is notoriously slow as it will create new retimed references at every frame. If you don't care about having smoothly interpolated retimed prototypes, creating all the individual frames as prototypes and switching prototypes accordingly is definitely an option as Thomas suggested. You can submit an RFE for us to look at adding it as an option to the retime prototypes LOP.

@npetit wow! Huge improvement over setting explicit frames. Thank you very much. In fact the documentation actually tells you to use frame offset method because it's not time-dependent <facepalm>.

Looking at your file in more detail, if you place a cache LOP after the instancer LOP, you'll get much better performance using the explicit frame method.

The reason is, the retime instances LOP tries to find any duplicate retimed prototype and optimises for those. In order to find matching prototypes it needs to look at the instances' frame value across all available timesamples. With no time samples, it cannot assume anything since the frame values could be jumping around randomly. So in your case, it's creating a unique prototype per instance. Creating 60K new reference prims per frame is going to grind houdini down to a halt.

With a cache LOP after the instancer LOP, it finds 207 unique retimed prototypes, matching the 207 unique retimed prototypes found when using a static frame offset. Without the cache LOP, it's creating 60K unique retimed prototypes.

jarjarshaq
@npetit wow! Huge improvement over setting explicit frames. Thank you very much. In fact the documentation actually tells you to use frame offset method because it's not time-dependent <facepalm>.

Using the static frame offset I'm getting better performance in LOPs with the retime instances LOP than I'm getting in SOPs with the usdframe prim intrinsic...

Yes that is what I found as well. And thank you for the additional info about adding the cache lop if using explicit frame. I'll have to be sure to stay in manual mode to set that up