Hi,I have a strange problem about usd cache and virtual memory!
I have a usd file about 40GB, it is a big tree with 500 frames animation,
problem is when i load it into LOP, it takes 40GB virtual memory,if i load another different tree(about 25GB),
now they take up 65GB virtual memory and i can't load the third tree,cause i don't have enough disk space for virtual memory.
I tried separate file per frame and use USD Stitch Clips ROP to generates a single USD file containing these sequences.
This solves the virtual memory problem，but another problem is every time i load this USDStitchClips file,it gets very slow.
looks it have to scan 500 frames file every time i load it.
it gets very very very slow when i load 10 different trees.
So, how did you solve this problem?
It confused me for two weeks.

I assume you are on Windows, because this bizarre handling of virtual memory and memory mapped files seems to only be an issue on Windows. On Linux and MacOS you can memory map as many files as you want and it doesn't seem to conflict with the OS virtual memory pool, so you don't hit these limitations. But I believe there isn't anything we or Pixar can do about this, so alternative strategies are required.

Value clips are definitely going to be a little slower than a single huge file, but not enormously so. And the initialization cost should be minimal as long as you generate a manifest file explicitly along with the value clip template file from the USD Stitch Clips ROP. What version of Houdini are you running?

Thanks reply,mtucker!
yes,i am working on windows and using houdini 19.0.531.
i think i have to try USD Stitch Clips again,maybe i missing somthing.

Hi,mtucker!
I tried USD Stitch Clips again,and it still slow.
it takes 5-7 seconds per asset when i load it.
if there are 10 assets in my scene,so i have to wait for 50-70 seconds when i load this scene.
so,my solution is use USD Stitch Clips ROP to generates a single USD file containing just one sequence file.
when rendering, i set the clips metadata back with VEX like below.
---------------------------------------------------------------------------
int has_clips = usd_ismetadata(0, s@primpath, "clips");
if(has_clips)
{
usd_setmetadata(0,s@primpath,"instanceable",0);
usd_setmetadata(0,s@primpath, "clips:default:templateStartTime",@Frame-1);
usd_setmetadata(0,s@primpath, "clips:default:templateEndTime",@Frame);
}
----------------------------------------------------------
for now ,everything looks fine.but I don't know if there will be other problems if i did this.
oh,by the way,if i reference a asset and set (make instanceable) on, value clips dosen't work,so i have to set instanceable off.
i known this uses more memory.
so,instanceable primitives and value clips dosen't work together，right?

last problem is about valueclips node in LOP(see the third picture)
i don't known if this is normal?

Just a comment on USD animation caches in general (value clips or single-file): You can use the "Set Default Values" to specify attributes that you know aren't animated, which should cut down on file sizes and memory use. Think of "Default Values" as "Static Values". The name is unfortunate and not intuitive right-away, but this is how USD labels/identifies values that aren't animated (i.e. time sampled). It's also a good idea in USD to make sure you aren't importing unnecessary attributes - if you are caching out animation, and you have lots of attributes from vellum/kinefx/etc... (especially string attrs) you can make your USD files very large.

We don't yet have a way to handle mixed static/animated cases automatically yet; it's something we're aware of, but this might help make your USD Exports and Value Clips a bit easier to work with.

thans for your comment, goldleaf!
"Default Values" is very usefull to make the cache file smaller，i did this whatever export a single file or sequence files.
for now,seems the valueclips donsn't work very well for me,i'll keep trying, hope i can figure out.
many thanks!

ccyzkk
thans for your comment, goldleaf!
"Default Values" is very usefull to make the cache file smaller，i did this whatever export a single file or sequence files.
for now,seems the valueclips donsn't work very well for me,i'll keep trying, hope i can figure out.
many thanks!

I think don't use the value clip lop, it's not optimal since you won't have the manifest and topology files. Use the usdstichclips rop to make a valueclip.

jsmack

ccyzkk
thans for your comment, goldleaf!
"Default Values" is very usefull to make the cache file smaller，i did this whatever export a single file or sequence files.
for now,seems the valueclips donsn't work very well for me,i'll keep trying, hope i can figure out.
many thanks!

I think don't use the value clip lop, it's not optimal since you won't have the manifest and topology files. Use the usdstichclips rop to make a valueclip.

