Continuing on my progress with the tuorials featured on Pluralsight, I moved onto Fluids. The set of tutorials went over some of the basics of the Fluid shelf tools, and explained in some detail exactly what a fluid in Houdini consisted of, as well as how to manipulate them using various methods. On top of this the tutorial briefly covered how to properly optimise fluid simulations, something which became very apparent early on when working with large bodies of water such as FLIP tanks, while my PC is quite high-spec, some of the simulation experiments I conducted during this week slowed my machine down to a crawl, some of which elapsed well over 2 hours just to simulate, which I will go into more detail further into this post. Overall the tutorials were very helpful is gaining a basic understanding of fluids in Houdini and did a great job of maintaining my interest throughout.

Aims

• Learn the basics of fluids in Houdini
• Produce test simulations and renders of my experiments
• Time my simulations and renders to better plan ahead to my final outputs

FLIP Fluids are the standard fluids that I will be working with throughout my time with Houdini, FLIP stands for Fluid Implicit Particle, the reason for this title is that the FLIP system is a hybrid of older methods for producing fluids in Houdini. Before FLIP, fluids were either rendered using volume or particles, the problem with these methods were twofold, volume was an accurate method for producing fluids, but used cumbersome techniques when producing the data for their behaviour (Similar to the method of volume collision detection mentioned in my previous blog post), this resulted in very slow simulation times. And particle fluids were erratic in their behaviour, and could result in unruly simulations. FLIP being the hybrid, takes both of these methods and uses them in tandem with eachother, resulting in an accurate but still somewhat effecient method of calculating fluids.

Upon creating a fluid from a piece of geometry, a large bounding box will surround the particles, this represents the limit of which the fluid can exist within the scene, the use of this being that a clear cutoff point can be created, so when parts of the fluid move out of the viewport, they no longer need to be calculated and make the simulation more efficient.

Looking at the node view, when creating a fluid two nodes are created at the object level, the fluid and the fluid interior, these two nodes mainly effect the appearance of the fluid when rendering out, whilst the tutorials did not go into any detail regarding this, I will have to make a mental note to research how to apply shaders to my fluids, as when I am creating my final outputs, keeping the default shader on my simulations will not result in a realistic look.

Speaking of realism, an important note I made when experimenting with fluids was that not applying any forces other than gravity to my fluids resulted in a very unrealistic look, as all the particles were sticking to the same velocity and direction. An easy method of combatting this was to add turbulence and randomness to the fluids, I achieved this using the ‘Curl noise’ and ‘Vortex’ options within the fluid source node. This resulted in the fluid twisting from the vortex and added some randomness to the initial velocity of the particles with the curl noise option, making my fluid look similar to water ejecting from a faucet.

For this simulation I wanted to do a quick test on my simulation time, according to the fluid output node, at it’s most dense point there were 50,000 particles which made up my fluid. For a 240 frame simulation of a fluid emitter, with both vortex and curl noise added, the simulation took 4 minutes and 30 seconds, overall a good time for developing the look of the fluid, but if I were to render I would obviously up the amount of particles significantly.

Next I moved onto FLIP tanks, unlike fluid emitters, the FLIP tank on its own consists of a constant number of particles and does not move outside of it’s predefined area. I noticed some recent changes to the FLIP tank when researching into the latest version of Houdini, now there is a feature call ‘Narrow Band’ when creating a tank, basically this simulates only the active parts of the tank, leaving any particles under the surface that don’t move unrendered, supposedly this saves on computing power but a quick test of my machine gave a difference of 1 second in simulation time. While it did not make a difference in my FLIP tank simulation, I imagine that a tank with a lower particle separation would benefit greatly in simulation time.

Example of the effects of narrow band.

Below I have embedded a quick render of my flip tank simulation, I added a POP wind node to the DOP network to simulate the waves of the ocean, and using one point of the boat to interact with the motion. While the boats reaction to the water looks quite unnatural, the fluid itself looks somewhat realistic. To improve on this I would first change the motion of the boat, perhaps by inserting some keyframes to smooth out the animation, and secondly I would lower my particle separation to create a more realistic looking fluid.

https://www.youtube.com/watch?v=-lI5FoiiOBQ

Simulation Time – 4 minutes 7 seconds

Render Time – 1 hour 32 minutes

https://www.youtube.com/watch?v=k69uCAxG8t8

