Matt is an FX Lead at Animal Logic Sydney where he's allllmooooooost finished working on The Lego Batman movie. He's a fairly recent convert to Houdini, and is currently enjoying an amusing rush of social media after doing some talks on the Sidefx booth at Siggraph, and recording a rambly webinar. He finds talking about himself in third person pretty funny.
The downloads for the above files can be found HERE.
Houdini is well known for its dynamics tools, and new users often throw themselves into particle and smoke sims straight away. The shelf tools make this easy, but to better understand dynamics you need to move beyond the shelf presets.
Diving into the dynamics operators, or DOPs, at this early stage, can be a revelation for a lucky few who 'get' it. For everyone else it's a confusing and scary place, and users quickly head back to the safer surface operators, or SOPs context. I was definitely in the latter category, and it took me a long time to get past my fear of DOPs.
As it turns out this was a good thing!
With help from my co-workers, I learned that it's possible to fake a lot of dynamic style things in pure SOPs. The Maya analogy would be to use non-linear deformers to fake a particle system, or seaweed swaying, or clouds moving, thereby avoiding simulation entirely. That means no caching, no juggling of forces and near instant updates.
SOPs also generally have a clean network flow, so setups are much easier to modify (and easier to debug when things go wrong, compared to the seemingly complex networks in DOPs).
Once you have a handle on all that, a great gateway into DOPs is the solver sop. To understand what the solver sop does, it’s good to quickly cover how regular sops work. You can think of sops as being forever 'in the now': They have no sense of what happened on the previous frame, or what will happen in the next frame. When you move to frame 12, your sop chain goes to the first node, cooks its results fresh just for this frame, then the second node modifies that result, which is passed to the third node, and so on until it gets to the end of the chain. If you move to frame 13, the entire chain is essentially reset, and the cooking begins again, with no reference at all to what happened on the previous frame.
The solver sop changes all this, and gives you access to the result of the previous frame. Simple enough in theory, but in practice this opens up a lot of interesting techniques. A basic one is to define motion in relative terms rather than absolute terms.
You could keep modifying the setup to try improve the behavior, or switch to a solver sop, which better captures how a car moves; a mostly constant forward velocity, with a random left/right force to steer the car:
A by-product of a solver based solution is how it scales; the notion of “one point has forward motion, with steering adjustments” can be expanded to “lots of points have their own independent forward motion, with steering adjustments”, with almost no effort. In essence, you've made your own particle system!
Say you had a car, and moved it using sops. You could use a noise function driven by time to control its position, something like
@P = noise(@Time);
This works, but the motion doesn’t look quite right:
Better still, once you get the idea of ‘take the previous frame and alter it’, you’re now much better prepared to tackle DOPs, as most of the simulation tools work in this way. The reason the solver sop is such a good introduction to DOPs is because the solver sop is a DOP, disguised as a regular SOP node. The notion of building on the previous frame is what defines DOPs and POPs.
DOPs? POPs? DOPs = Dynamic Operator, POPs = Particle Operator. Houdini had particles for many years before DOPs arrived. For a while they ran in parallel, where most of the simulation tools were available in DOPs, but particles stayed in their standalone POP network. Eventually the particle system was re-written to be a module within DOPs like everything else. However while every other DOPs module is referred to by either its purpose (cloth solver, wire solver), or cool name (pyro, FLIP), particles within DOPs are still referred to as POPs. Why mess with a good thing!
Random-wander setup
Here’s the same random-wander setup, but this time built as a particle simulation. While you could use vop networks or vex code to control behaviour, a key feature of dops (or pops in this case), is that SideFX offer many pre-built nodes to do most common tasks, and often lots of less-common tasks too. A node to control wandering, another for avoiding obstacles, another to stop particles from getting too close, it’s all ready to play with.
Simple dop system
Another simple dop system is the ripple solver. Give it a deforming surface, it will generate ripples based on those deformations. How it works under the hood may not concern you (I’ve added more info on my wiki), but the core idea of ‘make this frame be based on the previous frame’ is the thing to remember.
Further, comparing the ripple sim to the pop sim, it’s interesting to compare similarities; both use an object to store the motion, and a solver to do the calculation. This setup is mirrored in nearly every dop system Houdini provides.
When you move to something like the pyro solver, patterns start to emerge; it too needs an object and a solver (a smoke object and pyro solver), and like particles, requires a source. It can support force nodes, and other nodes to affect behaviour.
Because there are so many ways a smoke sim could be affected, SideFX provide a large library of components generally prefixed with ‘gas’, and referred to as micro-solvers. While they look intimidating, dive inside most of them and you’ll find the same pattern repeated over and over; a vop network, designed to modify the current frame based on the previous frame.
Once you get a handle on this modular workflow, dops become much less scary. Generally speaking when I start to learn a new dops module I’ll use the shelf tools to build a network. Then I strip the network to the bare minimum, read the docs on the object node and solver node for that simulation (where most of the important attributes and parameters will be documented, as well as where the example files will be), and start adding nodes as required.
Interestingly, a lot of DOPs are remarkably easygoing about the data you feed them. You can have POPs work with particles, but it works just as happily with curves.
Further, nodes from one DOP system can often be used with other systems, like using POP emitters and POP forces to emit and drive a packed rigid body simulation:
It goes deeper still! The solver sop I mentioned earlier? While it looks like it’s bringing simple DOPs into SOPs, its original purpose was the reverse; to bring SOPs to DOPs. Down here you can do whatever geometry processing you want, per frame, and feed it back into a simulation. For example you could take a curve driven by pops, and on each frame rebuild it, so the points that make up the curve are always a fixed distance apart. Add in a force to make each point repel each other, you have the basis of the differential curve growth tricks that have been popular of late.
And still there’s depths to be explored. Maximum silly kicks in when you realise you can have multiple solvers affecting the same geo. Want to have a wire solver and a pop solver affect the same geo? Sure. Cloth and ripple? Why not? In a similar way that sop nodes can be wired together to create interesting things, dop sims themselves can be thought of as uber-nodes, interacting in all sorts of wild ways.
Getting comfortable at this level of DOPs takes a while. I’ve only barely scratched the surface of what’s possible; I still haven’t learned FLIP fluids, or FEM, or Cloth, and there’s lots of submodules in other things I’ve hardly explored at all. And that’s what I love about it. A lot of Vimeo tests can be immediately recognised as shelf presets with minor tweaks (or copies of the latest OdForce forum post or popular video tutorial), but what’s truly inspiring is seeing folk use DOPs in unexpected ways; volume nodes with cloth, a custom gas microsolver to do some crazy effect, RBD affecting wires and a few clever Geometry SOPs . . . there are so many variations to try, new effects to uncover.
Pushing at this end of DOPs can sometimes be frustrating, as you’re often combining things in ways Sidefx haven’t thought of, much less documented. But playing on the fringes of unexplored territory is what makes it interesting, and often leads to unexpected and startling results.
The online Houdini community is pretty tight, and news travels fast when fresh and unique ideas are discovered. The best feedback I could think to give on a simulation wouldn’t be “Yes, that looks like real fire”, nor even “You’ve inspired me to do a water sim just like that”. I want to be stopped in my tracks, forced to rethink how much more I’ve got to learn, and offer the bamboozled feedback “how did you even think to simulate something like that?”
Inspire others to learn more, forge new paths, bamboozle. And do it all by basing the next frame on the previous frame.
Matt Estela 2016
By: Patricia Cornet
GridMarkets marketing