Posts Tagged ‘Cross-City South’

openBVE v1.2.10 released, Cross-City South v1.31.11 update, and UkTrainSys v0.3.1.9 now available, with enhanced AWS and TPWS simulation, diesel multiple unit support, and various improvements

Posted by Anthony_B on December 25, 2010 at 23:15

openBVE v1.2.10 released

openBVE LogoopenBVE has now reached v1.2.10, which marks the first stable release to feature cross-platform .NET support. This is great news for non-Windows users, who can benefit from the extended functionality, system simulation, and the AI support feature which new .NET plugins can provide. Please head over to the official openBVE homepage to download the latest stable release, as well as to read about the latest developments. Also, don’t forget to read the changelog, for a summary of various other changes which have taken place since v1.2.8.2.

openBVE users who also use my Cross-City South v1.31 route, should also note that the route is now updated for the new version of openBVE, and it also requires the latest version of the new UkTrainSys plugin for full simulation the class 323’s safety systems to be available, because I’ve now altered the route’s .Beacon commands to take full advantage of the enhanced realism of the new UkTrainSys AWS and TPWS implementation. More details can be found below…

UkTrainSys v0.3.1.9 now available, with enhanced TPWS and AWS simulation, diesel multiple unit support, and a few other enhancements

Railsimroutes LogoI’ve just released the next version of the UkTrainSys cross-platform plugin, which is now up to version 0.3.1.9. This latest release includes initial support for diesel multiple units. Other new features include the Vigilance Device reduced cycle time, far more realistic AWS and TPWS simulation, and several other improvements. Here follows some more information about the various features:

Diesel engine support:

UkTrainSys now has diesel engine support, which means that the plugin can be used with trains which rely on Simon Gathercole’s UKSpt.dll, such as Sprinters or the class 170 (although diesel locomotives are supported too, apart from ammeters and wheelslip protection – I’ll add these later). I’ve decided to recreate much of Simon’s complex diesel engine model, rather than the simple model. This means that UkTrainSys includes the requirement to hold the engine starter button down until the engines are running, as well as simulating the starter motor, and a percentage likelihood that the engine will stall on starting. I’ve also adapted the AI Support feature, so that the AI driver can start the diesel engine, even if it stalls, as well as restart the engine if it is shut down at any point.

Vigilance device with reduced cycle time:

It’s now possible to set an option within the UkTrainSys.cfg file, which enables the Vigilance Device reduced cycle time of 45 seconds, when the power notch is 6 or 7.

Miscellaneous changes:

Firstly, I’ve now implemented a solution for the infamous anomalous multiple-arm phenomenon, which a few people have commented on, when openBVE’s AI driver is enabled for the first time in a driving session. You shouldn’t see any weird, freaky stuff going on in the cab any more, provided that you don’t look over your shoulder, at least. 😉

Secondly, when traction power is not meant to be available, openBVE’s internal reverser position is now set to neutral, whereas previously, only the power handle was set to zero. This means that regenerative braking is disabled when passing through a neutral section, for example.

Thirdly, I’ve also expanded the range of optional Data values which can be recognised via .Beacon 50 commands. UkTrainSys can now be informed of an upcoming terminal station, and this instructs the UkTrainSys AI Support implementation to leave the reverser alone after stopping, so that UkTrainSys and openBVE aren’t continually squabbling over their respective desires where the reverser handle position is concerned. .Beacon 50 can now also be used to instruct the AI Support to lower the pantograph or stop the diesel engine upon the next station stop, after the doors have opened. .Beacon 50 can also be used to inform UkTrainSys of an upcoming neutral section, now. As UkTrainSys will implement a tap changer in future, and a tap changer can take over 30 seconds to run down to notch 0, this beacon can be placed quite some distance ahead of a neutral section. When this neutral section beacon instruction is encountered, UkTrainSys begins monitoring the train’s speed, along with the distance to the neutral section, and decides when exactly to return the power handle to notch 0. UkTrainSys also checks to see if the tap changer is enabled or not, and if it is, the time taken to run down the tap changer is taken into account.

Lastly, the AI guard and related beacons, have been expanded to accommodate multiple stopping points at a station, and UkTrainSys selects which beacon to act upon, depending upon how many cars the player’s train has.

Train Protection and Warning System (TPWS):

For this release, I’ve also significantly increased the realism of the Train Protection and Warning System (TPWS) implementation. With Simon’s previous generation of plugins written for BVE 4, the TPWS simulation seemed to be realistic to the end user, but it didn’t always work in a way which truly reflects how the real TPWS works. Thanks to openBVE, as well as openBVE’s API and documentation, I’ve been able to create a TPWS simulation which works just like the real thing, while also being backwards compatible with routes which were written with Simon’s BVE 4 plugins in mind.

For example, the implementation of the Overspeed Sensor System in Simon’s plugin, was a simplification of how the real OSS works. Simon’s plugin recognises the optional Data parameter of a single .Beacon 44002 or .Beacon 44003 command, as a maximum permissible speed. If the train’s speed exceeds the set speed which is encoded in the .Beacon command’s Data parameter, then the TPWS issues an OSS brake demand. This simplified system works well enough, however it doesn’t take acceleration or deceleration curves into account, for example, and it’s not how the real system works. My OSS implementation, works exactly like the real system.

UkTrainSys recognises a track mounted OSS as comprised of a pair of induction loops (beacons) – the arming loop, and the trigger loop. Where Simon’s plugin expects to read a set speed from only the trigger beacon, UkTrainSys can read a unique frequency from each beacon’s optional Data parameter instead. The permissible OSS set speed, is now determined by the distance between the induction loops, just like in reality. Furthermore, UkTrainSys implements a pair of on-board OSS timers, and the OSS timeout period can be set in the UkTrainSys.cfg file, to suit a passenger or freight train – there is no need to edit a route file to accommodate both types of train. Each timer acts independently of the other, being armed by different arming frequencies, and this allows for realistic nesting and interleaving of induction loops, as well as realistic system behaviour when travelling backwards over induction loops.

