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


Animated digital station clocks for openBVE, and 3D cab for 1992 stock released at BVE Routes & Trains

Posted by Anthony Bowden on 14th May 2010 at 6:50 am

Animated digital station clocks

Railsimroutes LogoopenBVE/DemoRoute1 screenshot - click to enlargeI’m not sure if any other openBVE developers have attempted this yet, but a feature I’ve been wanting to add to my routes for some time now, is animated digital station clocks which show the actual in-game time. Of course, we’ve seen a very nice working analogue station clock featured in » DemoRoute1 « (see right), but a digital clock would be useful, too.

I studied the functions in DemoRoute1’s analogue clock .animated file, along with openBVE 1’s source code to see how the display of in-game time is handled, and eventually opted to use multiplication rather than division in my functions as per the animated object in DemoRoute1. You can find some details of the finished set of files below.


Animated digital clock shown in the openBVE Object Viewer utility -- click to download sample files

Animated 24-hour digital clock shown in the openBVE Object Viewer utility.
Sample files can be downloaded here.

Please feel free to download and use the above files if you’d like to adapt them for your own route, all you need to do is create an enclosure for the digits, and translate or resize the digits, to suit your own needs. The digital clock consists of an object which shows a single digit from a texture containing a strip of digits from 0-9, a separator, and a black background. The .animated file is as follows:

digital_clock.animated:

[Object]
States = back.csv
Position = 0, 0, 0

; Hours

[Object]
States = digit.csv
Position = -0.51, 0, 0
TextureShiftYFunction = 0.1 * floor[mod[time * 0.000277777777777778, 24] * 0.1]

[Object]
States = digit.csv
Position = -0.33, 0, 0
TextureShiftYFunction = 0.1 * floor[mod[time * 0.000277777777777778, 24]]

[Object]
States = digit_separator.csv
Position = -0.21, 0, 0

; Minutes

[Object]
States = digit.csv
Position = -0.09, 0, 0
TextureShiftYFunction = 0.1 * floor[mod[time * 0.0166666666666667, 60] * 0.1]

[Object]
States = digit.csv
Position = 0.09, 0, 0
TextureShiftYFunction = 0.1 * floor[time * 0.0166666666666667]

[Object]
States = digit_separator.csv
Position = 0.21, 0, 0
StateFunction = value == 0
RefreshRate = 0.5

; Seconds

[Object]
States = digit.csv
Position = 0.33, 0, 0
TextureShiftYFunction = 0.1 * floor[mod[time, 60] * 0.1]

[Object]
States = digit.csv
Position = 0.51, 0, 0
TextureShiftYFunction = 0.1 * floor[time]

Note: The purpose of the mod[] function used in displaying the hour digits, is to ensure that the displayed time wraps around back to 00 when passing midnight, rather than 24 or higher being displayed.

Here’s a screenshot of the above working digital clock, adapted for use in a prototypical structure at Kings Langley on the Watford Junction to Rugby route; note the displayed time on the clock, matching the in-game time shown at the bottom left of the screen:


openBVE / Watford Junction to Rugby screenshot showing animated digital clock - click to enlarge

openBVE / Watford Junction to Rugby screenshot showing animated digital clock — click to enlarge
Note: Station nameboard textures created using » Station Nameboard Generator v2 «
Horizontal Rule

3D cab for 1992 stock released

Information IconI also just wanted to briefly mention that a new openBVE 3D cab has been released for the London Underground 1992 stock, with animated features including a traction/brake controller, speedometer, and working in-cab CCTV monitor. Night-illuminated cab indicators and screens are also included, and the overall effect created by the cab is very nice, despite a couple of initial teething problems. The 3D cab is an add-on for the BVE4 1992TS, which needs to be installed first; both downloads can be found at » http://bveroutes-trains.co.uk «. A note on installing the 3D cab — at the time of writing, I noticed that the 3D cab download contains an incorrect folder structure, i.e. there’s no “1992TS” subfolder included, and the files could easily end up accidentally being placed in your Train folder directly instead, which won’t work, of course. You will need to be careful as to where you choose to extract the files. For further information, you might like to monitor » this thread « on the BVE Exchange forum.

Screenshot
openBVE / 1992 Stock screenshot
» Download from http://bveroutes-trains.co.uk «

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



Chashinai Railway April updates

Posted by Anthony Bowden on 14th April 2010 at 12:30 am

Information IconWhat I would consider to be one of the flagship routes for openBVE due to it’s innovation, and one of the most varied and enjoyable, namely » odakyufan’s Chashinai Railway «, has been updated. The Misaki Line from Tawaramoto to Hitachiomiya can now be driven back and forth in both directions (via seperate route files), which is fun. The ATC system has also been redesigned, such that a gradual, smooth brake curve is now implemented, along with a Rapid Mode which removes the smoothening for use in the rush hour where trains are more frequent and adhering to the timetable is harder. Driving the Chashinai 9000 Series train with ATC, TASC and ATO activated is one of the most enjoyable things which can be done with openBVE, so I’d strongly recommend that you give this a try — it’s well worth it. Instructions can be found » here «. Please also note that the source code for the plugins used by the Chashinai Railway’s trains is included within the train download, and I’d recommend that anyone considering plugin development in future, study the cleanly written, concise source code as well, of course bearing in mind that a move to cross-platform .NET plugins will occur in future. Incidentally, publishing the source code for plugins is something I would like to see more train developers doing in future, and certainly something I will be doing in future (I’ll be writing a new cross-platform .NET plugin for the new class 323 of course), once » openBVE 2 « is in a more advanced stage of development.

