Memory management: SOPs hoovering up RAM

[John Pilgrim]

Hi all,

I'm having issues running out of memory on a current project, in the attached file.

Rendering a Flipbook or playing the timeline cause Houdini to eat up about 1GB of RAM per frame, resulting in an OS out of memory error after 48 frames.

I've RTFMed and Googled but am not sure how to stop Houdini from hoovering up RAM.

Analysis and suggestions will be greatly appreciated!

Thanks,

John

system details:

Houdini Apprentice HD 12.0.683

Windows 7 Pro x64 SP1

i7-3930K

64GB RAM

Virtual memory (ie. Pagefile.sys) limited to 4096MB, as I'm on a SSD.

PS: FWIW, I can reproduce the issue with Houdini running on Linux (Ubuntu 12.x)

Edited September 27, 2012 by John Pilgrim

[sam.h]

You can stop a SOP node from caching its result by using the unload flag (press 't' in a network view).

This would be annoying for an interactive session though.

You can clear SOP cache using the "sopcache -c" hscript command. Maybe you could use an opengl ROP to render and have a post frame script to clear the cache?

[John Pilgrim]

Thanks Sam!

Setting the unload flag for every node does not result in a memory usage improvement.

Neither does sopcache -M always -U always - m 1024

FWIW, I'm not losing any interactivity, as this network recooks every time you change frames, even to go to the prev frame that just rendered.

Which is a drag as cooking takes 40 seconds/frame.

I should add to the system details:

Quadro 4000 GUI + GTX580 GPU + nVidia driver 301.42-desktop-win7-winvista-64bit-english-whql

Sorry 'bout the 301.42, DaVinci Resolve (also on this box) requires that driver ver.

If someone was SURE that the driver was the cause of this memory issue, I'd go back to 297.03-quadro-tesla-win7-winvista-64bit-international-whq

Edited August 28, 2012 by John Pilgrim

[sam.h]

I'm using 275.09.07 and I'm seeing the same thing as you are, even with the viewport closed, just looking at the details view the memory gets chewed up.

Seems it is the UVTransform node using 90% of the ram, try disabling that one and trying again?

EDIT: actually, that makes sense since the display flag is on that node ....

EDIT AGAIN: I take my edit back! viewing the node above UV Transform improves memory usage a lot.

Edited August 28, 2012 by sam.h

[John Pilgrim]

Thanks for you help Sam!

Reducing the poly count from 2.2M to 600K seemed to solve the problem.

I'm fine with that workaround, as the heavier geometry was taking too long to cook and didn't need to be that dense.

It seems to me this is a bug that gets triggered by some combination of these ops when the geometry reaches a certain size.

John

[sam.h]

It might be better to just have representations of your mesh using lines which would be much more efficient. Also using the "wireframe" SOP to create tube primitives rather than having so many polys.

It sure is a a heavy scene!

[John Pilgrim]

It might be better to just have representations of your mesh using lines which would be much more efficient. Also using the "wireframe" SOP to create tube primitives rather than having so many polys.

Thanks for pointing out the Wireframe SOP and PolyWire SOP -- I will definitely look into those!

Can you expand on what you mean by "just have representations of your mesh using lines"?

Thanks again,

John

[sam.h]

What I mean is that it just seems wasteful to have so many polys for tubes that are such simple object, you could use the wireframe SOP to get some tube primitives or use the poly wire SOP with jut 4 sides and use rendertime subdivision .. something like that!

[John Pilgrim]

What I mean is that it just seems wasteful to have so many polys for tubes that are such simple object, you could use the wireframe SOP to get some tube primitives or use the poly wire SOP with jut 4 sides and use rendertime subdivision .. something like that!

That's what I thought.

I just wasn't sure if there was another approach you were thinking of.

Thanks again,

John