Specification

The full specification and reasoning behind the simulator can now be found here. This gives the full background on the simulator and an idea of whats to come. It also contains discussions and reasoning behind the technologies in use, as well as being a status update on the progress of the simulator.

Videos

Here a couple of videos of the simulator in action. The first shows the rain system working as well as the basics of the simulator, roads, the ground plane and the skybox as well as a few trees (whose leaves now point in the right direction). It also shows the rain being blown around during 'gusts' of virtual wind. The second shows the user moving around the virtual world, controlling the direction with the mouse (follow the cursor and watch how it turns). These were generated using the Windows Media 9 SDK and hence require Windows Media Player to watch.

They can be obtained here and here.

Road Signs

To make things look more like a real road system, I have begun to implement a road sign system. It's still in it's infancy, but it currently uses road nodes to generate a list of all the roads meeting at that node and create a texture for the sign showing the road names. Te texture is created in a similar way to the sprite font, however this time it copies pixels from a font bitmap into the target bitmap in memory, then binds this to a texture name and so on.

Some work needs doing to remove duplicates and put arrows on the sign so that it makes more sense, but it's a start. I could probably do with some higher resolution fonts as well, since the signs can be quite large on the screen, but that should be easy enough.

The main issue, however, will be positioning the signs in useful places. Roads often have nodes even if they only join two sections of the same road. Obviously there is no need to put a sign down that confirms you are still on the same road. On the other hand, when a junction is met, where should the sign be placed? This can be calculated by taking the direction the road is coming away from the node in, and placing the sign on the left-hand side of the road. Finding a vector perpendicular to the road is easy in two dimensions, and only slightly harder in three (take the cross product of the direction of the road and the global 'up' vector, that is (0, 1, 0)).

Road Markings

After much thinking and fiddling with code, the first semblance of road markings have appeared. To get this working, I have used the road link data which has a list of coordinates for each road showing the lay of said road. By lining up quads along this string of coordinates, pretty convincing road markings can easily be created.

Unfortunately, the markings are in sections of straight lines, which can be seen in this screenshot. The next step is to interpolate between the points on said line to make a curve, and align the markings tangentially along this curve.

Point Sprites and Leafy Trees

I finally managed to get point sprites working to a decent state, thanks to the magic of the Alpha Test, as can be seen in the latest screen shot. Only problem now is that the leaves displayed are all standing on end, rather than in a sensible direction...

One solution is to create a 3D texture with multiple rotations of the sprite, and then specify an r texture coordinate during calls display points. While this would undoubtedly work, a more sensible solution is to use a textured quad instead. Takes a little more programming, but ultimately it's a lot more flexible. And thanks to the geometry of the tree generated by Arbaro being a set of eight vertices making six trianges, I can get the direction the leaf is in, cross it with the camera vector and get the relevant vectors to displaying a textured quad.

I'll post a screen shot when I've done this...

Rain

Today I added a particle-based rain system, which you can see in the latest screen-shots. Currently it generates one thousand particles which are updated every frame based on their velocity. The system itself introduces gusts of wind at random intervals for random lengths of time, and this affects the movement of the particles.

Because rain tends to be at terminal velocity by the time we see it, the particles are given a starting velocity that only changes in the x- and z-dimensions (i.e. horizontal plane). Each frame, before gust influence is calculated, these values are decreased so that the particles will go back to straight downward motion, to simulate air resistance and to give a smooth reduction when a gust stops.

Trees

In the interest of making the simulator more realistic, I have started adding trees to the scene. Initially, I looked at implementing Weber and Penn's algorithm described in Creation and Rendering of Realistic Trees, however it became apparent after reading through and starting to implement a generator that this was not going to be easy, or fast. However, I came across a wonderful application called Arbaro, which is a java implementation of said algorithm for creating trees for POV-Ray.

Arbaro generates POV-Ray inclue files (.inc) which are text descriptions of the vertex, normal, and face data of the tree created. While this makes POV-Ray very portable, it also means it's not the simplest of files to read (binary files are easier, read a header, allocate some memory, read the rest...). So, after a bit of work deciphering the file, and trying to ignore unimportant sections, the simulator now reads in trees generated with Arbaro.

Since Arbaro is generating for a raytracer, it creates leaves for it's trees. Each leaf is comprised of six triangles. I decided that, in order to conserve precious rendering time, I would render leaves as either points, or point-sprites (i.e. particles). That meant I had to average the vertex positions of each triangle, and then average the averages for each leaf to leave me with one vector for each leaf.

The result is this:

Which looks pretty good, so far. Currently the leaves are rendered as anti-aliased points, and with blending enabled this makes them rougly circular. Since the number of leaves is constant, point sizes increase exponentially as the camera approaches the tree, so that gaps aren't left, and foliage appears thicker.

Constant point size:

Variable point size:

The only problem with this is that it makes the trees look a little cartoony close up:

However, I plan to implement point sprites in an effort to rememdy this.