Moving road vehicles have also been added together with traffic sounds, shown to best visual effect on overbridges, I think particularly on the Koriyama Line (also bi-directional), Takahagi and Ishinden Lines, and vehicles can be seen travelling parallel to the railway between Shirosato and Motegi on the Misaki Line as well. The use of texture shifting functions here, enables vehicles to appear as though they’re travelling along the road, despite it’s apparent gradient and directional changes. I’ll be doing something similar at Watford Gap and other locations on the Watford Junction to Rugby route, using a technique developed for 3D vehicles by odakyufan, » details of which can be found here «. Other details, such as beacons correctly aligned with sleepers and track are taken care of too, as I’ve tried to do with AWS magnets in my routes. You’ll also find far more variation in the numbers of passengers waiting to board your train, which makes stations pleasing and fun to approach as there’s far more to see now; the recent changes to openBVE regarding the weight of the train increasing with passenger load and the effect this has on performance, can be used to good effect here (don’t forget to download the most recent version 1.2.6.1 of » openBVE « for this to work). Watch out for wheelslip depending on location, environmental or meteorological conditions too!

Developers might also be interested in taking a look at how the Chashinai Railway’s route files have been prepared. openBVE’s $Include directive has been used extensively, with much greater efficiency and flexibility now possible.

Please visit » The Web Presence of Odakyufan « to download the latest release of Chashinai Railway, and also » this thread on the openBVE forum «, where additional screenshots, information, details and benefts of $Include can be found. This is sophisticated, high quality and beautiful work, and I look forward to seeing more in future.

Images captured at 1680×1050, with smooth transparency and 16xQ anti-aliasing and 16x anisotropic filtering
(Please hover over any thumbnail image for a description)

About to pick up additional passengers waiting to join the train at Izumozaki North on the Misaki Line, with ATC indicating a clear line ahead. [Click to enlarge] Animated road vehicles crossing the overbridge at Kawarada station where the Ishinden and Uchiike Lines join together, as the warmth of the rising sun adds ambience the scene. [Click to enlarge]
openBVE / Chashinai Railway screenshots
Download from » The Web Presence of Odakyufan «
Horizontal Rule

Railsimroutes Projects

Railsimroutes LogoI know haven’t posted any updates regarding my own projects for some time, about which I can only apologise. I have a couple of features which I want to be working on for » openBVE 2 « first, however when I have time spare I’m also working on implementing another feature for both of my routes, and I’ll post some screenshots of this once I’m happy with how it all looks. More to follow fairly soon…

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



openBVE 2 Renderer Demo released, a new direction for me, some views on openBVE 2, and the release of openBVE v1.2.6.0

Posted by Anthony Bowden on 15th March 2010 at 8:00 am

openBVE 2 Renderer Demo released, and a new direction for me

openBVE LogoBefore I talk about the new openBVE 2 Renderer Demo, I just want to announce that aside from developing my routes, I’m also now working with Michelle as a C# programmer, and I’m actively participating in the development of openBVE 2. So far, apart from various discussions, I’ve worked on adapting openBVE 1’s .X object parser as a loading-stage plugin for the new program. So, while you’re using the program, if you have any problems regarding X format objects created via the BVE Structure Viewer (the output from this tool is what openBVE effectively supports), then you can probably point the finger of blame at me. 😉 Just to remind and reassure readers, I am still developing my routes, and I haven’t abandoned them!

Horizontal Rule

The openBVE 2 Renderer Demo

openBVE LogoAs many of you will know, openBVE 2 has been in development for some time, and I’m pleased to say that a demo of openBVE 2’s new renderer is now available for download. Unlike it’s predecessor, openBVE 2 is modular — many of the functions which were previously carried out within the program, such as loading and parsing routes or objects, or brake system simulation, is now carried out by plugins instead. This means that openBVE 2 is extensible in a way which openBVE 1 is not. For example, with openBVE 1, adding support for a new 3D object format, would require modification of the core program itself, and a new release. But with openBVE 2’s extensible architecture, support can simply be added via a new plugin, which means the core program need not be modified or recompiled. Clearly, this is a much better design in the long term.

The new renderer demo is intended for advanced users and developers only, and the main purpose of the demo is to test the performance of openBVE 2’s new renderer in comparison with openBVE 1’s, on a variety of computer systems. Indeed, no train simulation features are actually included at this stage, and not all visible features of routes, such as backdrops or animated objects, are accomodated yet.

It would be greatly appreciated if you could download and test the new renderer, and report your experiences; for example, what framerates you see, what viewing distance you find yourself liking to use, and what performance you achieve when equivalent settings are used in both the openBVE 2 Renderer Demo and openBVE 1. Hopefully you’ll find that framerates using openBVE 2’s renderer are far higher.

You can visit the openBVE Renderer Demo page for the download, and please read the information presented there carefully: » http://openbve.trainsimcentral.co.uk/openbve2.html «

Please also consider posting your feedback in » this thread on the openBVE forum «, or send some feedback via e-mail to Michelle. Alternatively, you can leave some feedback in a comment on this blog entry or e-mail me, and I’ll pass your feedback on to Michelle. It would be helpful if you could include certain information, such as the following:

  • Your processor model and/or speed (e.g. Intel Core 2 Duo E8400 @ 3GHz, AMD Phenom II X2 545 @ 3.0GHz, etc…)
  • Your graphics card model (e.g. NVIDIA GeForce GTS 250, ATI Radeon HD 5670, etc…)
  • The amount of RAM you have (e.g. 2GB)
  • What operating system you’re using (e.g. Windows 7 64-bit, Ubuntu 9.10 32-bit, etc…)
  • The settings within in your settings.cfg file (found in the Binaries subfolder of the openBVE 2 Renderer Demo)
  • Your video card driver’s image quality settings (e.g. 16xQ anti-aliasing, 16x anisotropic filtering)
  • The framerates you encounter while running the openBVE 2 Renderer Demo, and openBVE 1, with equivalent settings
  • Lastly, don’t forget to take into account, the information on the openBVE 2 Renderer Demo download page…

