Making sand with Houdini

When I was still a vfx student, I was charmed by the sandman effect of Spiderman 3: by my opinion, after all these years it remains one of the best sand effects ever made.

Actually, just out of the theatre, I said to myself "I wanna make sand too!!".
The problem was that at that time I was familiar only with 3DS Max and Maya and none of them had a particle system good enough to make this kind of effect (nParticles system was released two years later).
Browsing around I learned that sandman effect was done with Houdini... and that was the exact moment when I started studying this software! :)

Anyway, the sand simulator of Spiderman 3 is a proprietary tool developed internally by Sony Pictures Imageworks and is not available in Houdini.

Houdini has a fluid solver called "Sand Solver", based on both PIC/FLIP methods and specifically designed for sand simulations. After release 10, it was hidden from the interface because the FLIP method is (=should be) handled better by the new FLIP fluid solver. After some tests in which I basically added a matrix strain field and a GAS Sand Forces microsolver to a particle FLIP fluid, I was frustrated by liquid-like sand simulations.

So I decided to try the "obsolete" Houdini sand solver. Even if hidden, it's still embedded inside the software and unhiding it is pretty easy: all you have to do is to run the following commands in Houdini Textport:

opunhide Dop sandsolver

opunhide Dop sandobject
opunhide Dop sandconfigureobject

After that, the two digital assets become visible in the DOP context and you can use them just like any other voxel fluid. Here is my test:

As you can see, the result is good but still a little "liquid".

Physically talking, the most realistic approach to sand dynamics would be with rigid bodies, since the grains of sand are nothing more than tiny rocks. In the other hand, using rigid bodies to simulate thousands or millions of grains is of course prohibitive in terms of calculation speed.

The problem is that the advection method (typical of all fluids) that is used by FLIP solver doesn't allow particles to suddenly stop after an impact or when trapped (like they were rigid bodies) because velocity is deviated from obstacles instead of being subtracted; in addition, the absence of grain-to-grain friction causes a wrong dissipation of forces. GAS sand forces microsolver turns off the motion of internal matter (trapped grains) allowing the particles to stack and tries to give an idea of friction between grains, but the resulting "sand" never stop sliding until it flattens almost completely.

Making (more than) some modifications to Houdini sand with microsolvers and adding a POP network to store the final position of grains and avoid the liquid motion, I've obtained the result shown in the video below:

(simulation time: less than 3 minutes)

The simulation is better (and still fast) but I want something more. In the meantime, I've built from scratch a new sand solver with the same behaviour but containerless (just like FLIP fluids)... anyway I'm still not satisfied.

As soon as I have time I'll try to build another custom solver. When it will be ready, I will update this post.

Houdini - pin table & led panel

Yesterday I saw on TV a beatiful commercial in which a pin table makes the animation of a horse, so I was wondering what's the best way to achieve this effect in Houdini.

Here is my test (special thanks to my cat Lucy for the help!):

The first (and of course bad) idea was a copy-stamp with a "pic" expression to affect the Y position of each instanced pin:

pic("../img_sequence/OUT",$BBX, $BBZ,D_CR)*ch("../yAmount")

This technique works fine, but it's very slow to calculate and also single threaded (can use only one CPU core). In addition, the cache would take a lot of memory because it has to store every single pin geometry (and that's no need in this because we only need position informations).

So, to optimize cache, I used the pic expression in a "point" node BEFORE the "copy" SOP (see the picture):

In this way cache files are much smaller because they cache template points only. Anyway, the evaluation is still slow.

The only way to optimize the evaluation is to remove the "pic" expression: fortunately, points can take color from images also by creating UVs and transfering texture color with a VOP SOP, that is much faster. Houdini 12 contains a digital asset that does exactly that, "AttribFromMap".

Placing an AttribFromMap before the "point" SOP and editing Y position expression to "$TY+$CR" ([point Y position] = [original Y position] + [red value]) is enough to get the same result as before with a reasonable evaluation time.

Whith the same method, you can easily create a LED panel effect. This time you have to create 3 different instance SOPs (red, green, blue) and merge them together before applying the copy operator:

1. Create a LED geometry (that will be instanced on grid points), for example a box.
2. Using AttribFromMap and Point SOPs, transfer the red channel of your footage to points; create an offsetted copy of the template points and apply another AttribFromMap to create the green channel; do the same for blue.
3. Merge all the instance points.
4. Instance the LED geometry on points with a copy SOP and transfer the template colours on instances (see the picture).

