Enrique De la Garza

futoryan
Curious if you've found any other solutions since the last post. We're looking to move toward Karma XPU from Octane and this FPS issue seems like a bit of a hassle.

Anything converting a ton of geometry from Sops to Lops is gonna slow down the viewport playback quite a bit. You are always better off precaching anything to USD before bringing it into Lops to not have to author any timesamples on the stage (the little green clock icon). Although this is really just a big problem when you have a lot of animated point data.

There are some smart workarounds you can do for animating non deforming geo that will increase performance, like just extracting the point xforms and doing a "Transform by SOP points" and applying those to a usd asset, you just have to match the prim and point paths. For deforming skinned geo using USDSkel massively increases performance vs just sopimporting the animated geometry to the stage, but this is more complicated and documentation is not as robust as it should be to get it to work (you have to a do a lot of shenanigans with agents and scene graph restructuring)

I'd just start by precaching all your stuff to USD to avoid that conversion from sops to lops and also making sure you are not authoring timesamples where you don't have to and you should see massive performance boosts.

mtucker
The most common thing I've seen leading to this kind of situation is (sometimes unintentional) caching within the LOP network. As an example, we recently got a bug submission where the Motion Blur LOP was causing memory bloat like this. It was an incorrect setting on the Cache LOP inside that HDA, which has now been fixed. So maybe look for Cache LOPs and Cache SOPs (especially ones buried inside HDAs).

Another interesting data point would be to know if you can reproduce without using Karma. This would help localize the problem to either being Karma causing the bloat or LOPs causing the bloat.

Would you mind sharing what the incorrect setting on the Cache LOP is? We do have a couple of HDAs with cache LOPs inside, but none of those run during the session until we trigger an export. I'll try to make a simple scene to see if i can reproduce, I might be able to just make a loop that continuously swaps a usd reference to a new file (I noticed this same issue was happening when I was batch processing some assets in a loop)

We've been experiencing the same issue at the studio. Haven't been able to pinpoint what causes this, but sometimes houdini seems to be increasing and accumulating RAM every time the stage gets loaded or small edits like transforms get dropped in, sometimes even if nothing on the stage itself has changed and the only thing that gets launched is Karma.

Example, we load in a USD asset made up of 50 other USD referenced assets, this consumes 15gb. After a few minutes switching viewports, launching KarmaXPU, moving some lights around. This can grow up to 100+ Gb until the system runs out of memory. Nothing we do seems to be able to flush the memory other than fully closing the houdini instance, not even deleting the entire scene or doing File-> New. We have to close the entire houdini session for it to release.

It is difficult to provide a hip file since (studio assets) but also it is hard to recreate since it happens 50% of the time we open a scene.