I am wondering if its normal for popnet with 200,000 (or so) visible particle, at any one time, to have very slow cooking times. I finding myself sitting for 5-10 minute blocks just waiting for houdini to cook. Then cook again for object instancing. Whats the secret. How do we work with large particle numbers and not just sot there.
Additionally with large number of visible particles houdini is very unstable under Windows. Is it better under Irix?

Dave R

have you tried the Cache OP?
I guess you'd have to re-cache if you make a change…but it should spped things up otherwise

Hit the ‘p’ key in the pop viewer. Then in the Viewer tab, you can set it to use a large cache size.

Ouch! Is there a rule of thumb of cache size. The scene is 600 frames.
On average there are 100,000 rain drops (visible) in volume, with about 1000 (or so), splitting into 8 particles (for splash effect). The (constantrate) I am controlling with CHOP, which is a bunch of noise and curve CHOPS blended together. The intention is to produce rain in sheets.
So anyway, with cache size to 600, Houdni is dying when constant rate is set to range that I need. Perhaps this is not a cache issue.
What exactly is the pourpose of cache? Is it so POPNET does not have to re-cook. And how do I bake, not cook, the particle simulation so that its just a Geometry with moving points, so that I can scrub back and forth, and one that will render identical every time, and does not have to re-cooked upon reload. But perhaps, becouse I have killed and splitting particles, the simulation cannot be baked.

Dave

If you are only dealing with previz in the POP viewer, then that is the place to place a larger cache size to improve interactivity.

If you are importing the particles into SOPs, then the way to cache is to append a Cache SOP like arctor has suggested.

The purpose in both cases is to avoid re-cooking when time changes.

I don't see the difference between “cooking” and “baking”. To me, those terms are synonymous.

Hope that helps.

david
this may help, if your POP simulation is all ready to go and you're happy with it you could render it out as geometry using the “geometry output OP” if that's what it is called…sorry i only have apprentice at home and can't confirm the ROP name, but that description should be enough for you to find it. anyway, after rendering out as geometry, read it back in with a fileSOP and no-more cooking. i guess it has a similar effect to what edward and arctor have described with the cache approach regarding playing your animation.
b

That's it, thats baking. The popnet is reduced to a geometry sequence. Thanx. I did that and it works, and I went one step further by writing out the metaball attached to popnet, so the end result is a bgeo sequence of these heavy metaball meshes.
Which, of course led me to the next problem. I can never get away from problems in Houdini, they occur one after the other. Now Houdini does not display the mesh. My guess is thats its so heavy Houdini's display system cannot display it efficiently. It takes about two to three minutes for system to update the display. I am unable to navigate through scene and time with splashes mesh turned on. I thought OK, it must be the mesh. So I wrote out the just the popnet as points, without metaballs, the fed the sequence as Copy template to put a metaball at each point. Same slow result.
This takes me back to my original question, that of how do we deal with complexity. I see this ultra heavy scenes in movies, and I just do not understand how the users can display it, let alone render so much information.

Dave R

I'm not sure how this will help in your particular situation but…whenever I do stuff with particles or dynamics in Maya I make the mistake of trying to do everything with one super complex particle system instead of breaking it out into pieces, then comping it together later…
would it be possible to do the same here?…again I don't know exactly what your setup is like so…
how about doing the splashes in a different scene? you could pull in the particle simulation - as it's cached already…

I can only assume this is how the big boys do things…

Hi David,

Generally speaking, when you're dealing with this kind of heavy geometry, you usually do not want to display these geometries in the viewport at all. You can ensure that the geometry itself is not displayed, but set the render-flag on the last node with the geometry piped into that node.

Using the above method might pose another problem – you might noticed that the “render time” is a tad bit too slow as well. This is because Houdini has to cook the geometry out to a scene description frame by frame before rendering. Therefore, the best way to deal with this is by rendering out a sequence of .ifd files (much like the .rib files for renderman) and render it out through command line rendering.

I have just completed my own simple PERL render script (for mantra and prman) that will looking into a specified directory and search for files with proper extension, and execute user's render command on it. If you have PERL installed on your Windows machine, I can give it to you next week. I just need to test it to make sure it's working properly at the moment. Hopefully I'll know enough C++ by the end of the summer to write a self contained executables so that people won't have to install anything.


Anyway, back to the original coversation. I believe that most studios don't usually look at their detailed geometry in the viewport much at all. You wouldn't be able to get anything done on time at this rate. In short, they usually have a pipeline set up that will automatically instance all project-related things into the scene at render time and such. At least this is how I understands it.

Hope that helped a little.
A.