The Trainstop Sensor System (TSS) implementation has also been made more realistic. With Simon’s plugins, a single beacon acts as the TSS installation, but with the real system, a pair of induction loops form the TSS – as with the OSS, there is an arming and trigger loop. UkTrainSys recognises TSS arming and trigger induction loops based upon frequencies specified via the optional Data parameter of the .Beacon commands. When the plugin encounters a TSS arming beacon, one of two TSS detection states is activated, and only if a TSS trigger beacon with a suitable frequency is encountered while the arming beacon is still within “detection range”, will the TSS be functional. If a TSS trigger beacon is encountered without an arming beacon having activated the system, then the trigger beacon is ignored, as with the real system. Again, this means that induction loops can be nested and interleaved, and prototypical reverse direction behaviour can be simulated.

Automatic Warning System (AWS):

I’ve not only improved the realism of the TPWS simulation, but I’ve also implemented a more realistic implementation of the Automatic Warning System (AWS), as well. With Simon’s previous generation of BVE4 plugins, and the routes designed for use with them, a single beacon command is used to represent an AWS magnet. The new UkTrainSys AWS simulation also supports this legacy behaviour, but UkTrainSys can also now respond to an AWS permanent magnet, together with an AWS electromagnet. Both are defined via separate .Beacon commands, with a distinction between the magnetic polarity of the magnets defined via the optional Data parameter. This allows for a fully realistic AWS simulation, using only one beacon type, whether associated with a signal or a speed restriction.

When UkTrainSys encounters an AWS permanent magnet, the AWS is primed, the AWS sunflower instrument goes black, and a timeout period is started. If an energised AWS electromagnet is detected within this timeout period, then an AWS clear is issued (i.e. the bell/bing sound, and the sunflower instrument stays black). If no electromagnet is detected within the timeout period, then an AWS warning is issued when the timeout period expires, just like with the real AWS. This also allows for a slightly more realistic simulation of the AWS when travelling at very low speed over an AWS magnet associated with a signal showing a green aspect. At very low speeds, the AWS can be primed by the detection of the permanent magnet, but the timeout period can expire before the electromagnet is detected, which leads to an AWS warning being issued, even though the signal is green (Simon’s plugins also simulate this). However, with UkTrainSys, if you don’t cancel the AWS warning, it will actually clear itself when the electromagnet is detected, with the overall effect being an AWS warning horn followed by the bell/bing sound (assuming the electromagnet is detected before a brake demand is issued).

UkTrainSys also supports AWS suppression magnets, which are used on bi-directionally signalled lines. By inserting a suppression beacon before or after a permanent magnet beacon, an AWS inductor can be made to work in either a forward only direction, or backwards only direction. Should openBVE support networked tracks and bi-directionally signalled lines in future, this can far more easily allow for a fully realistic simulation of AWS under those circumstances.

A summary of the advantages of the new UkTrainSys TPWS and AWS implementation:

  • Acceleration and deceleration curves are taken into account when traversing a TPWS OSS;
  • TPWS induction loops can be nested or interleaved;
  • Passenger and freight trains can have their own OSS timeout periods set, with no need to edit a route file to accommodate either train type;
  • A single beacon type can be used to represent all kinds of track-mounted AWS installations;
  • By defining the AWS permanent and electromagnets separately, a fully realistic AWS simulation can be achieved;
  • AWS suppression is supported;
  • The above features allow for fully realistic behaviour while travelling forwards or backwards over AWS inductors and TPWS loops;
  • It’s more fun when the simulated systems work in the same way as the real systems, with the same advantages and disadvantages of the real systems;
  • Lastly, it’s more future proof. Should openBVE support networked tracks or bi-directional signalling in future, I think the best way to ensure compatibility or ease of code maintenance, is to make the simulated systems work with the same principles, trigger events, inputs, outputs, and variables, as the real-world systems.

Disadvantages:

  • Placing the TPWS related beacons is a little more difficult, but it’s really no big deal if the documentation is read, and you have a calculator, as well as the ability to type in a few numbers (which any openBVE developer has to be able to do anyway). 😉
  • UkTrainSys can interpret the new frequency-based beacons in new routes, and it can interpret old speed-based beacons in existing routes (UkTrainSys is fully backwards compatible with legacy beacon commands in these routes), but Simon’s BVE 4 plugins won’t recognise the induction loop frequencies (or magnetic polarities) when encountered in new routes designed for openBVE and UkTrainSys.
  • Two beacons now make up an AWS magnet associated with a signal, but it’s only slightly more trouble than using one beacon.

UkTrainSys configuration files for openBVE trains

I’ve also released a set of configuration files which can be used with a variety of DMUs and EMUs available from trainsimcentral. If you are a Linux or Mac user, and want to enjoy some UK diesel traction in openBVE, then you can simply extract the latest UkTrainSys.dll into any of the supported TSC train folders, and then extract the appropriate configuration files into each folder. If you are a Windows user, then you might like to experiment with the new fully realistic AWS and TPWS implementation within the UkTrainSys plugin (on existing routes to test the backwards compatible legacy behaviour, and on either Cross-City South v1.31.11 or the AWS/TPWS test route available below, to test the new simulation). I would certainly appreciate any feedback. Please bear in mind that the guard’s buzzer sounds might play more times than they should – UkTrainSys expects the buzzer sound file to contain only one buzz sound, whereas these trains may contain two buzzes in the relevant sound file.

For more information and the latest downloads, plus complete documentation and example code snippets, please visit the UkTrainSys project page:


Railsimroutes.net - UK Train System Cross-platform .NET Plugin banner

UK Train System (UkTrainSys)
Cross-platform .NET Plugin

[v0.3.1.9 now available]

AWS and TPWS test route for use with UkTrainSys (or any supported train class), and Cross-City South v1.31.11 update

Railsimroutes LogoAs with the enhanced neutral section and Automatic Power Control feature included in the last UkTrainSys release, for this latest version, I’ve prepared a test route so that the new AWS and TPWS implementation can be tested. I’ve also updated Cross-City South to v1.31.11, and the openBVE route files now utilise the realistic AWS and TPWS simulation features of the UkTrainSys plugin.

The AWS and TPWS test route is around 7 km in length, and demonstrates a variety of AWS and TPWS installations. Each signal is held at red until a preset time, and you can either drive safely or commit SPADs to test that AWS and TPWS are working correctly. There is also a signal and a permanent speed restriction located near to each other, which requires the co-location of a TPWS OSS associated with the signal, plus another OSS associated with the permanent speed restriction. The OSS induction loops at this location are interleaved, and you can test how this works when the signal is red or otherwise. You can also practice driving at normal and extremely slow speeds over AWS magnets, to see how the dual magnet detection works, especially when a signal aspect is green. There is also a single track section, which is equipped with AWS suppression magnets, and you can drive forwards and backwards along the route to test this feature, as well.

