openBVE logo
Project Status (21st April 2019)
Welcome to the Railsimroutes.net Blog, where I'll be posting progress updates, work-in-progress screenshots, information about the progress I'm making with active projects, as well as anything else I feel is worth mentioning. Hopefully more frequent updates here will make the wait for upcoming releases more bearable! News from 2008, all the way back to 2001, can be found in the News Archive.

Railsimroutes.net YouTube Channel My openBVE videos and other comments from users and myself can also be found via my YouTube channel.



Blog and Progress Updates


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
Horizontal Rule

Information Icon Note: Updated 21:40 BST

Horizontal Rule

openBVE v1.2.2 Released

openBVE LogoopenBVE 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.

Horizontal Rule

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.

Horizontal Rule

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.

Horizontal Rule

openBVE 3D cab screenshot 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.

Horizontal Rule

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.

Horizontal Rule

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 «)

openBVE and Saijou Line--click to enlarge openBVE and Saijou Line--click to enlarge

Information Icon 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 «

openBVE and Chashinai Railway (Misaki Line, 9000 Series train with ATC, TASC and ATO)--click to enlarge openBVE and Chashinai Railway (Misaki Line, 9000 Series train with ATC, TASC and ATO)--click to enlarge

Tags: , , , , , ,
Posted in openBVE, Site News | 8 Comments »



3D cab update for class 323 EMU now available for openBVE v1.2

Posted by admin on August 30, 2009 at 12:30 pm

I’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.

Horizontal Rule

openBVE 3D cab screenshot

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).

Horizontal Rule

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

Horizontal Rule

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: , ,
Posted in openBVE | 16 Comments »



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 pm

openBVE v1.1.1.0 (Development Branch), 3D cabs, and other stuff…

openBVE 3D cab / X-City South screenshot - see video belowThe 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. 🙂

Horizontal Rule
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*) «
» Link to YouTube page (High Quality) «

Horizontal Rule

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 v1.1.1.0/3D Cab/Cross-City South v1.4 screenshot--click to enlarge

openBVE / 3D Cab / X-City South v1.4 screenshot–click to enlarge

Horizontal Rule
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).

Horizontal Rule
The Base 3D Cab
Horizontal Rule
openBVE / 3D cab screenshot - please see video above

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.

Horizontal Rule
Speedometer and Brake Gauge
Horizontal Rule
openBVE / 3D cab screenshot - please see video above
Speedometer Needle Object (with day/night textures):

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

Horizontal Rule

Speedometer (100 mph):

