How would one write out multiple geo sequences from one simulation? (H

[goshone]

With the new dynamics workflow in Houdini 13, there seems to be a tendency to simulate many things in the same DOP network.  In fact, this is the second time this issue has come up, and only the second project in H13.

 

Imagine RBDs falling into a flip simulation, (ice in water if you will), and you want to write out both the ice geometry and the water simulation geometry (flip points).  What I ended up doing in this case, is write out the .sim data once, then extract the geometries and write those out in a separate process.  This technique was clunky, as it resulted to a file node in-line in the DOP network, leaving a huge room for error. 

 

The second case deals with DOP particles, created using the new H13 particle workflow.  I have an RBD simulation of fractured geo, and I would like to add some small debris particles and smoke.  Should I do the sims in stages? (RBD -> particles -> pyro)

 

While it makes sense to do the pyro as a separate stage, since it would slow down the iterative process and dialing in the behavior of the RBDs, it would be awesome to be able to sim it once, producing 3 separate geo sequences at the same time.

 

Does anyone have thoughts or solutions to this?

 

Thanks in advance.

 

Gosh

[woodenduck]

I guess this is a matter of personal preference. I tend write everything out to disk as and when I can. Even with a pyro/smoke sim I'll write out the source geo before sending it to DOPS. I would work on the RBD sim, get that looking exactly how you want it. Then write it out and read it back in, then start on the particles. You will be able to work much faster and try out more iterations. I'm sure some people prefer to sim everything all at once, for me that's too many variables to manage.

 

As for the 'ice in water'. Obviously they need to be simmed together, but I would read them in to separate SOP networks and cache them out as individual .bgeo sequences.

[Nerox]

...I would read them in to separate SOP networks and cache them out as individual .bgeo sequences.

 

I think that is the point, because you would need have separate geo ROP's for that and when they are executed they'll recache the sim.

 

Now I'm thinking of it, it might be possible that when you submit a sim using HQueue, the H13 Simulation submitter has a new 'frame by frame' option, which should allow (when connected in the right order) to do a sim and split out various outputs through multiple Geo ROP's without recalculating the sim every time.

[Skybar]

I think that is the point, because you would need have separate geo ROP's for that and when they are executed they'll recache the sim.

 

Now I'm thinking of it, it might be possible that when you submit a sim using HQueue, the H13 Simulation submitter has a new 'frame by frame' option, which should allow (when connected in the right order) to do a sim and split out various outputs through multiple Geo ROP's without recalculating the sim every time.

I've never used HQueue, but in the Out-context you could just Fetch your geo rops, merge them and render frame by frame.

[goshone]

While I agree with the technique of writing geo to disk as often as possible, this is more of a question of efficiency, especially when having to fight for render resources or battle with time constraints.  While it makes a lot of sense to write sim data, then extract the geometry as needed to write them out separately, there isn't much, if any, time savings with that approach.  I found it taking entirely too long to read the .sim files and extract the RBD geometry.  There is a huge amount of time spent on transforming the RBDs.  It works, but it seems like it should not take that long to read data and apply it.

 

Another concern is any slight mismatches of the simulation.  I know Houdini is stable and predictable in this area, but I would hate to encounter a slight difference from sim to sim because maybe the render farm picks up a slightly different processor type with slightly different floating point calculations.  I am not sure if this is still a problem as it was years ago.