Screenshot Screenshot

The AWS and TPWS test route. On the left, is an AWS inductor, comprised of a permanent magnet, suppression magnet, electromagnet, and protection ramps for bi-directional running. On the right, is a pair of co-located TPWS OSS installations, with interleaved induction loops. Each OSS arming loop starts one of two independent OSS timers within the UkTrainSys plugin.

Download: AWS and TPWS test route [86 KiB – also includes updated neutral section test route]
Once extracted, the route file can be found here: Railway\Route\rsr_uktrainsys_test\

Screenshot
Note: Requires Cross-City South v1.31.11 (update | full version), along with UkTrainSys v0.3.1.9 installed with a suitable train.

The unrefurbished class 323 EMU together with the combined 3D cab and UkTrainSys v0.3.1.9 update is recommended.

Also remember that you need openBVE v1.2.10 in order to use this latest UkTrainSys .NET plugin, and also remember that this is an alpha release of the plugin, so it may have some issues, but they’ll be addressed as development progresses.

Updated AWS inductor screenshots – Cross-City South v2.0 and Watford Junction to Rugby

While coding the latest UkTrainSys updates, I updated the AWS magnet objects which I’m using in my work-in-progress routes. As UkTrainSys now recognises both AWS permanent magnets and electromagnets separately, I thought I’d separate out these parts of the existing AWS magnet into their own respective object files, so they can be easily assigned to beacon or freeobj structure indices, as appropriate. Here are some examples…

In the first screenshot, is an AWS permanent magnet associated with a fixed distant signal, which has a protection ramp on both sides, as this is a stretch of bi-directional line. In the second, the same applies, except an AWS electromagnet beacon is also in place. In the remaining screenshots, are permanent magnets associated with permanent speed restriction advance warning boards, which have only one ramp, as these tracks are uni-directional. These objects will be included in the UK Railway Infrastructure Object Library, however you can actually download and use them now, as they are included with the AWS and TPWS test route (see above).

Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot

Also, here are some examples of full AWS permanent and electromagnet installations on the Watford Junction to Rugby route:

Screenshot Screenshot Screenshot

West Coast Main Line Video

Railsimroutes LogoLastly, anyone with an interest in the real West Coast Main Line, might like to take a look at a video which I uploaded to YouTube recently, which features the Old Linslade and Leighton Buzzard areas – two locations I’m modelling in my representation of the Watford Junction to Rugby section of the WCML. Those of you who noticed or commented on the Train Operated Warning System I demonstrated in my last openBVE video (the rotating orange lights with audible warnings), can now watch the real system in action.

This footage was filmed in October 2004 to assist me with developing this part of the route (only in standard definition unfortunately), but you’ll see a couple of class 87s which were still in service at the time. Also featured, are ubiquitous Pendolinos, class 321 EMUs, as well as classes 58, 60 and 66 diesels, and class 90 and 92 25kV AC electric locos. Don’t forget to change to 480p resolution for the best image quality.

YouTube video screenshot

And finally…

Lastly, I’d just like to wish visitors a happy and peaceful Christmas, and say thanks for all the interest shown in my work so far. 🙂

UkTrainSys plugin update; enhanced simulation of neutral sections and Automatic Power Control, neutral section test route released, and new screenshots showing improved Brecknell Willis Highspeed pantograph models and new sunset backdrops

Posted by Anthony_B on November 26, 2010 at 21:25

Railsimroutes LogoFirstly, I just wanted to say thank you for the positive reception with which the UkTrainSys cross-platform .NET plugin has been received; this was very nice to see! Based on feedback, I’ve now updated the UkTrainSys plugin, so that the AI driver will operate the Driver Reminder Appliance en-route. I’ve also implemented an enhanced neutral section and Automatic Power Control simulation, but first, a little background information might be in order…

Neutral section (phase break) installations

For those who don’t know, a neutral section (or phase break), isolates different phases of the power supply being fed to the overhead electrification system from each other. This is accomplished by inserting a short length of insulated material into the contact wire, which the pantograph head can still slide across at speed. In the UK, I gather these insulated sections are typically comprised of glass-fibre rods with ceramic collars threaded on to them, with the total length of the neutral section itself, being only around 4 metres.

At either side of the neutral section, are a pair of track mounted magnets, called APC (Automatic Power Control) magnets. Whenever an APC receiver on an electric train detects these magnets, the APC system flips the state of the air-blast/vacuum circuit breaker (ACB/VCB) between the pantograph and the on-train traction equipment, interrupting or connecting the supply from the pantograph and overhead line.

Thus, when a train approaches the first pair of magnets prior to a neutral section, the ACB/VCB is commanded open, such that there is no power being drawn from the overhead line when passing through the neutral section (this prevents the pantograph from drawing an arc and accidentally connecting one of the power supply phases to earth – the neutral section cantilever/support tubes are earthed so that the two separated phases aren’t connected in the event of an arc). When the train passes the second pair of APC magnets after the neutral section, the ACB/VCB is commanded closed again, and power from the overhead line can be taken.

See the illustration to the left, for an overview of the installation. The yellow arrow indicates the direction of travel; the red line indicates which parts of the contact wire are still live, even if the Automatic Power Control system has opened the train’s air-blast/vacuum circuit breaker, and finally, the blue line shows the location of the neutral section itself.

Updated UkTrainSys cross-platform .NET plugin (v0.3.1.3), with enhanced neutral section and APC simulation

Railsimroutes LogoAnyway, an updated version of the UkTrainSys plugin is now available together with the class 323’s 3D cab (version 0.3.1.3 – downloads can be found further down), and I’ve made some improvements to the simulation of electric trains. Firstly, I’ve modified the pantograph behaviour – when the pantograph is rising or lowering, pressing the Up/Reset or Down button has no effect until either operation is completed. Pressing the Up/Reset button when the pantograph is already raised, will just re-close the air-blast/vacuum circuit breaker (ACB/VCB) if it’s open.

Secondly, and more importantly, I’ve significantly improved the simulation of neutral sections, and Automatic Power Control. Now, the APC magnets and the actual neutral section itself can be declared separately. This means that every time the correctly defined APC magnet beacon is passed, it will flip the current state of the train’s ACB/VCB. This however, does not affect the actual availability of line voltage from the contact wire.

