tamte
2. Geometry Clip Sequence LOP seems to be able to reference .bgeo* files directly and I'd assume probably other like .vdb, so I'd assume there should be no need to recache them again as .usd, but I haven't tried
https://youtu.be/R4SLw5EdzQ8?si=NZ4F9U2zwDvISC0s&t=1815 [youtu.be]

sekow
in the presentation you can see the lop went time dependent

robp_sidefx

sekow
in the presentation you can see the lop went time dependent

Yes, one of the things I didn't show (but really should have) is that, as with many of our other LOPs, we can generate a range of time samples directly from this LOP and avoid introducing the time dependency.

sekow
I wont be going around the fact that I need to cache those timesamples out as USD

def Xform "geoclipsequence_noTimeDep" (
    clips = {
        dictionary default = {
            double2[] active = [(1, 0), (2, 1), ...]
            asset[] assetPaths = [@../geo/sphere.0001.bgeo@, @../geo/sphere.0002.bgeo@, ...]

robp_sidefx
If you have "Flatten Clip Files" disabled (which I appreciate I left enabled in the screenshot & example above), then there shouldn't be any BGEO->USD conversion. You'll end up with a direct link back to the BGEO in your scene.

def Xform "geoclipsequence_noTimeDep" (
    clips = {
        dictionary default = {
            double2[] active = [(1, 0), (2, 1), ...]
            asset[] assetPaths = [@../geo/sphere.0001.bgeo@, @../geo/sphere.0002.bgeo@, ...]

sekow
I am just trying to avoid sitting here and waiting for 500 frames of heavy geometry getting loaded into ram just to be written down into a dictionary inside the usd.

tamte
Why would it need to load any file to memory?

protozoan

tamte
Why would it need to load any file to memory?

It used to be like that, but that was a long time ago and now should not be necessary anymore. The value clip generation should zing just through, even for large datasets.

robp: A lot of people seem to struggle with this. Maybe this warrants a case-study tutorial like "Solarifying production caches efficiently from start to finish" without skipping any checkboxes etc.

tamte

sekow
I am just trying to avoid sitting here and waiting for 500 frames of heavy geometry getting loaded into ram just to be written down into a dictionary inside the usd.

Why would it need to load any file to memory?
It just needs to write timesamples for file paths over that range, I imagine that's reasonably fast

But again, I haven't tried, but that's what I assume it would do in that mode

mtucker
And yes, we definitely need to put out more information about this process.

mtucker
The other option (which already exists as an RFE) is to provide a checkbox on the Geo Clip Sequence LOP that says "trust me, my scene graph hierarchy doesn't change from file to file, just generate the manifest from the first BGEO file". This will make the "multi frame" cooking mode of the Geo Clip Sequence very fast even for BGEO sequences as it will only need to load one BGEO file to create the manifest. Of course depending on your BGEO sequence, turning on this check box may generate an incorrect manifest file, but at least you'll be able to control this tradeoff between speed and "correctness". We don't have a timeline for this change, but this issue does keep coming up.

20.0.577
Added a new toggle to the Geometry Clip Sequence LOP which allows the topology and manifest files to be generated from a single clip file instead of using all the clip files. This can make this node much, much faster, and reduce memory usage, especially when using BGEO files for the clip files. Also made some other performance improvements to this node which should apply in all situations.

Thu. January 4, 2024