In the last module, we extensively discussed every aspects of vellum cloth simulation.

In this module, we will cover softbody, grains, and hair simulation using vellum solver.

The prerequisite knowledge of vellum cloth simulation is needed in this module because everything we are going to cover are pretty much similar to what we covered in vellum cloth.

We will break each of the aspects (softbody, grains, and hair) into three separate sub-modules in this module so that we can cover some important concepts.

Again, we will be applying the knowledge of everything we learnt in vellum cloth simulation in this module, with the introduction of some new nodes, so let us begin.

Soft bodies are created out of two types of constraints, namely cloth and struts. The cloth constraint creates constraints on the surface of the softbody mesh, while the struts creates an internal volume constraints within the volume of the softbody mesh, and this strut constraint is why the softbody mesh does not collapse into itself.

We will look at how to set up a very basic softbody and look at the important parameters.

Start by creating a geometry node named "softbody" and enter it's SOP level. 

Create a sphere and make it a polygon. Also increase it's subdivisions.

Create a vellum constraint and set the constraint type to 'cloth'. This is the same vellum cloth node we've already dealt with. 

Now to make the sphere behave like a proper softbody, we are going to create a vellum struts node. This node creates struts in the interior volume (volume constraints) of the sphere which helps to maintain the shape and volume of the sphere. 

Alternatively, we can just create a vellum configure strut softbody node directly which will automatically hookup the same connections above for us.

Finally, let's connect a vellum solver and enable ground collision.

If we play the simulation, the sphere falls and bounces like a softbody.

This is the most basic setup for a softbody.

It is very important to remember that whatever geometry or mesh we want to convert into a softbody is an airtight closed object.

If we increase the bend resistance on the vellum cloth node for the softbody, it will not fold or bend much, and will behave more like a water balloon. If we reduce the bend resistance, we will get some bending or folding effect. 

Increasing the stretch stiffness on the vellum strut node is going to make the geometry to retain more of it's original form, and reducing it will make it lose more of it's original form.

We can also setup softbodies similarly using the vellum configure tetrahedral softbody node.

We are going to apply everything we have learnt about vellum softbody and vellum constraints so far to create a jiggly belly for a fat character.

The method we are going to showcase in this example is good for adding vellum simulation to parts of an animated character.

Let us begin by creating a geometry node renamed "jiggle simulation" and enter it's SOP level. 

We will use an alembic node to import an animated fat man character. Since we are importing an alembic, let's use a convert node (or unpack node) to convert it into a polygon geometry that Houdini can recognize.

We will use an attribute delete node to get rid of the UV that came with the character just to avoid visual distractions.

Our setup should look like below:

If we playback, the animation is working. We want to add a jiggle effect to the fat man's belly using vellum softbody.

First, let us specify what part of the character's body we want to add the jiggle to by using an attribute paint node which will allow us to paint on the geometry.

Under the attributes tab, let's give it the name "jiggle". The character will turn to purple color, indicating that we are ready to paint.

Now select the node, hover your mouse in the viewport and press ENTER to enter into the paint mode. Follow the instructions on the viewport to learn how to use the paint brush.

Any part we paint red is going to get a value of 1 (FG Float) and anywhere painted purple will get a value of 0 (BG Float)

 We painted the following result:

Next, let us setup the vellum softbody. Right click and create a new vellum configure struts softbody node. This creates a cloth and a strut nodes for us. Let us also connect a vellum solver node at the end.

Let us enable the ground plane on the vellum solver and play the simulation using the default settings. The character collapses straight down as shown below:

As we can see, when the character collapses, we lose the animation and the shape of the character. To fix that, let us create a new vellum constraint node and connect it after the vellum struts node. Let's set the constraint type on this new constraint node to 'pin to target'. This will allow us to pin the vellum softbody constraints to the original animated geometry, in order to retain the shape for us.

If we playback, nothing happens. This is because all the points in the geometry are just being pinned to a point.

Let's select the pin constraint and change the pin type to 'soft'. Also let us change orientation pin type to 'soft' as well, and enable 'match animation'. 

Changing the pin type and orientation type to soft gives us access to tweak the stretch and bend parameters.

If we play, the character moves! However, it does not jiggle or simulate as expected. This is because the stretch stiffness is infinitely high. 

If we set the stretch stiffness on the pin constraint to something lower, we will start seeing some results:

If we set it even lower, we get this funny looking springy result below:

This is because the softbody is being pulled down by gravity and the pin constraint is also trying to pin the softbody back to it's original volume. Tweaking the stretch stiffness of this pin constraint will give us different kinds of jiggly results.

Now, let's make this jiggle only affect the belly area of the character which we painted earlier. The painted region are going to be very jiggly while the unpainted regions would remain rigid and stay true to the original mesh shape.

To do this, let us change the stretch stiffness scaling on the pin constraint to 'scale by both' to allow us control the stiffness by our painted attribute mask.

In the stiffness attribute field, let's delete the stretchstiffness written there and instead type the name of our paint mask, in our case, "jiggle".

Now if we play again, only the parts painted purple (BG Float = 0) will not be affected by the pin constraint and we get the jiggle result in those areas like below:

We can improve the result of the jiggle effect by tweaking the stretch and bend stiffness on the vellum cloth and vellum strut nodes. We can also tweak the stretch stiffness on the pin constraint as well.

We will paint more jiggle areas on the fat man to get more interesting results.

We set the stretch and bend stiffness on the vellum cloth to very high values:

We set the bend stiffness on the vellum strut to a high value as well:

And we reduced the stretch stiffness on the vellum pin constraint:

Here's our final result (ignore the intersecting mesh parts):

Here are some tests we did for a female character twerking and jogging:

This is how we can layer vellum simulations on top of animated characters.

You can play around with different settings on all the nodes to get different results!

So far we've been setting up our vellum simulations inside a geometry SOP level. We can also setup our vellum simulations inside the DOP level as well, and this method offers us an advantage that SOP level doesn't have, such as simulating multiple geometries at once.

We will create a vellum softbody simulation in a DOP level in this section.

Let's start by creating a geometry node, enter it's SOP level, and setup our basic softbody constraints, except we will not add a vellum solver. Instead, let us output both geometry and constraints of the vellum constraints in a null node as shown below:

Let us go back to the object level and create a new dopnet node. Double click on it to enter it's DOP level. We will see an output node in this level. 

We are going to create a very basic vellum setup inside this DOP level, similar to how we setup FLIP simulations. For that, we are going to create a vellum object, vellum source, vellum solver, and a gravity node, and connect them as follows:

To add a collider, we are going to create a static object and a static solver node and link them as well.

This is the most basic vellum setup in a DOP level. 

Let's now import our setups into this DOP network.

Select the vellum source node and reference-in the null output of the vellum geometry in the SOP path field, and the null output of the vellum constraint in the constraint SOP path field respectively.

If we play the simulation, it simply keeps falling. 

Let's add a grid as a collider.

Let's go back to the geometry SOP level where we setup the constraints and create a new grid geometry and connect an output null to it.

In the dopnet level, let's reference it into the static object SOP path field.

If we play the simulation now, it works!

We can now start refining the simulation until we get our desired results just like we've always done before.

An advantage of setting up our simulation this way is that we can spawn out multiple softbody geometries, which we cannot do in the SOP level. 

If we select the vellum source and change the emission type to 'each frame', it is going to continuously spawn out the softbody geometry on every frames. We can actually set an offset on the activation with a VEXpression that we've used before: $F%25 == 1 (meaning the activation will happen on every 25 frames for example).

In order to cache out the vellum simulation, we need to go into the geometry SOP level where our vellum constraint setup is. Then we will create a dopimport node to import the dopnet into this SOP level.

Once imported, we can connect it to a file cache node to write out the simulation, and also export as alembic like before.

We can have numerous combination of different settings to achieve several results. For example, to create foot prints, we will need the velocity damping on the vellum solver to be very high. We can also tweak settings like stretch stiffness, bend stiffness, rest length scales, plasticity and so on to achieve different kinds of results.

We can use this vellum softbody to create jiggly effects, water balloons, jelly look effect, or even couch or pillow deforming when an object presses on them.

Vellum grains are pretty easy to setup.

Let's start by creating a sphere and move it up a bit.