What this means, is that if the ACB/VCB is tripped open by an APC magnet, but your train stalls because you weren’t travelling fast enough, you can now manually re-close the ACB/VCB by pressing the pantograph up/reset button. If the train’s pantograph is not within the separately defined 4 metre long neutral section, you can take power from the overhead supply once again, and move the train backwards or forwards as appropriate, so you can try to build up enough speed in order to coast through the neutral section without stalling, this time. If the train’s pantograph does stop within the neutral section, then line voltage is not available, even if you try to re-close the ACB/VCB. In this case, you have to hope that your train is on a gradient, such that if the brakes are released, the train will roll out of the neutral section due to gravity. If this isn’t possible, then you have some explaining to do!

There is a more interesting aspect to this, though – with UkTrainSys, you can now drive backwards through a neutral section, not just forwards, and still have the full simulation experience. On a unit like the 323, (I think) the APC receiver is located on the bogie beneath the pantograph, on the second coach. The beacon receiver on an openBVE train is located at the front of the train, however – where the driver is (thereabouts). If travelling forwards, then when the front of the train passes an APC magnet beacon, this triggers a point-based event, and a check can then be performed, which will only carry out the ACB/VCB operation when the train is so many metres beyond the beacon; i.e the distance between the front of the train, and the location of where the APC receiver is supposed to be. But what happens if the train is travelling backwards? The location where the APC receiver is supposed to be, will pass the APC beacon before what is now the rear of the train (where the driver and openBVE’s beacon receiver are located), will pass the beacon, and hence trigger a beacon related event. This obviously won’t work properly, as the action triggered by the beacon, won’t happen until it’s beneath the driver’s position, which is too late when travelling backwards.

So, the UkTrainSys plugin now includes what I’m calling the “Offset Beacon Receiver Manager” (OBRM). Whenever the UkTrainSys plugin passes an APC magnet beacon while travelling forwards, the plugin stores information about the beacon in an array. The stored information includes the beacon type, it’s location, it’s optional data, and an offset distance which equates to the distance between the front of the train, and the location of where the APC receiver is supposed to be. The OBRM continually checks whether the train is currently travelling forwards or backwards, and whether the APC receiver location has passed the actual beacon location, taking direction of travel into account. When the trigger point occurs, the OBRM issues a command to the APC system, rather than doing this via the SetBeacon() method. The only other thing to mention, is that jumping to a station clears the encountered beacon history, so you actually have to drive forwards over a beacon for it to be stored by the OBRM.

This means that you can drive an EMU like the 323 through a neutral section backwards, but it also means that a Driving Van Trailer (DVT) with an electric loco pushing a rake of coaches from behind, can respond to the APC magnets at the correct time and location, whether travelling forwards or backwards, too.

Download:

Screenshot
Important: Remember that you need openBVE v1.2.9.20 in order to use the new UkTrainSys .NET plugin, and also remember that this is an alpha release of the plugin, so it may have some issues, but they’ll be addressed as development progresses.

Also, the UkTrainSys changelog can be found here: UkTrainSys project page.

Short neutral section test route, for use with UkTrainSys and the class 323 with 3D cab

Railsimroutes LogoI’ve prepared a short test route so that you can try this new feature. The route includes two neutral sections; the first on level track, and the second on an incline. Using the class 323 with the latest version of the 3D cab update and UkTrainSys plugin, you can drive through the neutral sections and play with the new behaviour.

Screenshot Screenshot
The neutral section test route (the white board gives notice of the neutral section)

On the first run, just pass through a neutral section as normal – it should seem pretty much identical to the neutral section experience in Network West Midlands, using Simon Gathercole’s BVE 4 UKMUt plugin.

On the second run, you can do things differently though – approach a neutral section slowly, and let your pantograph (where the APC receiver is located) pass the first pair of APC magnets, such that the VCB is tripped open, and then apply the brakes and come to a halt. You’ll note that the Line Volts indicator extinguishes, the VCB indicator light illuminates, and that you can’t take traction power – your train appears stuck. However, when the 323 has stopped, you can now reset the VCB by placing the reverser to Neutral and pressing the ‘2’ key – you should hear the VCB closing with a thud. Provided your pantograph is in contact with a live section of overhead line, the Line Volts indicator will illuminate again, and the VCB indicator will extinguish. Now you can take traction power. But what happens if your train is so close to the dead section of overhead line, that you can’t accelerate enough to coast through the neutral section, without stalling? You have to go to the external view by pressing ‘F2’, so you can see what side of the neutral section your pantograph is on, and choose whether to move the train forwards or backwards, such that you can take a “run up” at the neutral section, next time.

If you do stop with your pantograph in contact with the neutral section itself, then there is no line voltage, and resetting the VCB or lowering and raising the pantograph won’t change this. If you are on level track, your train is stuck there (you can cheat, and jump to another station, though). If however, you are on a gradient (the second neutral section is on an incline), then you can move the reverser to Neutral, and move the power handle to Off, and then release the brakes. Your train will now begin to roll backwards due to gravity (in reality, you would need permission from the signaller to do this). When your pantograph makes contact with a live section of overhead line again, the Line Volts indicator will light up, and you can take traction power again. If you continue rolling backwards, you’ll pass the APC magnet prior to the neutral section – this will trip open your VCB, despite heading away from the neutral section, and you’ll have to apply the brakes, stop the train, move the reverser to Neutral, and press the ‘2’ key to reset the VCB. Once done, you can take power, and go back as far enough as is required, to build enough speed in the forward direction to successfully coast through the neutral section.

Screenshots showing new sunset backdrops, and improved Brecknell Willis Highspeed pantograph models

Railsimroutes LogoFinally, I’ve been busy taking photos of sunsets again this week, and I just wanted to post a few more screenshots of the latest enhancement to the Cross-City South v2.0 and Watford Junction to Rugby routes. I’ve also, finally, got around to improving the Brecknell Willis Highspeed pantograph model, which now includes a full 3D pantograph head, with textures used throughout:

Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot

I hope you like the latest developments. 🙂

New cross-platform .NET plugin for UK trains released, class 323 3D cab and Cross-City South v1.31.09 update, openBVE v1.2.9 development branch, .NET plugins and AI support

Posted by Anthony_B on November 20, 2010 at 07:30
Screenshot
Updated: 22nd November 2010 @ 00:15 UTC (FEVF railway and steam loco update – see below)

New cross-platform .NET plugin for UK trains (EMUs currently), 323 3D cab / X-City South v1.31.09 updates, and openBVE v1.2.9 AI support

