➟ Go back to July 2008.
➟ Proceed to September 2008.
| In these blog entries, you will find information on the things that I am currently working on. Whatever you read in recent entries does not necessarily describe things that are available for public download. The sole purpose of this blog is to inform you about the progress on development which will eventually - that is, in the future - result in an actual release of those features. Do not mistake this blog for a changelog. |
The homepage manager has been worked on to arrive at a very usable stage now. People interested in taking a look at first parts of the new homepage created using this program can look here, where people interested in translating the homepage into different languages at a later point can also get to know the program by downloading it from there. Please see the forum for more information, though.
The algorithm used to calculate the forward and backward viewing distance has been further refined. While it worked correctly compared to the old (up to version 0.7.0.8) algorithm, it made the viewing distances unnecessarily large for some angles. The new implementation gets this correct, but still fails for top-down views, as did all previous implementations.
The camera movement was previously not perpendicular to the default viewing direction in the interior view, which has been corrected now. Furthermore, the ability to roll the camera has been added. Keyboard support is available not only for the camera roll now, but also to reset the camera into its default position. Support for compressed X objects has also been added, however due to uncertainty on how the compression algorithm actually works, their use is strongly deprecated.
Previously, signal aspects were wrongly assigned for invisible section, which could defeat their sole purpose on some routes. This has been corrected so that invisible sections perform exactly the same as visible ones. Furthermore, some refinements and bug fixes have been made to the built-in ATC system, which did not brake the train correctly when the current speed limit was zero and whose visual indication did not match the internal speed limit exactly.
A door indicator has been added which displays the current state of the left and right doors. Additionally, the stop indicator now reflects which doors need to be opened. If the left doors need to be opened at a station, the bar will be at the left of the screen, and if the right doors need to be opened, it will be on the right side. As for multilingual support, more parts of the interface are now localizable.
The parsers now accept the Unicode minus sign (U+2212) as an indicator for negative numbers, along with the hyphen-minus (U+002D) as before. Furthermore, the automatically generated timetable now uses a special alignment (full justification) for Japanese (and Chinese) station names (via CJK, hiragana and katakana detection) as this resembles the way real Japanese timetables are layouted.
Version 0.8 has been released today as all major goals have been achieved.
A few problems have been corrected. First of all, the Track.Sig and Track.Signal commands previously always accessed argument 2 (the name) even if the command did not have two arguments, leading to a crash in this case. Then, the route parser was not able to handle comments in RW routes correctly. And finally, the Track.FreeObj command did not apply translation in the Y-coordinate nor pitch and roll at all. All of these problems have been corrected now.
The use of early and late station arrival messages was accidentally swapped, which has been corrected now. Additionally, a digital clock has been added to the in-game user interface. The changes and bugfixes made so far have been released as version 0.8.0.1.
Previously, if the friction and brake forces were greater than the acceleration force, the train would still do some "micro-movement" due to an imprecise implementation of those forces at zero speed, which was predominantly apparent for low frame rates. This has been reworked as part of the preparations to implement more realistic friction and adhesion.
Preparations have been made to simulate static friction and rolling resistance. Currently I am investigating on when wheel slip would start, as this is basically a threshold. Additionally, acceleration provided by the motor and all other forces that are incorporated such as friction and rolling on an incline etc. are currently being reworked to be applied on a per-car or per-axle basis rather than for the whole train. This will also enable individual cars to move independently, with forces along the couplers restraining each car's movement by pushing and pulling other cars.
The internals of train speed and acceleration have been reworked to some degree. Each car now stores its own speed, and forces due to rolling on an incline, friction and the like are applied on each car individually. Additionally, forces between the couplers are now simulated, meaning that cars can push and pull, resembling inelastic collision, which makes unpowered cars behave more realistically than before. However, all of this is still in its very beginnings.
A new formula for calculating resistances of train acceleration is currently being implemented which depends on some friction constant and air resistance. A list of new factors contribute to this calculation, including the aerodynamic drag coefficient, the frontal area of the train, the air density and indirectly, the air pressure, air temperature and altitude above sea level. As such, routes now have additional properties like initial elevation above sea level, initial temperature and initial air pressure. The air temperature and air pressure even change with altitude, however, due to the very small changes in altitude even for mountaineous routes, these factors do not have a great influence. However, in the future, routes can define their initial elevation, air temperature and air pressure, which can have a tremendous effect on the air resistance, especially with different temperature settings (e.g. winter vs. summer). A long list of constants is internally used which contribute to these calculations, including molar mass of air, universal gas constant of air, temperature lapse rate and coefficient of stiffness. Air density is also recalculated from air pressure and air temperature and directly affects the speed of sound and thus the perceived pitch of the sound. However, the full range of features will only be exposed by introducing new options for route files, such as initial elevation, air pressure and air temperature, and for trains, such as frontal area. For existing material, predefined constants will be used, and as such, the effects of this new dynamic system will be minimal for existing material. However, a keyword search (e.g. for summer, winter, snow, etc.) and some analysis of the route file might be an idea to influence the choice of default settings, or options in the user interface.
Additionally, wheel slip has been partially implemented but requires extensive testing, as well as the new formula for resistances does.
I have given the Ferrovia Genova-Casella Line a run in order to test the new elevation-dependant effects (and that route rises by around 270 m in around 9 km). Upon testing, I noticed a severe bug in the geometric calculations openBVE performs to determine the exact world position and direction for a given track position out of its internal route representation. The problem was that whenever the track made a curve and changed pitch simultaneously, there was a noticable jump from the end of one 25m block to the start of the next one. This difference is only noticable with that line's very small curve radii (60m), steep inclines (45‰) and extremely short train (5m), so I did not notice the problem before. I have now given the geometric calculations a new thought and have rewritten them from scratch. After some initial problems with the new formula, the problem is now thankfully solved. Well, at least I hope so...
The new formula for calculating resistances has been slightly reworked and also, the default constants used therein have been adjusted, thanks to an extensive effort of research having paid off, eventually. The new formula includes mostly realistic values for frontal area of the train, the aerodynamic drag coefficient, and air pressure. Default settings for all of them are provided, while in the future, the train configuration file will be able to customize all of them if so desired.
The new simulation of coupling forces has been reworked into a very usable state and works acceptably fine. Currently, the coupler resembles a buffer and chain system, if anything. The cars have freedom to move apart from each and to approach each other other until thresholds apply, namely the minimum possible distance between the cars (buffers meet) and the maximum possible distance (chains are stiffed). Currently, buffers do not employ springs, which makes everything threshold-based, but as with the coupler model itself, this can be changed in the future. I actually implemented a coupler which itself acted as a mere spring, but there were inaccuracy problems in the calculation which resulted in some form of particle accelerator: the cars would approach and drift apart with successively increasing speed until the game crashed due to overflow and NaNs. The current implementation of a buffer and chain system will suffice for the time being.
I have experimented with full screen motion blur, which works by copying the current frame into memory and drawing it slightly transparently over the next frame. When the level of transparency is set correctly, this, even though it is frame-based, can be made invariant under different frame rates. While, the frame rate invariance works correctly, it seems harder than I initially thought to calculate a good intensity value depending on the current speed of the camera. Even though it is way too extreme currently, it basically works fine. The effect is very demanding, though, in terms of computational power required.
The wheel slip seems to work as expected. Every motor car exceeding the acceptable acceleration provided before wheel slip starts does not contribute to accelerate the car. A rough simulation of wheel spin is included so that the speed sensors pick up a higher speed, which is visible in the speedometer. Also the train engine sounds as if it was going at higher speed, although I do not know yet if this is realistic. Either way, the current implementation seems to work. However, I have spotted one problem with the coupler model. Whenever a car cannot move due to coupler forces preventing it to, it internally still has its original speed, so as soon as it is free to move, it starts to move which this suppressed speed instead of accelerating afresh.
The brake system is currently being completely overhauled in order to work on a per-car basis. The advantage is that systems like the automatic air brake can be correctly simulated to propagate changes in the brake pipe over time as soon as this conversion is completed. For very long trains, this can mean a minute or so in delay until all cars apply or release their individual brakes. The conversion will take some time as the system is complex and greatly interleaved with the rest of the simulation.
The automatic air brake is now internally distinguished between an active mode (e.g. locomotive) and a passive mode (e.g. wagon), where all the elements like the main reservoir, the equalizing reservoir, the brake cylinder, the brake pipe and the straight air pipe are simulated in active mode, while only the necessary subset present in other cars is simulated in passive mode. So far, the main reservoir works correctly again and the brake pipe, which was not previously simulated at all, now propagates the changes in its pressure throughout the train.
The automatic air brake system (Westinghouse) has been completely rewritten as the difference in the way the new simulation works compared to the old implementation was just too big. The new system simulates the main reservoir, the air compressor, the equalizing reservoir, the equalizing discharge valve, the brake pipe (whose pressure propagates between the cars in time), the triple valve, the auxillary reservoir and finally the brake cylinder. I am considering to implement a distributor instead of the triple valve, too, whose purpose is mainly the connection of an additional emergency reservoir for a quicker emergency brake application, however, I have not decided yet. The biggest problem currently is the calibration of the many different pressure rates applying between the components. In my debug sessions, the longer the train, the longer it takes for brake application and release, but sometimes, this does not seem to converge, meaning it does not propagate between the cars in any imaginable amount of time. So some work is still required to be done in order to get the system operating normally.
The automatic air brake now works quite normally and the problems that occured previously could be resolved. Due to simplicity of implementation, I have decided to definitely implemented the two-pipe version of the automatic air brake (brake pipe plus main reservoir pipe) and additionally a self-lapping handle for these brake systems. However, this will follow only in the near future as it does not have priority at the moment.
The electromagnetic straight air brake has been mostly reincorporated, as with all the other brake systems, it was required to rewrite it. However, even though the braking forces are simulated, the train does not yet decelerate.
Both the electromagnetic straight air brake and the electric command brake are available again, and the train is also able to decelerate again. The three electro-pneumatic types have also been rewritten and are available again. After all, the conversion of a train-based brake system to a car-based brake system was successful and will provide much more customized values for each of the components of each individual car.
I have played around with a first design prototype of a window-based user interface, but am not currently satisfied with the results.
The Track.Adhesion command has been integrated and there have been made a few modifications to the current implementation of adhesion and wheel slip. Basically, if the wheels lose traction when too much power is applied on low adhesion conditions, the wheels will begin to spin, while if the brake application is too strong, the wheels will lock. Assuming that the speedometer calculates the current speed based on the rotation rate of the wheels, the speedometer will also resemble these states by indicating higher speed than the train actually drives at, or zero speed, depending on the underlying conditions.
The toppling has been completely rewritten and is now based on a more or less realistic physical formula. Once a car exceeds the critical speed for toppling in a curve, the inner wheel will begin to leave off the rail. Contrary to the previous implementation, the point of rotation is now correctly the other wheel which has still contact with the rail. Once the car exceeds the critical angle for toppling, which is when its center of mass passes that point of rotation, the car will completely derail and fall down to the ground. The are even some gimmicks and side-effects. First of all, as the wheels do not have contact with the rail any longer, the run sounds stop playing, applying power results in wheel spin, applying the brakes results in wheel lock, the speedometer corresponds to these effects, the brake pipe will be disconnected from the adjacent cars and thus leak air to the atmosphere, consequently the brakes will apply, and so on. Applying power or the brakes does of course not yield anything as contact to the rails was lost, but the car will decelerate to a stand because of simulated friction between the car body and the ground. Of course, once toppling starts, reducing the speed will still save the train from entering such a disaster.
Collision detection has been implemented. When two trains collide, inelastic collision is simulated, and derailments can occur if the speed difference between the two trains is too large. The computations correctly take the different masses of the colliding cars into account. If the speed difference is small enough, one train can push the other without problems, which might have interesting value for future route-specific operations. Furthermore, car shaking has been added which occurs when decelerating to a stand too harshly, and also in collisions.
The timetable can now be scrolled up and down. Additionally, the brake debug output can be toggled on and off. I have made the progress that has been made on the way for 0.9 available as an intermediate release, version 0.8.3.0, today.
The CSV and RW route parser has been modified to be able to optionally only parse for the geometric data, station starts, speed limits and some other things. Loading a route this way is very fast, usually within a few milliseconds. I have successfully made a first attempt to create a route map based on this geometric data which will be a core-feature in the new interface.
After having tested some trains, especially freight trains with only one motor car, I came to the conclusion that the new, more realistic behavior of acceleration, in which the acceleration section resembles the power output of a motor car only, posed compatibility issues. Instead, the new model will be optional and the older model will stay the default. Within the old model, the acceleration section resembles the power output for the whole train, meaning that it is invariant on the amount of trailer cars which need to be pulled by the motor cars. Along with some other additions, the choice of acceleration model is implemented as an extension to the train.dat.
A bug in the toppling code has been fixed. Whenever the front axle and the rear axle were in curve radii with different direction (e.g. one left, the other right), the formula which averaged both curve radii to be used in further calculations produced nonsense values and could force the train to quickly topple or even derail.
I have worked on around half the documentation of the train.dat, including the additions that I have made to it. The document is partially available here.
Work on the train editor has been started. So far, most of the interface is complete and files can be loaded, however, neither can they be saved currently, nor is the motor sound editing part yet available.
I have intensively analyzed the behavior which can be observed in the acceleration curves in mackoy's Train Editor and could fine-tune some internal default values in openBVE in order to improve the reproduction of acceleration and top speed for many trains.
A bug in the collision testing has been fixed which made a wrong comparison when the player's train was in front of the previous train. The bug caused the player's train to accelerate to sick magnitudes of speed (2000 km/h or so).
For compatibility, the behavior of orphaned transponders has been changed. These are transponders without an associated section, for example due to the fact that the route does not use signals. While previously, these transponders were visually placed but otherwise without a function, they do have one now. When the train passed such a transponder, the ATS-P system is activated, which is required for routes which make use of the permanent or temporary speed restriction transponders. Such routes did previously not work with ATS-P, simply because the system could never be activated. This has been changed now so that these routes can properly work.
I have started to create the main menu in a window. After a lot of consideration, I went for something simple, yet pleasant to view. Many elements are already present but not working yet. The route selection is partially implemented and is already capable of showing the route description and an automatically generated map of the route.
The coupler code previously included a remnant of my attempt of creating a spring-resemblant coupler model, which I abandoned a while ago. This remnant, however, was the actual reason why trains were reported to instantly speed-up to nonsense values in the past few days. This bug, which is consided a very serious one, has been addressed in version 0.8.3.12 by removing that superfluous line of code.
The main menu has been further worked on.
Inside the main menu, it is now possible to select the route and train individually. Route and train images and descriptions can be shown, and the encoding for route and train can be selected individually. In the future, openBVE will remember these settings per route and per train. Of course if Unicode was used, this burden for the user would be unnecessary.
The game can now be started through the main menu, where the settings for the resolutions and quality settings are taken into account and remembered between sessions. Additionally, the values for Route.Change were previously interpreted incorrectly, which has been fixed, and compatibility with the plugins has been further increased by improving the setting for B67Notch and removing redundant calls to KeyUp() at startup.
The texture manager has been given the additional capability of loading not only full images on the fly, but also portions of a bitmap. Previously, the panel parsers handled bitmaps like the brake indicator specially and divided them into individual sub-bitmaps which were passed to the texture manager. However, the on-demand loading capability was not available for such bitmaps, meaning that all bitmaps needed to be loaded at startup and could never be unloaded anymore, as reloading them was not possible. This has been fundamentally changed. The panel parser now handles bitmaps like the brake indicator as every other image and leaves the job of extracting portions of the bitmap to the texture manager. The benefit is that it is possible to unload absolutely all images used by openBVE and to reload them at any time. This was a necessary feature in order to allow for OpenGL to switch between fullscreen and window mode in-game as OpenGL demands to reload all textures when doing this.
The main menu has been added the recently used routes and trains feature to more easily select these last used items.
The main menu can now remember the encoding setting for each individual route file.
The encoding setting for trains is now also saved. The main menu is now in a very usable state, even though some of the anticipated features are yet missing. Furthermore, the texture manager stores the wrap mode for textures now, so that textures can be either clamped (used in panels) or repeated (used by world objects). Clamping is useful in order to reduce wrapping artifacts. As for train sounds, the brake cylinder air sounds have been reincorporated.
The const speed system has been reincorporated. Instead of magically adjusting the power output to keep the speed of the train constant as previously done, the system now deliberately lags a bit in terms of adjusting the power output to better reflect how a real system might work. For each motor car, the acceleration of the car is calculated from the speed, and if non-zero, the motor power output is gradually adjusted so that the calculated acceleration converges to zero over a short period of time. The update interval for the const speed system is now internally customizable, thus updates are made in regular interval instead of every frame.
Error handling and reporting has been improved for the Acceleration section in the train.dat, as well as for the Track.FreeObj command.
The Track.Stop command has been added the backward and forward stopping tolerances, which were previously missing.
The hold brake device has been reincorporated. It works similar to the const speed device in that the device adjusts the power output over short periods of time to converge to the measured target value to hold the speed on downward slopes. The readhesion devices have been implemented as well.
The first preparations have been made to allow to select the mapping of the controls in the main menu. Joystick support is being added in this process and is already working in the menu to give a preview of the attached joysticks, however, not yet during the simulation.
Commands can now be added and modified in the main menu, however, currently only keyboard assignments can be made. The settings cannot be saved or loaded yet.
Joystick assignments can now be made for commands, including for axes, hats and buttons. Within the simulation, those controls can now also be used. Analog equivalents to the power and brake controls are being added to map these controls to half a joystick axis or the full joystick axis. Power and brake commands are now also descriminated between controls for trains with a single handle and for those with two handles.
➟ Go back to July 2008.
➟ Proceed to September 2008.
|
|