[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:

Main Reservoir (range covers 7-8 bar, as per the 2D panel):

[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

Horizontal Rule
Combined Traction/Brake Controller
Horizontal Rule
openBVE / 3D cab screenshot - please see video above

The reverser is pretty straightforward, however this is what I’m using for the combined power/brake handle:

Combined Traction/Brake Controller:

[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

Class 323 Combined Traction/Brake ControllerThe 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:
Class 323 Combined Traction/Brake Controller Mesh
This is also the technique I used for creating the AC electric loco roof sections, by the way:
AC Electric loco roof section

Horizontal Rule
Horn Lever
Horizontal Rule
openBVE / 3D cab screenshot - please see video above
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.

Horizontal Rule
Other indicators
Horizontal Rule
openBVE / 3D cab screenshot - please see video above
For any other standard atsi plugin variable with two states (e.g. 0 and 1):

[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…

[object]
states = 3dcab\controls\dra.csv
position = 0, 0, 0
textureshiftyfunction = pluginstate[13] * 0.5

Horizontal Rule

Texture mapping in dra.csv object:

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.

DRA example

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:

Proving lights example
Horizontal Rule
Simulated Headlight Effects
Horizontal Rule
openBVE / 3D cab screenshot - please see video above

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:

Working Headlight (panel.animated file):

[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:

Working Headlights (csv object example):

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.
Horizontal Rule

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.

Horizontal Rule
Working TV Screens
Horizontal Rule
openBVE / class 323 interior screenshot - please see video above

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:

TV Screen Static Effect (Object 1):

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

Horizontal Rule

TV Screen Static Effect (Object 2):

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

Horizontal Rule

TV Screen Static Effect (Animation Function):

[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.

Horizontal Rule
Window raindrop effects
Horizontal Rule
openBVE / class 323 interior screenshot - please see video above

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:

Raindrop mesh--click to enlarge
Raindrop effect animation code:

[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…

Horizontal Rule
Pantograph spark and ground lighting effect
Horizontal Rule
openBVE / class 323 interior screenshot - please see video above

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:

Sparking effect:

[Object]
states = Class323_Spark_1.csv
position = 0, 0, 0
statefunction = if[mod[speed, 3] > 2.9, value == 0, -1]
refreshrate = 0.03

Horizontal Rule
Flashing Tail Light
Horizontal Rule
openBVE / Watford Junction to Rugby screenshot - please see video above

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:

Flashing Tail Lamp Animation:

[Object]
States = TailLamp_1a.csv
Position = 0, 0, 0
StateFunction = if[mod[time, 0.55] > 0.08, -1, 0]

Horizontal Rule
Signal Ground Lighting
Horizontal Rule
openBVE / Watford Jn to Rugby screenshot - please see video above

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:

Signal ground lighting animation function (assumes .Section 0;2;3;4 commands and 4 aspect signals):

[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…).
Horizontal Rule

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 !

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:

Tags: , , , , , , ,
Posted in openBVE | 25 Comments »



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

Posted by admin on June 16, 2009 at 12:04 am

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

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:

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:

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:

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

Tags: , , , ,
Posted in openBVE | 4 Comments »



openBVE v1.0.6.0, Cross-City South v1.4 Updates

Posted by admin on May 24, 2009 at 11:50 pm

New 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:

openBVE v1.0.5.0, ATS-Sn/P Test Route, Smooth Transparency option enabled--click to enlarge
Smooth transparency [openBVE 1.0.5.0]
openBVE v1.0.5.0, ATS-Sn/P Test Route, Smooth Transparency option enabled--click to enlarge
Smooth transparency [openBVE 1.0.6.0]

Similarly, here we have the » Chashinai Railway «:

openBVE v1.0.5.0, Chashinai Railway, Smooth Transparency option enabled--click to enlarge
Smooth transparency [openBVE 1.0.5.0]
openBVE v1.0.5.0, Chashinai Railway, Smooth Transparency option enabled--click to enlarge
Smooth transparency [openBVE 1.0.6.0]

For a detailed explanation about this solution, please see michelle’s » Developer’s Blog «

Horizontal Rule

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.

Horizontal Rule

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:

openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge
Horizontal Rule

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:

openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge
Horizontal Rule

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:

openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge
Horizontal Rule

Lastly, I’m also updating the pointwork so it’ll be up to the standard of Watford Junction to Rugby:

openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge openBVE v1.0.6, Cross-City South v1.4, Smooth Transparency option enabled--click to enlarge
Horizontal Rule

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: , , , , ,
Posted in openBVE | 8 Comments »



Jaunty Jackalope and openBVE

Posted by admin on April 25, 2009 at 8:42 am

Ubuntu 9.04 “Jaunty Jackalope” (which is a Linux distribution for any dear readers who may not be particularly au fait with the wonderful world of operating systems…), has just been released. With this version, it’s possible to install a seperately packaged, unofficial version of openBVE maintained by Paul Sladen (currently at v1.0.2.0; the » official openBVE « release is at v1.0.3.0 at the time of writing) via the ‘Applications’ > ‘Add/Remove…’ menu item (I haven’t used Kubuntu in a while and I’ve forgotten what the equivalent in KDE is). A specially prepared, public domain version of the Cross-City South route (v1.31.03) is also installed automatically when openBVE is installed via this method, along with a reduced functionality (plugin DLLs don’t work on non-Windows operating systems), public domain version of the class 323 which Steve over at » trainsimcentral « also kindly donated.

X-City South v1.31.03 is just a cut-down version of the public release available from this site, with the copyright files removed and alternative backdrops added, and fewer route files; I prepared it so that openBVE could be considered for inclusion in Ubuntu’s list of installable open source applications, as for a game engine to be accepted, it requires some equally permissively licenced game data to be supplied with it. Eventually the Ubuntu X-City South package should be identical to the official X-City South v1.4 package once it’s been released, and I hope to send any updates to Paul so the Ubuntu version is kept up-to-date; by implication, X-City South v1.4 will be entirely copyright free as well. Any copyright material, like the Birmingham New Street announcement audio files, will be available as an optional extra only.

After installing the latest ATi Catalyst drivers (and, at last, my Radeon HD 2600 Pro graphics card finally works with Ubuntu), it was nice to see openBVE running in Linux myself, and with decent framerates too. The framerate in the first screenshot of XCS v1.31 was 80 fps (90 fps in Win XP), and in the third screenshot, showing XCS v1.4, 17 fps (20 fps in Win XP). The latter screenshot actually includes more animated trees than will feature in the final XCS v1.4 release though, and in-cab, I was seeing up to 30 fps):

openBVE v1.0.2.0 running in Ubuntu 9.04--click to enlarge openBVE v1.0.2.0 running in Ubuntu 9.04--click to enlarge openBVE v1.0.2.0 running in Ubuntu 9.04--click to enlarge

I admit there was also some momentary fascination after I turned on Ubuntu’s “Extra” visual effects option which enables hardware accelerated graphical effects to be applied to windows, and watched my X-City South v1.4 development route carry on running at 25-30 fps while I distorted and bounced the poor helpless openBVE window around the desktop (sorry I wasn’t able to capture a screenshot, just a low quality video still):

openBVE v1.0.2.0 running in Ubuntu 9.04

I may be finding that framerates are just a bit lower than in Windows XP, but they’re still good and I enjoy using openBVE in Ubuntu instead. The application’s forms all rendered nicely although the loading and error dialogs remained visible once the SDL window was created; I’ll carry on testing it and see if I notice any other issues.

Any Windows users who might be considering trying openBVE on Ubuntu, should remember that plugin DLLs don’t work natively on non-windows operating systems, so various functions in BVE 4 trains like TPWS won’t work. For this functionality to be available in Linux, you’ll need to use openBVE with Wine instead, which isn’t quite as easy to set up (I haven’t personally had time to try it yet, but as shown in this » YouTube video of the Northern Line « for example, if you do go to the trouble, it’s well worth it).

Information Icon Edit (1st May ’09): I have tried and succeeded in getting openBVE v1.4.0.1 running with Wine and Mono 2.4 for Windows in Ubuntu since this entry was published, and it was quite easy after all. See the comments for more. 🙂

Tags: , , , , , ,
Posted in openBVE | 11 Comments »



Cross-City South 7-Zip trial

Posted by admin on April 19, 2009 at 7:55 am

In 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.

openBVE Help and Information
openBVE Help and Information
BVE Help and Information
BVE Help and Information

Information IconEdit: 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: , ,
Posted in openBVE, Site News | 8 Comments »



Platform Generator utility released

Posted by admin on April 19, 2009 at 7:45 am

Alan 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 screenshot--click to enlarge
openBVE / Cross-City South v1.4 plus 323 screenshot

Tags: , , , ,
Posted in openBVE | 2 Comments »



Cross-City South v1.4 Progress

Posted by admin on March 24, 2009 at 12:22 am

I 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?! Emoticon Wink However, the project is going well, and I should have some more news soon.

Tags: ,
Posted in openBVE | 4 Comments »



Animated Exterior Car Objects

Posted by admin on February 26, 2009 at 10:00 pm

openBVE / X-City South screenshot - see video belowAs 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. Emoticon Smile 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.

Horizontal Rule
Video: Demonstration of class 323 animated exterior car objects (work-in-progress)

» Link to YouTube page (HD – best quality) «
» Link to YouTube page (High Quality) «

Horizontal Rule

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 screenshot--click to enlarge

openBVE / Cross-City South v1.4 plus 323 screenshot–click to enlarge

Horizontal Rule

Horizontal Rule
Rotating Wheelsets
Horizontal Rule
openBVE / Class 323 screenshot - please see video above

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:

RotateXFunction = value + mod [(speedometer * delta), 2.765] / 2.765 * 3.14 * 2

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:

Not goodRotateXFunction = value + speedometer * 0.05949986086344

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.

CorrectUpdate

Thanks to a certain mathematically adept someone, I now have a new formula which is better in terms of performance and ease of use:

CorrectRotateXFunction = value + delta * speedometer / WHEEL_RADIUS_IN_METRES
Horizontal Rule
Animated Doors
Horizontal Rule
openBVE / Class 323 screenshot - please see video above

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:

Right door animation (Updated):

[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.

Horizontal Rule
Animated Window Reflections
Horizontal Rule
openBVE / Class 323 screenshot - please see video above

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:

Window reflection animation:

[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…

Horizontal Rule
Interior Illumination
Horizontal Rule
openBVE / Class 323 screenshot - please see video above

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.

Horizontal Rule
Animated Pantograph
Horizontal Rule
openBVE / Class 323 screenshot - please see video above

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):

Pantograph animation (updated 5th July 2009):

[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]]

Horizontal Rule
Animated Wipers and Working Headlights
Horizontal Rule
openBVE / Class 323 screenshot - please see video above

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:

Wiper animation (code for left wiper only; reverse the signs of each occurrence of ‘power[]’ for the right wiper, excluding the one in the last TranslateYFunction command):

[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.

Horizontal Rule

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):

Head and tail lights:

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. Emoticon Smile

Tags: , , , , , ,
Posted in openBVE | 58 Comments »