Railsimroutes LogoAfter the latest development branch of openBVE (v1.2.9 series) was released last month, I started work on a new open source, cross-platform plugin written in C#, which I wanted to be a suitable alternative to the plugin currently used by the class 323 EMU. Simon Gathercole’s UKMUt.dll has served me well since BVE Trainsim 4 was released, but after the latest openBVE developments, I knew the time had come to create a new plugin which could be developed to take advantage of the new possibilities which openBVE now provides. I also wanted to create a plugin which could be updated as openBVE develops, either by myself, or with help from other programmers and developers, so that the community doesn’t need to experience plugin-related problems for too long.

This new plugin is called UkTrainSys (short for UK Train System of course); it is modular in design, and aims to simulate a variety of systems that trains which run on the UK’s rail network may be equipped with. Initially, I’m working to recreate as much of the functionality found in Simon Gathercole’s range of BVE 4 plugins as necessary, although some new features are included as well. So far, the plugin features the following:

▪ Automatic Warning System (AWS);
▪ Train Protection and Warning System (TPWS);
▪ Driver Reminder Appliance (DRA);
▪ Vigilance Device;
▪ Traction and brake interlocks;
▪ Battery which can be discharged, recharged and overloaded;
▪ Overhead supply;
▪ Pantograph and vacuum circuit breaker;
▪ Automatic Power Control;
Power supply and electrical system circuit breakers (more for future use);
▪ In-cab blower;
▪ Head and tail lights;
▪ AI guard for station stop monitoring and buzzer codes;
AI Support which assists openBVE’s AI human driver in handling systems simulated by the plugin automatically
  (including support for visible in-cab driver’s hands and arms).

Note: Wipers, windscreen rain effects and diesel engine simulation are yet to be started. I’m also planning for various other systems to be inlcuded in future, such as TPWS+ (TPWS Plus), RETB, ERTMS, random failures, and a tap changer.

Users of trains which include plugins developed for BVE 4, will likely know that when openBVE’s AI human driver is enabled, the AI driver may not always be able to operate a plugin enabled train correctly, simply because openBVE has no way of knowing what systems are simulated by a plugin, and even if openBVE did know what systems were simulated, it still wouldn’t know what to do with them. Hence, the new UkTrainSys plugin uses openBVE v1.2.9’s AI Support feature, which lets the plugin assist openBVE’s AI human driver with operating the systems which are simulated by the plugin.

When you start a route, and enable openBVE’s AI human driver by pressing Ctrl+A, while using the latest release of the class 323’s 3D cab in combination with the UkTrainSys plugin (see below for the download), you will see the AI driver’s arms and hands reach out for the controls, and interact with them whenever necessary. The AI human driver will run through the startup and self-test procedure for you, pressing the AWS reset button, raising the pantograph if required, and setting the taillights and headlights. The plugin takes the time-of-day into account, so the correct headlight setting is chosen based upon the in-game time (and updated as the day goes on). The AI driver will deactivate the DRA before departure, respond to the guard’s buzzer signal with a buzzer response, cancel AWS warnings as they occur, respond to TPWS brake demands, re-raise the pantograph if it is lowered mid-journey, and so-on. The UkTrainSys plugin’s AI Support will also respond to a new beacon type, which instructs the AI driver to blow the horn at certain locations.

Screenshot
Note: Both the 323 3D cab and UkTrainSys plugin were updated on 21st November 2010 @ 01:30 UTC
Issues with TPWS Isolation, and the driver’s arms remaining visible after turning off openBVE’s AI driver, are hopefully resolved…
Inset image

I’ve updated the class 323’s 3D cab with new animations which require the UkTrainSys plugin (now included in the download), and I’ve also equipped Cross-City South v1.31 with the aforementioned new beacon type, so the AI driver can sound the horn automatically.

  • The updated 323 3D cab and pre-configured UkTrainSys plugin can be downloaded here [2.3 MiB]
    (The unrefurbished class 323 from Trainsimcentral is required first – the 3D cab and plugin update should OVERWRITE any existing files in the “Cl323 Unrefurb_openbve” folder).
  • If you are already using Cross-City South v1.31.071, you can download a small update to v1.31.09 link out of date [95 KiB]

If you don’t already have the route, aren’t sure which release of Cross-City South v1.31 you already have, or want to see details about the latest changes, please download the full version and visit the Cross-City South v1.31 project page instead.

Screenshot
Important: Remember that you need openBVE v1.2.9.15 in order to use the new UkTrainSys .NET plugin with AI support, and to enjoy the new 3D cab features! Also remember that this is an early alpha release of the plugin, so it has some issues, but they’ll be addressed as development progresses.

The UkTrainSys plugin also has it’s own project homepage, where just the plugin, source code, current and planned feature list, changelog and documentation can be found. Train developers with an interest is using the UkTrainSys plugin, now or in future, may wish to visit the following page and read the documentation.

Note: If you have downloaded the updated class 323’s 3D cab with the pre-configured UkTrainSys plugin, remember that you should not overwrite the UkTrainSys.cfg file included with the class 323 3D cab update!


Railsimroutes.net - UK Train System Cross-platform .NET Plugin banner

UK Train System (UkTrainSys)
Cross-platform .NET Plugin

[Alpha release now available]

I’ve also been working on some new backdrops for both Cross-City South v2.0 and Watford Junction to Rugby. I was happy with the daytime backdrops which you’ve all seen already, but the sky portions of the last set of sunset and sunrise backdrops were entirely hand-made (replacing low resolution BVE4-era images), and I wanted to replace these with photographic textures of a similar quality to the daytime backdrops instead. Fortunately, there as been some favourable weather during the past few days, so I was able to take some nice photographs. Here are the new sunrise and sunset scenes, shown with the 323’s latest 3D cab update, and the openBVE v1.2.9 / UkTrainSys plugin enabled AI support feature in use:

Screenshot Screenshot Screenshot Screenshot

Recent openBVE v1.2.9 development branch updates

openBVE LogoTowards the beginning of the November, openBVE v1.2.9.11 was released (now up to v1.2.9.15), and Michelle introduced a new set of experimental preprocessing directives. These take the form of $if(), $else() and $endif(), and obviously, these allow for conditional parsing of blocks of code within a route file. This can be an alternative means of achieving what can be accomplished with the $Include directive, which is handy when only a small block of code needs to be conditional.