https://www.youtube.com/watch?v=uSJW1B1WVFo

Moving on to some further work in Houdini, I wanted to get a better grasp of collisions and dynamics before I moved on to particles, to accomplish these goals I continued to progress through the Houdini Core Skills tutorials featured on Pluralsight. The tutorials themselves covered a broad overall view of how particles and collisions work, again mainly sticking to the shelf tools available within Houdini, but also delving somewhat into VEX expressions without overwhelming the viewer. Topics covered ranged from how particles and collisions work in tandem, the birth attribute and sprites. Overall, these set of tutorials were very helpful on improving my understanding of how each node in the DOP network affects the sim, as well as giving me a good amount of knowledge in how to approach my final sims.

Aims

• Gain a better understanding of how collisions are calculated within Houdini
• Further test and play around with dynamic operators and how they can affect a sim
• Learn the basics of particle operators and some VEX expressions

The particle tools within Houdini, like most tools are either located in the shelf or within the tab menu of the node view. Using the source particle emitter on a piece of geometry will cause all parts of that geometry to emit particles, without any other forces applied to this other than the gravity node which is automatically added, the particles will fall straight down at a constant rate seemily infinitely. To further control how these particles behave, it requires jumping into the DOP network and playing around with some settings. The most important of these settings is under the POP source (Where the particles will emit from), from here you can access the Birth tab, which can control how many particles are emitted per frame and how long these particles will stay in the scene

For optimisation in the simulation, the life expectancy value can be quite important as well, this value controls how long a particle will remain in the scene before it dies. The default value for this is 100 and is measured in seconds, not frames, so a life expectancy value of 1 at 24fps will mean that once a particle reaches the 24th frame of the sim, it will cease to exist. On top of this there is the life variance value, which adds seconds in the positive and negative to randomly assigned particles, the purpose of this being that it creates a more natural cut off point for particles, whereas without it there will be a very abrupt end to the particles emitted. A random seed can also be added to the Life Variance value, resulting in differrent values being applied to the particles.

Particles and the values applied to them are also affected by the framerate of the scene, for example, an emitter with a birth rate of 5000 will generate more particles at 24fps than a scene set at 30fps.

After some experimentation with these values, as well as using the POP velocity tools, I used some geometry provided in the tutorials excersise files to create a basic effect of firing a fire extinguisher, and a space shuttle re-entering the earth’s atmosphere. Both of these effects were created relatively simply, for the fire extinguisher, I had emitted the particles from the nozzle part of the geometry by creating a group node for the selected faces and directing the POP source node to that node, then adding some values to the initial velocity of the particles as well as some variance to these values to create a more natural flow of particles. And for the space shuttle, the particles were emitted from the base of the craft, turning off gravity and then adding a POP wind node into the DOP network so that the particles flew upwards and interacted with the rest of the geometry.

Onto the next set of tutorials, which were relatively short, these covered some of the basics of dynamics which I already had a relatively good understanding of, but went into some greater detail regarding collisions and exactly how they were calculated within Houdini.

Dynamics can be viewed simply as another toolset for animation, which can be a more time effective and realistic method for animation over keyframes, animated a box falling onto a plane can take a long time to animate by hand when aiming for realism, but with dynamics and the shelf tools, can be a relatively simple process with good results.

Diving into the node view in some greater detail, when applying rigid body dynamics or any other set of dynamics to a piece of geometry will create an Auto DOP network which works like a river of data, first the object source node which states where in the node view the geometry will be pulled from, moving onto a merge nodes, which are simply there to filter and combine any nodes to keep the view clean. This then moves onto the most important part of the DOP network, which is the solver, a solver is basically a ruleset which any geometry connected to it must conform to, it contains what constitutes most of a simulation.

Regarding collisions, the Auto DOP network uses collision data to optimise the scene, so without looking at the collisions of a RBD object, the simulation may not represent true to life collisions, which can result in clipping and other oddities when interacting with other RBD objects.

Collision geometry can be calculated in multiple ways, using the RBD solver, collisions can either be calculated using volumes or surfaces. Whilst volume can be a faster method of calculating collision data when working with simpler objects, it gets significantly less accurate using a low amount of divisions. The way this works is that when using the colume for collisions is that Houdini takes a box and places it to encompass the object and the amount of divisions within that box determines how many times the box is divided in the X Y and Z directions. So when working with more complex geometry, a low number of volume divisions will result in an inaccurate set of collision data, whereas a high number of divisions will require significantly more computational power, as this method also analyses spaces within the box with no geometry.

