Archive for June, 2009

Upgrade to WordPress 2.8

Posted by Anthony_B on June 20, 2009 at 00:18

I’ve just upgraded from WordPress v2.7.1 to v2.8. Well, actually I backed up the database contents, deleted the previous WordPress installation and MySQL database, and took the opportunity to start again with a fresh installation and then imported the backed up data. As far as I’m aware everything is working fine, but please let me know if you have any problems.

openBVE v1.0.7.1 released; performance improvements and new object development features

Posted by Anthony_B on June 16, 2009 at 00:04

openBVE v1.0.7.1 is now available; I’d recommend heading over to the » openBVE homepage « to download the latest stable release, and don’t forget to read the » Changelog « for a full list of alterations and new features.

Information Icon Update (18th June): openBVE v1.0.7.2 was released yesterday. This version includes a bugfix relating to problems when some objects were loaded, which also resulted in error messages. As far as I’m aware, the objects concerned were those with meshbuilder blocks containing both Cylinder commands and AddFace commands referencing the cylinder’s vertices, which should now be loaded without any problems in v1.0.7.2.

This release can offer some potentially superb performance improvements on some routes. With Cross-City South v1.31.02, and 8x antialiasing/16x anisotropic filtering set via my graphics card drivers, along with bilinear interpolation set via openBVE’s options, I see between 20-35% increases in framerates compared to openBVE v1.0.6.2 with identical settings. With anisotropic filtering and smooth transparency enabled via openBVE’s settings, I also see between around 25-46% increases in framerates with identical settings in both openBVE versions. So for example, where the entrance to Birmingham New Street used to take me down to 15 fps with smooth transparency enabled, now I can reach a much more fluid 21-22 fps. I won’t publish any figures regarding Cross-City South v1.4 yet, as the route is still in development and the performance level changes often as I experiment with it. These results are obtained on an AMD Athlon 64 X2 4200+ @ 2.2GHz, 2GB DDR2-800 CL5-5-5-15, ATi Radeon HD 2600 Pro 256MB DDR2 PCIe equipped system by the way.

The improvement which has most impressed me though, is the performance of openBVE v1.0.7.1 with Watford Junction to Rugby. To say that I’m delighted would be a massive understatement, as I’ve seen between 30-160% increases in framerate compared to v1.0.6.2! Generally though, framerates of around 17-21 fps (on the four track sections between stations, in the external view with those nice AC electric and Mk2 coach objects) are now fairly typical, where around 11-14 fps was a typical range before. Framerates are higher when in the cab view, of course. Certain extremely detailed areas which still need to be simplified for openBVE 1’s renderer, like the Bourne End and New Ledburn Junctions, as well as Tring and Bletchley, are now handled much better as well (10-12 fps rather than 4-6 fps as it was before, with framerates recovering to normal levels after passing through these isolated locations). To put this in perspective, the route loads around 2600 objects of all types with over 72600 .Freeobj commands, which is a lot more than usually found in a BVE route, and this is over a 106 km distance (in comparison, Cross-City South v1.31 loads around 700 objects of all types, with around 5600 .Freeobj commands over around a 25 km distance). In BVE 4, the framerate may be comparable initially, but if I start driving from Watford Junction, it stutters frequently, and BVE 4’s renderer gives up after reaching Kings Langley just a few kilometres into the route, and BVE 4 crashes without even an error message shortly after; WJ-R is a long way past being suitable for BVE 4 now, hence an awful lot of stuff will need to be removed in the BVE Trainsim versions of the route.

These latest openBVE optimisations which give rise to improvements in framerates, may also mean that route loading times increase a little as the object geometry is optimised, although in practice, I’m finding that only 5-6 seconds are added to Cross-City South v1.4 / new class 323 loading times, and 9 seconds added to Watford Junction to Rugby’s loading time, bringing the total loading time to 39 seconds for the latter route. Nevertheless, if this is a problem for you, please read » this thread « for information about the hidden options which enable you to limit what the new object optimiser does, allowing for faster loading times, but naturally at the expense of in-game performance.

