!

!
!
!
!
!
!
!
MSc!Thesis!
!

!Crowd!Simulation!&!Implementation!in!
Houdini!using!custom!VEX!SOPs!
!
!

!
(Nomish(Bhardwaj,(i7222320,(MSc(Computer(Animation(&(
Visual(Effects,(NCCA,(Bournemouth(University)(
(
(
(
(
(
December(2013(

INDEX&
&
&
Title&
!
&
!
&
!
Chapter&1&
&
!
&
1.1 Introduction!&!Abstract!
1.2 Related!Work! &
!
&
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!

Page&
!
!!
!
!
!
01!
03!
!
!
!
!
Chapter&2&
!
!
!
2.1!Background!&!Theory!
07!
!!!!!!!!!2.1.1!Tools!of!Choice:!Houdini!&!VEX!
07!
!!!!!!!!!2.1.2!Overall!Implementation!of!System! 10!
!!!!!!!!!!!!!!!!!!!!I!Agents!
11!
!!!!!!!!!!!!!!!!!!!!I!Simulation!
12!
!!!!!!!!!!!!!!!!!!!!I!Geometries!
15!
!
!
2.2!Behaviors!&!Mind!Implementations!
16!
!!!!!!!!!2.2.1!Simple!Behaviors!
17!
!!!!!!!!!!!!!!!!!!!!I!Separation!
17!
!!!!!!!!!!!!!!!!!!!!I!Alignment!
18!
!!!!!!!!!!!!!!!!!!!!I!Cohesion!
19!
!
!
!!!!!!!!!2.2.2!Mind!Algorithms!
20!
!!!!!!!!!!!!!!!!!!!!I!Simple!Mind!
21!
!!!!!!!!!!!!!!!!!!!!I!Priority!Mind!
22!
!
!
!!!!!!!!!2.2.3!Advanced!Steering!Behaviors!
23!
!!!!!!!!!!!!!!!!!!!!I!Steer!Arrive!
23!
!!!!!!!!!!!!!!!!!!!!I!Steer!Wander!
24!
!!!!!!!!!!!!!!!!!!!!I!Obstacle!Avoidance!
25!
!!!!!!!!!!!!!!!!!!!!I!Steer!On!Surface!
26!
!!!!!!!!!!!!!!!!!!!!I!Path!Following!
27!
!
!
!
!
Conclusions&&&Future&Work&
28!
I Screenshots!
28!
I Future!Work!
30!
!
References&

!
!
!

ACKNOWLEDGEMENTS&

!
!
!
I!would!like!to!thank!Professor!Jon!Macey!for!providing!me!with!inspiration!and!
guidance!throughout!the!course!of!developing!this!project.!I!would!also!like!to!
thank!Professor!Phil!Spicer!for!providing!advice!that!helped!me!towards!the!
completion!of!this!project.!Finally,!I!would!like!to!thank!all!my!professors,!
classmates!and!friends!at!the!NCCA!who!have!been!a!support!along!the!duration!
of!MSc.!

1!

Chapter 1

1.1 Introduction & Abstract

Crowd behaviors can be observed among collective groups of animals, insects
and birds. Each group exhibits various behaviors; some specific to the species
while some behaviors could on a generalized level, be common to most crowds
overall. These behaviors define the way the individuals of the group interact
with each other, as well as the surrounding environment as a whole. Each
individual can be treated as a separate entity, referred to as agents along this
documentation.

(Figure 1.1: Bison herd, courtesy National Geographic)

Some common observations among aforementioned crowds could yield us to

witness such behaviors. For example, the above image (Figure 1.1) shows a
herd of bison. Further observation reveals that each of the bison has individual
identities, but each one constitutes to the formation of a cohesive group as a
whole. The herd is moving across the ground plane towards a common target
location, they are all aligned in such a way that each one moves in a similar
direction, they stick to each other while maintaining some distance amongst
each other, every individual has its own space to move about but overall the
herd has common objectives. Such simple behaviors are easily noticeable in
flocks and herds of many animals or birds and even insects.

2!

[Figure 1.2: Swarm of ants, courtesy Wikimedia] [Figure 1.3: Swarm of bees, courtesy BBC]

As can be observed from the above images (Figures 1.2 & 1.3), such simple
behaviors can also be observed in swarms of insects, even bees.
With the advancement in technology, there is a co-existing rise in demand to
emulate real life like behaviors in the virtual computer graphics environment.
With the technology available at hand, this can and has been made into a
reality. Various stand-alone off-the-shelf softwares such as MASSIVE do exist,
but nevertheless, large scale industries such as Moving Picture Company,
Double Negative, Industrial Light & Magic all build their own software for
simulating behaviors of crowd. This offers a much higher level of flexibility for
individual firms, also reducing the licensing and costs related with purchasing
proprietary software.
Simulating a crowd has numerous advantages as opposed to conventionally
animating every individual element of a crowd. The requirement of using a
crowd simulation comes in when a particular shot/scene needs a number of
characters animated, more than those that are viable to be individually worked
upon.
My masters project aims to simulate these crowd behaviors on a number of
agents, in Side Effects Houdini FX, using custom VEX operators being
cooked in a SOP Solver, within a DOP network. The following thesis will
provide the specifications and documentation of the same, further explaining
the idea, theory and algorithms behind the whole system.
The project was made on Side Effects Softwares Houdini 12.1.77, running on
a Mac OS X v10.9 platform.

3!

1.2 Related Work

Crowd simulation systems have evolved over the course of two decades, one of
the very first uses of behavioral animation was used in a short animated film
named Stanley and Stella in: Breaking the Ice (1987), this piece of animation
was unveiled at the SIGGRAPH 87 and was a created by Craig Reynolds and
other at Symbolics Graphics Division. The animation was specifically aimed at
presenting the capabilities of the boids artificial program.
Use of Crowd Simulation systems have been prevalent over the years since
then and have been used in all forms of computer graphics, including films,
advertisement, visualizing traffic/pedestrian simulations etc. Such systems have
had various uses to simulate all forms of crowds ranging from simple flocks
such as birds, bees etc. to simulating complex behaviors of crowd such as large
armies of characters, (humans, creatures, etc). With the growing demand of
photo-realism, and emulations of real-life phenomena, having life-like crowd
simulations emulating real behaviors of a crowd is a must.
In James Camerons Titanic (1997), extensive use of crowd simulation was
used to generate life-like movements for virtual humans. The movements of
these people were generated from a library of precaptured motions. It offered
great advantages, including safety of real people having to perform actions
such as falling off the ship, otherwise (Gu 2004).
During the time of production of Wolgang Petersons Troy (2004), Warner
Bros., the need for simulating high level crowd simulations became a necessity
since the movie was based on the greatest battle of all times. Moving Picture
Company was assigned to the task of VFX. After considering the cons of
buying Massive software licenses straightforward for the ordeal, its high cost
of licenses and having realized it wasnt capable enough for their requirement
Moving Picture Company employed R&D developers to create and develop an
engine to simulate a multi-agent animation system in order to control crowd
behaviors. (Bielik 2004)
This resulted in the formation of Artificial Life Crowd Engine, better known by
its acronym, ALICE. ALICE was developed as a Maya based multi agent
animation system and it enabled Crowd Technical Directors (TDs) to create
crowd layouts and simulation using Mayas build and a whole lot of custom
tools.

[Figure 1.4: Use of Alice: before(l.) and after(r.)]

4!

Crowd control networks are easy to generate in ALICE, simply by plugging

dependence nodes together, forming a network path that is easy to understand
and maintain.

[Figure 1.5: ALICE control network]

(Figure 1.5) shows one such network. ALICE was also employed in
Christopher Nolans Batman Begins (2005), to control 3D bat swarms, and this
was the first time ALICE was put to use for controlling complete 3Dimensional movements of agents. (Kolve 2004).
When Ridley Scotts Kingdom of Heaven (2005) came into production, again,
the task was handed to MPC to deploy ALICE in order to simulate epic battle
scenes. It may seem that the use of same technology employed for simulating
crowds in Troy could be used for Kingdom of Heaven, but this wasnt the case.
Kingdom of Heaven relied on the entire content being produced in 2D, whereas
Troy was a 3D project and was assembled in 2D (Bielik 2005).
The output of ALICE consists of a cache file containing information of the
pose and form of each agent in the simulation. ALICE has since been used
over 30 feature films.
Another popular software package, mentioned earlier, named MASSIVE was
developed by Stephen Regelous. MASSIVE stands for Multiple Agent
Simulation System in Virtual Environment and it employs the use of fuzzy
logic to control individual agents to respond to its surrounding and other
agents. It was originally developed for use in Peter Jacksons Lord of the Rings
trilogy and has since then become one of the leading softwares for simulating
crowd behaviors, used in feature films and commercials, television shows etc
MASSIVE has aided to projects such as 300 (2007), Avatar (2009), Eragon
(2006), WALL-E (2008), Hobbit (2012), Life of Pi (2012) and many more.

5!

[Figure 1.6: Network Node view in MASSIVE]

As can be seen in Figure 1.6, MASSIVE also employs a nodal tree network to
control agents and their behaviors.
Another software package, essentially a plug-in for Autodesk Maya exists by
the name of Golaem Crowd. A French-based company that goes by the same
name Golaem developed it. It was released in 2011 and has since then been
used in production for titles such as Asterix and Obelix: God Save Britannia
(2012) and for simulating zombie crowd in the film Warm Bodies (2013).
On similar lines, Basefount has developed a plug-in for Maya, named MiArmy,
for controlling crowd-based behavioral simulations and creature physical
simulation/rendering. Miarmy uses fuzzy logic with no requirement of
programming and/or complexities of connecting nodes and supports all popular
renderers such as Renderman, Mental Ray, V-Ray etc.
Crowd Simulation systems hold value outside of the animation/vfx industry as
well. Such systems are used to build numerous simulations such as crowd
evacuation models, to simulate pedestrians/traffic systems, in medical and
science research areas, etc. One such simulation system was developed in
Karlsruhe, Germany by PTV group (Planung Transport Verkehr AG). Named
PTV VISSIM, it uses the concept of micro-simulation, i.e. simulating each
element/agent individually, this includes all interactions and properties of
behaviors being simulated at an individual level. It is widely used to simulate
traffic, including vehicles (cars, trucks etc.), public transport (trains, trams,
buses), even two-wheelers/bicycles and pedestrian behavior. This holds
advantage in fields such as transport planning, simulating zebra
crossings/pedestrian behavior at traffic lights, urban planning, fire/emergency
escape planning etc.

6!

[Figure 1.7: Simulation at a Traffic Signal using PTV VISSIM]

The above image (Figure 1.7) shows a simulation and behavioral interaction
between cars and pedestrians crossing a traffic signal.

7!

Chapter 2

2.1 Background & Theory

2.1.1 TOOLS OF CHOICE
Houdini & VEX
Houdini, a popular and powerful 3D animation application software package,
was chosen as a software package to build the simulation system. One of many
reasons behind this is its intuitive network-based procedural workflow based
on nodes (Figure 1.8). This helps in keeping the system modular, and very
adaptable.

[Figure 1.8: A nodal network view for procedurally generating a wall in Houdini]

Furthermore Houdini incorporates the use of scripting languages such as

Python, H-Script, VEX etc. providing an added flexibility in designing a
simulation system. The base of the crowd system consists of point geometry,
and the behavioral algorithmic manipulations are applied on these geometric
points. Normally, for particle simulations, one would employ a POP surface
network node within Houdini. POP networks offer high functionalities in terms
of event handling, state behaviors etc., but are fairly limited if one wants to

8!

implement custom behavioral algorithms such as the ones needed in Crowd

Simulations. POP Networks always limit the simulations to be played from the
first frame, whereas using something such as a DOP network, one can import
the previous frame geometry to apply the manipulations to. Additionally, using
a DOP network in Houdini, a SOP solver can be implemented within, that
cooks a SOP network, frame by frame. This SOP network being cooked
contains the network of VEX SOPs.
VEX stands for Vector Expressions and it works on a per-point basis (pixels,
particles, channel samples etc). VEX is a scripting language, native to Side
Effects Houdini. It was originally meant to be a shading language that has been
extended from simply working on pixels being shaded, to being able to work
with other types of data like geometric points, pixels of a certain frame, point
particles and other data. Such an integration of VEX with Houdini provides a
great advantage to be able to build systems from a ground-up level and also
gives a high amount of flexibility for manipulations of point positions required
in various simulations.
VEX operations can either be hard-coded in custom made VEX operators, or
similar operations can be performed in a visually interactive way provided by
Houdini, using VOP SOPs. VOP SOPs are used to create VEX networks and
use the Houdini network viewer to allow the user to interactively view/add/edit
the different VEX operations being performed at a network level, as shown in
(Figure 1.9).

[Figure 1.9: Network view of operators within a VOP SOP]

This offers a more user-friendly approach as compared to the conventional

method of simply writing up code. On the other hand, using custom VEX
operators by hard coding VEX functions offers a much higher amount of
control and flexibility. Hence, the selected chosen method of approaching the
crowd simulation system was creating custom VEX operators, coded in VEX.
As mentioned before, a DOP Network was implemented within Houdini. This
DOP Network holds the SOP Network incorporating the VEX SOPs. These
VEX SOPS held within the SOP Network get cooked per-frame using a SOP
Solver node. This results in manipulating the geometry and points by
specifying and implementing behavioral algorithms within different VEX
SOPs. Also using the nodal network implementation in Houdini, these custom
VEX operators could be inter-linked to create a network where different data

9!

and their implementations can be passed around easily. An important

fundamental point to note with VEX is that it does not create data, like
geometric points etc; its functionality dictates it to simply manipulate or
modify existing data. (Gary 2007).
But it does allow one to create attributes for the existing data, or geometry
points in our case, and this was highly advantageous in order to be able to
simulate behaviors on a given set of geometry points. Hence, by creating or
importing geometry points on a geometry level within Houdini, we can apply
transformation and manipulations, based on algorithms, within the VEX SOP
using VEX code functions. These geometry points have attributes such as
Position, Normals, Id, etc. Such attributes are managed at a global level and
hence can be accessed by the VEX SOPs, thereby allowing them to manipulate
these values. VEX works on a S.I.M.D pattern, i.e. Single Input Multiple Data.
It works on all the points at the same time, hence the algorithms need to
implemented keeping this in mind.
Houdini offers a fantastic way to access the geometry points, offering a pointcloud support implementing K-D trees. Such point cloud architecture allows
quick lookups for neighbours, which is certainly a helpful feature in a system
such as a crowd-simulator. (Kewlani 2013)
A VEX function called pcopen is used for this purpose, and this function
returns a point cloud file (.pc) and queues up access to the points contained
within it. These points can then be iterated using pciterate. (Side Effects
Software 2013)
Within a DOP Network, Houdini offers a SOP Solver. This node solves, or
cooks the network within a SOP Network, frame after frame, allowing us to
solve the next time step using the previous frame geometry (Figure 1.10).
While Houdini does offer a Houdini Object Model (HOM), that is essentially
an API allowing one to use Python as a scripting language to manipulate data,
the point-cloud lookup functionality is not applicable in this case. Although
Python would serve an advantage over VEX, this being the ability to generate
newer point data, the fact that the boon of point-cloud lookups within Houdini
would be lost. Instead, we can use another feature of Houdini, that is, create
Digital Assets for wrapping up object geometry at a geometry level, thereby
allowing a user to be able to change the number of points, along with other
functionalities at a generic geometry level.

10!

2.1.2 OVERALL IMPLEMENTATION OF THE SYSTEM

A Behavior in our context maybe defined as any module that suggests and
computes a steering direction. Using behaviors to guide a crowd-simulation
system helps keep it modular, expandable and also makes things easier to
implement and understand.
Basic crowd behaviors were first devised and developed by Craig Reynolds in
1987. He defined a basic flock of crowd to have behaviors of Separation,
Cohesion and Alignment. (Reynolds 1987)
A successful crowd simulation would have to imply a various combinations of
such behaviors. Initially, to start off with building a modular Crowd Simulation
System, basic flocking behaviors were implemented. These include basic
separation, cohesion and alignment. The overall implementation design
structure of the system is broken down into the following parts; namely:
-

Agents (Containing geometry points, attribute data related to the points,

etc., desired agent geometry can be stamped on these points)

Simulation (Using simulation solver and SOP network)

-> Behaviors (Defining our behaviors to be implemented)
-> Mind (The central unit that does all the final calculations and
computes the final steer force to be applied to the agents)

Environment (Containing geometry related to ground terrain, obstacles,

etc.)

(Figure 2.1: Basic system architectural design)

11!

Agents
Agents can simply be defined as a sole instance of an autonomous character
(Schnellhammer! 2011). These could range from something as small as
ants/insects to more complex human beings. These could also be swarms of
bats or a flock of birds or even vehicles. Different agents will behave
differently, by setting custom parameters and behaviors.
In our case, all agents are represented using geometric points. Our behavioral
algorithms are solved on these points and their movement is altered
accordingly. Geometry is then copied onto these points just as a final look. This
geometry can be replaced with imported BGEO geometries or a string of
geometries can be imported and time-shifted in such a way that it follows an
animation-cycle movement instead.
To generate geometry points for our agent, we start with scattering points over
a grid. Houdini provides with a scatter SOP that enables us to scatter points
over geometry, thereby converting the geometry into a set number of points (as
specified in the scatter SOP). This works well, but has a drawback to it; it does
not uniformly scatter points. For this I have used an external Houdini Digital
Asset called csUniformScatter (Schnellhammer 2010). Instead of utilizing an
external digital asset, we can also use the Compute Number of Points option
of the Scatter SOP but it is still advantageous to use the asset in order to have a
more even/uniform scatter by increasing the Distribution Iteration value of
the asset.
These scattered points are then projected onto the ground-plane using a Ray
SOP. Ray SOPs will scatter the primitives onto the specified input, ie., the
ground-plane in this case. Initial attributes are set using the AttribCreate SOP,
and also using a Point SOP, the initial velocity, scale and up-vector values are
set (Figure 2.2).

12!

[Figure 2.2: Network of creation of initial state of agent particles]

Once we have the initial system of geometry points, this geometry is called into
a DOP Network, where the actual simulation happens.

Simulation
A DOP network was created for handling point manipulations and updating
positions, rather than a POP Network (as discussed earlier). Within the DOP
Network, the initial state of the agents, more specifically, the point geometry
created before, is imported into a SOP Solver using a SOP Geometry node
(Figure 2.3).
A SOP Solver DOP lets the DOP simulation use a SOP network to evolve an
objects geometry over time. (Side Effects Software 2011)
This means with the SOP Solver we can get the last time-step of our geometry,
modify it and then pass it to our next time step. (Schnellhammer!2011)
The SOP network in question, is nothing but a chain of SOPs, in this case, the
custom VEX SOPs coded in VEX, comprising of our Behaviour Network.

13!

[Figure 2.3: Simulation DOP Network]

Within the Behaviour Network (Figure 2.4), a stamping expression is used on

an Object Merge Node to fetch the previous time frames geometry. This is
used as a starting point for the next time-step within the Network of Behaviour
SOPs. (Side Effects Software 2011)

[Figure 2.4: The Behaviour Network]

The output of this is then called into our initial agent SOP network using a
DOP Import SOP. This is where different geometries are copied onto the
agents geometry points. (Figure 2.5)

14!

[Figure 2.5: Agent SOP Network]

Once the geometry was copied onto each point, the new geometry moved on
the same position as that of the agent points, with their positions getting
updated simultaneously with those of the agent point positions. This does
simulate movement, however, the agents do not rotate with. For this reason, a
VOP SOP is created, used to add a rotation attribute to the geometry points
(Figure 2.6). As attributes created are at a global level, this can be accessed
within our simulation.

[Figure 2.6: Rotation add VOP SOP]

ALGORITHM:
! VEX function lookat is performed with its To Location set as heading
and passing Up vector

15!

! Convert this from matrix to quaternion

! Add this attribute as rotation
! Extract Transform from Lookat from the matrix obtained from lookat
and save this as a vector attribute

Geometries used as agent representation:

In order to represent agents, a basic human male OBJ file was obtained
(TF3DM 2013).
A particularly time consuming task was creating a bipedal rig within Houdini
with the applied geometry. The rig was further used to create a walk-cycle
animation of 34 frames and the frames were exported as a sequence of BGEOs
after reducing the poly-count. (Tedin 2013)
These BGEOs were imported per-frame using a time-shift SOP, producing a
walk-cycle movement for the agents.

[Figure 2.7: Agent Representation Geometries]

Another simple geometry of a droid was procedurally modeled in Houdini

(Figure 2.7).

16!

2.2 Behaviors & Mind Implementations

As explained before, our Behavior Network resides within our simulation DOP
Network and this is where the steering algorithms are being applied to a
Mind. Each Behaviour Node defines different algorithms, acting as behaviors
being applied to each agent. These nodes compute a certain amount of steering
force, based on the behavioral algorithm applied. Each behavior is also
implemented with priorities. These forces are sent to the mind Solver, called
SteerSolver. The Steer Solver node decides what forces are applied to what
extent, based on the priorities and other defined parameters. The forces
calculated by the behavior nodes are nothing but velocity vectors, having
certain magnitude and direction. Hence, vector math is applied to compute
these steering velocities.
To start with, basic behaviors of a flock, as devised by Craig Reynolds (1987),
were implemented. These include Separation, Cohesion and Alignment (Figure
2.8).

[Figure 2.8: Craig Reynolds Flocking Behaviors]

17!

2.2.1 SIMPLE BEHAVIORS

Separation:

[Figure 2.9: Separation Behavior]

In a crowd, the members of a crowd normally tend to not get really close to one
another, and steer away from each other if they get too close. They tend to
maintain a certain space around them, and keep a certain distance of separation.
As can be seen in (Figure 2.9), an average Steer Separation force is calculated,
comprising of an average steer force that moves away from the neighboring
agents, and this force is applied to the current agent. Also, without the
application of such a steering behavior, the agents will overlap positions, or if
used in combination with a behavior such as cohesion or point-of-arrival, they
would all swarm into one single point, creating a vortex like appearance.
Underlining the importance of this separation behavior, a VEX operator was
created.
ALGORITHM:
! Define a Search Radius around the current agent point position to
search for neighbours
! Get agent points with positions within that radius (using point cloud
lookup)
! Compute the difference between a found points position from the
current point position and negate it (since it will be an opposing steer
force)
! Divide this difference by the distance between the points (closer the
points, more the force and vice versa)
! Do same for all found agent points within the search radius and store
the sum of these steering forces
! Divide sum by the number of neighbour agents found, this is the average
steer Separation force
! Clamp/Contain forces accordingly

18!

In order to avoid simple collisions, an Interpenetration Constraint was added.

With this, if the agent points are within a very close distance to each other
(Determined by pscale value), a force is applied, steering away from each other
by the amount of distance found.

Alignment:
The behavior of Alignment makes all the agents in the entire crowd steer in a
similar direction. Every agent within the crowd will have some defined
direction. In order to steer the crowd along a common direction, the agents
within a crowd try to align themselves with each other, according to the group
as a whole, or simply with the agents as seen within the field of view of the
current agent.

[Figure 2.10: Steer Alignment Behavior]

As (Figure 2.10) suggests, the current agent in action will calculate an average
direction of its neighbor agents and will steer towards the calculated average
direction.
ALGORITHM:
! Define field of view angle
! Get agents within the affected angle
! Sum up their velocities
! Divide sum by number of neighbor agents found
! Found result will be the average steer Alignment force. Clamp
accordingly.

19!

Cohesion:
If we observe crowds in real life, the behavior of cohesion is quite significant.
The members of a crowd show a grouping behavior, that makes the group act
as a single whole cohesive unit. Each member of the group is consciously
aware of not steering away too far from the group. This is done by maintaining
a cohesive force amongst all agents within the group. Cohesion behavior makes
every agent calculate an average cohesive steer force and steering towards a
direction with that force applied. This is simply done by checking the positions
of the nearby agents.

[Figure 2.11: Steer Cohesion Behavior]

As can be seen in (Figure 2.1), the agent in question searches for neighboring
agents in a defined area around it, depending on the way it perceives the
environment, and steers towards an average position, closer to the found
neighbors thereby forming a group.
ALGORITHM:
! Define field of view angle
! Get agents within the affected angle
! Sum up their positions
! Divide sum by number of found agents
! Calculated result will be the average steer Cohesion force. This can be
clamped accordingly.
Furthermore, by adding a viewing-angle among the flocking behaviors, i.e., by
making the agents respond to flocking behaviors only within a field of view,
we get queuing behaviors. (Reynolds 1987)

20!

2.2.2 MIND ALGORITHMS

The mind algorithms are computed within the SteerSolver VEX SOP. At a
basic level, the steerSolver SOP computes a simulation step for the next frame.
A simulation step determines the velocity of the agent in the next time frame.

[Figure 2.12: A simulated time step]

This is done by doing a simple vector addition of the current velocity with the
vector forces being applied to it. These vector forces are the computed behavior
forces calculated by the behavior nodes. Once the total steer force is calculated,
the position of the agent is updated on a per-frame basis, dividing the
calculated sum by the frame-rate-per-second (FPS) value and adding it to the
current position of the agent. Hence, the agent will accelerate towards the
direction of the steering force applied to it (Figure 2.12). Houdini provides us
with a variable, TimeInc, this variable provides us with the FPS value. (Side
Effects Software 2011).
Thats just the very basic level of calculating the applied forces, these forces
need to be sorted out according to different priorities. Prioritizing behaviors
help simulate real-world phenomena better, just what an actual mind or
conscience would do. As mentioned before, all calculated behaviors have been
provided with different priorities, Based on these priorities, our steerSolver
VEX SOP will compute a final steering force that it will in turn, apply to each
agent. VEX works in a Single Input Multiple Data (S.I.M.D) form, this means
one must work on the context of a single agent being compared with the rest
using point clouds to lookup, and using the mind algorithms to sort out the
application of behavioral steer forces after which Houdini does the separate
computations for all agents and applies these computations to them using the
behavioral algorithms defined. In order to compute steering forces based on
priorities, a simple mind calculation and a priority mind calculation is

21!

employed. Counters are created and maintained to handle different priorities

and behavior forces. These are concatenated in strings and different forces are
concatenated to the string using the concat function provided by VEX.

Simple Mind:
As every behavior has a priority attached to it, the simple mind calculates the
steering force by simply multiplying the calculated steering forces with their
respective priorities and computes a final sum value. If a steering force has a
higher priority, a larger amount of that force would be used, and vice-versa, if a
steering force has a lower priority, a lower amount of that steering force will be
used.

[Figure 2.13: A Simple Mind]

As can be seen in the above graph (Figure 2.13), a simple mind will compute
different behaviors depending on their priorities, even if the total priority count
goes beyond unity. Hence, this calculation will simply sum up the product of
steering force behaviors (Cohesion, Arrive, Separation) with their respective
priorities (0.3, 0.2, 0.6). Simple Mind in this way can calculate steering fores
based on different weights.
ALGORITHM:
! Find out the number of behaviours
! Get steer forces
! Get priority values
! Save sum of products of steer forces and priority values

22!

Priority Mind:
Unlike a simple mind, a priority mind sets a maximum priority and does not let
the priority calculation exceed this maximum priority. The priority mind sorts
through the priorities and gives a higher weight to higher priorities and vice
versa. This is done by stacking up the priorities in order of importance, (Figure
2.14); the priority mind calculation then cuts off the priority values of
behaviors that exceed the maximum priority limit. (Schnellhammer!2011)

[Figure 2.14: A Priority Mind]

As can be seen by the above figure, the priority value of Separation is greater
than that of Cohesion, with priority of Arrive being least. Hence if the sum of
priorities exceed the maximum limit (1 in this case), the behavior with the least
priority will have its priority cut-off.
ALGORITHM:
! Find out the number of behaviours
! Stack priorities with their respective steering forces
! Sort this stack (Using simple Bubble Sort) such that steering forces with
maximum priority placed first and least priority placed last
! Start adding consecutive priorities from starting position of stack
! Check if sum of priorities is greater than maximum priority, if yes do
nothing
! Check if sum of next priority with current sum of priorities is greater
than maximum priority, if yes, find out the remaining priority, and
assign this as the new priority for that particular behavior force
! If none of the conditions are true, it means we are within the maximum
priority limit, and steering calculations can be done normally as in the
simple mind

23!

2.2.3 ADVANCED STEERING BEHAVIORS

Steer Arrive:
To direct the crowd to a particular point of arrival, a steer Arrive behavior SOP
was created. What happens in such a behavior is that all the agents seek a
particular target point. While we can easily achieve the steering force for this
behavior (Figure 2.15), simply by subtracting the position of the target from the
current position of the agent, this will not mimic the exact arrival behavior.
This is because, using such an algorithm, the agent will steer towards the target
with a maximum velocity, and will keep seeking the target with that velocity,
making it overshoot the target, and returning back to do the same thing.

[Figure 2.15: Seeking a target]

In order to prevent such an over-shooting, we need to consider the agents speed

as relative towards the target, Reynolds describes a more sophisticated
approach. We can imagine a virtual radius around the target point, once the
agent is within the specified radius, it will start slowing down, in accordance
with the distance of arrival, meaning, at the edge of the radius the speed will be
maximum, whereas at the target itself the speed would be near 0. (Shiffman
2012).
Two modes of arrival are present in the system; one arriving at an object and
the other mode is simply specifying the target manually.
ALGORITHM:
! Find out difference between targets location and current agents location
! If the target is an object, get its transformation matrix and calculate
location
! Define a radius around the target location
! If the distance between agent and target point is greater than the
defined radius, seek it with maximum velocity, i.e., maintain steering
force as difference between target position and current position
! Else, if agent position is within the radius, fit the length of desired
velocity (ie the speed) in accordance with the distance from the target
position

24!

Steer Wander:
Each member of a crowd always has a certain tendency to wander away from
the course of the desired path; this is emulated with the Steer Wander behavior.
What Steer Wander does is, it provides a steering force pointing to a random
direction and steers the agent slightly towards that random direction.
At the first implementation of this behavior, the agents were showing a jittery
movement, as they were randomly being pointed in different directions. So
instead, a slightly more advanced approach was used wherein an agent would
determine its future position (similar to the way Craig Reynolds determines
future location in Offset Pursuit behavior) and a random point would be
chosen on a circle around the future position (Figure 2.16). This point is chosen
as the final wander point to be steered towards. (Buckland 2005)

[Figure 2.16: Wander Behavior]

ALGORITHM:
! Find future location by getting unit vector of our velocity (ie.
Normalized vel) and multiplying with a constant value (this will be the
distance of prediction)
! Project a circle with a desired radius around the future location
! Find a random point along the circumference
! Steer to that point location
Such a behavior avoids the jittering associated with a wander movement and
makes the wandering movement smoother.

25!

Obstacle Avoidance:
In important behavior in crowd systems, obstacle avoidance ensures that the
agents avoid the obstacle objects within the environment. Obstacle avoidance is
a behavior that steers a vehicle to avoid obstacles lying in its path. (Buckland
2005)
For this purpose, obstacles of walls and columns were procedurally modeled
within Houdini. (Figure 2.17)

[Figure 2.17: Obstacles]

In order to achieve this, we fire a test-ray, (our velocity in this case) from our
agent in question, to the obstacle geometries. (Figure 2.18) Under normal
circumstances this would make our computations really slow as we compute
for all obstacle geometries, but as Houdini caches the simulations, no matter
how long it takes, the cached simulation can be played back at a real-time.
We can simply project this testing vector back on the polygon of the intersected
obstacle. This projected vector is our steering vector. (Schnellhammer!2011)

[Figure 2.18: Obstacle Avoidance]

In such a scenario, if we are closer to the obstacle, the steering force will be
stronger and vice-versa, almost light a ray reflecting upon a mirror.

26!

ALGORITHM:
! Fire a test vector
! Using Houdini VEX function intersect, check for intersection point on
the obstacle. This function saves the primitive number of the obstacle.
! Use this prim number to calculate the primitive normal, using
prim_normal VEX function
! Project this test vector on the obstacle polygon using scalar projection
(ie. Dot product)
! Do same test in multiple directions
! Calculate maximum steering force between obstacles. The max steering
force would be received from the nearest obstacle
! Apply force as necessary

Steer on Surface:
In order to base our crowd agents over a ground plane, or a terrain, we need
them to have velocities projected on that ground plane. This is an important
feature in a crowd system where the agents are land-based. We do this by
projecting all positions and forces onto the ground surface.
ALGORITHM:
! Fire a test vector towards ground geometry and use intersect function to
determine the intersected points
! Do cross product of forward with primitives normal (found using
prim_normal) to get side vector
! Do cross product of side vector with normal to get a vector with
direction opposite to normal, this is the tangent vector
! To project velocity onto tangent, do scalar projection on the tangent, i.e,
calculate dot product of forward vector and computed tangent vector
! Do same for all steering forces
! Use the found normal as new up vector

27!

Steer Path Following:

Keeping in mind we dont want our agents to just stick to the path and strictly
follow it (we can do that simply by using follow path command in Houdini), a
behavior was implemented wherein the agents get attracted to a certain defined
path. This path acts as a force-field attracting the agents towards it. The Path
Following behavior will compute a steering force that moves the agent along a
series of waypoints forming a path. (Buckland 2005)
The path is formed using a number of line-segments each with an assumed
starting and end-point. Calculating the closest distance of the current agent
with each line segment, and steering the agent towards the closest line segment
using scalar projections will implement such a behavior. An added feature was
implemented where the path is assumed to have a certain amount of radius.
Along with this, each agent calculates its future position to determine whether
it falls within the path radius, if not it calculates the closest point on the path
(normal to the path) and steers towards that point. (Shiffman 2012)
(Figure 2.19) shows the same.

[Figure 2.19: Path Following Behaviour]

ALGORITHM:
! Get future position of agent
! Check whether within path radius
! If not, calculate perpendicular normal to the line segment from current
position
! Do this for all the line segments within the path
! Select line segment with shortest perpendicular normal
! Do a scalar projection on the line segment to get origin point of
perpendicular normal
! Seek towards the found normal point

28!

Conclusion & Future Work

A crowd simulation system made up of autonomous agents was successfully
implemented within Houdini. VEX was used to create custom SOPs in order to
represent different behaviours.
Screenshots of some results are depicted below:

Screenshot 1: Scene Populated with approx. 10,000 droids depicting wander

behaviors, obstacle avoidance, flocking & queuing behaviors with Simple
Mind.

29!

Screenshot 2: Path Following. The Path is represented in green

Screenshot 3: Rendered Droids & Environment

Screenshot 4: Arrive behavior with priority mind, exhibiting queing behaviours

30!

FUTURE WORK
While the current system can be used t o implement basic crowd simulations
such as populating environments, simulating animals, birds, insects,
humans/pedestrians etc, with such a system, there is significant amount of
future scope and improvements by extending the system to incorporate
behaviours such as:
-

Offset Pursuit behavior: A behavioral algorithm where a crowd agent

would determine the future position of the object/agent in pursuit and
seek that location. This was intended to be applied but was dropped out
because of lack of time.
Predators/Flee: Another set of autonomous agents who would seek/hunt
the crowd agents, at the same time the agents would try to flee from
these predators.
Hide: The crowd agents would attempt to hide behind obstacles,
beyond the view of predators.
Integrating Python along with VEX to have superior flexibility over
manipulation behaviors. This would enable us to be able to generate
new points and geometry.
Battle Simulations: Simulating battle-field behaviours such as attack
formations, collision of armies etc
Sports Simulations: The system can be extended by adding complex
behaviours to manipulate sport events such as football, rugby, basketball
etc.
Fuzzy Logic: Fuzzy rule based logic can be implemented to give more
realistic behaviors.
Traffic Simulations: Adding complex behaviors to emulate cars,
pedestrians, cyclists, and other vehicles movements. This can also be
extended to simulate a working city.

There are many vast extensions that can be implemented by adding new and
more complex behaviors and also different mind implementations.
Another important feature is to build the entire system in such a way that it can
be used as a single cohesive digital asset, rather than using only the behavior
VEX SOPs as digital assets.
In another context, the animations added to the simulations could be
procedurally animated on a per-frame basis, giving it a far more realistic look.

REFERENCES'&'RESOURCES'
!
!

"

"
!
"

A.!Bielik!(2005).!`Kingdom&of&Heaven:&MPCs&Sword&and&Sandal&Hat&
Trick'.!Available!From:!http://www.awn.com/![Accessed!15.10.2013].!

"

C.!Kolve!(2004).!!VFX&Work.!!HP!CARSTEN!KOLVE.!Available!from:!
http://www.kolve.com/vfxwork/vfxwork.htm![Accessed!15.10.2013]!
!
J.!Haddon!&!D.Griffiths,!The!Moving!Picture!Company!(2006).!A&
System&For&Crowd&rendering.!ACM!SIGGRAPH!2006!Sketches,!
SIGGRAPH!06,!New!York.![Accessed!19.10.2013].!

"
!

A.!Bielik!(2004).!`Troy:&Innovative&E&
ects&on&an&Epic&Scale'.!Available!From:!http://www.awn.com/!
[Accessed!15.10.2013].!
!
L.!Kermel!(2005).!`Crowds&in&Madagascar'.!In!ACM!SIGGRAPH!2005,!
Courses,!SIGGRAPH!'05,!New!York,!NY,!USA.!ACM.!

"

Gu,!E.,!2004.!Crowd&Simulation:&Implementation&on&Geometry,&
Animation&and&Behavior.!WPE!II!Paper!(PhD).!University!of!
Pennyslvania.!

"

Gary,!D.,!CMI!VFX!(2007).!!Houdini&VEX&Volume&1.!Video.!Available!
From:!http://cmivfx.com.![Accessed!20.10.2013]&

"

Kewlani,!T.,!2013.!Ant&Directed&Ant&Crowd&Simulation&in&Houdini.!
Thesis!(Masters).!Bournemouth!University.&

"

Reynolds!C.W.,!1987.!Flocks,&herds&and&schools:&A&distributed&behavioral&
model,!ACM!SIGGRAPH,!Computer!Graphics,!v.21!n.4,!p.25"34.&

"

Side!Effects!Software!(2013).!Houdini:&3D&Animation&Tools.!!Software.!
Available!from:!http://sidefx.com![Accessed!23.10.2013]!

"

Schnellhammer!C.,!2010.!Uniform&Scattering&in&Houdini.!Houdini!
Digital!Asset.!!Available!from:!
http://schnellhammer.net/blog/2010/06/uniform"scattering"in"
houdini/!![Accessed!09.11.2013]!

"

TF3DM,!2013.!High&Poly&Male.!OBJ!File.!Available!From:!
http://tf3dm.com/3d"model/high"poly"male"2014.html![Accessed!
20.11.2013]!

"

Tedin,!C.,!CMI!VFX!(2013).!!Houdini&Rigging&Animation&Fundamentals.!
Video.!Available!From:!http://cmivfx.com.![Accessed!22.11.2013]&

!
&
!
&
!

!!

!
&

&

"

Schnellhammer,!C.!"!CMI!VFX!(2011).!!Houdini&Flocking&Systems.!Video.!
Available!From:!http://cmivfx.com.![Accessed!20.11.2013]&

"

Shiffman!D.,!2012.!Nature&of&Code.!1st!Edition.!Magic!Book.!Available!
From:!http://natureofcode.com/book/!

"

Buckland!M.,!2005.!Programming&Game&AI&by&Example.!Texas:!
Wordware!Publishing.!

!
!
!
!
!
!

!
!
!
!

APPENDIX'

'
'
'
Videos:!
!
1. final.mov!:!Video!result!with!10,000!(approx.)!agents!simulated!with!
arrive!and!follow!path!turned!off!
2. fastarrive.mov:!Video!result!showing!arrival!and!queuing!
behaviours!with!high!Interpenetration!avoidance!(collisions)!
3. humanwalk.mov:!Representation!of!human!walk"cycle!
4. pathfollow.mov:!Video!result!showing!path"following!behavior!
5. POV.mov:!!Accelerated!point"of"view!of!an!agent!