You can find some help regarding identifying your graphics card model on » this page «. Where video driver settings are concerned, you can read » this page «. Windows users can often just press Windows Key + Break to find out CPU model and speed, amount of RAM, and operating system. Michelle is very busy, but if you would like to send some feedback and find yourself unsure as to what to do, then I’d be happy to help you. 🙂

Horizontal Rule

I’m delighted to say that all the routes I’ve tried, benefit greatly from openBVE 2’s new renderer. Not only are framerates higher, but the viewing distance can be increased significantly as well. 🙂 This is also good news for those of you waiting for Watford Junction to Rugby. For example, take the highly detailed Bourne End Junction area, which contains nearly a kilometre of 60mph crossovers between the fast and slow lines, lots of complex overhead line equipment, and plenty of track and lineside detail. With a viewing distance of 3000m (yes, 3 kilometres :)), in openBVE 1, the framerate here is dragged down to a measly » 19 fps « . But with openBVE 2’s renderer, I get an impressive » 155 fps « instead.

Here are some other examples of framerate improvements. For detailed specifications of the computers used in these tests, please » see here «.

Settings in openBVE 1:

Viewing Distance: [3000m]
Resolution: [1920×1200 fullscreen]
Image Quality: [Anti-aliasing: 16xQ, anisotropic filtering: 16x]
vSync: [Off]
Interpolation: [Anisotropic Filtering]
Transparency: [Sharp]

Settings in openBVE 2 Renderer Demo:

Viewing Distance: [3000m]
Resolution: [1920×1200 fullscreen]
Image Quality: [Anti-aliasing: 16xQ, anisotropic filtering: 16x]
vSync: [False]
Interpolation: [5]
objectOptimization: [2]
blockClipping: [true]
All other settings: [Default]

Please note that all framerates were taken with the camera left at it’s initial position and orientation, to produce reliable and consistant results. In openBVE 1, the F3 external camera key was pressed once and left remaining at the start of the route, and the train moved to the end of the route via the Jump to Station menu, to ensure that no external car objects were lowering framerates.

Core 2 Quad Q9650 / GeForce GTX 260 based system:

Route: openBVE v1.2.5.1 (fps) openBVE 2 Renderer Demo (fps)
Ferrovia Genova-Casella 109 325
Chashinai Railway (Ishinden Line) 78 366
Saijou 117 423
Keio.net 220 327
Guaianazes-Estudantes High-Res 64 327
ATS-Sn/P Test Route 83 437
Uchibo 86 456
Network West Midlands 105 412
Watford Junction to Rugby 38 231

Athlon64 X2 4200+ / Radeon 2600 Pro based system:

Route: openBVE v1.2.5.1 (fps) openBVE 2 Renderer Demo (fps)
Ferrovia Genova-Casella 24 52
Chashinai Railway (Ishinden Line) 15 63
Saijou 17 67
Keio.net 40 88
Guaianazes-Estudantes High-Res 11 51
ATS-Sn/P Test Route 17 71
Uchibo 17 74
Network West Midlands 20 66
Watford Junction to Rugby 9 34

As you can see, on my systems, openBVE 2’s renderer is far superior to openBVE 1’s. Of course over time, more features will be added, and these will use some more of the newly available CPU and GPU resources and reduce peformance a bit. However, for those of you with slow computers, these extra performance reserves could mean that more detailed routes and trains could be usable than would be the case with openBVE 1.

Horizontal Rule

Some more framerate comparisons… openBVE v1.2.5.1 on the left, openBVE 2 Renderer Demo on the right. Remember that we’re interested in the framerate, not the graphical quality, at this early stage! Support for backdrops and smooth transparency will be added to openBVE 2’s renderer in due course. Also note that the viewing distance likely used by many openBVE users is the default 600 metres, but here, the viewing distance is 3000 metres instead.

openBVE v1.2.5.1 openBVE 2 Renderer Demo
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot
Screenshot Screenshot
All screenshots taken at 1920×1200 resolution, with openBVE’s anisotropic filtering setting enabled with sharp transparency/interpolation mode 5, and 16xQ anti-aliasing/16x anisotropic filtering (Core 2 Quad Q9650 at default 3GHz, and GeForce GTX 260 55nm)
Horizontal Rule

Community concerns regarding “openBVE 2”

Information IconI want to mention briefly the concerns regarding the name “openBVE 2” being changed soon, as architecturally, the new program is entirely different to openBVE 1, let alone BVE Trainsim, and I’ve noted some fears being expressed regarding the name change and widening scope of the project, particularly where add-on compatibility is concerned. However, I think these fears are being blown out of proportion. All openBVE content will still be compatible with the new program, so there’s no need to panic — add-ons aren’t going to suddenly become defunct. If any developers have concerns about this, please feel free to discuss them with either myself or Michelle.

