
- [WJ-R]: 1980s object removal (Castlethorpe/Hanslope area)
- [XCS]: Pending
- [UkTrainSys]: v0.3.2.0 released
- [Object Library]: Preparing...
- [Website]: Fifth version of website launched

Blog and Progress Updates
September 28, 2009
openBVE v1.2.2, working ammeters, X-City South v1.31 bug fixes, minor 323 3D cab update, openBVE route updates
Posted by admin on September 28, 2009 at 6:34 pm![]()
|
openBVE v1.2.2 Released
openBVE v1.2.2 has been released, and this version includes some new variables for developers to use in animated objects or 3D cabs, including new variables for acceleration and motor acceleration; more variables can now be used to query specific cars as well. New subjects covering acceleration and motor acceleration which developers can use in the legacy panel2.cfg file are also provided, and some bug fixes are also included in this release. Please visit the » openBVE homepage « and read the » Changelog « for more details.
![]() |
Working Ammeters
One new variable is accelerationMotor. As mentioned on the openBVE forum, this can be used for creating working ammeters. The class 323’s cab doesn’t feature an ammeter, however, anyone wanting to experiment with this might like to consider the following panel.animated code as a *starting point*. You can copy and paste the code below into the 323’s panel.animated file to add a new ammeter needle to the cab and see it in action. Please bear in mind that I’ve not had time to test this in a variety of scenarios though:
panel.animated code for a simple ammeter (including illuminated needle):
[object] states = 3d_cab\speedometer_needle.csv, 3d_cab\speedometer_needle_dark.csv statefunction = if[hasPlugin == 1, !pluginstate[30], 0] position = -0.43, 2.23, 11.45 rotatexdirection = -1, 0, 0 rotatexfunction = -2.4 + abs[accelerationMotor[0]] * 1.5 rotateyfunction = -1.11 rotatezfunction = -1.57 rotatexdamping = 2, 1 |
Notes: in the rotatexfunction line, -2.4 determines the needle rotation with no motor acceleration, and 1.5 determines the needle rotation with maximum motor acceleration. You can adjust these two values according to your ammeter gauge design. If you add an ammeter to your own 3D cab, remember that the statefunction line and multiple states (*.csv files in this case) may not be necessary depending on what plugin DLL, if any, you wish to use. When it comes to designing full 3D cabs for the class 86 and 87 electric locomotives for use with Watford Junction to Rugby, I’ll revisit ammeter design in more detail.
![]() |
Cross-City South v1.31 Bug Fixes and 3D Cab Update
I’ve also fixed a few bugs in the Cross-City South route. There were a few objects (houses, warehouses etc.) which included some surface lighting issues, which have now been fixed. Some class 170 3D objects also contained incorrect ‘Color’ commands resulting in errors being reported when the routes were loaded; these have now been changed to ‘SetColor’, which is correct for CSV format objects. As some of you will know, the Cross-City South also uses some .Sta commands only for signalling approach control purposes, which aren’t meant to be stopped at. However, you would still be penalised if you passed such a station without stopping. Thanks to Paul Sladen, I’ve now corrected these .Sta commands so that you can pass them without being penalised, while preserving the approach controlled signalling functionality.
You can download the full v1.31.03 route package via the Cross-City South download page.
There aren’t any new features included, as all of those improvements are going into the Cross-City South v1.4 project instead, and I’d prefer to hold those improvements back until the v1.4 is ready for release, as the end result will be more enjoyable that way.
Incidentally, the changes to the .Sta commands are as follows (the ArrivalTime and PassAlarm arguments, which are underlined):
Old: .Sta ;;09.4300;;-1;1;;;1;0;;11 New: .Sta ;P;09.4300;0;-1;1;;;1;0;;11 |
Important Note: Those of you still using BVE 4, will find that the route files now call upon the openBVE version of the unrefurbished class 323 EMU by default (Train\Cl323 Unrefurb_openbve). BVE 4 users can either install the openBVE version of the train, or edit the route files to use the older BVE 4 class 323.
![]() |
I’ve also updated the 323’s 3D cab so that it makes use of the new hasPlugin variable. If you’re using openBVE v1.2.2 with a non-Windows operating system, then this will allow the cab illumination to work in the absence of the Windows only plugin DLL, which wasn’t the case previously.
I’ve also made some adjustments to the placement of the brake gauge, as it wasn’t quite right before, and now when you pass through a neutral section, the cab lighting should remain unaffected as the UKMUt.dll’s ats30 (pantograph up) is used as well as ats31 (Line Volts) now. The carriage light dimming effect will be retained in the passenger area once the new 323 external objects are released however. I’ve also remembered to remove several superfluous GenerateNormals statements from some objects this time, as they serve no purpose in an openBVE add-on.
Someone also kindly informed me that there may be some further innaccuracies with the cab’s indicators; once I’ve investigated further I’ll address these issues at some point in future. It’s also nice to note that the 3D cab may have been downloaded perhaps as many as 1500 times since it’s release.
Download:
» 323_unrefurb_3d_cab_28-09-09.7z « [1.7 MiB — requires openBVE v1.2.2]
Important: Also requires » Cl323 Unrefurb_openbve_05.02.09.zip « to be installed first.
![]() |
Other Things
I’m not making much progress with my projects at the moment, and I know that some of you may be disappointed that I’ve not yet finished Cross-City South v1.4 despite me saying that it’d be done before now (this is also why I’m usually reluctant to give release dates, and I shouldn’t have done so where this project is concerned). Rest assured, barring any disasters, it will be finished eventually and I’m still in the game, however, sometimes circumstances in the real world prove to be too much of a distraction, and it means that what one wishes to accomplish in the simulated world has to wait for a little while. This won’t last long however, and patience will be rewarded.
![]() |
And Finally…
The Saijou Line for openBVE was released a few days ago (the author’s » blog « is linked to via my blogroll), and this is an openBVE exclusive route featuring some very nice atmosphere and night lighting. There are a few errors, however the route is well worth giving a try, as it’s a good example of how animated objects and lighting can be used to bring much more life to a route and make it that much more enjoyable. You’ll find a variety of blinking lights, such as car indicator lamps, and the aviation obstruction lights fitted to tall structures (I’ll be modelling the same feature on the cluster of 250m tall VLF radio towers at the Rugby Radio Station on the Watford Junction to Rugby route). Moving cars and buses can also be found on roads, as well as flashing level crossing lights, road based traffic lights which change when the train is approaching, animated water, and moving elevators. You can download the route here: » http://tozai.s77.xrea.com/BVE/Sjyou.html « (the author’s homepage is here: » http://tozai.s77.xrea.com «)
![]() ![]() |
Edit: Another openBVE route recently updated, was the Chashinai Railways network, along with the 9000 Series train; when this train is used with the Misaki Line in particular, in addition to ATC, you can now enjoy simulated TASC (Train Automatic Stopping Controller) and ATO (Atomatic Train Operation) systems which enable fully automated driving, thanks to a new plugin which enables sophisticated safety system simulation. The 9000 series’ panel also includes photorealistic dirt on the windscreen, increasing realism. Visit odakyufan’s website for the updates, and don’t forget to read the Train Operation Manuals before you start: » http://odakyufan.uuuq.com «
![]() ![]() |
Tags: Animated Objects, Cross-City South, Functions, openBVE, Screenshots, Site News, Watford Jn to Rugby
Posted in openBVE, Site News | 8 Comments »
August 30, 2009
3D cab update for class 323 EMU now available for openBVE v1.2
Posted by admin on August 30, 2009 at 12:30 pmI’d like to apologise for the lack of updates recently, unfortunately I had to take a break from the world of openBVE during the past few weeks. This means that the Cross-City South v1.4 project has lain dormant for much of that time, however I’m pleased to say that a pre-release version of the new class 323’s 3D cab can now be downloaded as an update for the openBVE beta class 323 available from trainsimcentral.
This initial release of the 3D cab comes complete with working gauges, as well as an animated traction/brake controller, reverser, AWS reset button, and horn lever, along with working TPWS indicators, AWS sunflower, DRA, and other indicators as well. Cab lighting is also included, along with semi-functional headlights (but not in the daytime headlight configuration). With openBVE’s Interior (Look Ahead) camera view accessible by pressing F1 until the view mode is selected, the Mouse Grab option enabled by clicking the Right Mouse Button within openBVE’s 3D view, as well as the driver’s body/head motion simulation model, a more realistic experience of driving the class 323 should now be possible.
![]() |
Download:
Please see this more recent blog entry (look for the image of the 3D cab at night)
Please note that this 3D cab isn’t entirely finished yet, and some non-essential details are yet to be added; it’s been updated since the version shown in the recent » YouTube video « however, especially on the non-driver’s side of the cab (a big thanks to » Steve Green « for his help here).
![]() |
This release works best with a route designed to accompany it, in this case, Cross-City South v1.4. Of course this isn’t available yet, so I’d recommend the following routes for testing. The Network West Midlands routes also include neutral sections, of course:
Cross-City South v1.31.03
Any routes, including the experimental night route.
Network West Midlands (» bve4.net «)
Network West Midlands Apr 09\2006-today\14.40 [323] Maybank-Hammerwich 3car local 2008.csv
Network West Midlands Apr 09\2001-2005\23.10 [323] Maybank-Hobbs X 3car local 2002.csv
![]() |
Major issues in this initial pre-release preview:
- Wiper animation is inadequate, and wiper control knob isn’t implemented yet
- Raindrop effects aren’t implemented yet
- Headlight effects may need some work
- No details added to the rear of the cab behind the driver; ceiling details are likely inaccurate
- The seats are comprised of only temporary meshes
I would have liked to release the exterior views and/or Cross-City South v1.4 along with the 3D cab so that a greater experience could be had, however neither the route or external objects are in a state which I would consider fit for public release yet. In the case of the exterior car objects in particular, they’re much closer to being ready, but only for those of you with faster CPUs and graphics cards. I don’t wish to discriminate against those with slower hardware, so I’d prefer to only release the 323 exterior car objects after I’ve created optional lower detail 3D models as well. Hopefully the 3D cab will make the wait a little more bearable, though. 🙂
Tags: Animated Objects, Cross-City South, openBVE
Posted in openBVE | 16 Comments »
July 5, 2009
New Video Uploaded: 3D Cabs (openBVE v1.1 Development Branch), 323 Interior, Watford Junction to Rugby Hi-Res
Posted by admin on July 5, 2009 at 3:50 pmopenBVE v1.1.1.0 (Development Branch), 3D cabs, and other stuff…
The first release (v1.1.0.0) in the development branch of openBVE was made available a few days ago, and now v1.1.1.0 has subsequently been released — the development branch includes support for full 3D cabs with animated objects, and mouse controlled camera rotation. v1.1.1.0 also introduces driver’s head motion, which responds to acceleration and deceleration, as well as inertia.
As many will no doubt have noticed, I’ve not shown much by way of screenshots or video of openBVE’s in-cab experience thus far, as personally, I’ve always viewed the existing 2D panel support as something of a legacy feature which didn’t really demonstrate openBVE’s true potential, so I’ve been waiting for this moment for a long time, and I have to say, it most certainly lives up to expectations and is quite simply fantastic! Applying emergency brakes has never been so much fun. 😉
Firstly, releases in the openBVE development branch are intended for developers who wish to expermiment with new features and offer feedback before these are eventually incorporated into the stable branch. Development releases may contain undetected issues, and features are subject to change, which means the development releases aren’t entirely suitable for regular users and the less technically minded, however I strongly recommend that developers and advanced users take a look at the development releases. If you’re interested in examining the new 3D cab support, you can head over to the » openBVE homepage « to download version 1.1.1.0, along with a demonstration 3D cab update for the 113-1000atccab train (look under Examples via the » Developing for openBVE « menu). Please also read the » Changelog « for a full list of alterations and new features.
Anyway, I’ve spent around a week working on a 3D cab for the new class 323 EMU and Cross-City South v1.4, and I’m really pleased with the results so far. I’ve uploaded a new YouTube video to briefly demonstrate the immersive nature of a 3D cab, the added realism, and some of the animated object possibilities — animated traction/brake controller, reverser and horn lever, working in-cab safety system indicators, simulated working headlights which give the effect of outside illumination (but see caveat below), along with working in-cab illumination. I think the potential of openBVE as a cab based simulator can now be truly realised, and speaking personally, this has forever changed the way I experience openBVE routes, and as long as photo-realism is maintained in new 3D cab environments, I’ll likely not want to go back to 2D cabs now.
This latest video was originally intended to show some other things I’ve been working on, so you’ll find many clips of the new 3D interior for the class 323, which includes seating, working television screens and lights, moving and streaking raindrop effects (inspired by the rain effects from Flight Unlimited 3), and ground illumination from the windows and pantograph sparking at night. The performance improvements which came with openBVE v1.0.7 also enabled me to capture some higher resolution video of Watford Junction to Rugby, of which many shots are included (and it has train sounds rather than my dreadful music this time 😉 ).
I’m also pleased to say that Cross-City South v1.4 now includes a full set of on-train conductor’s announcements, with enormous thanks to voice recording artist Pete Kingwell » http://www.petekingwell.com «. Pete has also recorded a set of alternative Birmingham New Street station announcements, and we agreed that all these sounds could be released into the public domain along with the rest of the Cross-City South v1.4 files once released. Thanks must also go to Paul Sladen (maintainer of the Ubuntu version of openBVE) for intiating this aspect of the project as well. I’m glad to be able to remove another set of copyright files from the route now, while being able to add something new which has been missing from the Cross-City South route for years as well, and an example on-train announcement is included in the video.
While viewing the 323’s cab, please note that I don’t actually know what the non-driver’s side of the cab looks like in any detail at all, so I’ve just had to use my imagination; if anyone can point out inaccuracies, feel free to tell me about them. Other than that, enjoy. 🙂
![]() Video: Demonstration of class 323 3D cab, interior fittings, and Watford Junction to Rugby hi-res (work-in-progress) I strongly recommend viewing this video in full screen due to some night time shots, in which some details might be hard to make out otherwise. By the way, yes, I know 323 EMUs don’t run from Watford Junction — that part of the video is just a bit of fun. 🙂
» Link to YouTube page (HD – *Best Quality*) « |
Here’s a 1280×1024 resolution screenshot of the new 3D cab. The framerate here is 25 fps, with 8x anti-aliasing and 16x anisotropic filtering enabled (on a Radeon HD 2600 Pro graphics card). Smooth transparency and anistropic filtering was also enabled in openBVE’s settings as well:
![]() openBVE / 3D Cab / X-City South v1.4 screenshot–click to enlarge |
3D Cab Features and Animation
For the 323’s 3D cab, I’ve opted for a combination of moderately complex 3D geometry combined with photo-realistic textures, some of which were easily adapted from the existing 2D panel images. Developing the new cab wasn’t really more difficult than developing any other animated object, as that is exactly what the cab is — it just took longer as there are more animated parts. The most difficult tasks I found, were probably the gauges and needles, which needed quite a lot of experimentation before the results were right, partly because the 323’s panel is sloped backwards rather than being vertical, meaning that correctly tilting the axis around which the animated needles rotate took a little while.
As an additional starting point for other train developers, here are the functions I’m using in the panel.animated file for the speedometer, main reservoir and brake cylinder needles, amongst other features, which I’m using.
Note: Some examples include two states, where one specifies an object illuminated by in-cab lighting, and the other specifies a non-emissive version of the object, shown when the power is cut, based on state of the ats31 plugin variable defined in the 323’s panel2.cfg file (when used with Simon Gathercole’s UKMUt.dll).
![]() The Base 3D Cab ![]() ![]() |
Base 3D Cab Objects:
[object]
states = 3dcab\class323_dmso_cab_interior_lights_on.csv, 3dcab\class323_dmso_cab_interior_lights_off.csv
statefunction = !pluginstate[31]
These two objects contain any non-animated portions of the cab, but one is a duplicate with emissive properties disabled, so in-cab lighting can be turned on and off according to the state of plugin variable ats31 in this case, which simulates the effect of the power being cut, or a cold and dark cab environment.
![]() Speedometer and Brake Gauge ![]() ![]() |
CreateMeshBuilder
AddVertex,-0.003,0.04,0
AddVertex,0.003,0.04,0
AddVertex,0.003,0.00,0
AddVertex,-0.003,0.00,0
AddFace,0,1,2,3
LoadTexture,speedometer_needle.bmp, speedometer_needle_n.bmp
SetTextureCoordinates,0, 0, 0
SetTextureCoordinates,1, 1, 0
SetTextureCoordinates,2, 1, 1
SetTextureCoordinates,3, 0, 1
SetDecalTransparentColor,0,0,0
SetEmissiveColor,200,200,200
RotateAll,0,1,0,90
[object]
states = 3dcab\gauges\speedometer_needle.csv, 3dcab\gauges\speedometer_needle_dark.csv
statefunction = !pluginstate[31]
position = -0.5505, 2.232, 11.452
rotatexdirection = -1, 0, 0
rotatexfunction = -3.678 + abs[speedometer] * 0.0945
rotateyfunction = -1.11
rotatezfunction = -1.57
The gauge background and cover are included as part of the base 3D geometry of the cab itself, not as seperate objects. The value -3.678 in rotatexfunction rotates the needle to 0 mph on this speedometer (adjust for your own gauge as required, using ObjectViewer to check the results). Where the last value (0.0945) is concerned, you can adjust this, initially, in 0.01 increments and test drive your train in openBVE until your speedometer is calibrated correctly (press Ctrl+V multiple times as required in-game, and compare the actual speed with the speed shown on the speedometer). Alternatively, you can temporarily replace the variable speedometer with a value in m/s (converted from the unit of measurement shown on your speedometer), check the calibration via ObjectViewer, and adjust the last value accordingly. The other rotation commands are there to tilt the axis around which the needle rotates, to match the sloped 323’s panel.
A similar approach applies to the following needles:
[object]
states = 3dcab\gauges\brake_needle.csv, 3dcab\gauges\brake_needle_dark.csv
statefunction = !pluginstate[31]
position = -0.741, 2.263, 11.462
rotatexdirection = -1, 0, 0
rotatexfunction = 1.12 + mainReservoir * 0.0000051
rotateyfunction = -1.11
rotatezfunction = -1.57
Brake Cylinder (range covers around 0-3.5 bar, as per the 2D panel)
[object]
states = 3dcab\controls\brake_needle.csv, 3dcab\controls\brake_needle_dark.csv
statefunction = !pluginstate[31]
position = -0.731, 2.263, 11.462
rotatexdirection = 1, 0, 0
rotatexfunction = -1.52 + brakeCylinder * 0.0000053
rotateyfunction = -1.11
rotatezfunction = -1.57
![]() Combined Traction/Brake Controller ![]() ![]() |
The reverser is pretty straightforward, however this is what I’m using for the combined power/brake handle:
[object]
states = 3dcab\controls\power_handle.csv, 3dcab\controls\power_handle_dark.csv
position = -0.952, 2.0, 11.173
statefunction = !pluginstate[31]
rotatexfunction = if[powerNotch >= 1, -0.125 * powerNotch, 0.10 * brakeNotchLinear]
rotatexdamping = 20, 0.8
rotatezfunction = if[powerNotch >= 1, 0.05, 0]
rotatezdamping = 20, 1
The rotatexfunction line allows both brake and power notches to be taken into account; adjust the -0.125 value to change the angle of the controller when position P1 or above is chosen, and similarly the value 0.10 for the brake steps. While determining what values to use, you can temporarily replace the above function in rotatexfunction with a simple function in the form of ROTATION_VALUE * x, where the former determines the degree of rotation, and x represents your chosen power/brake setting (for example, in the case of the class 323, a value of 1 to 4 for position P1-P4, and similarly 1 to 4 for position B1 to B3 and EMG as we’re using brakeNotchLinear here).
Also, the class 323’s combined traction/brake controller doesn’t just pivot back and forth; it’s also offset slightly to the left during the P1-P4 steps compared to the B1-B3 steps (you can see this in the screenshot on the left), which is what the rotatezfunction and rotatezdamping commands are for.
Incidentally, you might have noticed that the combined traction/brake handle appears to be a rather rounded, and smoothly sculpted object — this is achieved with a combination of 3D geometry and a good texture which captured some reflected light, further improved with custom normals (as another side note, the spherical object at the end of the horn lever shown in the next section is a pair of simple 2D surfaces arranged in a cruciform fashion; no detailed 3D geometry is needed there). How might one go about creating an object like this power/brake controller, without a 3D modelling tool? What I do, is apply the idea of the computed axial tomography medical imaging technique (CT scan) to object building; I first create a set of flat, 2D polygons or layers with temporary faces to build the basic framework of the mesh (you can draw this on paper first and number the vertices, if it helps — handy when it comes to defining faces and texture mapping later), then I adjust the vertices of the first layer until the shape looks about right, and then create the next layer and adjust and so-on, and then define final faces of the object and delete the temporary faces, followed by the addition of custom normals and texture mapping:
This is also the technique I used for creating the AC electric loco roof sections, by the way:
![]() Horn Lever ![]() ![]() |
[object]
states = 3dcab\horn_lever.csv, 3dcab\horn_lever_dark.csv
position = -0.07, 2.06, 11.234
statefunction = !pluginstate[31]
rotatexfunction = pluginstate[24] * 0.5
rotatexdamping = 30, 0.8
rotateyfunction = -0.3
The horn lever was straightforward to implement; it’s rotation simply depends on the value of the ats24 plugin variable in this case. rotateyfunction = -0.3 simply rotates the object so it’s perpendicular to the desk panel it’s attached to.
![]() Other indicators ![]() ![]() |
[object]
states = 3dcab\indicators\tpws_isol.csv
position = 0, 0, 0
statefunction = !pluginstate[10]
This is simple and works fine, and is also recommended. However, if on a state change, you notice that the newly loaded object appears momentarily untextured, and this bothers you, then you can use the following technique instead…
states = 3dcab\controls\dra.csv
position = 0, 0, 0
textureshiftyfunction = pluginstate[13] * 0.5
CreateMeshBuilder
AddVertex,-0.5905,2.0885,11.381
AddVertex,-0.5485,2.0885,11.381
AddVertex,-0.5485,2.0525,11.365
AddVertex,-0.5905,2.0525,11.365
AddFace,0,1,2,3
SetTextureCoordinates,0, 0, 0
SetTextureCoordinates,1, 1, 0
SetTextureCoordinates,2, 1, 0.5
SetTextureCoordinates,3, 0, 0.5
SetDecalTransparentColor,0,0,255
SetEmissiveColor,255,255,255
SetColor,130,130,130
SetBlendMode,Additive
Here, the illuminated DRA image is placed in the bottom half of the texture, while the top half of the image is transparent. By using a texture shifting function, no state change occurs, so you won’t notice any momentarily untextured surface appearing which can happen when a state is changed and the object hasn’t been loaded previously.
![]() |
If, for example, your ats subject had 4 states rather than 2 as in the above DRA example (with it’s bitmap split into 4 sections), you could use a value of 0.25 (i.e. 1 / 4) in your texture shifting function instead:
![]() |
![]() Simulated Headlight Effects ![]() ![]() |
I’m still experimenting with the simulated in-cab headlight effects and some refinements are needed, but here’s what I’ve come up with so far:
[object]
states = 3dcab\ext_headlight_1.csv, 3dcab\ext_headlight_1a.csv, 3dcab\ext_headlight_1b.csv
position = 0, 0, 0
statefunction = if[pluginstate[20] > 0, pluginstate[20] – 1, -1]
The object code I’m using is like the following:
ext_headlight_1.csv
CreateMeshBuilder
AddVertex,-1.3, 3.0, 11.67
AddVertex,0.6, 3.0, 11.67
AddVertex,0.6, 1.5, 11.67
AddVertex,-1.3, 1.5, 11.67
AddFace,0,1,2,3
LoadTexture,transparent.png, headlight_interior.png
SetTextureCoordinates,0, 0, 0
SetTextureCoordinates,1, 1, 0
SetTextureCoordinates,2, 1, 1
SetTextureCoordinates,3, 0, 1
SetBlendMode,Additive
SetColor,150,130,100,120
The three objects are flat, vertical surfaces which load a simple texture with a sunburst gradient fill, representing a glow (similar to the light_xxxxx.png signal glow images included with openBVE’s compatibility signal objects, or the pantograph sparking effects I’ve shown previously). The glow colour in the texture is white, and the SetColor command is used to determine what colour headlight is depicted (a yellowish-white in the example above); this way, only one texture is needed. These objects are positioned just beyond the cab window, and the additive blending mode simulates the effect of illuminating whatever is behind the surface (the track and scenery, in this case). The height of the surface determines whether just the track, or the scenery, appears to be illuminated. The file “transparent.png” is a tiny, completely transparent PNG file loaded as the daytime texture, so the headlight effect is only visible in low light (as it’s loaded as a nighttime texture), or when the .Brightness command is used.
The states are linked to the proving lights in the cab (ats20), and each object has it’s surface repositioned to simulate headlights on the left or right, or centred in the case of the marker lights.
There is one caveat however; while this works well at night, or when in a tunnel during daytime, the effect doesn’t look so good when passing beneath a short overbridge (i.e. where a low .Brightness value is set over a distance of just a few metres), as the headlight glow becomes visible here, when in reality it wouldn’t. As a compromise, what I’ll probably do in the final release, is reserve the headlight effect for the nighttime headlight configuration only, not the daytime configuration (possible with the UKMUt.dll plugin). You’ll have to decide whether this minor issue is worth it or not.
Class 323 Interior
I thought I’d talk a little about the 323’s interior as well. The interior view features the expected things; i.e. seats and partitions, but I’ve also included working TV screens, working carriage lighting, raindrop effects which run down and streak across the windows at varying speeds (depending on the speed of the train), and ground illumination from the windows and sparking pantograph.
![]() Working TV Screens ![]() ![]() |
The working TV screens use simple texture shifting and translation functions — for the left screen with the car and rolling news ticker, there’s nothing I haven’t described before, apart from applying the functions to a very different set of meshes. Where the static effect is concerned, this is created by using two surfaces with a small texture containing a patchwork of black and white pixels; one of the objects has the texture reversed vertically and horizontally. One object is positioned slightly in front of the other, and both have alpha values set via the SetColor command to soften the appearance of the end result. These objects then have their textures shifted via the same function:
CreateMeshBuilder
AddVertex,0.46, 3.492, 3.597
AddVertex,0.765, 3.492, 3.597
AddVertex,0.765, 3.273, 3.597
AddVertex,0.46, 3.273, 3.597
AddFace,0,1,2,3
LoadTexture,Class323_TV_Texture_2.png
SetTextureCoordinates,0, 2, 0
SetTextureCoordinates,1, -0.001, 0
SetTextureCoordinates,2, -0.001, 2
SetTextureCoordinates,3, 2, 2
SetColor,0,0,0,180
SetEmissiveColor,255,255,255
AddVertex,0.46, 3.492, 3.595
AddVertex,0.765, 3.492, 3.595
AddVertex,0.765, 3.273, 3.595
AddVertex,0.46, 3.273, 3.595
AddFace,0,1,2,3
LoadTexture,Class323_TV_Texture_2.png
SetTextureCoordinates,0, 2, 0
SetTextureCoordinates,1, 2, 2
SetTextureCoordinates,2, -0.001, 2
SetTextureCoordinates,3, -0.001, 0
SetColor,0,0,0,180
SetEmissiveColor,255,255,255
[object]
states = ..\Class323_TV_2.csv, ..\Class323_TV_2a.csv
position = 0, 0, 0
statefunction = if[pluginstate[31] == 0 & pluginstate[33] == 0, -1, value == 0]
textureshiftxfunction = 2 * time
refreshrate = 0.01
The pluginstate[i] variables are there so that the TVs are only switched on when there’s power, and stay on when passing though a neutral section (ats31 is the Line Volts indicator, and ats33 the Vacuum Circuit Breaker indicator). The refreshrate = 0.01 line just adds a slight degree of flickering to the screen.
![]() Window raindrop effects ![]() ![]() |
The raindrop effects also deserve a little more explanation. These are comprised of two surfaces, the first of which has ordinary raindrops similar to what you’ve seen in BVE 4 cabs, except here, the surface simply has one tiled, transparent texture containing multiple raindrops and the texture is slowly shifted. The second surface, loads a texture depicting several streaking rain drops, and the speed of the streaking is linked to the speed of the train, although they still move slowly down the window when the train is stationary. What I did differently, was to make the surface irregularly shaped, so the raindrops appear to change direction as they travel across the window due to turbulence or inteference:
![]() |
[Object]
position = 0, 0, 0
states = Class323_DMSO_1_RainDrops_1.csv
statefunction = !pluginstate[200]
textureshiftyfunction = -0.1 * time
textureshiftxdirection = 0, 1
textureshiftxfunction = value – delta * speed / 60
refreshrate = 0.01
ats200 is one of the raindrops you’re familiar with from the 2D BVE 4 cabs…
![]() Pantograph spark and ground lighting effect ![]() ![]() |
The pantograph sparking and ground illumination effect is a simple additively blended glow effect, which will appear mostly briefly at various times during a journey, but not continuously and not necessarily frequently. When seen for the first time, it might seem as though the effect appears at random, but actually the times at which you’ll see sparking are based on the speed of the train. This is acheived via the following function:
[Object]
states = Class323_Spark_1.csv
position = 0, 0, 0
statefunction = if[mod[speed, 3] > 2.9, value == 0, -1]
refreshrate = 0.03
![]() Flashing Tail Light ![]() ![]() |
In terms of visual effect, the tail light is implemented just like the signal aspects. The animation code I’m using to achieve a short blink followed by a longer period of extinguishment is as follows:
[Object]
States = TailLamp_1a.csv
Position = 0, 0, 0
StateFunction = if[mod[time, 0.55] > 0.08, -1, 0]
![]() Signal Ground Lighting ![]() ![]() |
These effects are really easy — the objects are just like the headlight objects mentioned previously, except these extend out behind the signal and are animated objects loaded via .SigF commands instead. The simple animation function I’m now using is as follows:
[Object]
Position = 0, 0, 0
States = Sig_GroundLight_R.csv, Sig_GroundLight_Y.csv, Sig_GroundLight_Y.csv, Sig_GroundLight_G.csv
StateFunction = if[section > 0, section – 1, 0]
Incidentally, I’ve now adopted more or less the same technique developed by michelle for openBVE’s compatibility signal objects where my own signal aspect/lens and glow effects are concerned, as it’s obvious that a lot of care went into these effects, and they look superb when applied to my own signal objects with the lens hoods as well (see the video…).
Updated Pantograph Animation Functions
Lastly, I’ve updated my old Animated Exterior Car Objects blog entry to include some updated unctions which resolve a problem with the code which I hadn’t considered previously. Bascially, the code I used meant that the pantograph animation speed was dependent on the framerate on the user’s computer, which is obviously no good — if slow framerates were encountered, the animation would proceed very slowly, while if high framerates were experienced, the animation speed would be too high. By incorporating the delta variable and a factor into the functions, this problem is solved. Actually this should have occured to me, because I observed this behaviour when I was experimenting with the wheel rotation initially… D’oh. Thanks michelle !
Tags: Animated Objects, Artwork, Cross-City South, Functions, openBVE, Screenshots, Videos, Watford Jn to Rugby
Posted in openBVE | 25 Comments »
June 16, 2009
openBVE v1.0.7.1 released; performance improvements and new object development features
Posted by admin on June 16, 2009 at 12:04 amopenBVE 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.
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. 🙂
![]() |
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:
![]() ![]() ![]() |
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
or…
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:
![]() ![]() |
On the left, we have a simple mesh with 8 vertices and 3 faces:
![]() |
CreateMeshBuilder
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 AddFace,0,1,3,2 AddFace,2,3,5,4 AddFace,4,5,7,6 SetColor,190,160,160 |
On the right, we have the same mesh, but with vertex normals specified, resulting in the smoothly shaded appearance:
![]() |
CreateMeshBuilder
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 AddFace,0,1,3,2 AddFace,2,3,5,4 AddFace,4,5,7,6 SetColor,190,160,160 |
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:
![]() ![]() |
![]() ![]() ![]() ![]() |
![]() |
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:
![]() |
Tags: Cross-City South, Hardware, openBVE, Screenshots, Watford Jn to Rugby
Posted in openBVE | 4 Comments »
May 24, 2009
openBVE v1.0.6.0, Cross-City South v1.4 Updates
Posted by admin on May 24, 2009 at 11:50 pmNew openBVE release–v1.0.6.0
A new version of openBVE is now available, version 1.0.6.0; head over to the » openBVE homepage « to download the latest stable release. One of the three most noticeable improvements in this version (the other two being time acceleration and the ability to mute sound, more below) concerns the Smooth Transparency feature, which has been dramatically improved. If you’ve enabled this option in openBVE previously, you might have noticed that while the quality of the rendered scenes was much better with Smooth transparency enabled, occasionally, unsightly fringes appeared around some transparent textures, where translucent pixels were rendered. This was problem was also more pronounced on Cross-City South v1.4 due to the frequency with which texture transparency is used in the new scenery. This issue concerning texture transparency and the z-buffer is a complex topic which I gather not all OpenGL developers adequately address, however Michelle has found a way of solving the problem, and while the performance is a little lower than with the previous implementation (especially on routes where a very high number of polygons use texture colour transparency), the visual quality is far better, as the following comparison screenshots demonstrate (along with the new X-City South v1.4 screenshots below).
On the left, we have the » ATS-Sn/P Test route « in openBVE v1.0.5.0; click the thumbnail and note the fringes around the catenary gantry texture. On the right, we have v1.0.6.0–no such issue can be observed, and the end result is superb:
|
Similarly, here we have the » Chashinai Railway «:
|
For a detailed explanation about this solution, please see michelle’s » Developer’s Blog «
![]() |
Other welcome enhancements and changes in v1.0.6.0 include:
- A time acceleration feature (Ctrl+J, switches between x1 and x5 speed);
- The ability to mute the sound (Ctrl+M — now you can listen to music via your media player while in-game, which is quite a lot of fun when used with the time acceleration feature! 🙂 );
- A consistent look is now achieved where fog and background images are concerned, regardless of viewing distance;
- And more… Please see the » changelog « on the openBVE site for details.
If you’re still using openBVE v1.0.3 or 1.0.4, then after updating to the latest release, you’ll also benefit from changes which were introduced with v1.0.5, including amongst other things, a bug fix relating to odd behaviour where unwanted roll was initially applied to the external camera view, enhanced AI driver behaviour where cruising is concerned, and additions to the Doors parameter of the .Sta command.
![]() |
Cross-City South v1.4 scenery improvements
Firstly, apologies for the lack of project updates recently… Unfortunately I’ve not done quite as much as I’d hoped to in the past month. Nevertheless, I’ve been working on updating the scenery objects for Cross-City South v1.4, and this is proceeding quite well now. It’s proving to be quite time consuming, and the bulk of the work involves replacing a fair number of the previously 2D trees and bushes with more realistic partially 3D versions, allowing the scenery to look good even when the camera is panned to the side, such as when looking out of the windows, while also enabling the camera to be moved a little further away from the train in the external view without the scenery looking unrealistic. Hedgerows have also been improved, not just the trees.
I’m currently adding pretty highly detailed vegetation just to test performance and visual quality, but once I’m finished I’ll likely perform a batch search and replace operation on all the scenery files to reduce the number of surfaces to improve framerates a little. I’m relatively happy with how the scenery is turning out, but I have to say, it’s just a little tedious; I’ll be glad when this task is over and I can get back to the animated objects!
Here are some screenshots to show the progress so far; the scenery, lighting and shading isn’t finalised yet, but the images give a general impression of the end result I want to achieve. The trees and hedges still look a little too repetetive to me–I’ll try and improve upon this if I have time… All screenshots depict the route at 1280×1024 resolution with 8x antialiasing, 16x anisotropic filtering, and with openBVE v1.0.6.0’s smooth transparency enabled. A fast graphics card will likely be needed for higher framerates with the latter feature in use, at least with openBVE 1’s renderer:
![]() ![]() ![]() |
![]() |
I’m also experimenting with mixing both 2D and 3D trees to achieve a balance between visual quality and performance; 3D trees are placed near to the lineside, while 2D trees are placed behind these, and the overall effect looks reasonable to me; I hope you agree. It should work well, provided the player doesn’t move the camera beyond the effective scenery edge boundary which the 2D tree surfaces create–openBVE is still primarily a cab view simulator, after all. Here are some examples of the scenery testing location at Longbridge:
![]() ![]() |
![]() |
I’ve also added shadows beneath the trees and OHLE masts (another feature brought in from Watford Junction to Rugby), as well as beneath hedgerows to improve the appearance of the scenery. The shadows are simply very low resolution textures, which in the interests of performance, don’t use alpha channels, just ordinary texture transparency. The low resolution of the textures provides the necessary blurring:
![]() ![]() ![]() ![]() |
![]() |
Lastly, I’m also updating the pointwork so it’ll be up to the standard of Watford Junction to Rugby:
![]() ![]() |
![]() |
openBVE Help Guide updated
Just in case anyone hasn’t read through the comments on my last blog entry or otherwise noticed, I updated my openBVE Help and Information Guide recently, to include instructions explaining how openBVE can be installed and used by Ubuntu Linux users, either via the Add/Remove option, or by installing and running the program via Wine (which allows BVE 4 plugin DLL equipped trains to be used in Linux). I update the guide regularly as well, so if you need any assistance with openBVE which isn’t covered elsewhere, please visit the updated guide for more information: openBVE Help and Information.
Incidentally, since I replaced the X-City South executable installer with the .7z archive, downloads have been just as frequent as before, and I’ve had no more requests for help with installing the route than usual (and I don’t get many requests for help usually); indeed someone who was a newcomer to train simulation kindly informed me that they’d managed to install openBVE, BVE4, and Cross-City South with help from the guides I’ve prepared. So I’m assuming that most of you are managing fine with the installation process. 🙂
Tags: Artwork, Cross-City South, openBVE, Screenshots, Site News, Trackwork
Posted in openBVE | 8 Comments »
April 25, 2009
April 19, 2009
Cross-City South 7-Zip trial
Posted by admin on April 19, 2009 at 7:55 amIn what may or may not prove to be a popular move, I’ve replaced my beloved NSIS executable installer within which the Cross-City South route was previously distributed, with a 7-Zip archive instead (and the other Cross-City add-ons have also been repackaged). I’m doing this as a trial to see how users cope with installing the route using a compressed archive manager instead of an installation program. I’m not willing to package the route using the more popular but less effective .zip format, as the resulting filesize is much larger than the .7z equivalent–the Cross-City South .zip version comes to a massive 32 MiB, while the 7-Zip archive comes in at 13.5 MiB, which is a little smaller than the installer it replaces (which figures, as both were compressed using the same LZMA compression method). All archives by default, have either the ‘Railway’ or ‘Train’ folder as the root folder within the archives, so you can always choose the same destination path when extracting the contents, and so there’s little doubt as to which folder the contents are supposed to be extracted to.
Okay, so I’ll miss using NSIS to package my add-ons as it was a very flexible installer creation tool, but more seriously, openBVE is intended as a cross-platform program, and executable (.exe) installers only work natively on Windows and not on other operating systems, which is unfair to non-Windows users wanting to use the route, or indeed those who have their add-ons installed in a non-default location. openBVE’s developer has also stated that add-ons released in installers aren’t considered to be openBVE content at all (and I can’t be happy if X-City isn’t considered to be openBVE content), so one way or another, distribution via compressed archive is the way of the future for openBVE, and I hope you’ll all be able to adjust to this change. If absolutely necessary I may reintroduce the executable installer alongside the .7z archive, but I’d prefer not to if possible.
There are no changes to the route itself (with v1.4 on it’s way, updating the old version isn’t really a good use of my time), however to prepare yourself for Cross-City South v1.4 and other openBVE add-ons in future, you can head over to the » Cross-City South download page « and try out the compressed archive installation method instead. I’ve also added new content to the » openBVE Help and Information « section of the site, which includes a couple of screenshots of what we can all look forward to with openBVE in the near future, along with step-by-step instructions to help with the downloading and installation of the Cross-City South .7z package for use with openBVE, along with recommended settings, and so-on. I’ve also slightly updated the » BVE 4 Help Section «, and you can also view an updated version of the » Cross-City South/Class 323 Tutorial « tailored for openBVE.
|
Edit: I’ve made a couple of amendments to the openBVE Help page and the Cross-City South download page, as they contained some unclear instructions and mistakes–sorry! I’ll continue to update them if necessary.
If you have problems installing the Cross-City South via the compressed archive method instead, I’d really like to hear about your installation experiences. Please feel free to add comments to this blog entry if you have any problems (no registration required, just click the ‘x Comments’ link below), or e-mail me. If there’s no feedback, I’ll assume you’re all managing just fine. 🙂
Tags: Cross-City South, openBVE, Site News
Posted in openBVE, Site News | 8 Comments »
Platform Generator utility released
Posted by admin on April 19, 2009 at 7:45 amAlan Wheeler’s new Platform Generator (Plat Gen) tool was released recently; head over to » eezypeazy.co.uk « to download this handy utility. The program creates a variety of photo-realistic customised platform segments, allowing route developers to choose the surface and side textures, create platform ramps, curved platform lengths at various radii, and more. The generated objects are placed via the .Freeobj command rather than the .Form commands. Here’s a screenshot of one of the resulting platforms at University station on the Cross-City South v1.4 route:
![]() openBVE / Cross-City South v1.4 plus 323 screenshot |
Tags: Cross-City South, openBVE, openBVE Community, Screenshots, Software
Posted in openBVE | 2 Comments »
March 24, 2009
Cross-City South v1.4 Progress
Posted by admin on March 24, 2009 at 12:22 amI am sorry for the lack of updates during the past few weeks. This is partly because more of my time has been taken up by non-railsim related stuff during the past month, but also because I’ve completed most of the experimentation as far as XCS v1.4’s animated objects are concerned now (I have to stop somewhere otherwise I’ll never finish it), and what remains to be done isn’t especially newsworthy in comparison–mainly adding what I’ve already shown throughout the route. I also can’t imagine that any of you would be particularly interested in reading about that sub-folder I renamed two days ago, those trees I added to a set of ground objects, or that exciting search through my archives to find a photo of a class 323’s seating?! However, the project is going well, and I should have some more news soon.
Tags: Cross-City South, openBVE
Posted in openBVE | 4 Comments »
February 26, 2009
Animated Exterior Car Objects
Posted by admin on February 26, 2009 at 10:00 pmAs most of you will likely know already, » openBVE « now enables developers to use animated exterior car objects. I was pleasantly surprised by all the positive feedback and comments regarding my last video which I uploaded to YouTube (thank you!), but one criticism which was pointed out several times was the disparity between the quality of the scenic visuals, and the rather simplistic objects used to represent the class 323 EMU–the objects were fine for BVE’s passing trains, but less so when you can move the camera up close and look at the details, or lack thereof. I didn’t think it was worth spending much time on this latter aspect until animation could be applied to the exterior car objects, but now this is possible, I’ve been working on some far better 3D models for the class 323. I had hoped to get this task finished sooner, but it’s taken longer than I originally expected unfortunately–the main difficulty was getting the rounded cab looking right, and texturing it correctly. However, I’m now happy with the appearance, and so I present the work-in-progress fully 3D exterior car objects for openBVE and Cross-City South v1.4. Incidentally, as with all my openBVE/BVE objects, these models are entirely hand coded, with no “help” from 3D modelling software.
Currently the objects are rather more complex than I originally intended (so far, the entire three coach EMU contains around 8200 vertices/4900 faces), and there is a performance penalty that comes with using them; on a fairly typical BVE route, framerates should be okay, but when paired with a very highly detailed and intensively animated route such as Cross-City South v1.4, a fast PC will likely be required to enjoy both extensively detailed animated scenery and detailed external car objects with reasonable framerates. What I intend to do, for those of you with slower hardware, is release alternative versions of the exterior car objects with lower polygon counts, and because of the way I’ve created the textures, the end result should still look good despite less complex geometry. Even these lower detail versions will be rather better than the previous objects though. So ultimately, if framerates are a problem, you can simply choose either richly detailed scenery, or richly detailed train objects, depending on which is more important to you.
Currently, the models include the following standard animated features:
- Rotating wheelsets including wheelslip effects (with provision for animated suspension, and bogie rotation should such functionality be possible in future)
- Bi-parting, sliding plug doors (some issues with door open/close sound synchronisation–see below)
- Moving window reflections (twin-layered with transparency, to create a parallax effect)
The models also include the following animated features linked to plugin (UKMUt.dll) variables:
- Windscreen wipers (left/right sweep, plus arc motion; the wipers aren’t perfect–see below)
- Head and tail lights (both ends of train)
- Interior lights (on or off via pantograph up/down button)
- LED destination display with flicker (on or off via pantograph up/down button)
- Working pantograph (all illuminated features also extinguish when pantograph is lowered)
I’ve also prepared another video to show these features. Please note, the 3D objects aren’t finished yet; some textures need updating, and I’ve yet to add interior fittings. Developers might want to continue reading on, as I’ll explain how some of these animations have been implemented, and share some sample code from the .ANIMATED objects.
![]() Video: Demonstration of class 323 animated exterior car objects (work-in-progress) » Link to YouTube page (HD – best quality) « |
I also thought you might like to see a high resolution image of Cross-City South v1.4 and the new high detail class 323; in this screenshot, I’m running openBVE fullscreen at a resolution of 1280×1024, with 8x anti-aliasing and 16x anisotropic filtering enabled (on a Radeon HD 2600 Pro graphics card). Bilinear interpolation was enabled in openBVE’s settings, with the Transparency mode set to Sharp. I was getting around 16-19 fps at the time; the framerates in the next version of openBVE will hopefully be a little higher due to performance optimisations where animated object normals are concerned, although this gain may be offset by the addition of more animated scenery objects to the route:
![]() openBVE / Cross-City South v1.4 plus 323 screenshot–click to enlarge |
![]() Rotating Wheelsets ![]() ![]() |
The first things I tried to animate were the wheelsets. Initially I had difficulty getting this to work as anticipated, and observed unexpected results while using the Speedometer variable, i.e. the resulting wheelset rotation appeared as though it were based upon acceleration rate rather than an actual velocity value (and » Ron « found the same when he first tried to animate wheelsets, it would seem). I usually like to try and figure out solutions to such problems myself, but sadly I’m not the reincarnation of Pierre de Fermat, and as such, my mathematical knowledge was insufficient. Fortunately, a way forward could be found over at the » openBVE Japanese « site, which includes some helpful material covering animated objects and functions. The following function can be used to rotate each wheelset:
Incidentally, 2.765 is the circumference of the wheel. The above formula works perfectly, but initially I wondered if it was more complicated than it needed to be, so I attempted to find a more simple alternative, and somehow arrived at the following formula, where the value 0.05949986086344 results from (pi / 0.88) / 60, where 0.88 is the diameter of the wheel:

Initially this seemed to work well, but on closer examination, the end result wasn’t as good as the more complex formula because the rate of rotation varies with the framerate, and I observed no difference in performance between the two anyway.
Update
Thanks to a certain mathematically adept someone, I now have a new formula which is better in terms of performance and ease of use:
![]() |
![]() |
![]() Animated Doors ![]() ![]() |
The bi-parting sliding plug doors are comprised of a pair of 3D door objects, which slide forwards and backwards via a translation along the Z axis, with values supplied via the left/rightdoors[i] variables, e.g:
[Object]
Position = 0.002, 0, -5.552
States = Class323_Door_2_R_Dark.csv, Class323_Door_2_R.csv
TranslateZFunction = rightdoors[0] + 0.864
TranslateXFunction = min[power[10 * (rightdoors[0] – 0.1), 3] + 1, 1] * 0.05
StateFunction = pluginstate[31]
[Object]
Position = 0.002, 0, -6.417
States = Class323_Door_2a_R_Dark.csv, Class323_Door_2a_R.csv
TranslateZFunction = -rightdoors[0] + 0.864
TranslateXFunction = min[power[10 * (rightdoors[0] – 0.1), 3] + 1, 1] * 0.05
StateFunction = pluginstate[31]
Left door animation:
[Object]
Position = -0.002, 0, -5.552
States = Class323_Door_2_L_Dark.csv, Class323_Door_2_L.csv
TranslateZFunction = leftdoors[0] + 0.864
TranslateXFunction = -min[power[10 * (leftdoors[0] – 0.1), 3] + 1, 1] * 0.05
StateFunction = pluginstate[31]
[Object]
Position = -0.002, 0, -6.417
States = Class323_Door_2a_L_Dark.csv, Class323_Door_2a_L.csv
TranslateZFunction = -leftdoors[0] + 0.864
TranslateXFunction = -min[power[10 * (leftdoors[0] – 0.1), 3] + 1, 1] * 0.05
StateFunction = pluginstate[31]
The StateFunction command is there to switch between illuminated and non-illuminated versions of the door objects, and pluginstate[31] is equivalent to the ats31 subject in the class 323’s panel2.cfg file (when used with Simon Gathercole’s UKMUt.dll), i.e. the Line Light indicator (so the lights appear to go out when the pantograph is lowered). The objects are also translated along the X axis so they “plug” into the bodyside when fully closed. Unfortunately the door open and close sounds aren’t fully synchronised with the door motion; with UK trains, warning beeps are heard before the doors actually start to close, but the beeps are contained within the door closing audio file, and of course the visible doors start to close as soon as the beeping starts. The duration of the door opening motion is also shorter than the duration of the door opening audio files. I haven’t tried having door animation controlled via plugin variables yet; when I have time I’ll look into this further.
![]() Animated Window Reflections ![]() ![]() |
The window reflections are made from two semi-transparent surfaces, which have texture shifting functions applied, based upon the current speed of the train, e.g:
[Object]
Position = 0, 0, 0
States = ..\Class323_DMSO_1_WindowReflections.csv
TextureShiftXFunction = value + speed * 0.001
[Object]
Position = 0, 0, 0
States = ..\Class323_DMSO_1_WindowReflections_bg.csv
TextureShiftXFunction = value + speed * 0.0001
There’s a foreground reflection texture with transparency, showing near-track bushes, and there’s also a background reflection texture, showing a low resolution version of the backdrop (ground and sky) texture, and this surface’s texture is shifted more slowly than the foreground texture, creating a rather nice parallax effect when the train is in motion. The overall effect looks rather good in my opinion, but of course, if the reflection textures depict a Summer scene, but the train is used on a Winter route with snow, it looks a little silly…
![]() Interior Illumination ![]() ![]() |
Interior lighting strips, along with interior fittings and additional semi-transparent yellow surfaces to lighten the windows when viewed from outside at night (allowing adequate night-lighting effects while still being able to have daytime window reflections), are displayed when the pantograph is raised, and swapped for non-emissive versions when the pan is lowered, so it’s possible to turn the carriage lights on and off. When the pantograph is lowered, all exterior lights are also state-changed or translated so they appear to extinguish, and won’t illuminate until the pantograph is raised again. This is achieved using if[pluginstate[31] ... ] commands, as demonstrated in the next section.
![]() Animated Pantograph ![]() ![]() |
The pantograph itself can be visibly raised and lowered, with the head having a Y axis translation applied, and the upper and lower arms having X axis rotation, along with Y and Z axis translation applied. The pantograph animation is conditional upon the state of the value of plugin variable 31, or the ats31 subject in the class 323’s panel2.cfg. The code I’ve written which enables this is as follows (since updated on the 5th July 2009, thanks to a post by michelle herself):
[Object]
Position = 0, 4.24, 9.071
States = ..\Pantograph_BWHS_Head.csv
TranslateYFunction = if[pluginstate[31] == 0, if[value > -0.97, value – delta * 0.49, -0.97], if[value < 0, value + delta * 0.49, 0]]
[Object]
Position = 0, 4.24, 9.071
States = ..\Pantograph_BWHS_UpperArm.csv
TranslateYFunction = if[pluginstate[31] == 0, if[value > -0.45, value – delta * 0.225, -0.45], if[value < 0, value + delta * 0.225, 0]]
RotateXFunction = if[pluginstate[31] == 0, if[value > -0.29, value – delta * 0.145, -0.29], if[value < 0, value + delta * 0.145, 0]]
TranslateZFunction = if[pluginstate[31] == 0, if[value < 0.06, value + delta * 0.03, 0.06], if[value > 0, value – delta * 0.03, 0]]
[Object]
Position = 0, 4.24, 9.071
States = ..\Pantograph_BWHS_LowerArm.csv
TranslateYFunction = if[pluginstate[31] == 0, if[value > -0.45, value – delta * 0.225, -0.45], if[value < 0, value + delta * 0.225, 0]]
RotateXFunction = if[pluginstate[31] == 0, if[value < 0.27, value + delta * 0.135, 0.27], if[value > 0, value – delta * 0.135, 0]]
TranslateZFunction = if[pluginstate[31] == 0, if[value < 0.06, value + delta * 0.03, 0.06], if[value > 0, value – delta * 0.03, 0]]
![]() Animated Wipers and Working Headlights ![]() ![]() |
The windscreen wipers aren’t as good as I’d like them to be yet; when the if[pluginstate[i] ... ] conditions are satisfied and the truevalue formulae are executed, the wipers can jump to a position mid-sweep rather than starting to move from their currently held position. The same problem can happen when switching the wipers off as well, although the way I’ve implemented it, the wipers will stop in whatever position they are in when the wipers are turned off. More work needed here… Each wiper is comprised of two arms, and a wiper blade. The code so far, is as follows:
[Object]
States = ..\Class323_DMSO_Wiper_L_1.csv
Position = -0.56, 2.27, 0
RotateZFunction = if[pluginstate[198] > 0, power[1 – abs[cos[time]], 0.5] * 1.3, value]
[Object]
States = ..\Class323_DMSO_Wiper_L_1a.csv
Position = -0.5, 2.27, 0
RotateZFunction = if[pluginstate[198] > 0, power[1 – abs[cos[time]], 0.5] * 1.3, value]
[Object]
States = ..\Class323_DMSO_Wiper_L_1b.csv
Position = -0.55, 2.28, 0
TranslateXFunction = if[pluginstate[198] > 0, -power[1 – abs[cos[time]], 0.5] * 0.73, value]
TranslateYFunction = if[pluginstate[198] > 0, power[sin[time * 2], 2] * 0.13, value]
The last TranslateYFunction command moves the wiper blade up and down at the correct speed, which when combined with the X axis translation, creates the overall effect of an arc movement rather than a simple left-right motion.
![]() |
The head (and tail) lights are linked to the proving lights in the cab (the ats20 and ats21 subjects in the class 323’s panel2.cfg). Each headlight configuration has it’s own csv object. The headlights will only be illuminated when the pantograph is also raised (dependent on the state of plugin variable 31, or the ats31 subject in panel2.cfg). When the tail lights at one end of the train are on, they automatically turn off at the other end of the train. For the rear of the train, the headlights can only illuminate if the tail lights are also off. The code which enables all of this is as follows (please note, I’m presenting two alternative ways of implementing the lights on the leading vehicle, the reason why can be found below):
Class323_DMSO_1.animated (lead vehicle) OPTION 1
[Object]
States = ..\null.csv, ..\Class323_Headlights_0.csv, ..\Class323_Headlights_1.csv, ..\Class323_Headlights_2.csv
Position = 0, 0, 0
RotateYFunction = 3.1416
StateFunction = if[pluginstate[31] == 1, pluginstate[20], 0]
[Object]
States = ..\null.csv, ..\Class323_Taillights_1.csv
Position = 0, 0, 0
RotateYFunction = 3.1416
StateFunction = if[pluginstate[31] == 1, pluginstate[21], 0]
Class323_DMSO_1.animated (lead vehicle) OPTION 2
[Object]
States = ..\Class323_Headlights_0.csv
Position = 0, 0, 0
RotateYFunction = 3.1416
TranslateYFunction = if[pluginstate[31] == 1, if[pluginstate[20] == 1, 0, -600], -600]
[Object]
States = ..\Class323_Headlights_1.csv
Position = 0, 0, 0
RotateYFunction = 3.1416
TranslateYFunction = if[pluginstate[31] == 1, if[pluginstate[20] == 2, 0, -600], -600]
[Object]
States = ..\Class323_Headlights_2.csv
Position = 0, 0, 0
RotateYFunction = 3.1416
TranslateYFunction = if[pluginstate[31] == 1, if[pluginstate[20] == 3, 0, -600], -600]
[Object] States = ..\Class323_Taillights_1.csv
Position = 0, 0, 0
RotateYFunction = 3.1416
TranslateYFunction = if[pluginstate[31] == 1, if[pluginstate[21] == 1, 0, -600], -600]
Class323_DMSO_3.animated (rear vehicle)
[Object]
States = ..\null.csv, ..\Class323_Headlights_0.csv, ..\Class323_Headlights_1.csv, ..\Class323_Headlights_2.csv
Position = 0, 0, 0
StateFunction = if[pluginstate[31] == 1, if[pluginstate[21] == 1, pluginstate[20], 0], 0]
[Object]
States = ..\Class323_Taillights_1.csv, ..\null.csv
Position = 0, 0, 0
StateFunction = if[pluginstate[31] == 1, if[pluginstate[31] == 1, pluginstate[21], 0], 1]
In Option 1 above, the lead vehicle’s headlights are changed using StateFunction commands alone. This method works fine, but the first time each state is changed to, you’ll see the object’s texture isn’t loaded until a fraction of a second after the object is displayed, leading to a flash of colour which is a little distracting. Using Option 2 gets around this issue however, because the headlight objects and textures are always loaded upon swtiching to an external view, and are displayed by translating the relevant object along the Y axis instead, conditional upon the value read via the pluginstate[i] variable. As these textures are always loaded in an external view, StateFunction commands alone can be used in the rear vehicle.
Incidentally, the RotateYFunction = 3.1416 lines simply rotate the relevant objects 180° around the Y axis (the value is in radians, rather than degrees).
What I need to do next, is add interior fittings such as seats, luggage racks, LCD TV screens, and so-on. I might make some more progress with the route itself instead though, as to be honest I could do with a break from modelling the minutiae of train objects for a while.
Tags: Animated Objects, Artwork, Cross-City South, Functions, openBVE, Screenshots, Videos
Posted in openBVE | 58 Comments »