thanks jsmack!
Most of time I prefer use python to make a valueclip since the clips metadata looks simple and easier to change data with VEX.
like this:
clips = {
dictionary default = {
string templateAssetPath = "clip.#.usd"
double templateStartTime = 101
double templateEndTime = 103
double templateStride = 1
asset manifestAssetPath = @./result.topology.usda@
string primPath = "/World/model"
}
about manifest, i can make one manually，although it is more troublesome.

I've never seen the performance degredation you're talking about when using value clips. I assume you're just referencing in the template file generated by USD Stitch Clips to load the value clip? All this talk of the Value Clip LOP and using python/VEX to author value clips has me wondering if you're actually authoring the value clip manually, which I would recommend against once you've used USD Stitch Clips.

In particular, your use of relative paths to the manifest file has me concerned... If you're authoring this USD metadata in LOPs, you should always use full paths to external files (USD files, texture maps, whatever). Houdini can convert those absolute paths to relative paths when you write out the USD with a USD ROP. Relative paths authored by LOP nodes into anonymous in-memory layers will be interpreted as relative to the "current working directory" of Houdini, which is a process-wide global settings that is often equal to $HIP, but can easily get changed to something else, and therefore should never be assumed.

mtucker
I've never seen the performance degredation you're talking about when using value clips. I assume you're just referencing in the template file generated by USD Stitch Clips to load the value clip? All this talk of the Value Clip LOP and using python/VEX to author value clips has me wondering if you're actually authoring the value clip manually, which I would recommend against once you've used USD Stitch Clips.

In particular, your use of relative paths to the manifest file has me concerned... If you're authoring this USD metadata in LOPs, you should always use full paths to external files (USD files, texture maps, whatever). Houdini can convert those absolute paths to relative paths when you write out the USD with a USD ROP. Relative paths authored by LOP nodes into anonymous in-memory layers will be interpreted as relative to the "current working directory" of Houdini, which is a process-wide global settings that is often equal to $HIP, but can easily get changed to something else, and therefore should never be assumed.

hi,mtucker!
Sorry, I was too busy to reply.
you are right,using python/VEX to author value clips is no a goodidea and it's inefficient.
Maybe that's not the right way to use Value Clip,So,finally,I used alembic file as an alternative.
just reference alembic file in usd.
a little sad but maybe this is the better way for our pipeline on windows.
Many Thanks!

Any updates on this one?
Are things better in houdini 19.5? Or 20?

I have scene with let say 10 assets, each one of them has FX sublayer (destruction and pyro). All pyro was loaded with volume lops. All fx layers have proxy, so it wouldn't show volumes in viewport.
Thanks to presentation from Rise, managed to make rbd destruction much lighter.

If you just scrub scene for a while, virtual memory fills, until eventually it fills out all of it (250 GB) and fails. I have 128gb of Ram. On render machines (64gb), just fails. Even though memory consumption is around 30gb. Seems it wants to consume much more virtual memory and fails.

My whole idea was to give animators ability with simple particle systems to just put explosions in the scene. So, if it hits ground, it would instance out ground_explosion.usd, while it hits any of the buildings/vehicles in the scene it would sublayer appropriate building/vehicle.usd.

But this thing with virtual memory is bugging me. It is impossible to work with this in SOPS, and it is impossible to render it, at least on 64gig machines.

I don't think your problem is related to anything discussed in this thread. I presume you are not using value clips, because there is really no reason to when dealing with volumes. Also, this thread relates to virtual memory being consumed when loading very large USD files. When dealing with volumes, the USD files involved are generally quite small, since all the data is in the external vdb files, which are just referenced by the USD files (like texture maps). If memory is being consumed and not released when scrubbing through a scene, that likely indicates a problem with the renderer (either karma or Houdini GL, or perhaps you're using some other renderer?)

I would certainly recommend that you test your scene in 19.5 if you haven't done so already.

If the problem persists, and you are able, submitting a hip file to support to help us reproduce the problem is the best way to help us tackle any issue. Barring that, a much more detailed description of how your USD is structured might let us create our own hip file to replicate what you're seeing. But we'd need a lot more detail than what you've provided here.

For example, some questions that occur to me looking at this image and reading your description: I can see that you have a point instancer called "ground_explisions", but I assume each explosion starts at a different time, so is there a separate prototype for each explosion? Is each explosion referencing the same explosion USD but with a unique time offset value? Does the memory consumption grow when you deactivate the volume primitives? Does the memory consumption grow if you deactivate the RBD explosion animations? How are the RBD explosions being incorporated/overlaid on top of the assets? There's really no evidence here about what part of the scene is causing the memory to grow, but that's something you should be able to determine fairly quickly by turning off parts of your scene.

You also say at the end that "It is impossible to work with this in SOPS". Is that a typo? Did you mean LOPs? If not, then how are you pulling this into SOPs? What are you doing with it there? Are you unpacking the USD prims? Are you looking at the SOP representation in the viewport?

Basically, you need to start from square one and walk us to where you are now, otherwise there isn't much we can do to help.

I'll try to be more clear this time.

So, intent of my system is to be used both in SOPS and LOPS.

1. Animator would open his animation scene in which he has environment HDA loaded. It loads whole environemnt USD, which loads bunch of building USD's. Everything there is shown as proxy.

2. He would have simple explosion POPs with which he would decide where grenades would hit. If these particles hit one of these building assets, it would trigger sublayering of appropriate FX destruction USD. If particles hit ground it would add point to instancer which instances ground_explosion.usd.

So, animator would see proxies of usd destruction like this. Figured out it is most optimal to have these vdb converted to low poly geo proxies.


Problem with that is the fact it is very slow. Even though I'm pulling only proxy geometries from LOPS doesn't stop sublayer for processing stuff 2-3s per frame.



Data moves like this:
a) layout of explosions SOPS
b) importing explosion list in LOPS, figuring out which ones are instances, and which ones are sublayer destructions over existing assets.
c) importing proxies of destruction from LOPS back to SOPS so animator has preview of what he is doing.

Idea was to have everything packed up in usd files, so we don't have to do double work. One system in sops for animator (where bgeo proxies would be read) and other one in LOPS for look dev.

4. As for instancing and virtual memory, pinpointed what was causing problem. Retime instances makes them unique frame, that is for sure. Converting dirt explosion meshes to value clips, think that would consume far less ram, as you guys already wrote up there.

After testing this in Houdini 19.5 result is solid 24 fps when usd geometries are imported from LOP to SOP.
And virtual memory consumption is normal. <70GB



That pretty much solves all of my problems. Thanks!

I am beginner in Houdini and I am learning by myself. I was working on a wine glass template when is go to the solaris view and on the stage network i create a reference node. But this will not showing my wine glass usd file please help me out of this if anyone know what the issue is

This should probably go into a new thread.... But in that new thread, please post the details of the error on the node (Ctrl+MMB-click on the node to pop up an info dialog that will hopefully provide some useful error information), and we can go from there. Have you verified that the USD file can be loaded into usdview? Would it be possible to share the file?