Fluid sim constantly crashes on render.

[chazfest]

Hi,

Any advice as to what could be going wrong with my fluid sim?

It's a FLIP fluid sim with a matchmoved camera and basic scene geo.

I've set the particle separation to .5 as it's a pretty huge scene. Every time I render it out as an image sequence, it crashes at the 2nd or 3rd frame. I even left it running for 8 hours over night to see if it'd get past it somehow (no joy there).

I also tried attaching a file node in the autodop network to write out the sim files, this didn't get past frame!! And also crashed, eventually!!

I've attached the hip file in case anyone might be kind enough to take a look.

As will become evident from the hip file, I'm a beginner, so any advice, criticism and tips are massively appreciated!!

Thanks in advance.

Chaz

London TubeTunnel FluidSim-BIG-V2.hip

[SpencerL]

Hi,

Any advice as to what could be going wrong with my fluid sim?

It's a FLIP fluid sim with a matchmoved camera and basic scene geo.

I've set the particle separation to .5 as it's a pretty huge scene. Every time I render it out as an image sequence, it crashes at the 2nd or 3rd frame. I even left it running for 8 hours over night to see if it'd get past it somehow (no joy there).

I also tried attaching a file node in the autodop network to write out the sim files, this didn't get past frame!! And also crashed, eventually!!

I've attached the hip file in case anyone might be kind enough to take a look.

As will become evident from the hip file, I'm a beginner, so any advice, criticism and tips are massively appreciated!!

Thanks in advance.

Chaz

Hey,

I havent taken a look at your file, but based on what you are describing it sounds like you are trying to render before writing the sim out to disk. In any/every case of sims its always a good idea to write the sim out as a geo sequence, ie .bgeo and then render that. It makes sense that your scene would crash as the fluid sim is eating a alot of your system resources, ie ram/cpu, and if you add a render on top of that it will lead to crashing.

[chazfest]

Hey,

I havent taken a look at your file, but based on what you are describing it sounds like you are trying to render before writing the sim out to disk. In any/every case of sims its always a good idea to write the sim out as a geo sequence, ie .bgeo and then render that. It makes sense that your scene would crash as the fluid sim is eating a alot of your system resources, ie ram/cpu, and if you add a render on top of that it will lead to crashing.

Thanks SpencerL,

That makes sense when you put it like that, it must be a HUGE strain on all of my resources.

My attempts at writing out the baked .sim files were previously unsuccessful, I just added a 'FILE' node at the bottom of the autodop network (under the gravity node). It didn't get past the first frame, so maybe I was going about it in the wrong way if I should've actually been writing out the .bgeo files instead. Any tips on how I could go about doing this?

Also, on a side note, can I pull up a particle count for any frame in my scene? I'm wondering how many particles are actually involved from square one, I'd assume there's rather a lot

Thanks for the response!

Chaz

[GallenWolf]

File DOP is great for saving out the entire simulation but it takes awhile to read back. Did you put say, mysim.$SF4.sim instead of just mysim.sim? You'd need the frame padding for the file dop.

Suggestion: Use a DOP Import SOP to bring in necessary objects for render from the DOP network, and from there use a regular Geometry ROP to bake out those objects to .bgeo. Read them back in with a File SOP, and you should be good to go.

I don't think there is a way to directly view the number of particles in the viewport, but when I need to do that, I'd put down a Font SOP, and use a npoints() expression pointed at the point cloud/particles to get the point count.

[mawi]

Thanks SpencerL,

That makes sense when you put it like that, it must be a HUGE strain on all of my resources.

My attempts at writing out the baked .sim files were previously unsuccessful, I just added a 'FILE' node at the bottom of the autodop network (under the gravity node). It didn't get past the first frame, so maybe I was going about it in the wrong way if I should've actually been writing out the .bgeo files instead. Any tips on how I could go about doing this?

Also, on a side note, can I pull up a particle count for any frame in my scene? I'm wondering how many particles are actually involved from square one, I'd assume there's rather a lot

Thanks for the response!

Chaz

You can se number of entries in the details view. For DOPs look in the particlefluid/geometry data.

[chazfest]

File DOP is great for saving out the entire simulation but it takes awhile to read back. Did you put say, mysim.$SF4.sim instead of just mysim.sim? You'd need the frame padding for the file dop.

Suggestion: Use a DOP Import SOP to bring in necessary objects for render from the DOP network, and from there use a regular Geometry ROP to bake out those objects to .bgeo. Read them back in with a File SOP, and you should be good to go.

I don't think there is a way to directly view the number of particles in the viewport, but when I need to do that, I'd put down a Font SOP, and use a npoints() expression pointed at the point cloud/particles to get the point count.

Thanks GallenWolf,

Nail on the head, that's exactly what I saved the sim files as, I assumed it would need the '$SF4.sim' extension. That's worth knowing that it's needed for the file dop.

Thanks for your suggestion of using the DOP Import SOP, I'll try that tonight. I'm not 100% sure on how to execute it, am I right in thinking the following?:

(1) Create the DOP Import SOP at the top/object level, bring in all static objects and fluid from the AutoDOP Network, then:

(2) Create a Geometry ROP also at the top/object level, to bake out the objects from the DOP Import SOP as a '.bjeo' sequence, and finally:

(3) Create a File SOP in the Auto DOP Network to read the '.bjeo' sequence back in? Presumably these will then be used in the rendering process instead of re-simulating everything? Thus sufficiently speeding up the render times?

If this all works, that could solve to issues, as I also need to pre simulate the fluid by about 50 frames ideally, so that when the shot starts, the fluid sim is already in full flow.

I apologise in advance for immediately firing back a bunch of questions

And thanks again for your help, I say it every time, but the Houdini community is ACE!!

Thanks in advance.

Chaz

[ikarus]

could be your memory being capped out, how much RAM do you have?

[chazfest]

could be your memory being capped out, how much RAM do you have?

8gb RAM

Macbook Pro 2010 unibody, 2.4ghz core i5.

I noticed that the first 2 frames used up almost 20gb of my hdd space!!!! Something's surely wrong? Just no idea what I've done

[mawi]

8gb RAM

Macbook Pro 2010 unibody, 2.4ghz core i5.

I noticed that the first 2 frames used up almost 20gb of my hdd space!!!! Something's surely wrong? Just no idea what I've done

In the scene you posted above the separation is set to 0.05 and the emitter-size is 40x15.

[mawi]

dubble...

Edited July 6, 2011 by mawi

[chazfest]

dubble...

Yeah, I increased the emitter size until it was big enough to fit into the scene. And lowered the particle separation, perhaps too much? Should I try decreasing the size of the emitter? Or increasing the particle separation? Or both perhaps?

Also, just to note, I've tried to export the bgeo sequence to no avail, I attached the DOP Import SOP and ROP output nodes inside the particle fluid node. It exported the first frame successfully, and then crashed on the 2nd frame!!!

I'm getting the impression I'm in way over my head here? If anyone could advise how I can salvage this experiment, I'd be eternally grateful!!!

Thanks in advance.

Chaz

[olegwer]

It exported the first frame successfully, and then crashed on the 2nd frame!!!

1.Could u show your dopimport sop?

2.You working with very 'heavy' geometry. It is necessary to simplify geometry before loading to autodopnetwork. (You can use your heavy geometry to rendering and visualizationin in viewport but for dop importing u should reduce count of edges/polygons).

3.Houdini saves temporary simulated files on C:\hard drive by default. Change location of "temp" folder.

Edited July 6, 2011 by olegwer

[mawi]

Yeah, I increased the emitter size until it was big enough to fit into the scene. And lowered the particle separation, perhaps too much? Should I try decreasing the size of the emitter? Or increasing the particle separation? Or both perhaps?

Also, just to note, I've tried to export the bgeo sequence to no avail, I attached the DOP Import SOP and ROP output nodes inside the particle fluid node. It exported the first frame successfully, and then crashed on the 2nd frame!!!

I'm getting the impression I'm in way over my head here? If anyone could advise how I can salvage this experiment, I'd be eternally grateful!!!

Thanks in advance.

Chaz

If you set it to 0.5 you start with 1900 and are up to 180000 particles @ frame 10.

At 0.05 you start with 189000 particles and I cant even sim it to frame 2 on 16gb ram.

[GallenWolf]

(1) Create the DOP Import SOP at the top/object level, bring in all static objects and fluid from the AutoDOP Network, then:

(2) Create a Geometry ROP also at the top/object level, to bake out the objects from the DOP Import SOP as a '.bjeo' sequence, and finally:

(3) Create a File SOP in the Auto DOP Network to read the '.bjeo' sequence back in? Presumably these will then be used in the rendering process instead of re-simulating everything? Thus sufficiently speeding up the render times?

Hmm the terminology described here may not exactly be correct... but in general yes.

1. Create the Dop Import SOP inside a *Geometry object*, and use that to bring in the simulation objects. You may want to use multiple dop imports to split things up so the fluids and static objects are not in a single file - or use groups and merging to save them multiple dop imports into a single file per frame.

2. Yes, you can create a Geometry ROP to export the bgeo, or create the Geometry ROP in the /out, would do the same thing.

3. Nope, you would want to create the File SOP inside a Geometry Object - could be the same one used to bake out the geo - and point that file sop to the filepath used by the Geometry ROP for its exports.

Rendering of simulations need to be done through Geometry Objects - you can render an Autodop Network directly IIRC, BUT I do not think there would be much control over shader, blur etc.

Hence, inside the /obj I would usually have a Dop network for simulation, and multiple geo objects for rendering.

HTHs!

[GallenWolf]

btw, if you are doing sims with the autodop network, this should actually be setup for you automatically; there should be an auto dop network and geometry objects created in /obj that do the baking out as well as rendering, with shaders assigned....