I’ve also noticed people express concerns that openBVE 2 is going to be far more difficult to use and develop add-ons for. From the end-user’s point of view, and with cooperation from add-on developers (like me), it could actually be far easier, because it will be possible to install and uninstall add-ons from within the program itself, via it’s graphical user interface, rather than dealing with archiving utilities, self-extracting archives, different directory structures contained within them depending on which developer packaged them, and so-on. This kind of stuff is not easy for everyone, especially beginners, and it has to be repeated with every add-on. Where add-on creation is concerned, one of the benefits of the modular, plugin-based architecture, is that adding support for new file formats, such as file formats created by 3D modelling applications, becomes easier, not harder. It also means that route building tools, should they be made, can more easily interface with the host program via the new API. Those of us who prefer hand-coding methods, myself included, can still do what we’ve always done as well — it’s all a choice. Of course, with a program capable of rendering a vast world, it does become harder to make add-ons which fully exploit this new potential. Even I’m not exploiting this potential with my add-ons currently, but in future this may be highly desirable (just as I’ve upgraded my routes incrementally in the past), and the ability will be there for anyone who wants it, or who can envisage a use which even we haven’t even thought of yet. Anyway, the modular architecture makes it easier to build content creation tools, or provide support for existing tools and their file formats, which will make the growing possibilities easier to take advantage of. This does however, require some good programmers willing to devote some time to creating such tools, or writing plugins to support existing tools or formats; I recognise this, and I’m sure Michelle does as well. Lets try to be a little more positive about the future.

Horizontal Rule

openBVE v1.2.6.0 released

openBVE LogoLastly, openBVE v1.2.6.0 has also been released. Now is a good time remind ourselves that openBVE is a train simulator first and foremost, and with this latest release, the mass of the train is now affected by boarding passengers, which can slightly affect the performance of the train. A bug has also been fixed in the Jump to Station menu, and the Interior (Look Ahead) camera is now selected by default for 3D cabs (like the » class 323’s 3D cab « for example, or » Roberto Benini’s EM A1 3D cab «). There are various other changes too; please visit the » openBVE homepage « for more. 🙂

Tags: , , , , , , , ,
Posted in openBVE, openBVE 2, Site News | 4 Comments »



openBVE v1.2.5, Watford Jn. to Rugby progress, class 390 Pendolino, other developer’s add-ons, Cross-City South bugfix, and one million visits

Posted by Anthony Bowden on 31st January 2010 at 5:50 pm

openBVE v1.2.5.0 released

openBVE LogoopenBVE v1.2.5.0 was released a few days ago, and various changes have been made to openBVE since my last blog entry. In this release, the main form (i.e. the window for route selection, setting options, etc.) is smaller so that it can be used on smaller screen sizes (e.g. 800×600) or with larger fonts, and if the window is resized, the new size is saved between sessions. The player’s train now derails when passing the end of the track, as well.

Michelle has also written an impressive RIFF/RIFX/WAV PCM/ADPCM parser, which she’s ported from openBVE’s successor to openBVE 1. This removes the need for two dependencies, namely ALUT and SDL, and her parser supports a wider range of sampling rates. Other improvements recently, include a shortening of loading times for routes using detailed animated objects (which eventual users of the projects being developed here will appreciate). Also, there’s the addition of the $Include preprocessing directive which allows text in other files to be parsed in place of the directive in a route file (with random selection of multiple included files), and point-based turns (via the .Turn command) are smoothened out, which gives much more pleasing results. Please see » this thread « for more discussion about these latter features.

Head over to the » openBVE homepage « to try the latest v1.2.5.0 release, and you can read the changelog for further details. Remember that the » developer tools « have also been updated as well.

Horizontal Rule

Watford Junction to Rugby progress update

Railsimroutes LogoIt’s been quite a while since I posted any updates regarding my routes, so I thought you might like to know what’s happening with the Watford Junction to Rugby project this time. I’m relatively happy with the state of the permanent way and between-station railway related lineside objects, so I’m now implementing some more scenery enhancements, including improved under-bridge shadow effects, moving road vehicles, and lineside buildings. I’ve also, at last, started working on the stations and so far I’ve created new photo-realistic lamposts, photo-realistic 3D platforms, and various signs.

Previously, the underbridge shadows I’d implemented were simple untextured meshes with alpha applied via the SetColor command. In addition, I’ve now applied a small 8×8 pixel texture where the outer 28 pixels act as the transparent color, and the inner pixels are nearly black. When this texture is applied to the existing shadow meshes and the color adjusted accordingly, smoothly transitioned shadows can be achieved. I’ve also added deeper shadows to the sleeper textures to improve the appearance of the track, and added more blue colouration along with reducing the lightness of the railhead, to make the rails look a little more metallic. I’m also implementing shadows cast by platforms and embankments as well. The way in which I’ve implemented the latter can give the appearance of dappled sunlight caused by trees, and increases the effect of warmth created by sunlight and the realism of locations within cuttings, although this feature will be optional in the final release as there’s a possibility that it may incur a performance penalty on slow graphics cards. Lastly, I’ve added some new photographic backdrops which I’m experimenting with at the moment. Take a look at the following screenshots to see how the route is coming along (please note that there may be some inaccuracies, as the route shows trackwork or infrastructure as it was in different eras simultaneously at the moment):

openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge openBVE v1.2.5 and Watford Junction to Rugby--click to enlarge
openBVE v1.2.5, and Watford Junction to Rugby with new lineside buildings, station details, road vehicles, scenic shadows, and backdrops.
All screenshots taken at 1920×1200 resolution, with openBVE’s smooth transparency enabled, and 16xQ anti-aliasing/16x anisotropic filtering (Core 2 Quad Q9650 at default 3GHz, and GeForce GTX 260 55nm)
Horizontal Rule

Class 390 Pendolino

