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


New Video Uploaded: 3D Cabs (openBVE v1.1 Development Branch), 323 Interior, Watford Junction to Rugby Hi-Res

Posted by Anthony Bowden on 5th July 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 | 24 Comments »



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

Posted by Anthony Bowden on 1st June 2009 at 11:40 pm

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

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

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

Some atmospheric » Chashinai Railway « screenshots:

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

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

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

Horizontal Rule

Randomisation in RSR-UK Routes

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

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


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

Server Upgrades

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

Tags: , , , , , , ,
Posted in openBVE, Site News | 1 Comment »



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

Posted by Anthony Bowden on 24th May 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 »



Animated Exterior Car Objects

Posted by Anthony Bowden on 26th February 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 | 44 Comments »



openBVE’s Object Animation

Posted by Anthony Bowden on 26th November 2008 at 10:00 pm

If you’ve visited the » openBVE Homepage « recently, you’ll know that Michelle has released openBVE v0.9.1.5 and DemoRoute1, and these introduce animated objects to the community for the first time. While the new animation capabilities are just a preview, aren’t supported yet and are subject to change, I’ve been playing with the new functionality to see what might be possible. As the animation capabilities may be altered in future versions of openBVE, none of these X-City demonstrations should be considered final.

In Michelle’s DemoRoute1 we can see an animated departure screen, clock, an A320 flying overhead, flashing level crossing light, moving cars and simulated interaction, and an escalator. These are the kinds of features I’d like to add to Cross-City South v1.4 as well, as they’re just brilliant–but rather than show you what Michelle has already demonstrated, I thought I’d start with something a little different. In the video below, I’ve used .PointOfInterest commands, and placed animated sheets of rain to create the effect of precipitation (achieved via texture shifting), moving clouds achieved via the same method, and animated water on the canal.

Note: openBVE will have built-in rainfall in future, so using animated objects to create this effect won’t be required eventually; but I was curious to see if such effects were possible with animated objects alone.

Download openBVE / X-City South video - please use the YouTube links to the rightVideo: openBVE v0.9.1.7 and X-City South v1.4 (textures not finished yet)

Animated clouds, falling rain, moving water, and a passing train

Note: This video is now included as part of a compliation on YouTube.

« [YouTube “High Quality” version] | [YouTube “High Definition” version]

Class 150 objects from » Network West Midlands «

A note on the passing train–this is just a fun experiment, and animated objects aren’t really suited for this purpose as the animated object doesn’t follow any track, but rather a direction defined in the animated object file; I probably won’t include it in the final release route as there’s no sound accompanying the train. However, the technique is suitable for trains passing over or under bridges for example, like in the » IIYAMA Line 2060 « route, where the train is some distance from the player, moving across the screen (Lichfield Trent Valley on the Cross-City North route could also be a suitable location for such an effect):


openBVE screenshot

The moving water in the above X-City South v1.4 video also needs some work, but involves a static canal object with ordinary texture, and then two animated, texture shifted alpha-enabled surfaces overlaid; one moving left to right (to match the cloud’s direction of movement), and the other moving along the Z-axis. When combined, they make the water appear to ripple slightly if you look closely for a few seconds, particularly where the tree reflections are visible on the right.

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



Lighting, Shading and Contrast

Posted by Anthony Bowden on 20th November 2008 at 9:00 pm

In this first entry, I’m going to talk about shadows, contrast and realism. Recently, I’ve been playing around with improved shadows and lighting effects, which are now possible thanks to » openBVE’s « support for daytime/nightime texture transitions, as well as support for alpha-enabled PNG images which can be used as textures. Michelle and I briefly discussed time-of-day texture transitions and headlight glow effects recently, and it occured to me that not only could a glow effect be achieved with openBVE’s extended commands, but soft shadows could also be created. In these two screenshots of the Class 323 EMU on Cross-City South, you can see how these openBVE capabilities facilitate a rather nice effect in-game, which I feel adds to the visual quality and immersiveness considerably:

openBVE screenshotopenBVE screenshot

A while ago, » Daniel Beardsmore « and I were discussing my Watford Junction to Rugby screenshots, and that while they looked good, there was just something… not quite right about them. He hit the nail on the head when he mentioned contrast–which is simply too low in my textures–resulting in a somewhat washed out appearance to many of the scenes:

openBVE screenshot

While helping with some of the » now resolved « openBVE plugin compatibility issues recently, I spent some time enjoying… sorry, testing… the rather stunning Japanese » ATS-Sn/P Test Route «, and afterwards, the deficiency in my own textures became even more obvious, as the ATS-Sn/P Test route’s textures have greater contrast and more shading, creating a much richer and more realistic and compelling visual experience, despite both routes using photo-realistic textures:

openBVE screenshot openBVE screenshot

The effect of shadows and contrast is also shown to good effect in the Joetsu Border and South routes (available here: » http://gri.s60.xrea.com «):

openBVE screenshot openBVE screenshot

Adding better shadows to Watford Junction to Rugby helps considerably, although I need to up the contrast further still, particularly in the vegetation textures, and add more shading to the track textures:

openBVE screenshot openBVE screenshot openBVE screenshot openBVE screenshot openBVE screenshot openBVE screenshot

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