Vellum grains need points to be created (just like most other dynamics we've treated before). So, we can fill the volume of the sphere with points by connecting a points from volume node to it. We can also use a grain source node to create the points for us.

Next, we will connect a 'vellum configure grains' node. This node will automatically convert the generated points into grains.

We can also create point group and specify them in the group flag on the vellum grain node, and that will create the grains based on the selected group.

Right now the grains are looking too big, so we can reduce their size by lowering the particle size setting.

Next, we will connect a vellum solver node and enable ground collision. If we play the simulation, the grains will fall down.

Right now the grains are behaving weirdly. There is a delay before they spread upon hitting the ground. Also, their motion does not stop quickly. So let's tweak this behaviour.

Let's increase the substeps on the vellum solver to about 2 or 3 to improve the step calculations. Also, let's increase the collision passes to about 20. 

Then on the forces tab, we can increase the velocity damping to about 0.1

If we play the simulation again, we will see that the grains now behave properly.

If we want more grains, we need to simply reduce the particle separation on the points from volume node.

Just like every other simulations we've learnt, we can get creative with how the grains behave by introducing some forces or velocity or have other objects to interact with the grains.

Let's do a fun exercise whereby we have vellum grains interacting with a vellum cloth. We will have the grains initially stored inside a cloth geometry, then we will apply some force to tear the cloth geometry to spill out the grains inside it.

Let's create a sphere, and move it up with a transform node. With a second transform node, we will create a copy of the sphere and scale it down a bit.

Let's create a pin group for the outer sphere which will serve as the bag for the grains.

Next, let's turn the outer sphere into a vellum cloth. Perform the usual setups.

Let's make the grain bag a bit stretchy by reducing it's stretch stiffness to 1,000,000.

Next, let's make the grains.

Connect a points from volume node to the output of the inner sphere. Then connect it to a vellum configure grains node.

Adjust the grains size by lowering the particle size on the vellum grain node.

Now, let's link the vellum cloth and vellum grain nodes together to the vellum solver. We will do this by using the vellum pack and vellum unpack node that we have already learnt about. Our connections should look as follows:

If we play now, the grains and the bag interacts, and the weight of the grains will make the bag to sag. The bag appears to be too stretchy, so let's increase it's stretch stiffness to the highest.

Under the 'physical attributes' tab of the vellum grain node, we can also lower the mass to make the grains lighter.

If we play again now, the bag does not sag like before. Let's also increase the substeps and collision passes on the vellum solver for a better result.

Now, let's tear the bag so that the grains can spill out.

Add a edge fracture node to the outer sphere, and increase the number of fractured pieces. 

Next, add a vellum constraint and set it's type to weld points. Let's also enable 'breaking' so that the welded points can break.

When we play the simulation, the bag breaks right away. So let's increase the threshold to strengthen the welded points.

Play around with different threshold settings to get different results.

In the example above, we generated grains from an airtight closed object filled with points that were generated with the points from volume node. And when we played the simulation, the grains simply falls under gravity and scatter on to the ground.

What if we want to create a pile of sand at rest so that at the beginning of the simulation, they are already at rest and then they can be acted upon by a collider geometry?

What we need to do is to first create the geometry from which we want to generate the rest grains. Of course this geometry must be closed and position at a starting rest position.

Let's start by first creating a geometry node renamed "rest grain" and jump into the SOP level.

Then let's create a sphere and resize it as shown below.

Let's clip off the bottom half of the sphere using a clip node. Without doing any settings on the clip node, it will trim off the bottom half of the sphere.

Next, let's close the opened border of the half-sphere with a polyfill node. We reduced the subdivisions on the half sphere because the polyfill node messed up the topology, so we will remesh it after closing the border.

Add a remesh node to remesh the bad topology. 

Now add a null output node, and we are done setting up the grains emitter geometry. Let's put all the current nodes connection into their own group and name it "grains emitter".

As we can see, this emitter geometry is right on the ground where we want the grains to be created. The emitted grains will inherit the position of the emitter geometry which is already at rest, so when the grains get generated, they will also remain at rest.

Now let's generate the grains using vellum.

Create a vellum configure grains node, and connect the null output into it's geometry input.

On this grain node parameters, let's enable 'create points from volume'.

This will automatically create points within the emitter geometry on which the grains would be created.

If we want to generate more grains within the volume of the emitter geometry, we can reduce the particle size parameter. The lower the particle size, the more grains we have.

From above, the grains are looking evenly arranged. If we enable the 'jitter scale' setting, it is going to randomize the points, making the generated grains less evenly arranged.

We can tweak the physical attributes of the grains under the 'physical attributes' to adjust how the grains move, such as the mass (how heavy are the grains), friction between them, attraction or repulsion force between each grains etc.

Next, let us add a vellum solver to simulate the grains.

Let's enable the ground collision on the vellum solver so that the grains will rest on the ground when we playback.

By default, when we play the simulation, the grains falls and scatters all over the ground, and they don't settle quickly.

The first thing we should do is to increase the solver to 2.

If we want them to settle fast and still retain their original emitter shape, we will need to increase the velocity damping on the vellum solver so that they lose energy quickly. 

If we go to the advanced tab, under 'sleeping', we can enable 'auto sleep' so that the particles would be at rest, so they will not move much unless acted upon by an external force. We need to keep the velocity threshold to a pretty low value (like 0.001) and set sleep delay to a higher value so that the particles can maintain their rest position.

Now the grains settle much faster with these new settings.

Now let's add a collider geometry. 

We will animate a torus rising from beneath the grains and use the torus as a collider.

So let's create a torus and use a transform node to animate it rising upwards from beneath the grains.

We will wire-in the collider into the vellum grain node.

If we play the simulation, the torus interacts with the particles as expected.

The grains currently behave like dry sands which is good if that's what we're looking for.

We can also make them behave like wet sands, we can do that under the vellum solver advanced tab. If we navigate to the 'grain collision' section, we can set the repulsion weight to zero. This will make the grains more clumped together, and when we run the simulation, they behave like wet sand.

Thus when;

Repulsion Weight = 1, the grains repels each other more and behave like dry sands;

Repulsion Weight = 0, the grains clump together more and behave like wet sands.

We can also achieve similar results by varying the attraction weight as well.

Attraction Weight = 1, the grains clump together more and behave like wet sands.

Attraction Weight = 0, the grains repel each other more and behave like dry sands.

We can use the 'search scale' to determine how far apart the grain particles must be to attract or repel each other.

The attraction and repulsion settings on the vellum solver node can both be set to 1 and will act as a multiplier when we tweak the repulsion and attraction weight settings on the vellum grain nodes themselves.

We can see a big difference between the dry and wet behaviour of the grains.

Now if we look at the 'grain collisions' setting, we will see that the 'max neighbors' is greyed out and we can't edit it.

In order to make this setting accessible to us, let's expand the open CL section and turn off 'open CL Neighbor Search'. 

Once we do that, we will now have access to control the 'max neighbors'. This is a very useful parameter for getting really interesting results with the attractions between the grains particles.

If we increase the max neighbors, we will get lesser clumped grains. If we decrease the max neighbors, we will get more clumped grains.

When we set max neighbors to 40, we get the following result:

When we set max neighbors to 10, we get the following results:

A permutation and combination of different settings on the friction, dynamic friction, and attraction weight will give us different kind of behaviour for the grains, so feel free to experiment a lot.

We can add field forces to our vellum grains in the DOP level to influence their behaviour and get interesting shapes. 

To quickly demonstrate this, let us create a stack of grains at rest using the basic vellum grains setup:

Then setup a quick dopnet setup as follows:

We can stack layers of forces to affect the grains here.

For this let us create a force field node, a position node, and a sop geo node and connect them after the gravity like follow:

The sop geo node is used for referencing-in a geometry that will serve as the field guide, and the position node can be used to reposition the field guide. Finally, the field force node is used to modify the force settings. 

However, this will not work right out of the bat, we need to also set up a geometry that will serve as the force field guide. So let's go back to the SOP level to setup this guide geometry.

Let's create a tube, set it's size and extrude it:

We want the force field to act in the direction of the normal of the guide object, so let's crate a normal node for the guide object.

Then we will use an attribute wrangle node to create the normal attribute for this guide geometry. In the VEXpression, simply type "@N" and press CTRL + ENTER to activate it.

Now let's go back to the DOP level and on the sop geo node, let's reference-in this guide geometry. 

Let's make sure to set the default operations to 'set always' on the position, sop geo, and field force nodes as well.

Then on the field force node, let's delete the "force" in the force attribute field and type in N instead, to indicate Normal. 

We can use the Scale Force parameter to control the magnitude of the field force. We can also animate this parameter over time from 0 to whatever magnitude we want. 

If we are going to animate any parameter on any node inside the DOP level though, we have to set the default operation on the node where we are animating to "set always" so that the vellum solver can evaluate the animation over time.

We will also keep the "use max distance" on to limit how far the particles would be pushed.

Here is the result based on the normal of the guide geometry. The grain particles are pushed off in the direction of the normals of the guide geometry.

When we animate the scale force parameter over time, we got the following interesting result:

We can also stack up layers of different force fields with different guide geometries.

Here's a stacked setup example and the result below:

We can cache the vellum grains simulation using either the vellum I/O or file cache node.

We don't need to add a vellum post process node to vellum grains because they are already particles displayed as smooth spheres.

To export the grains to render in Maya, we simply need to export them as Houdini Digital Asset (check the Maya-Houdini workflow module to learn how to set this up).

Here's a rendered result in Maya Arnold:

Here's another test we did on rest sands, rendered with Maya:

We can also emit vellum grains from animated geometries.

We've already setup the scene by importing a character alembic with animation data and converting the character into vellum grains. 

This is how our scene looks right now:

When we playback, it moves. 

However, if we check the vellum grain node's information, we will notice that the total number of points inside the character keeps changing over every frames. This is not good for our sandman simulation as we need to have a consistent number of points throughout the simulation.

How do we get the number of points to be consistent then?

If we go back to the first frame, we can use a timeshift node to freeze the character at that frame. So let's delete the Frame channel so that it freezes the character on frame 1. If we playback, the character remain still and we've lost our animation.

Like we've examined before, we can bring back the animation by using a point deform node. To get a really good result with the point deform node, it is better to have the character animation starts from a T-pose (or default pose) so that all parts of the geometry can be properly bind and they will deform correctly. Using the point deform in a non-default pose might cause some weird deformation on the character.

See how we connected the inputs of the point deform node below:

So basically, the timeshift node will ensure that the total number of grains in the character stays the same; and the point deform node will be used to get back our original animation.

If we scrub on the timeline now, we will see that the animation is back.

If we also check the total number of points on different frames, we will see the numbers stay the same now throughout.

We can reduce the capture radius on the point deform node to get a better approximation of the deformed object relative to the deforming object, and this will make the playback even faster.

Now, let's simulate. 

We can do the simulation by creating a vellum solver node. However, let's use the DOP method in this case.

So let's feed the output of our current setup into a null output node.

Go back to the object level and create a dopnet node. Then inside the dopnet's DOP level, create the following basic setups. 

Afterwards, reference-in the null outputs of the geometry and constraint from the vellum setup.

We are not going to use any constraint at all in this simulation. We are simply going to drive the simulation mostly by attributes that we will create later.

For now, if we play the simulation, the sandman crumbles right into the ground and the grains are spreading out quite a lot and does not slow down quickly. Well, at least this shows that our basic setup is working.

To control the movement and behaviour of the grains, let's perform the following settings on the vellum solver node:

This is the result we get so far with these settings:

If we reduce the 'attraction' parameter to a lower value, we will start introducing some sort of bounciness in the grains. However, for our purpose here, we set it to a value of 15 so that we can get some clumpiness.

Now, let's link the animation.

We are going to pre-build some attributes to help us do this. Let us go back into the SOP level where we setup the vellum and create an attribute create node to create a new attribute named "stopped" (this attribute name is recognized by the VEXpression and it is a Boolean) and set it to an integer.

This attribute (@stopped) we just created will affect all the points in the input object (in this case all the grains, but it can also be geometry as well). We will use this attribute to control the pins instead of @mass.

When the value of this new attribute is set to 1, that indicates TRUE (a Boolean statement), and all the grains will be pinned and the solver forces won't have any influence on the grains and they will remain unaffected by gravity, but when set to 0, that indicates FALSE, and all the grains will be unpinned and the solver forces will influence the grains and they will crumble.

Let's click the + button to create another attribute named "pintoanimation". This is also another Boolean attribute recognized by the VEXpression, and what it does is to pin points to an animation target like the name suggested, and it also uses the integer values of 1 and 0 for TRUE and FALSE respectively; where 1 means we will pin the animation to the target, and 0 means we won't pin the animation to the target.

Of course, the animation target would be whatever we specified in the target SOP field on the vellum source node like we saw earlier.

Now we have the two attributes we need.

Now if we play the simulation, we will get the same result of the sandman moving just as we did during the vellum grains setup before the simulation. This is nice. However, with this setup, nothing else will ever happen. 

What we want to happen is for the particles to be freed or released over time during the simulation.

To loosen things up, let's add an attribute VOP node inside our SOP level vellum setup.

We learnt about point VOP node in the footprint module. The way the attribute VOP works is pretty similar, so we should be familiar with the VOP workflow.

Let's double click this node to enter it's VOP level.

As usual, we will see two unconnected nodes as shown above.

The particles are in per point basis. If we plug the position to the color output, we will see a resulting color gradient on the particles.

Let's create a relative to bounding box position node. This will normalize the color values from 0 to 1 on each axes relative to the bounds of the geometry.

To visualize these color values as their 0 to 1 gradient, let's connect a vector to float node making sure we are connecting the output Y of this vector to float node to the geometry output node. This will allow us to preview the gradient along y-axis.

Let's drop a compare node and set the test to greater than for example. If we drag the slider front and back, we will see a sharp gradient across the geometry. We can animate this gradient and link it with a predefined attribute.

For example, we can animate this from 1 to 0 to set the pin from TRUE to FALSE, and this way we can gradually release those pin constraints to make the vellum solver forces affect the grains. This is how we are going to control the pin constraints being released over time.

However, we won't animate this parameter inside this VOP level. Instead, let's click the gear icon next to 'compare to float' and choose 'promote parameter'. This parameter will now be available for us to manipulate on the attribute VOP node in the SOP level.

Note that white is 1 and black is 0.

We want the sandman to start disintegrating from his head, so we will change the test to 'less than'.

Now let's animate this parameter from 1 to 0 over the timeline.

Let's go back into the attribute VOP node and create a bind export node. This will allow us to output our animation to any attributes we want instead of the few ones available on the geometry output. 

In this case, we want to output to the stopped and pintoanimation attributes we created earlier. So we will need two bind export nodes and input the names of the two attributes respectively.

Let's disconnect the connection to the geometry output so we have something like this:

We can still preview the output result by following the tip above.

Let's quickly change one more thing before we do the simulation again. Go back to the dopnet DOP setup;

Currently, the two attributes we created 'stopped' and 'pintoanimation' don't get fed into our dopnet simulation just yet.

Let's add a sop solver node to the vellum source node to make us explicitly import them so that they can be updated in our simulation geometry at every frame.

Double click the sopsolver to enter it's geometry context level. We will get this default level:

Let's create an attribute copy node and an object merge node to import our animated geometry. We will connect them as follows.

On the object merge node, we will import our animated sandman (the one we got from the point deform).

On the attribute copy node, we will remove the 'Cd' in the attribute name field, and instead specify the two attributes we've earlier created. So these two attributes will explicitly be copied and they will be updated every frames.

If we playback the simulation now, we will see that it's now working.

We are not quite there yet as this is our first pass of the simulation. 

Go back to the SOP level vellum setup. Let's add a blast node to visualize things better.

With this node, we can visualize the result of the stopped attribute. If we set it up like above and write that VEXpression inside the group, we will only now visualize the result of the animation of the stopped attribute.

Shift click on the animated 'input2' parameter on the attribute VOP node and let's refine the animation curves to suite our taste.

Here's our refined animation graph:

The animation of the attribute VOP release will now be modified.

Let's add a fuse node and plug it to the second input of the attribute VOP node. Increase the snap distance a bit.

Let's modify the attribute VOP input setups as follows:

We used the bind export node to export the attributes we created/modified from the VOP level (that's what the node is used for). Then we can refer back to the exported attributes in the SOP level down the nodes.

The reason for doing this is because we want to release the grains in chunks. So the near point node and import point node help us to create those chunks setup. Although this step is not really necessary, but if we're trying to breakup our grains apart in chunks, this is one way we can approach it.

If we want to change the chunks patterns, we just need to change the snap distance on the fuse node.

Right now we're happy with the progress we've made so far with the simulation. Now let's increase the resolution of the simulation.

We can reduce the particle size on our vellum grain node to get a higher resolution.

Let's reduce it to 0.005 to get a lot more particles.

Go back to the dopnet, select the vellum solver and perform the following settings under the common tab:

In the advanced tab, perform these new settings:

Now let's cache the simulation.

Go into the SOP level and create a dopimport node to import the dopnet into the SOP level. 

In order to optimize the size of the simulation, let's use an attribute delete node to get rid of some unneeded attributes. We will delete every other attributes except for position (which is automatically retained) and pscale.

Then we will connect a file cache node and cache out the simulation to disk.

Our simulation now looks like this:

If we notice that the grains are no longer displayed as spheres like before but instead as points, this is because the attribute delete node got rid of the attribute responsible for displaying the grains as sphere. We can get back that sphere look by doing the following:

Create a copy to points node. Whatever geometry we use on this node would be copied to the points' pscale. This is also a way we can instance custom geometries to points inside Houdini.

Also in the display settings under the geometry tab, if we set the tessellation to 0, it will help us to optimize things and we can preview our particles more easily.

If we want to make the sandman appear more organic and less uniform, we can use a mountain node to displace the input geometry.

We can also export this simulation to Maya as an Houdini Digital Asset to render.

Here's our Maya test result:

Earlier, we talked about using copy to points node to instance custom geometries over a group of points.

Let's quickly learn how that works inside Houdini.

Let's create a grid and use a scatter node to scatter some points on it.

Next let's create a sphere, increase it's resolution and deform it with the mountain node. 

Now we are going to instance this sphere on the grid points. So let's create a copy to points node. Connect the output of the grid to the points input, and the output of the sphere to the geometry input.

This works!

However, in a situation whereby we want to instance the custom geometry to millions of points in our scene, this is going to drastically slow things down computationally.

An efficient workflow would be to simply reference the custom geometry into Houdini rather than it being actually there. 

When we reference-in an object, we won't be able to modify it's components, however we can scale it, rotate it or move it around, but we won't be able to modify it's form.

A good node we can use to do this is the pack node. So let's create the pack node and connect our custom geometry to it right before we instance it. This will pack the custom geometry and compress it's size.

With this pack added, we can increase the total number of points on the grid and this will no longer slow down the scene like before, and everything will still be smooth.

Here's the memory utilization comparison:

So far, we've extensively discussed how to create grains and simulate them.

Earlier we mentioned that we can also use a grain source node to create points within a geometry mesh. When we connect this node to a vellum configure grains node, it will automatically create the grain particles for us without doing any other thing.

A benefit of using this grain source node is that it has a 'uniform radius' option, and if we leave this option on, we will get a uniform particles size throughout (that is the same pscale).

If we examine the geometry spreadsheet, we will see that they all have the same pscale values with this option turned off.

However, if we turn it off, it will randomize the particles sizes for us and we will get different pscale values.

We can also enable the 'compute mass' parameter on this grain source node, and this will take the pscale into account and calculate the mass of each particles based on that. If the grain particles have uniform radius, their mass will also be the same; and if they have non-uniform radius, their masses will be different. 

In order to simulate the grains, of course, we will use the vellum solver. However, we need to ensure that the 'particle size' on the vellum configure grains node is turned ON and also linked to the particle size on the grain source node via relative referencing as well for consistency in number of particles.

Another way we can randomize the sizes of the grains particles is to create a pscale attribute and randomize them.

Like we've explained before, the pscale is an attribute that controls the size or radius of particles. So the first thing we need to do is to create the pscale attribute after the vellum solver node using an attribute create node and give it the name "pscale".

We will set the Class to Point and Type to Float as shown below:

Then to randomize the size, we will add an attribute randomize node. In the Attribute Name dropdown, we will choose 'pscale' which is what we want the randomize to affect. We will also reduce the Global Scale and set the Min and Max Values.

This will randomize the sizes of the grain particles.

In this same way we can randomize color on the grain particles as well. We will first need to create the color attribute, and use the attribute randomize to randomize the colors (color is a 3-value vector input)

In the earlier sections, we've examined how we can use the attraction, repulsion and friction settings to get different kinds of behaviour for our grains simulation.

We can also use the vellum constraints with our vellum grains just like we've learnt before, so we should be familiar with how vellum constraints work normally.

So let's add a vellum constraint to a very basic vellum grains setup.

For vellum grains, we want to make use of the 'glue' constraint as this is the preferred constraint for grain particles.

If we preview the glue constraint, nothing happens. This is because the grains are created out of points, so we should change the group type on the geometry and target field to points, and we should now see the constraints.

Here's a preview of the glue constraints between the grain particles (we did this by plugging a null node to the glue constraint output):

If we play the simulation, we are still getting the same result as normal grain simulation and we can't really see the effect of the glue constraint. This is because by default, there aren't really many constraints.

To modify this, let's take a look at the glue constraint settings:

If we increase the 'constraints per point' to say 4, we will get a much denser constraint now.

If we play the simulation, we will get a weird result and the grains are flying up.

Let's lower the stretch stiffness on this constraint, and also enable breaking. Let's also set the breaking threshold to a high value like 20.

If we play again, we should start seeing a better result.

If we increase the constraint per point and breaking threshold to even higher values, it will retain the shape of the grain emitter more, behaving more like a softbody.