If you’re interested in how these performance improvements have been implemented, take a look at » michelle’s blog « where the relevant OpenGL concepts are discussed (the May and June 2009 pages). Essentially, OpenGL’s GL_TRIANGLE_STRIP and GL_QUAD_STRIP structures are now used along with GL_POLYGON structures which were used exclusively in prior versions of openBVE, and using these structures where possible means that fewer vertices need to be transmitted to the rendering pipeline (due to there being fewer effectively duplicated vertices), thereby improving performance. These other structures are generated automatically by the new object optimiser included in v1.0.7, which was written for openBVE 2’s engine but has been added to openBVE 1. Version 2 of openBVE should deliver even greater performance improvements however, thanks to the use of display lists rather than the immediate mode currently used.

This early performance improvement also means that I can capture some higher resolution video of Watford Junction to Rugby now, so come back soon as I’m preparing another of my YouTube videos, in which I’ll also show a couple of other things I’ve been working on. 🙂

Horizontal Rule

New Object Development Features

Two new features have been added which allow developers greater flexibility and functionality where object creation is concerned — the Shear / ShearAll commands, and the ability to specify vertex normals in B3D and CSV objects (previously, vertex normals could only be specified in .X objects, which were awkward to hand edit). Before experimenting, please make sure that you’ve downloaded the latest versions of » openBVE«, » Object Viewer « and » Route Viewer « (if necessary, clear your browser cache first to ensure you aren’t just getting older versions of the downloads from your hard disk cache instead of the webserver).

Shear and ShearAll

Using the Shear / ShearAll commands, we can now skew meshes or entire objects, which makes certain kinds of objects much quicker and easier to create. Take a bridge which crosses a railway at an angle for example; designing the bridge object such that it’s perpendicular to the railway is relatively easy, but creating it at an angle can be more time consuming, especially if the bridge includes an arch. Using the new commands, we can create the bridge in a perpendicular fashion, and then easily perform a shear mapping operation on all the vertices in either a MeshBuilder block or the entire object:

Original bridge object, perpendicular to rail--click to enlarge Original bridge object, sheared to the right--click to enlarge Original bridge object, sheared to the left--click to enlarge

These results are created with the following commands added right at the end of the object file:

ShearAll, 0, 0, 1, 1, 0, 0, 0.75


ShearAll, 0, 0, 1, 1, 0, 0, -0.75

Please see the relevant openBVE documentation » here « for more information about these commands and the parameters.

Vertex Normals

If you’ve used the Cylinder command in your objects, you’ll probably have noticed that the resulting collection of faces were smoothly shaded. Creating any other mesh however, resulted in flat shading. If the object was converted to the .X format, it was possible to manually hand edit the vertex normals to smoothly shade faces, but due to the nature of the format this wasn’t user friendly, and wasn’t possible at all in B3D or CSV format objects. Now though, what I think is an easy way to apply vertex normals and smooth shading to meshes has been implemented. Take the following screenshots:

Standard mesh--click to enlarge Standard mesh with vertex normals specified--click to enlarge

On the left, we have a simple mesh with 8 vertices and 3 faces:

AddVertex, 3, 0, 1, ;vertex 0
AddVertex, 3, 0,-1, ;vertex 1
AddVertex, 1, 1, 1, ;vertex 2
AddVertex, 1, 1,-1, ;vertex 3
AddVertex,-1, 1, 1, ;vertex 4
AddVertex,-1, 1,-1, ;vertex 5
AddVertex,-3, 0, 1, ;vertex 6
AddVertex,-3, 0,-1, ;vertex 7

On the right, we have the same mesh, but with vertex normals specified, resulting in the smoothly shaded appearance:

AddVertex, 3, 0, 1, 0.6, 1, 0
AddVertex, 3, 0,-1, 0.6, 1, 0
AddVertex, 1, 1, 1, 0.3, 1, 0
AddVertex, 1, 1,-1, 0.3, 1, 0
AddVertex,-1, 1, 1,-0.3, 1, 0
AddVertex,-1, 1,-1,-0.3, 1, 0
AddVertex,-3, 0, 1,-0.6, 1, 0
AddVertex,-3, 0,-1,-0.6, 1, 0

In the first annotated Object Viewer screenshot, you can see that the automatically generated normals are depicted via the vector lines emanating from the vertices (you can view these by pressing the N key within Object Viewer). Note also the flat shading, and how this relates to the direction of the normal vectors. In the second screenshot however, which shows the same mesh with manually defined normals, smooth shading is now applied, and vertices 2, 3, 4 and 5 now have one normal vector each, affecting all faces that share those vertices. You can see that each normal vector is created relative to the associated vertex coordinates.