Personally, I’m finding this very handy for such features as temporary speed restrictions (TSRs). In this scenario, I can randomly introduce TSRs at different locations, so routes can be rather more fun to drive. At the start of the file, we can declare a variable $Sub(0), which has a random number assigned from within a certain range, and then use the value stored in $Sub(0) as a condition which is used by $if() directives. If the value held by $Sub(0) is zero, then the code within any $if() block which depends upon this variable is not used, but if the value is greater than zero, then it is. By using the $else() directive, we can show something else if the TSR is not to be included, such as discarded sections of old rail, left there by the track workers after they made their repairs and removed the TSR. Spate indicators could be handled in a similar way.

For example:

; Declare a variable which stores a randomly generated number…
$Sub(100) = $Rnd(0;1)

With Structure
.FreeObj(0) tsr_warn_20mph.csv
.FreeObj(1) tsr_20mph.csv
.FreeObj(2) tsr_terminate.csv
.FreeObj(3) discarded_rail_sections.csv
.FreeObj(4) track_workers.csv

.Beacon(0) portable_aws_magnet.csv

With Route

; Enclose the route commands related to a TSR within $if()/$else()/$endif() directives…
$if($Sub(100))
    3000, .Beacon 44001;0,    ; portable AWS magnet
$endif()

$if($Sub(100))
    3183, .Freeobj 0;0,    ; 20 mph TSR advanced warning board
$endif()

$if($Sub(100))
    4200, .Freeobj 0;1, .Limit 33;0,  ; commencement of 20 mph TSR
$else()
    4305, .Freeobj 0;3;5,    ; no TSR so show discarded old rails instead
$endif()

$if($Sub(100))
    4400, .Freeobj 0;2, .Limit 97;0,    ; termination of TSR
$endif()

It’s also possible to use these new preprocessing directives elsewhere in the route file. For example, a different object could be assigned to a free object index, depending upon a condition being true. You can also nest these new preprocessing directives; i.e. place $if/$else()/$endif() selection statements within other selection statements, for example:

; a nested $if()/$else()/$endif() selection statement
$if($Sub(100))
    4200, .Freeobj 0;1, .Limit 33;0,  ; commencement of 20 mph TSR
    $if($Sub(101))
        4205, .Freeobj 0;4;-4,  ; track workers shown based upon another $Sub variable but only if the TSR is shown
    $endif()
$else()
    4305, .Freeobj 0;3;5,    ; no TSR so show discarded old rails instead
$endif()

Support for these new preprocessor directives is still experimental, and not guaranteed to be included in the next stable release of openBVE, however I’ve not encountered a problem with the feature thus far, at least with regard to the things I’d like to use the feature for, and it’s really very easy to use. Some more testing would be beneficial, but I hope the feature stays, and I’ll certainly be making use of it if it does.

Other news – Chashinai .NET plugin updated with AI support, new Network West Midlands video, and FEVF railway updates

Information IconIn case you weren’t aware, the new cross-platform .NET plugin which is used by the trains which run on the Chashinai Railway, was updated earlier this month to include AI support, which is a lot of fun, especially with the Chashinai 9000 series train complete with ATS-Sn, ATS-P, ATC and TASC. As with the new UkTrainSys plugin, the updated Chashinai Railway plugin’s AI support assists openBVE’s AI human driver in operating the safety systems, so you can enable the AI human driver and even watch the startup procedures handled by the AI driver. The plugin source code is available as well, of course.

Screenshot Screenshot
Chashinai Railway Takahagi Line (9000 series train, ATS-P, AI driver enabled)

I also wanted to quickly mention that Steve Green has posted a short YouTube video of the upcoming Network West Midlands 2010 update, demonstrating animated level crossing barriers interlocked with the signalling, together with updated objects such as a new AWS magnet, which I thought looked really good:

Several other videos of the upcoming NWM release can also be found on Steve’s YouTube channel, and screenshots can be found on the Network West Midlands website.

Screenshot
Update: 22nd November 2010 @ 00:15 UTC

Lastly, I wanted to show something a little bit different – Roberto Benini, developer of the FEVF (Ferrovia Elettrica Val di Fiemme) railway, has released an animated Mallet Henschel & Sohn 6036 steam loco for openBVE, which is well worth a look, and I noticed that the FEVF Railway itself now has some moving trains at Cavalese station too. The route and train can be downloaded here:

Roberto Benini has also posted a YouTube video of the new loco:

openBVE v1.2.8 and increased rendering speed, openBVE v1.2.9 development branch with cross-platform .NET plugin support, Cross-City South v2.0 update, and openBVE performance with budget versus high-end CPUs, and discrete versus on-board graphics

Posted by Anthony_B on October 14, 2010 at 00:20
Screenshot
Updated: 16th October 2010 @ 22:50 UTC

openBVE v1.2.8 released, with significant rendering speed improvements

openBVE Logo openBVE v1.2.8 was released recently, which includes a reorganised renderer which can provide significantly higher framerates than the old renderer found in v1.2.7.4. This is achieved by rendering opaque faces (i.e. faces without alpha), using OpenGL display lists. There are two ways to enjoy the performance increase; if you currently have low framerates, then the boost could make routes more enjoyable, however if you already have high framerates, then you can increase the viewing distance significantly so that you can see much further away from the train, whilst maintaining similar framerates to those you are already used to seeing. You can visit the Official openBVE Homepage for the download and to read the changelog, as well as read this thread on the openBVE forum for more information.

Here are some framerate and image quality comparisons which I conducted on my main development PC (Core 2 Quad Q9650 / GeForce GTX 260), showing some notable improvements:

On the left is openBVE v1.2.7.4, and on the right, the new v1.2.8:

Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot

openBVE’s default viewing distance is 600 metres, however, here are some screenshots showing what the upcoming Watford Junction to Rugby route looks like with an increased viewing distance of 2000m. This particularly benefits the straight sections of this route, allowing you to see more than one upcoming signal at the same time. Thanks to the new renderer, it’ s possible to significantly increase the viewing distance, while still having very playable framerates on a good computer with reasonably detailed exterior car objects:

Screenshot Screenshot Screenshot Screenshot Screenshot Screenshot

Most people are reporting better performance with the new renderer, however if you notice any previously unseen stuttering with the new renderer and detailed routes, I’d really appreciate it if you could contact me with some information about your computer’s specifications and the route being used, as it might be useful for me to know, when I draw up recommended system requirements and openBVE settings, particularly for the upcoming Watford Junction to Rugby project. Thanks.