An example of volume collision detection.

Surface collision detection on the other hand can either usse the edges or points of a piece of geometry to collect data, which results in an accurate representation of collisions, without having to calculate any empty space, and purely sticks to the geometry, when working with complex objects, this can be a faster and more efficient method of gathering collision data.

An example of surface collision detection.

Next Steps

• Utilise my knowledge of collisions and particles to produce a few experimental simulations
• Begin to learn about fluids within Houdini

Taking my first steps in Houdini was somewhat more difficult than i had originally anticipated, as finding learning resources and tutorials on the subject was either non-existant or well above my current skill level. After a while of searching I found that the best beginner tutorials available were locked behind a paywall, after some deliberating I decided to go with the offerings on pluralsight.com due to the sheer amount of material they had available on Houdini.

After discussing this issue with my tutor, I was told to consider making my own basic tutorials to fill this gap, once I had become comfortable with the software.

Aims:

• Learn the basics of the Houdini interface
• Transfer over my existing skills in polygonal modelling
• Get to grips with rigid body dynamics
• Render out a basic scene

I followed along with the ‘Introduction to Houdini 15’ course featured on pluralsight which is roughly 7 hours long, overall, the series of tutorials in this course were incredibly helpful in breaking down the interface and various tools available in Houdini, and covered a wide range of topics and concepts. The only flaw I could find was that the series was made during version 15, whereas I was using V16, this caused a few minor problems along the way, but were quickly solved by turning to help pages and forums, most of these problems concerned tools that had moved in the interface or combined with another.

After getting the hang of the interface, the series moved onto importing an existing model of a car, which needed to be resized. It was explained that scene scale within Houdini was very important, what this means is that the units of measurement used for the size of a piece of geometry will have a large effect on dynamics and the results they produce. For example, using the same dynamic simulation on objects of two different sizes will yield different results.

Larger objects will appear to fall more ‘slowly’.

Moving onto some polygonal modelling, I began tidying up the car model, as well as modelling the wheels. One useful tool I found whilst doing this was the ‘slide on surface’ feature within the move tool, which enabled me to move and clean up my topology, without risk of distorting the shape of the model, something which would have been useful throughout my work with maya.

After this, I moved onto modelling the tires for the vehicle, it was at this point where the procedural nature of Houdini became apparent to me, whereas in maya, operations such as subdividing or extruding were destructive, in Houdini these operations are carried out in the node view and placed in a sequential order, then can be changed at will, no matter how far up they are in the hierarchy without causing any errors in the model. This was also very useful in cases where something did go wrong with the model, as I could simply work my way through the nodes and spot where the error was made.

The wheel consisted of roughly 30 nodes.

After playing around with some of the shelf tools to make the wheel, it was time to UV unwrap, having a decent amount of experience in this area from my time in Maya, I was prepared for quite a tedious process, but to my surprise, the entire process was automated and produced good results. I intend to research into this in some more detail, as I’m quite curious how this works.

Unwrapped wheel

Last but not least was a quick dive into rigid body dynamics (RBDs) to create the final scene, overall , this was quite a basic attempt but turned out quite well. I took the existing building geometry and seperated a window pane by using the select primitive tool and then the RBD fractured object tool. Houdini does this by first converting the object to a volumetric fog, then selects random point as to where the object is to be fractured (The number of these points can be manually adjusted).

After this it was  a simple process of adding a ground plane to act as a static object for the vehicle to land on, as well as the initial launching pad for the car. I then made the final car a RBD hero object, went into the DOP (Dynamic operators) network that these processes created, and added some velicity to the cars initial state so that it launched and broke the window with a good amount of force. I also altered the bounce and friction values of the car, as the first simulation resulted in the car giving off the impression that it was made of rubber. Gravity is automatically added when making RBD objects at its real world value of 9.8m/s down the Y axis.

I made a quick render of my final scene, which can be viewed below.

https://www.youtube.com/watch?v=i2N9zJUqTPU

Next Steps

• Begin to learn particles in Houdini
• Learn how to best optimize my renders
• Research into work I intend to take inspiration from