To give some examples of where to use this feature, the ability specify normals allows me to, for example, reduce the number of faces on a curved surface to improve performance in some circumstances, or smoothly shade the grass embankments shown in the bridge screenshots above, or the curved surfaces of locomotives and rolling stock:

Original object with automatically generated normals--click to enlarge Object with vertex normals specified--click to enlarge
Original object with automatically generated normals--click to enlarge Original object with automatically generated normals--click to enlarge
Object with vertex normals specified--click to enlarge Object with vertex normals specified--click to enlarge
Horizontal Rule

Finally, for the more technically minded amongst us, openBVE’s debug output layout (viewable via the F10 key) has been revamped and contains some interesting extra data relating to the number of each different face type in use:

openBVE v1.0.7.1 debug output

The innovative Chashinai Railway, RSR-UK route randomisation, hi-res Watford Junction to Rugby screenshots, and server upgrades

Posted by Anthony_B on June 1, 2009 at 23:40

The innovtive Chashinai Railway, randomisation and new development techniques for openBVE

Some of you may remember the Chashinai Railway network which was released way back in 2004, but soon after publication it was withdrawn, after controversy surrounding permissions where certain files were concerned. The fictional Japanese route network has now been significantly updated and is available again, and is now designed exclusively for » openBVE «. The route’s developer, Jens (Odakyufan), has devised some innovative new techniques which take advantage of openBVE’s capabilities, and together they introduce some exciting new possiblities for developers and users, including for example — even within a single route file — randomised time of day selection, randomly selected choice of train and service to drive, determining the probability of certain end results occuring, and more. Using if conditions and casing, it’s possible, for example, to choose which platform or siding is departed from or entered at random, provided code for each of these routing options has been written, specially prepared and added within the route file.

This is clever stuff, which presents all kinds of new possibilities for openBVE developers. Visit » Odakyufan’s website « to download the Chashinai Railway network which includes all the required trains (you need the latest openBVE v1.0.6 release), and take a look at the » development techniques and tips section « to see how randomisation and conditional pre-processing can be applied by developers creating routes for openBVE, along with ideas for improving the handling of tunnel object lighting, cab brightness and time of day. Incidentally, Jens also hopes to model a section of the well known Odakyu Odawara Line starting from Tokyo’s busy Shinjuku station, which should be fascinating due to the railway infrastructure, proximity between the line and the surrounding city and it’s roads and numerous buildings, and the object density to be depicted in such scenes.

Some atmospheric » Chashinai Railway « screenshots:

openBVE v1.0.6, Chashinai Railway (Kawarada, Ishinden Line), Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Chashinai Railway (Ashikari, Ishinden Line), Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Chashinai Railway (Minaminaka Sidings, Minaminaka Line), Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Chashinai Railway (Izumozaki North, Misaki Line), Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Chashinai Railway (Izumozaki North, Misaki Line), Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Chashinai Railway (Izumozaki South, Misaki Line), Smooth Transparency option enabled--click to enlarge

Incidentally, the situation surrounding the Chashinai Railway presents some issues to consider. It’s a route that was built using a large number of other author’s objects, and was originally made just for personal use — publishing the route wasn’t originally intended, so it’s author didn’t keep track of where each file came from. However, over time, the project evolved into something which was worth publishing, and this creative endeavour was shared with the community. The route was also notable as being one of very few Japanese styled lines developed by a European author (the only other I can recall right now, being Viktor’s fictional » BVE Garden Line «). Unfortunately, because Jens hadn’t kept track of the origin of the many files used, determining the authors of all these files at a later stage became problematic, so some work was uncredited, and not all permissions saught. Upon it’s release, some developers objected to this. Back then, the Western (English speaking) BVE community as it seems to me, was more like a microcosm of the worst aspects of international relations and ideological conflict than an ideal community at times, and soon after it’s release, despite conflicts with developers being resolved, the Chashinai Railway was withdrawn, presumably because of all the controversy it caused, and I guess Jens was put off from releasing anything into the community again for several years. Having seen the innovation, intelligence and artistic excellence which he’s now shared with us some years later–as a community–I think we’re rather lucky that he wasn’t driven away permanently by the awful, polarised atmosphere which used to dominate the community in the past (and I’m certainly not blameless where this state of affairs was concerned either); if he had left for good, then people in another field might be enjoying the fruits of his creativity instead of us, or indeed nobody else at all would be enjoying the results, and we would all be the poorer for it.

