Sparse volume rendering crash

[Paul Oblomov]

Open. Go to frame 29 (wait a lil). Render.

Locks computer for about 10 minutes. Sometimes unloads H right away. Last thing I saw -

Todays vray, h 18.416

P.S. 256gb RAM

[Gosho.Genchev]

Hey, Paul,

are you sure you're not running out of RAM ? It might be a good idea to cache the volumes to disk in VDB format before rendering.

I've been waiting for about 2 minutes now for your scene to simply load and RAM has filled up to 20 GBs so far so I assume it's a heavy one. I'll check when it's done caching and message you back.

Best regards!

[Paul Oblomov]

Of course not. 110GB was eaten.

It might be a good idea to cache the volumes to disk in VDB format before rendering.

Sure it might, but 29frames - how often you cache simple sim to .vdb ?

P.S. H uses intel tbbmalloc, but in a strange way, so you can try to use windows mem allocator (TBBMALLOC_PROXY_ENABLE=0). It will be three times slower, but won't eat all your RAM.

[Paul Oblomov]

Hope your PC won't melt down

[Gosho.Genchev]

Haha, yeah, mine did - 32 GBs of RAM only. Decided to wait for the weekend and grab one of the shared office machines - I'm setting up Houdini there and will message you when I've got something.

Still, I'm not sure even if the crash reproduces that there's much that can be done - when we render Houdini's native volumes, we essentially bake the voxel information into memory or the VRScene instead of reading it from disk. Such a data set may not be suited for what has been implemented to support native rendering - there used to be an issue with data overflow a long time ago that was fixed already but there's ... limits.

Anyway, I'm running the sim now and will message back.

Have a great weekend

[Paul Oblomov]

Oh great. Just thought, how THAT simple scene can lead to a crash. Really, simple default setup. I wonder how mantra handle it... baking too ?

[Gosho.Genchev]

From V-Ray's point of view it's just voxel data - the complexity of the setup doesn't matter at all.
It's typical workflow to drop a ROP and cache to disk - I genuinely don't see the use case of waiting for more than an hour for the sim to play in the viewport for 30 frames so you can hit render and lose all the data when changing the frame. The sim has been running for 45 minutes so far on a 28 core workstation, producing 5GB cache files per frame - I think it would be fair to expect the artist to cache such simulations. Other softwares (e.g. Phoenix, Fume) write to disk while the sim is running and read the files back when you hit render. Houdini does not do that by default.

Best regards!

[Paul Oblomov]

Hm. H cached to RAM. Not sure it differs from saving to disk It is faster to read I suppose and maybe some lookdev thing is faster, than saving to disk. For a noob like me. In maya, phx is able to not save to disk at all, just a preview generation. Was that cacheless mode done without smth in mind ?

Anyway, I think vray shouldn't crash

[Paul Oblomov]

To clear things up - I need only .vbd, so vray can handle it, right ? Bgeo is not an option? I just cached and 12gb bgeo file crashing h.

[Gosho.Genchev]

Yes, VDBs work - I tested with your scene and the volumes do render.

Storing anything in the bgeo format is essentially the same as reading it live from Houdini - polygons, curves, volumes, particles, etc. If you want to ensure your VRScenes are as light as possible, use Alembics for hair/particle/geometry and VDB for volumes.

I'll talk with the devs today about the crash - hopefully there's a way to handle it so Houdini won't crash but I can't promise we'll be able to render 12GBs worth of native volumes.

[Paul Oblomov]

I just new to vfh, so loots of questions, how this and that works