openBVE v1.2.9 development branch released, enabling support for cross-platform .NET train plugins

openBVE Logo The latest version 1.2.9 development branch of openBVE, includes support for .NET assemblies (plugins), which enables cross-platform plugin compatibility, just as with openBVE itself. With previous versions of openBVE, and of course BVE Trainsim, only Win32 C++ plugins were supported, which limited their use to the Microsoft Windows platform, leaving Linux and Mac users to rely on openBVE’s built-in safety systems only, with a great deal of functionality found in plugin enabled trains unavailable. With .NET assemblies, these can be written in a variety of languages which target the .NET framework, such as C# or Visual Basic .NET, and users of non-Windows operating systems can also enjoy enhanced train functionality once new .NET plugins start to appear.

Anyone with at least some programming experience can visit the .NET assembly train plugin section on the official openBVE website, to download template projects to help you get started. If you’ve already developed a Win32 C++ plugin previously, you might prefer to look at the “C# project files (for updating from Win32 plugins)” download specifically. Anyone interested in making general comments can do so in this thread on the openBVE forum, while anyone wanting to help improve the design of the plugin API by making suggestions, can visit this thread instead.

I’ve started writing a replacement .NET plugin for the class 323, although I’ll design it such that it could be used with other trains too. I’ll release the new .NET assembly and publish the source code when there’s something worth showing, unless someone else writes a plugin which is sufficiently good enough, before me.

Screenshot
Edit (16th October): I forgot to mention that some .NET assemblies are already available; the plugins for the 1000, 2000 and 9000 series trains used by the Chashinai Railway have been ported to C# by odakyufan, and you can download them here (at the bottom of the page). These might be helpful if you’d like to see some example source code and structure, although bear in mind that openBVE .NET plugin support is still experimental at this stage, so you may need to check for both openBVE and plugin updates in future.

Of course, if you’re a more advanced non-Windows user and just want to enjoy driving trains, then you too can now experience some of the best in-cab system functionality available for openBVE. Here’s the openBVE v1.2.9.2 development release, with Chashinai Railway’s Misaki Line, and the 9000 series train with fully functional .NET plugin enabled safety systems, running in Ubuntu 10.04 32-bit Linux (itself running within a virtual machine under Windows 7 64-bit, in this case):

Screenshot
Chashinai Railway Misaki Line, and 9000 series train
with .NET plugin enabled safety systems, used
with openBVE v1.2.9.2 in Linux

Birmingham Cross-City South v2.0 update

Railsimroutes LogoIf you’ve been keeping an eye on the news infobox at the top left of the blog (or my Projects page), you’ll have noticed that I’ve been continuing work on the pointwork along the Cross-City South route, and I’ve also been working on updating the pointwork on the approach to Birmingham New Street as well. All pointwork between Alvechurch and Five Ways is now finished, and ready for animation to be applied prior to release. The pointwork on the approach to Birmingham New Street is a rather difficult task though. At this location, there are single and double slips, switched diamond crossings and three-way points, all crammed into a rather small space, and all located on quite a sharp curve. There are also a variety of point machines, including electric, hydraulic clamp-lock, and Westinghouse electro-pneumatic types, as well as cast manganese steel and conventional frogs. I like to model these kinds of details, so I’ve spent quite some time working on this area – I’m not finished yet, but will be shortly. Cross-City South was originally designed with a 25 metre block length in mind, however the pointwork doesn’t fit neatly, so much of the pointwork is contained in two large set-piece objects instead. I always felt that this task was going to be the hardest part of the Cross-City South v2.0 upgrade, as it’s rather tedious and difficult (and indeed I was right), however for me, the route wouldn’t be complete without it, as I want Cross-City South v2.0 to be of the same standard as Watford Junction to Rugby, so I’ll endure the pain.

Here’s a screenshot of one of the Birmingham New Street pointwork objects:

Screenshot

At first glance it doesn’t look like much, but on closer inspection, it’s actually rather detailed and intricate. This object features 4076 vertices, and loads 9 textures. Each rail is carefully texture mapped, to ensure that the Pandrol rail fasteners are as closely lined up with the underlying sleepers as possible, and that the inside of the railhead as depicted in the texture, matches the mapping on the object. Depending upon the location of a rail within the point assembly, different kinds of rail fasteners are depicted. If you examine the existing equivalent object in Cross-City South v1.31, you’ll notice that that old object is afflicted with z-fighting issues; I’ve taken special care to ensure that this doesn’t happen with the new version. In the case of the cast manganese steel frogs, these feature a combination of 3D geometry and use of a photographic texture of the prototype, to create the desired 3D effect:

Screenshot Screenshot Screenshot

Each fishplate is also modelled in 3D, and these are also responsible for much of the vertex count, incidentally – this also means that they can be easily removed to create a lower detail object, however. Each point blade has a texture depicting baseplates beneath it, and where the tie bar assemblies will go, oil-stained ballast is featured. The object has also been designed in such a way, that animating any of the point blades is very easy to do in future. I’ll post a screenshot of the object within the route, once I’ve finished the second of these pointwork objects, improved the appearance of New Street station a bit, and finished some other things.

Prior to starting on the New Street pointwork updates, I also spent some time working on the Kings Norton area. In the existing Cross-City South v1.31, I didn’t lay any track in the sidings to the west of the station, and instead, I included a simple texture depicting a pair of tracks on a flat surface to the right of the loop siding. Cross-City South v1.31 was designed for BVE Trainsim 2 and 4 with their cab-only view and lower resolution, of course, so there wasn’t much point in modelling the extra tracks. With openBVE, it’s well worth adding them, however:

Screenshot

Here are some screenshots of the updated pointwork and track geometry at Kings Norton (I’ll replace these points with the more recently installed concrete sleeper versions soon):

Screenshot Screenshot Screenshot

You might have noticed that scenery has been improved a little in those previous three screenshots; I’m currrently adding the embankment/tree alpha shadow technique I developed for Watford Junction to Rugby, throughout the Cross-City South route as well. Here are a few more screenshots showing the latest scenery enhancements I’ve been working on, as well as little things like extended length sleepers beneath electric point machines, and disused trackbeds:

Screenshot Screenshot Screenshot Screenshot


Budget versus high-end CPUs, discrete graphics cards versus on-board graphics, and openBVE/Watford Junction to Rugby performance

