MSc Thesis: Crowd Simulation Implementation in Houdini FX using Custom VEX Operators

!!!!!!!!

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!!!!Chapter&2&!2.1!Background!&!Theory!!!!!!!!!!2.1.1!Tools!of!Choice:!Houdini!&!VEX!!!!!!!!!!2.1.2!Overall!Implementation!of!System!!!!!!!!!!!!!!!!!!!!!I!Agents!!!!!!!!!!!!!!!!!!!!!I!Simulation!!!!!!!!!!!!!!!!!!!!!I!Geometries!!2.2!Behaviors!&!Mind!Implementations!!!!!!!!!!2.2.1!Simple!Behaviors!!!!!!!!!!!!!!!!!!!!!I!Separation!!!!!!!!!!!!!!!!!!!!!I!Alignment!!!!!!!!!!!!!!!!!!!!!I!Cohesion!!!!!!!!!!!2.2.2!Mind!Algorithms!!!!!!!!!!!!!!!!!!!!!I!Simple!Mind!!!!!!!!!!!!!!!!!!!!!I!Priority!Mind!!!!!!!!!!!2.2.3!Advanced!Steering!Behaviors!!!!!!!!!!!!!!!!!!!!!I!Steer!Arrive!!!!!!!!!!!!!!!!!!!!!I!Steer!Wander!!!!!!!!!!!!!!!!!!!!!I!Obstacle!Avoidance!!!!!!!!!!!!!!!!!!!!!I!Steer!On!Surface!!!!!!!!!!!!!!!!!!!!!I!Path!Following!!!Conclusions&&&Future&Work&I Screenshots!I Future!Work!!References&

Page&!!!!!!01!03!!!!!!07!07!10!11!12!15!!16!17!17!18!19!!20!21!22!!23!23!24!25!26!27!!!28!28!30!

!!!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 3-Dimensional 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 point-cloud 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!(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.!! " 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].!! " 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!