Railsimroutes LogoSome of you may remember that the class 390 Pendolino was given an » openBVE exterior car update « some time ago, thanks to Cramaboule. I’m pleased to announce that I’m now working with Cramaboule to produce some detailed exterior models of a similar quality to the class 323 I’ve demonstrated previously, along with a full 3D cab, so there will be some more nice looking rolling stock to run on Watford Junction to Rugby. I’ll post some screenshots as the models are developed, but for now here are some photos of what we can look forward to:

Class 390 Pendolino photograph (Milton Keynes, June 2005)--click to enlarge Class 390 Pendolino photograph (Milton Keynes, June 2005)--click to enlarge Class 390 Pendolino photograph (Cheddington, June 2005)--click to enlarge Class 390 Pendolino photograph (Old Linslade, October 2004)--click to enlarge
Class 390 Pendolino photos (1400×1050)
Horizontal Rule

Other more recent openBVE add-on releases

Information IconSince my last blog entry, some high quality openBVE add-ons have been released. Just in case anyone missed these releases, here are some screenshots and links to some excellent new add-ons with rather beautiful graphics:

Note: All screenshots taken at 1920×1200 resolution, with openBVE’s smooth transparency enabled, and 16xQ anti-aliasing/16x anisotropic filtering (Core 2 Quad Q9650 at default 3GHz, and GeForce GTX 260 55nm)
openBVE v1.2.5, FEVF Railway and EM A1 3D cab--click to enlarge openBVE v1.2.5, FEVF Railway and EM A1 3D cab--click to enlarge openBVE v1.2.5, FEVF Railway and EM A1 train--click to enlarge
FEVF Railway and EM A1 3D cab.
Homepage: » FEVF Railway «
Horizontal Rule
openBVE v1.2.5, mtrain HD v2.0 and Hong Kong Island Line--click to enlarge openBVE v1.2.5, mtrain HD v2.0 and Hong Kong Island Line--click to enlarge openBVE v1.2.5, mtrain HD v2.0 and Hong Kong Island Line--click to enlarge
mtrain HD v2.0 and Hong Kong Island Line.
Homepage: » winsome’s Studio « | » Hong Kong Island Line «
Horizontal Rule
openBVE v1.2.5, First Brno Track and CD163 plus coaches--click to enlarge openBVE v1.2.5, First Brno Track and CD163 plus coaches--click to enlarge openBVE v1.2.5, First Brno Track and CD163 plus coaches--click to enlarge
First Brno Track and CD163 plus coaches.
Homepage: » Brno BVE Website «
Horizontal Rule
openBVE v1.2.5, Guaianazes-Estudantes route and CAF 440 train--click to enlarge openBVE v1.2.5, Guaianazes-Estudantes route and CAF 440 train--click to enlarge openBVE v1.2.5, Guaianazes-Estudantes route and CAF 440 train--click to enlarge
Guaianazes-Estudantes route and CAF 440 train
Homepage: » BVE Brazil Fans «
Horizontal Rule

Upcoming openBVE projects to keep an eye on…

Information IconThere are a couple of new projects in the works which I’m personally very much looking forward to seeing, namely » Odakyufan’s « representation of the Odakyu Odawara Line running from Tokyo’s Shinjuku station, and the new Iida line currently being developed. The latter will of course be known to BVE users as one of Gaku’s classics (see my links page), but the new Iida line, train and exterior car objects being developed at » http://mus-iida.jpn.org « look beautiful and very realistic so far.

Some superb early screenshots of » Odakyufan’s « representation of the Odakyu Odawara line were also published a little while ago. The Odawara line starts from Tokyo’s busy Shinjuku station, and the line is well known for it’s Romancecar limited express services for tourists visiting Odawara and the surrounding resorts, but it’s also a busy commuter route and the Odakyu Electric Railway uses it’s own OM-ATS safety system, which will be simulated in a semi-realistic way due to the absence of detailed technical information. Odakyufan has a goal of modelling at least the first five stations, and this will be interesting to see, as this section of the line is surrounded by densely packed buildings. The screenshots showing the exit from Shinjuku station, Japanese 1500V DC catenary and Tokyo’s buildings all look very promising indeed, and easily recognisable, even at an early stage of development.

Odakyu Odawara line -- click to visit homepage Odakyu Odawara line -- click to visit homepage Odakyu Odawara line -- click to visit homepage
Homepage: » The Web Presence of Odakyufan «
Horizontal Rule
mus-iida.jpn.org -- click to visit homepage mus-iida.jpn.org -- click to visit homepage mus-iida.jpn.org -- click to visit homepage
Homepage: » http://mus-iida.jpn.org «
Horizontal Rule

Cross-City South bugfix

Railsimroutes LogoI’ve uploaded an update for Cross-City South v1.31, which fixes the following issues:
  • Incorrect pathname in route files using the class 323 passenger views.
  • The ground repeater signal prior to Birmingham New Street station is now accurately modelled, such that the red aspect is nearest to the driver (i.e. the signal is as though it were upside down now, as in reality). Many thanks to Paul Sladen for pointing this out.
  • In the night routes, “P” has been added as the ArrivalTime argument of the Five Ways .Sta commands (to indicate that trains are not meant to stop). Thanks again to Paul for bringing this omission to my attention.
  • Also in the night routes, the repetition count for Background(0) has been added, which was missing previously, leading to a horizontally compressed background image.

