Top-down view
Side view
Street-level view
We tested our model in a virtual city which was constructed before the beginning of this project. The city geometry originally came from a model of Rio de Janeiro, and random textures were pasted onto the buildings and roads. The city consists of 924 buildings spread aross 23 city blocks, intersected by 61 roads meeting at 43 intersections. There are 235K triangles in the model. The city layout is almost a perfect grid, except for two roads which are at a slight angle. Some areas of the city are grassy fields, representing city parks. All of our roads are two-lane, and each intersection is modeled with a stoplight. Here are some screenshots of the city:
We have used an open source 3DS model loader lib3ds[1] and a 3D Nissan GT-R car model from Turbo Squid[2] to render the cars. The 3D car model is composed of around 300 polygons with mapped textures. We also varied the color of the texture to produce cars with 5 different colors.
The car motion model is a particle system with varying forces being applied to them, depending on the car’s position in the city. To simplify the particle system, each car is assigned to one lane of the road in the city at any given point of time. We maintain all cars in a first-in-first-out (FIFO) queue for each lane. Thus, updating the car’s position will be a single-step checking against the car in front of it. This method is much more efficient than implementing collision detection with every other car in the city and allows us to simulate car motions in real-time (without the texture-mapped 3D car model). It is true that checking only for the car in front of us is not enough to prevent collisions at the road intersection points (the junctions), but we handle this as a special case by the intersection objects that we created. The details about intersection are described in later section. Now for each car in the lane, we will apply a force to it according to the following rules:
For the first car in the FIFO queue, we have to drive it forward until it reaches the traffic light at the intersection point. We have divided this motion into 3 cases.
Case 1:
|
After the car has speeded up, it is fine to apply a constant force for acceleration. The following graph shows the variation of force that we have used in our car model.
|
Case 2:
|
where v is the final velocity, u is the initial velocity, a is the acceleration and s is the distance. Substituting it into our situation will yield: where m is the mass of the car, v is the velocity of the car when the braking just starts and s is the stopping distance, which in this case, equals the current distance of the car from the traffic light. This braking force is applied constantly to the car until it reaches the light. |
Case 3:
|
When it reaches the traffic light, it must be stopped! The force and velocity are both set to 0. |
For all other cars in the FIFO queue:
These 3 cases apply to them similarly, except that the distance s will be defined as its distance from the car in front of it instead of from the traffic light.
After deriving the applied force to each car, we used Euler's method to simulate the car motion. We found that this simplified particle system is both efficient and accurate for modeling car motion. To further improve the model, we allow cars to accelerate even if it is within the braking distance from the traffic light if the light is going to stay green for a while. This allows a continuous stream of cars to pass through the intersection when the green light is on.
At the intersection point, a different motion model has to be used. Instead of deriving the exact force for making the turn, we compute a simple path for the car to follow at the intersection. A car can either turn right, left or go straight.
We used interpolation to compute the path for going straight and making a right turn and used a Bezier curve for making a left turn.
We implemented our stoplights with a very simple model. When a car attempts to enter the intersection, it is placed
in a waiting queue. This queue is separate from the queue that is stored in the road; only the car at the front of the road
can enter this waiting queue. Admission to the intersection is determined by the current state of the light
and the current state of the cars that are currently in the intersection or are attempting to gain access to the intersection.
Each stoplight has four locks, each corresponding to one of the
roads connecting to the stoplight: east, west, north, and south. When a car moves through the stoplight, it acquires the lock
corresponding to its destination. Therefore, a car moving from west to east acquires the east lock. If the light is red,
a right turn is allowed if the the lock to the right of the car is open, signifying that no other cars are trying to
move to that exit and that a turn is safe. If the light is green, a right turn is allowed if the right-hand lock is
open. Going straight is allowed if both the right-hand locks and straight-ahead locks are open. Finally, a left turn is
allowed if all three are open. We are aware that this model does not exactly reflect the true rules of right-of-way
(in the United States at least), but we have found that this approximation produces reasonable results while greatly
simplifying the process of yielding to other cars. The stoplight was always arranged so that the north and south entrances
would be green while the west and east were red, and vice versa.
We experimented a little bit with modifying the stoplight timing to observe the effect it would have on traffic flow.
We tried a synchronized approach where all of the stoplights changed at once, and we also tried randomizing the time at which
the stoplight would change. We did not really see a visible difference between the congestion in both approaches. We also
modified the amount of time that the stoplight would stay green before changing, and observed that short times would lead
to increased congestion because only a few cars could get through the intersection before it turned. Since cars must
accelerate if they are stopped, cars following one another in rapid succession gain an advantage because they do not have to
stop. However, if the stoplight time is too long, the cars coming from directions with red lights will form long queues,
often wreaking havoc on the traffic patterns further down these roads. We discovered that there is a careful balance
between the number of cars and the arrangement of intersections; if too many cars try to pass through too few intersections,
it is possible that deadlock can occur.
Our simulator is able to position the camera at one of the randomly picked car and follows its view point as it moves around the city. It can produce a driver's view car motion animation.
Here're some of the videos generated from our simulator:
| Normal simulation | AM rush hour simulation | PM rush hour simulation |
| Close up view of the intersection | Drive through view (The glitches in the video was caused by video compression when we uploaded it) | |
We have successfully simulated car motions in a realistic urban city in real-time. The cars are able to drive towards any given destination, accelerate, make turns, stop for traffic lights and avoid collision with other cars. By varying the time of the day, traffic volume, stoplight frequency, car origin and destination, we observe interesting car distribution in our simulation. The traffic model can effectively help in making urban planning decisions. Furthermore, we have created the option of viewing the simulation from the perspective of the car driver and produced an amazing video-game like driving animation.
