Wednesday 19 February 2014

The Optimal Racing Line


I've recently reached the stage in the TORCS-Adaptive project in which I need to consider implementing some more sophisticated performance measurement than simply monitoring the player/AI driver's speed. I stumbled across a rather dated but still very relevant series produced by Brian Beckman, PhD, named The Physics of Racing. There were many useful articles here, however Part 4 and Part 5 were the most relevant to this project. Part 4 of the series introduces the idea of centripetal force (centre-seeking force), and is able to produce an equation from which we can derive the maximum driving speed for a given arc radius. I won't go into the details here - those interested can see the link at the bottom of this post - but ultimately the equation derives to:

Where v is the maximum possible velocity, a is the sideways acceleration and r is the radius of the curve. Here we can see that the radius is being used almost as a scalar for the velocity - the sideways acceleration multiplied by the radius gives the maximum possible velocity. Therefore we an infer that the optimal corner arc in terms of speed alone is in fact the one with the largest possible radius. The diagram below has been adapted from the diagram shown in The Physics of Racing Part 5:


Here, w is the width of the track and W is the width of the track minus half of the car's width. When considering the optimal path we are considering the trajectory of the car's centre of mass as opposed to the paths of individual wheels. Therefore, the width of the track is slightly lower to prevent the car dragging it's wheels off the sides. The optimal path can be seen here as Line M, the line that passes through points E, Q and X. Two more sub-optimal lines that hug the sides of the track are shown for sake of example, Line o and Line i. Ro and Ri are the inner and outer radii of the curve, and also happen to be respective to the arc radius of the curves in Line o and Line i. If Ri is the radius of the curve of line i and K is the radius of Line M, it can be seen that the speed possible on Line M is far greater.

References:
Beckman, B. (1993) The Physics of Racing [online] Available at: http://phors.locost7.info/contents.htm

Tuesday 4 February 2014

Pinball!

As part of a recent University project, I implemented a Pinball game using PhysX 3.3.0, GLUT and OpenGL for some basic rendering. I also made use of SOIL for simple image loading and BASS for audio. The game consists of a few different features, including switches, spinners and bumpers, and was designed to accurately model the physics of a pinball machine. It also marks my first ever complete (if small) game written entirely in C++! By complete, I mean an application consisting of rendering, input and audio, all of the components required for a basic game.



I have uploaded the game and it's source code (with a VS2010 solution, as anyone with more recent windows IDEs, i.e. Visual Studio 2013 should be able to open this). It can be downloaded from here.

TORCS-Adaptive Progress

I've been making some progress recently on TORCS-Adaptive, my final year project at the University of Lincoln. Thus far, I've managed to implement procedurally generated tracks into TORCS, that now function both in console racing mode and in graphical mode. The generation of new 3D models when adding new track segments still has some performance issues, however I've manage to set up a pipeline in which performance measurement and adaptive difficulty algorithms can be easily tested and analysed using AI drivers. Currently, I have a very simple AI driver set up. In order to build a completely random track, I use the 'Procedural' race mode. When in the runtime/runtimed folder, it is possible to run TORCS in console mode on Windows as follows:




This will run TORCS in the console, with the race manager contained in procedural.xml. This file can either be modified directly in a text editor, or the race can be set up within TORCS itself and it will be saved. At the end of the race, there is now a feature of the procedural library that builds the entire track, and writes it's data out to a .txt file with data readable by gnuplot. Gnuplot allows the user to then plot this track, with results such as the following:


This image shows a plot of the entire track, with accurate scaling. The values on the X and Y axis are both in metres.