In the sample scene (download here, password "valeriodinapoli") I have prepared both effects.

Houdini – How to create a “Rigid Body Emitter”

A couple months ago the director asked me to make an effect of rocks falling randomly from the sky: in this case I needed  to build a system that continuosly emits objects (like a POP emitter), but those objects had to behave like rigid bodies. So I had the idea of a "rigid body emitter": you can watch the video below to better understand what I am talking about.

To replicate this effect, just follow these simple steps:

• Create a POP network with an emitter: the particles generated by this network will be used as instance points. Set a small value for particle life expectancy (something like 0.05).

• Create a DOP network with a "RBD point" (manually or by using the Point RBD shelf tool); use the particles as template. This powerful operator creates a copy of a given SOP (as rigid body) on each point of another SOP.

• Here is the trick. :) Using an expression, edit "creation frame" parameter to make the PointRBD generate continuosly new objects: "$F", for example, means that PointRBD creates new objects on each frame (but I strongly recommend to NOT use it, or many rigid bodies will interpenetrate). I used this expression to create new rigid bodies every 2 frames, until frame 100:

if($F<100,if($F%2==0, $F, 0), 0)

After that, you can randomize many things, like phisical properties, size, emitted objects and so on. To do that, you must basically create the corrensponding attributes on particles and transfer them to the PointRBD node.

Download the sample scene from here (password: valeriodinapoli) to better understand this workflow.

Houdini - UV on particle fluids

Last week I did some research about the techniques to add UVs on particle fluid.
Apparently it might seem rather pointless to map a liquid (since the texture will mix by itself and become chaotic in a few moments), but if you have to simulate a viscous liquid, the motion of the particles will be slow and limited, allowing you achieve some nice and slowly "advecting" UVs.

First of all, we have to distinguish two main cases:

1. Dynamics has not been simulated yet. In this case, all you have to do is create UVs and transfer the corresponding attribute to the particles in SOP context BEFORE you run the simulation: in this way you'll simulate particles that store UV while advecting and, after the simulation, you'll be able to transfer the uv attribute from particles to the particle fluid surface.

2. You have already done the simulation (in Houdini or external software, like Real Flow). In this case, you have to add somehow the uv attribute to particles in the first frame and make it follow the dynamics.

So,

• create the particle fluid surface in the first frame and lock the particle surface node;
• create UVs on this locked node and promote the uv attribute from vertex to point;
• still working in the first frame, transfer the uv attribute from the particle surface to simulated particles and lock the attrib transfer node (see the picture below);
• make the particles with UV follow the original particles;
• create a new particle surface node and make sure you transfer the uv attribute to it

Note: more particles you have, the more precise are the resulting UVs.

You can download a sample scene from here (password: valeriodinapoli).

Python script for Maya - Create dynamic chain from curve

"Create dynamic chian from curve" is a python script for Autodesk Maya that I wrote just for fun about one year ago.
It creates chains procedurally from NURBS curves and adds IK animation controls, two different dynamics systems (one faster, one more accurate) and dynamic contraints. Everything is procedural, so you can re-arrange the curve, change rings size and shape and so on.

How it works:
- The script does a bunch of things. Basically it measures the curve length and places some hidden locators on it. On each locator it places a joint, an hi-res ring and a proxy ring.
- Each hi-res ring is equal to an original hidden ring (so, by modifying it, you affect all rings) and constrained to the corresponding low-res ring.
- Low-res rings are skinned on joints and used also as ncloth objects, to provide very fast simulations.
- The original curve is both used as IK spline for joints and hair for simulations with Hair system solver.

You can download it for free from Creativecrash: click here.
If you like it don't forget to rate it.

Thanks!

Houdini - cookie node tip: how to make it work as it should

Last week I did a lot of boolean operations on geometries and I noticed that sometimes Houdini cookie node doesn't work properly, generating a bunch of artifacts. If you are a Houdini user you know well what I'm talking about!

Original geometry

Cookie with artifacts

After some tests I discovered how to fix that issue... and it's very simple! Basically this node works better with some scales and generates some errors when your geometries are too big or too small.

So,

• if you have tiny geometries, scale them up a lot (100 times or more) BEFORE you plug them in the cookie node and re-scale down by the same value after the boolean operation;
• if you have huge geometries, scale them down before the cookie op and scale 'em up after.

Finally working!