Existing Cross-City South v1.31.03 users can simply download a small update to v1.31.05 here: xcs_1_31_05_update.7z [180 KiB]. If you’re using a version earlier than v1.31.03, you might be better off downloading the full route pack again, which also now includes the aforementioned update. The previously separate class 37 and 158 route files are now included in the main download as well. Please also note that BVE 4 doesn’t work on my current Windows 7 64-bit/NVIDIA GeForce GTX 260 setup, so this update has only been tested in openBVE, as it’s inconvenient having to dual boot or use another computer every time I want to check some minor thing in the old BVE 4. There aren’t any changes which should affect BVE 4 users, but if any issues arise, please let me know with as much detail about the problem as possible, and I’ll investigate.

Horizontal Rule

Finally…

Railsimroutes LogoI noticed that the site has had it’s one millionth visit today (as opposed to page view), insofar as it’s possible to measure such things — the actual number of users of my routes will likely number in the low thousands, of course. Thank you to everyone who has taken an interest in my work during the eight or so years since this site was launched!

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



High resolution openBVE screenshots and updates

Posted by Anthony Bowden on 12th October 2009 at 7:39 am

Thankfully I have more time available now, so I should be able to pick up where I left off and resume development for openBVE. I recently upgraded my computer, and I’m rather pleased with how openBVE and various routes including my own are running on the new system, so I want to share a few more screenshots of how openBVE, Cross-City South v1.4 and Watford Junction to Rugby can run on higher-end hardware, as well as to show some progress being made. I’m working on adjusting the dawn lighting to produce some nice visuals on Cross-City South v1.4, and I’m also experimenting with some higher resolution catenary textures particularly suited to openBVE’s smooth transparency mode, as well as adding some 3D trees to Watford Junction to Rugby to see how the extra detail is handled. Here are some WUXGA 1920×1200 resolution screenshots from openBVE v1.2.2, with full 16xQ anti-aliasing, 16x anisotropic filtering, and with smooth transparency enabled; there aren’t many animated objects visible in these scenes however, so framerates on equivalent hardware (see below) will be a bit lower in the final releases. Some other openBVE add-ons are presented, as well as my own:

openBVE v1.2.2 and X-City South v1.4--click to enlarge openBVE v1.2.2 and X-City South v1.4--click to enlarge openBVE v1.2.2 and X-City South v1.4--click to enlarge
openBVE v1.2.2 and X-City South v1.4--click to enlarge openBVE v1.2.2 and X-City South v1.4--click to enlarge openBVE v1.2.2 and X-City South v1.4--click to enlarge
» openBVE v1.2.2 «, and Birmingham Cross-City South v1.4 with new class 323 and 3D cab (1920×1200)
(London Midland Class 153 externals by » Steve Thomas «)

Horizontal Rule

openBVE v1.2.2 and Watford Junction to Rugby--click to enlarge openBVE v1.2.2 and Watford Junction to Rugby--click to enlarge openBVE v1.2.2 and Watford Junction to Rugby--click to enlarge
openBVE v1.2.2, and Watford Junction to Rugby with 2D and 3D trees (1920×1200)

Horizontal Rule

Amongst the features planned for openBVE 2, are thunder and lightning effects. Early on during the openBVE project I demonstrated rainfall effects and thunder using openBVE 1’s capabilities; while it’s possible to create these effects within a route, I think it would be better to have these effects handled by openBVE rather than the route developer, along with lightning. This is another feature which I’m very much looking forward to, but I wanted to see what kinds of effects could be created anyway, so I did a few experiments. The following screenshots show how I envisage lightning might look on a route like Watford Junction to Rugby in future; the textures require a little refinement as this is just a test, but you get the idea (in full motion, the lightning strikes flicker and the effect looks better):

openBVE v1.2.2 and Watford Junction to Rugby--click to enlarge openBVE v1.2.2 and Watford Junction to Rugby--click to enlarge openBVE v1.2.2 and Watford Junction to Rugby--click to enlarge
openBVE v1.2.2, and Watford Junction to Rugby lightning experiment (1920×1200)
Horizontal Rule

Another openBVE project, the excellent » Chashinai Railway « network, was updated again a few days ago; the 1000 and 2000 series trains now have new plugins catering for ATS-SN as well as ATS-P in the case of the 1000 series train (don’t forget to read the train operation manuals on the website before driving with these safety systems), and both feature photo-realistic 2D/panel2.cfg based cabs with fully working ammeters and slightly dirty windscreens. The rivers found on these routes also demonstrate a good way of implementing moving water, and the new passenger textures, and photo-realistic trees and scenery textures enhance the routes as well. Here are some high resolution screenshots of the routes and 1000/2000 series trains; note the fully working ammeters in the in-cab screenshots (requires » openBVE v1.2.2 «):

openBVE v1.2.2 and Chashinai Railways--click to enlarge openBVE v1.2.2 and Chashinai Railways--click to enlarge openBVE v1.2.2 and Chashinai Railways--click to enlarge
openBVE v1.2.2 and Chashinai Railways--click to enlarge openBVE v1.2.2 and Chashinai Railways--click to enlarge openBVE v1.2.2 and Chashinai Railways--click to enlarge
openBVE v1.2.2, Chashinai Railway (» odakyufan «), and 1000/2000 series trains with working ammeters (1920×1200)
Horizontal Rule

Also, here are a few high resolution screenshots of the recently released » Saijou Line « for openBVE as well, which include various animated objects, night lighting and great atmosphere:

