Introduction

My name is Franco Pizzani and I was born in Uruguay, although I have spent most of my life in Spain. Four years ago, when I was 27, I landed my first job in the video game industry after self-learning 3D. I worked at elite3D in Valencia, Spain, for about 3 years as a 3D artist and I had the opportunity to contribute to the development of titles such as Call of Duty: Infinite Warfare and Call of Duty: WW2 doing modeling, texturing and photogrammetry. Sometime during that period, I started to experiment with Houdini on the side, just for the fun of learning something new. However, at some point I realized that I wanted to take it further; therefore I’m currently enrolled in the Houdini FXTD program at Lost Boys Studios in Vancouver, Canada.

How the Project Started

For the third project in my Houdini course, we had to create a crowd system. The first few lectures covered basic concepts about crowds and how they behave. We also learned techniques like how to implement Reynolds Boids behaviors (separation, alignment, and cohesion) in VEX mainly by using pcopen to gather information from neighboring particles; furthermore, we discussed how to make them react one way or another depending on various parameters, so that was pretty cool. Then we learned more about the built-in Houdini crowds tools that can automatically do all that for you in conjunction with the crowd solver. While the crowd solver and the built-in tools are pretty amazing, I really wanted to experiment and push what I could do with VEX, so I thought a traffic system would be unique. In my mind, the traffic system, being something so mechanical, would give me the opportunity to be in charge of controlling and setting up every necessary attribute like vectors and forces to make the traffic system feasible. At the same time, simulated traffic systems don’t seem to be your typical Houdini project, so I saw it as a double win.

Base of the Project

The core of this project is a pop solver and a bunch of pop wranglers (the nodes where you write VEX) that basically read and set attributes. Then, these attributes are used to define states based on different conditions.

There are over 90 attributes being calculated at every frame, these range from what I call “primary attributes” that are kind of the raw data composed of direction vectors, distances, and information about other agents in the simulation. These primary attributes are then analyzed to set “state attributes”. These state attributes are used to define the state of the vehicles, which are either “accelerating”, “braking”, “stopped” or “traveling at top speed”.

A very simple example: if there is a vehicle in front of me that is in the same lane as me, its direction, therefore, is the same as mine, and the distance to the vehicle in front is lower than a predefined braking distance, then the attribute “braking at vehicle in front” will be true, triggering the “braking” state. When this state is triggered, there is a brake node in charge of reducing the force applied to my vehicle based on the distance, thus reducing my velocity and distance to the vehicle in front preventing it from ever colliding. If my vehicle is in the “braking” state and my speed equals 0, then it must mean that I’m stopped, so this triggers the “stopped” state. If a vehicle is braking or stopped but there is no reason to be doing that anymore, it will change to the “accelerating” state, applying force again. With a long list of “if else if” statements, I can change from state to state checking for different conditions using these “state attributes”.

VEX functions like pcopen and neighbor are your best friends when it comes to accessing other points and their attributes in the simulation. I tried to keep it as organized and modular as possible. Each frame the pop solver will execute these nodes from left to right and top to bottom.