Information IconSometimes I see people talking about poor framerates or image quality in 3D games which they use, such as openBVE, or others. Upon finding out about the system specifications in use, the cause of the low performance, in the case of Windows 7 and Vista, is often due to inferior graphics drivers being used (i.e. those bundled with Windows by default or obtained via Windows Update, rather than from the graphics card manufacturer). However, the other frequent cause of unsatisfactory performance, is a slow graphics card, and sometimes, a slow CPU.

Personally, I’ve used less-than-stellar graphics cards in my desktop PCs for use with openBVE, but being a geek, I’ve never used on-board graphics solutions (integrated on the motherboard) in a desktop PC before, as I’ve always dismissed them as not being up to much. It occurred to me that perhaps I was being too hasty in writing integrated graphics off, as I’ve never actually tried to play games on such a solution in a desktop PC myself. The same goes for budget CPUs, such as those in Intel’s Celeron or AMD’s Sempron lines – I’ve never been interested in them as I’ve always viewed them as merely cut-down versions of “real” fully-featured CPUs, such as those in Intel’s Pentium and Core product lines, or AMD’s Athlon and Phenom lines.

So, I thought I’d test openBVE on a contemporary budget PC to find out what it was capable of, with the cheapest of Intel’s newer CPUs that I could find – a socket LGA 775 based Celeron E3300 with the Wolfdale-3M core (the same core used in Core 2 E7xxx and Pentium Dual Core E5/6xxx processors), which runs at 2.5 GHz with 1MB of Level 2 cache. This CPU is combined with the cheapest of all graphics solutions – on-board graphics integrated onto the motherboard – in the form of Intel’s “Graphics Media Accelerator” X4500, which is a part of the G41 Express “Eaglelake” chipset. I was also curious to find something out – if a choice has to be made between a better CPU or a better graphics card, which is the best to go for where openBVE is concerned?

I ran the hardware in a few configurations, and tested openBVE’s performance with my upcoming Watford Junction to Rugby route. Here are the results, and in all cases, the best image quality that each graphics solution is capable of was selected, and in all except the last test (number 4), the following constants apply:

CPU: Intel Celeron E3300 @ 2.5 GHz
RAM: 2 GB PC-6400 DDR2 SDRAM (dual-channel configuration)
Operating System: Windows XP Home Edition (32-bit)
openBVE version: 1.2.8 (Sharp transparency, 1920×1200 fullscreen, 600m viewing distance)

Two locations were used for measuring framerates: Watford Junction, and Bourne End Junction.

Test setup 1:

Graphics: Intel GMA X4500 (G41 Express Chipset, 128MB shared video memory) [Antialisasing: n/a, Anisotropic Filtering: 2x]

Framerates (fps)
Watford Junction 12
Bourne End Junction 9

Test setup 2:

Graphics: AMD/ATI Radeon HD 2600 Pro (256MB DDR2) [Antialisasing: 8x, Anisotropic Filtering: 16x]

Framerates (fps)
Watford Junction 34
Bourne End Junction 24

Test setup 3:

Graphics: NVIDIA GeForce GTX 260 (896 MB GDDR3) [Antialisasing: 16xQ, Anisotropic Filtering: 16x]

Framerates (fps)
Watford Junction 118
Bourne End Junction 101

Test setup 4:

Lastly for comparison purposes, here’s what we get when the GeForce GTX 260 is paired with a faster and more powerful quad-core CPU:

CPU: Intel Core 2 Quad Q9650 @ 3 GHz
Graphics: NVIDIA GeForce GTX 260 (896 MB GDDR3) [Antialisasing: 16xQ, Anisotropic Filtering: 16x]
RAM: 4 GB PC-6400 DDR2 SDRAM (dual-channel configuration)

Framerates (fps)
Watford Junction 179
Bourne End Junction 160

From these results, we can see that the budget Celeron E3300 is actually a rather nice CPU (which isn’t too surprising I suppose, given the architecture in use), and more than good enough for highly detailed routes such as Watford Junction to Rugby when paired with a decent graphics card. By comparing the two GeForce GTX 260 results, we can see that the speed of the CPU matters, however performance is also very clearly determined by the graphics hardware, and I would say that it’s the more important factor when it comes to openBVE performance. While I didn’t test the Core 2 Quad CPU with Intel’s GMA X4500 integrated graphics, I think it’s highly unlikely that framerates would have been much higher with this combination (overclocking the Celeron E3300 from 2.5GHz to 2.92GHz, made a difference of only around 1 fps when the integrated GMA X4500 was used). Intel’s on-board graphics is simply too slow, and the image quality is a bit poorer too, as there is no antialiasing, and the anistropic filtering level is rather limited (compare this screenshot using Intel’s GMA X4500, and a screenshot using the GeForce GTX 260). Intel’s driver control panel claims to support 16x anisotropic filtering, although openBVE/OpenGL reports that 2x is the maximum supported. The framerates don’t tell the entire story either though, as the much faster GeForce GTX 260 graphics card also gives more fluid and stutter-free performance than the budget Radeon HD 2600 Pro does. This is especially true when large textures, animated objects and higher levels of antialiasing and anisotropic filtering are used, as well.

So, if anyone is thinking of upgrading their computer soon and would like to run something like Watford Junction to Rugby, and money is tight, then my advice would be to bias your budget in favour of getting the best graphics card possible, while trying to keep some balance between the CPU and GPU in terms of what each is capable of. For the energy conscious amongst you, also bear in mind that newer generation graphics hardware tends to be more power efficient for a given level of performance. While quad core CPUs are nice to have, dual core CPUs are just fine, too. Indeed, running openBVE on only two of the four cores of the C2Q Q9650 CPU, by setting the affinity for the OpenBve.exe process accordingly, makes only a small difference to performance. Running openBVE on only a single core, even at 3 GHz, does result in performance being halved though, therefore I can’t recommend a single core CPU any more, when dual core CPUs are so common now. Of course, if you can live without the rich graphics or geometrical complexity of the latest openBVE routes, and only want to run less demanding examples, or those previously designed for BVE Trainsim, then even the cheapest contemporary hardware including on-board graphics, may suit your needs just fine where openBVE is concerned, if you don’t mind losing a little image quality and have realistic expectations.
For example: [ Uchibo – Intel GMA X4500 | X-City South v1.31 – Intel GMA X4500 | Saijou Line – Intel GMA X4500 ]