openBVE v1.2.2 and Saijou Line--click to enlarge openBVE v1.2.2 and Saijou Line--click to enlarge openBVE v1.2.2 and Saijou Line--click to enlarge
openBVE v1.2.2 and Saijou Line--click to enlarge openBVE v1.2.2 and Saijou Line--click to enlarge openBVE v1.2.2 and Saijou Line--click to enlarge
openBVE v1.2.2 and the Saijou Line (» http://tozai.s77.xrea.com «) (1920×1200)
Horizontal Rule

Watford Junction to Rugby, Performance, and *BVE

All of these screenshots were captured on a system with a Core 2 Quad Q9650 CPU (3 GHz), 2GB DDR2-1066 RAM and a GeForce GTX 260 graphics card, running on a motherboard equipped with the P45 Express chipset, and as you can see, even Watford Junction to Rugby runs nicely here, never dropping below about 40 fps in the external view with the class 87 and a 600m drawing distance (achievable with 2 CPU cores in use rather than 4). It will likely run even better with openBVE 2’s renderer, allowing those with slower computers to enjoy some higher framerates too. It’s also important to note, out of openBVE, BVE 2, BVE 4, and the latest pre-release version of BVE 5 (after the route has been converted to it’s new formats), that at the moment, openBVE remains the only simulator that is capable of loading and/or handling Watford Junction to Rugby with the high level of detail and object count it currently has, and openBVE handles the route on a slower Athlon64 X2 4200+ system with a Radeon HD 2600 Pro as well. Incidentally, I can’t assess whether Cross-City South v1.4 would be suitable for BVE 5 yet, as the route is very unfinished and there’s still a lot left to add; of course you’d certainly lose all the dynamic scenery and animation effects, along with the 323’s 3D cab, exterior and passenger views after such a conversion–hence I can say that my priority will remain openBVE. Naturally with Watford Junction to Rugby, I want to focus on openBVE primarily as well, and as the project is taking a long time to complete, BVE 2 and 4 compatibility and detail reduction will now be a lower priority, and I’ll only start on this task after all the openBVE features are finalised and the project is otherwise completed.

Lastly, I’ve been used to using openBVE with a 17″, 5:4 aspect ratio TFT monitor at a resolution of 1280×1024, but now I’ve seen openBVE running on a 24″ TFT with a 16:10 aspect ratio, routes and trains can look magnificent, and I’m highly impressed by the additional immersion which is offered, especially with the 323’s 3D cab. The higher resolution also makes arranging and working with a text editor and openBVE’s development tools much more enjoyable, and it’s also better for working with something like a C# IDE for example, or image editing software. More updates will follow soon.

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



openBVE v1.2.2, working ammeters, X-City South v1.31 bug fixes, minor 323 3D cab update, openBVE route updates

Posted by Anthony Bowden on 28th September 2009 at 6:34 pm
Horizontal Rule

Information Icon Note: Updated 21:40 BST

Horizontal Rule

openBVE v1.2.2 Released

openBVE LogoopenBVE v1.2.2 has been released, and this version includes some new variables for developers to use in animated objects or 3D cabs, including new variables for acceleration and motor acceleration; more variables can now be used to query specific cars as well. New subjects covering acceleration and motor acceleration which developers can use in the legacy panel2.cfg file are also provided, and some bug fixes are also included in this release. Please visit the » openBVE homepage « and read the » Changelog « for more details.

Horizontal Rule

Working Ammeters

One new variable is accelerationMotor. As mentioned on the openBVE forum, this can be used for creating working ammeters. The class 323’s cab doesn’t feature an ammeter, however, anyone wanting to experiment with this might like to consider the following panel.animated code as a *starting point*. You can copy and paste the code below into the 323’s panel.animated file to add a new ammeter needle to the cab and see it in action. Please bear in mind that I’ve not had time to test this in a variety of scenarios though:

panel.animated code for a simple ammeter (including illuminated needle):

[object]

states = 3d_cab\speedometer_needle.csv, 3d_cab\speedometer_needle_dark.csv

statefunction = if[hasPlugin == 1, !pluginstate[30], 0]

position = -0.43, 2.23, 11.45

rotatexdirection = -1, 0, 0

rotatexfunction = -2.4 + abs[accelerationMotor[0]] * 1.5

rotateyfunction = -1.11

rotatezfunction = -1.57

rotatexdamping = 2, 1

Notes: in the rotatexfunction line, -2.4 determines the needle rotation with no motor acceleration, and 1.5 determines the needle rotation with maximum motor acceleration. You can adjust these two values according to your ammeter gauge design. If you add an ammeter to your own 3D cab, remember that the statefunction line and multiple states (*.csv files in this case) may not be necessary depending on what plugin DLL, if any, you wish to use. When it comes to designing full 3D cabs for the class 86 and 87 electric locomotives for use with Watford Junction to Rugby, I’ll revisit ammeter design in more detail.

Horizontal Rule

Cross-City South v1.31 Bug Fixes and 3D Cab Update

I’ve also fixed a few bugs in the Cross-City South route. There were a few objects (houses, warehouses etc.) which included some surface lighting issues, which have now been fixed. Some class 170 3D objects also contained incorrect ‘Color’ commands resulting in errors being reported when the routes were loaded; these have now been changed to ‘SetColor’, which is correct for CSV format objects. As some of you will know, the Cross-City South also uses some .Sta commands only for signalling approach control purposes, which aren’t meant to be stopped at. However, you would still be penalised if you passed such a station without stopping. Thanks to Paul Sladen, I’ve now corrected these .Sta commands so that you can pass them without being penalised, while preserving the approach controlled signalling functionality.

You can download the full v1.31.03 route package via the Cross-City South download page.

There aren’t any new features included, as all of those improvements are going into the Cross-City South v1.4 project instead, and I’d prefer to hold those improvements back until the v1.4 is ready for release, as the end result will be more enjoyable that way.

Incidentally, the changes to the .Sta commands are as follows (the ArrivalTime and PassAlarm arguments, which are underlined):

Old: .Sta ;;09.4300;;-1;1;;;1;0;;11
New: .Sta ;P;09.4300;0;-1;1;;;1;0;;11

Important Note: Those of you still using BVE 4, will find that the route files now call upon the openBVE version of the unrefurbished class 323 EMU by default (Train\Cl323 Unrefurb_openbve). BVE 4 users can either install the openBVE version of the train, or edit the route files to use the older BVE 4 class 323.

Horizontal Rule

openBVE 3D cab screenshot I’ve also updated the 323’s 3D cab so that it makes use of the new hasPlugin variable. If you’re using openBVE v1.2.2 with a non-Windows operating system, then this will allow the cab illumination to work in the absence of the Windows only plugin DLL, which wasn’t the case previously.

I’ve also made some adjustments to the placement of the brake gauge, as it wasn’t quite right before, and now when you pass through a neutral section, the cab lighting should remain unaffected as the UKMUt.dll’s ats30 (pantograph up) is used as well as ats31 (Line Volts) now. The carriage light dimming effect will be retained in the passenger area once the new 323 external objects are released however. I’ve also remembered to remove several superfluous GenerateNormals statements from some objects this time, as they serve no purpose in an openBVE add-on.

Someone also kindly informed me that there may be some further innaccuracies with the cab’s indicators; once I’ve investigated further I’ll address these issues at some point in future. It’s also nice to note that the 3D cab may have been downloaded perhaps as many as 1500 times since it’s release.

Download:

» 323_unrefurb_3d_cab_28-09-09.7z « [1.7 MiB — requires openBVE v1.2.2]

Important: Also requires » Cl323 Unrefurb_openbve_05.02.09.zip « to be installed first.

Horizontal Rule

Other Things

I’m not making much progress with my projects at the moment, and I know that some of you may be disappointed that I’ve not yet finished Cross-City South v1.4 despite me saying that it’d be done before now (this is also why I’m usually reluctant to give release dates, and I shouldn’t have done so where this project is concerned). Rest assured, barring any disasters, it will be finished eventually and I’m still in the game, however, sometimes circumstances in the real world prove to be too much of a distraction, and it means that what one wishes to accomplish in the simulated world has to wait for a little while. This won’t last long however, and patience will be rewarded.

Horizontal Rule

And Finally…

The Saijou Line for openBVE was released a few days ago (the author’s » blog « is linked to via my blogroll), and this is an openBVE exclusive route featuring some very nice atmosphere and night lighting. There are a few errors, however the route is well worth giving a try, as it’s a good example of how animated objects and lighting can be used to bring much more life to a route and make it that much more enjoyable. You’ll find a variety of blinking lights, such as car indicator lamps, and the aviation obstruction lights fitted to tall structures (I’ll be modelling the same feature on the cluster of 250m tall VLF radio towers at the Rugby Radio Station on the Watford Junction to Rugby route). Moving cars and buses can also be found on roads, as well as flashing level crossing lights, road based traffic lights which change when the train is approaching, animated water, and moving elevators. You can download the route here: » http://tozai.s77.xrea.com/BVE/Sjyou.html « (the author’s homepage is here: » http://tozai.s77.xrea.com «)

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

Information Icon Edit: Another openBVE route recently updated, was the Chashinai Railways network, along with the 9000 Series train; when this train is used with the Misaki Line in particular, in addition to ATC, you can now enjoy simulated TASC (Train Automatic Stopping Controller) and ATO (Atomatic Train Operation) systems which enable fully automated driving, thanks to a new plugin which enables sophisticated safety system simulation. The 9000 series’ panel also includes photorealistic dirt on the windscreen, increasing realism. Visit odakyufan’s website for the updates, and don’t forget to read the Train Operation Manuals before you start: » http://odakyufan.uuuq.com «

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

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



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 | 27 Comments »



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

Posted by Anthony Bowden on 16th June 2009 at 12:04 am

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

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

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

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

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

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

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

Horizontal Rule

New Object Development Features

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

Shear and ShearAll

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

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

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

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

or…

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

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

Vertex Normals

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

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

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

CreateMeshBuilder
AddVertex, 3, 0, 1, ;vertex 0
AddVertex, 3, 0,-1, ;vertex 1
AddVertex, 1, 1, 1, ;vertex 2
AddVertex, 1, 1,-1, ;vertex 3
AddVertex,-1, 1, 1, ;vertex 4
AddVertex,-1, 1,-1, ;vertex 5
AddVertex,-3, 0, 1, ;vertex 6
AddVertex,-3, 0,-1, ;vertex 7
AddFace,0,1,3,2
AddFace,2,3,5,4
AddFace,4,5,7,6
SetColor,190,160,160

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

CreateMeshBuilder
AddVertex, 3, 0, 1, 0.6, 1, 0
AddVertex, 3, 0,-1, 0.6, 1, 0
AddVertex, 1, 1, 1, 0.3, 1, 0
AddVertex, 1, 1,-1, 0.3, 1, 0
AddVertex,-1, 1, 1,-0.3, 1, 0
AddVertex,-1, 1,-1,-0.3, 1, 0
AddVertex,-3, 0, 1,-0.6, 1, 0
AddVertex,-3, 0,-1,-0.6, 1, 0
AddFace,0,1,3,2
AddFace,2,3,5,4
AddFace,4,5,7,6
SetColor,190,160,160

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

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

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

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

openBVE v1.0.7.1 debug output

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