Information Icon Edit: I was going to discuss the community, my own changed attitudes towards copyright, and the role the BVE Developer Guidelines play as a part of this blog entry, and talk about whether for the good of the community in the future, they should be revised or whether they’re even needed any more. However, this entry is primarily about innovation and development techniques, so I’ll save the extended discussion until later.

Horizontal Rule

Randomisation in RSR-UK Routes

Having seen what Jens has achieved, I’m experimenting with these new innovations on my own routes as well. With Watford Junction to Rugby for example, I’m able to use the random pathing feature of » BRR « to create short alternative paths between, for example, Watford Junction and the crossovers to the north of the station, or between Hemel Hempstead and Bourne End Junction. This is the tricky part as it involves carefully setting up the .Rail related commands (or even inserting temporary crossovers) to ensure alternative paths can be selected and generated, followed by replacing .Turn commands with .Curve commands in BRR’s temporary route file output. Then, by referring to the casing technique example which Jens has provided, I can easily add all the $Sub() preprocessing commands to these code fragments via a couple of simple search and replace operations, and then copy and paste these sections into the WJ-R route file making any tweaks necessary, and add the condition and randomisation code, to allow openBVE to randomly choose whether the player starts on the fast or slow lines, or switches between them for short sections en-route. Currently this isn’t practical for longer sections of the Watford Junction to Rugby route; not really because it’s too difficult, but rather because it increases loading times too much due to the sheer number of commands I’ve used in the WJ-R route file, which takes too long to be parsed. I can also randomise the time of day chosen, along with the service and traction, and the optional display of a multitude of objects within the route. The location and types of passing trains shown can all be randomised, along with appropriate sounds, and so-on. All within a single route file and program. 🙂 The » example code « for achieving some of these things may appear complex at first, but actually it’s not so bad once you’ve tried it–naturally something like Watford to Rugby is much harder to work with as it’s so complex, so if you try it with your own route, it shouldn’t be as difficult. I’ll continue to experiment with this as my projects develop… More to come in future.

In the meantime, it occurs to me that I don’t think I’ve ever uploaded many, if any, high resolution images of Watford Junction to Rugby before, so here are a selection showing the aforementioned junctions, and a couple of others (please forgive the mixture of pre 1990s and post 2000 infrastructure at Watford…). This is still very much a work in progress, and neither the lighting or shading is refined yet. The scenery quality has fallen behind that of X-City South v1.4 in some respects now, and 2D trees are still in use at the moment as so much detailed 3D geometry has been applied to the railway infrastructure itself; with openBVE 2’s graphics engine, perhaps more will be possible though…

openBVE v1.0.6, Watford Junction to Rugby (Watford Junction)--click to enlarge
openBVE v1.0.6, Watford Junction to Rugby (Watford Junction)--click to enlarge openBVE v1.0.6, Watford Junction to Rugby (Hemel Hempstead)--click to enlarge openBVE v1.0.6, Watford Junction to Rugby (Bourne End Junction)--click to enlarge openBVE v1.0.6, Watford Junction to Rugby (Bourne End Junction)--click to enlarge openBVE v1.0.6, Watford Junction to Rugby (Near Blisworth)--click to enlarge
Horizontal Rule

Server Upgrades

Lastly, apologies if some of you were unable to access the site for a little while yesterday; my webhost was performing a scheduled hardware upgrade of the server where Rail Sim Routes UK is hosted. I’ve been very happy with the performance and speed of the server since I moved the site to the new host last November, with no problems reported to me, as far as I’m aware. However, it should perform even better and with greater reliability now after this upgrade, which I gather consists of a step up from a single to a dual Quad-Core Intel Xeon processor configuration along with a doubling of the quantity of RAM to 8GB. In the unlikely event that anyone tried to e-mail me while the server was briefly offline (sometime between 23:00 and midnight on 31st May), any messages should have still reached me, however if you think there might have been a problem, please try again just in case.