I spent quite a few hours working out most of the kinks in the path-finding function, so it's now able to accurately start and end each path at an intersection, where the next decision has to be made on where to go.

After that, I boosted the number of cars in the test environment to 250 to see how it ran... not too badly. The frame rate dropped to about 110 to 190 frames per second depending on how many cars are on-screen at once. Code profiling reveled that there's nothing extremely inefficient going on in the background, except for our friend toOpenGLColor() which continues to make it's presence known by gobbling up 20% of the frame rate. It looks like I will have to tackle that problem some time.

Once I had all the cars on the road, I noticed that they really all looked the same, even though there's four different kinds at the moment. The reason for this is that colours are fixed in the vehicle XML file, so that meant it was time to unleash random car colours I'd been threatening!

I modified the model loader so that the vehicle XML file can be used to specify "random" as a colour choice, or a fixed colour, which allows police cars and taxis to remain a white or yellow while everything else is a hippie-mind-blowing-rainbow-of-colour.

I also implemented picking on the car nodes so I can select them...

Here's a quick video.

Dim lights Embed Embed this video on your site

One thing to note is that the video capture process can cause the number of frames captured per second to fluctuate... the game frame rate fluctuates too, so it makes it appear like the frame rate is steady... except for OpenSteer, which notices the delay and moves the cars further on the next frame if there's a slow down while saving a frame. This of course means cars tend to overshoot way-points occasionally in the video, and they will spin around or suddenly reverse direction. It doesn't happen while actually playing with the engine, honest!