mtucker Indeed. Please give it a try and let me know if the performance has gotten to where you want it to be. Thanks!
Pretty sure that our need for performance will never be satisfied..and as soon things get faster, the workload gets bigger. But this is very appreciated and I am going to test it today
So what is the recommended way to handle large FX caches in Solaris then?
Right now when we want to render, we are required to load every single frame of the bgeo sequence into RAM (not all at once). With longer shots it also means longer caching of the USD ROP for the whole stage because of the loading of the primitives. There was the update of the Geometry Clip Sequence node with the All Clip Files Have Matching Scene Graph Structure checkbox. When recaching this geoclipsequence into its own USD, I have to sample on the node the whole timeline, but then the process is relatively fast (few seconds at most). But then I have a problem with referencing the usd back in stage as now this usd is loading all the timesamples at once (my session usually crashes before it loads, so this is just a hypothesis, not confirmed).
Back to my original question then. What is the recommended way to handle large or long bgeo caches in Solaris? How do I reference it back in stage, so the USD Stage is lightweight and only references the bgeos either in previous USD file or in itself without loading all the frames during the process?
The answer to your question is "the geo clip sequence LOP". If it's not working as expected, or not generating results that work for you, then please provide some kind of example/demo file that shows this happening. This is the intended and expected workflow, so if it's not working, we'd like to fix it.
Loading a properly structured value clip into a scene should not cause all the clip files to be opened at once. And the geo clip sequence LOP should always be authoring properly structured value clips.
I did notice you saying that you sublayered the value clip file into your scene, which is a bit unusual. Generally when working with value clips I've seen the referenced onto a stage rather than sublayered. I don't think that should matter, but it might be worth testing...
Does this workflow support a sequence of vdbs? Plugging a volume LOP into the 2nd input it correctly shows it as a value clip, but caching it hangs. Alternatively directly pointing to the vdb sequence the clip only caches one frame, and lists the volume filePath as a Default Value instead of Value clip. Not sure where I'm going wrong.
Definitely use a Volume LOP, and using value clips buys you absolutely nothing in this situation. VDBs are "large geometry", but not in any sense that USD is aware of. USD handles VDBs like texture maps - simple paths to files on disks containing data that only the renderer cares about. Value clips are useful to split large amounts of USD data between multiple USD files on disk. But VDB files are already organized this way, so adding value clips into the mix adds complications to the authoring workflow and provides no advantages to the runtime or rendering.
To be clear, you _can_ use a volume LOP and value clips together, but there isn't enough information in your description to provide any useful analysis of why your setup isn't working, and I'm not bothering to ask additional questions about it because in the end I'll still tell you to stop trying to use value clips
what is the recommended way for deadling with a sequence of heavy animation .usd files that I need to layer over the static .usd file. for anim I am caching only points and velocities while the static has the bulk of the data. geoclip sequence is slow for me but I am using 20.0.547, should I upgrade or it wont matter if I am dealing with .usd files not .bgeo?
