As I have never programmed with OpenGL as a graphics library, I hereby conduct basic experiments, starting at 6:00 in the morning. A basic CSV object parser has been written and the object can be displayed with some problems. Support for cylinders and rotation is missing at the moment. This makes the program a basic structure view after around 7 hours of work, though some parts don't render correctly. The AddFace command is not directly supported. Instead it is interpreted as AddFace2. The basic structure for texture management and route storage has been layed out. Work started on a CSV route parser to accomodate the Structure.Ground, Structure.Rail, Track.Ground, and partly the Track.RailType and Track.Height commands. The ground and the Rail 0 are displayed in the entire route. Initial perspective problems could be resolved. Curves can also be displayed now.
The texture manager has been extended to support transparent color via an RGBA enviroment and editing the image to make the transparent color fully transparent in the alpha channel. Actual ARGB images could be supported already, but have not been tested yet. The texture manager also differentiate between loading RGB and RGBA textures. The internals of World.cs have been partially separated to ObjectManager.cs, TextureManager.cs and TrackManager.cs in order to have a more modularized environment. Also, the parsers use only invariant culture now, for international compatibility.
Track.Rail and Track.RailEnd is now available in the CSV route parser, and the rails seem to be placed correctly in all scenarios. The Structure.FreeObj, Structure.WallL, Structure.WallR, StructureDikeL, StructureR and Track.FreeObj, Track.Wall, Track.WallEnd, Track.Dike, Track.DikeEnd commands have also been added and seem to behave correctly. Rotating and translating in the CSV object parser has been implemented. The rotation performed is slightly different compared to what BVE produces. This needs to be fixed. Maybe the mathematics of the rotation matrix are wrong. The event manager and corresponding event follower have been introduced. Background change events are supported. Added the ability to parse Structure.Background and Track.Back in the CSV route parser. The background image is displayed as a cylinder, which differs from the way BVE does it, with 6 repetitions of the texture in a full circle, just as BVE. The alignment of the background image seems to be correct regardless of the amount of polygons used, default 32.
The renderer now adds all faces with alpha channel used to a delayed faces list in order to draw them last. This solves the transparency problems that previously occured. The CSV route parser has been extended to include the Structure.FormL, Structure.FormR, Structure.FormCL, Structure.FormCR, Structure.RoofL, Structure.RoofR, Structure.RoofCL, Structure.RoofCR and the Track.Form commands. Although the center part of the forms (FormC and RoofC) work with the Uchibo route (the reference), the behavior of how BVE edits the center parts is not well understood and the current implementation might therefore fail to reproduce other routes correctly. Assumed to work until a counter-example is found. About current problems. An error in the Track.FreeObj processing was found that prevented the correct alignment on rails other than rail 0. Next, the glfw.dll needs to be distributed along with the program and a dll has been found and works on all three reference systems. Next, the tanigumi line reproduces correctly except one misaligned hill en route. It needs to be investigated whether this is due to the rail processing in the CSV route parser or the rotation matrix employed by the CSV object Rotate command in the CSV object parser. The CSV route parser has been extended to include the Structure.CrackL, Structure.CrackR and Track.Crack commands. As with the form, it renders correctly using the Uchibo route, but the way how BVE edits the cracks is not fully understood. Assumed to work until a counter-example is found. Also, the Structure.Pole, Track.Pole and Track.PoleEnd commands have been implemented. Works correctly, but the built-in structures for poles that were not loaded via Structure.Pole are currently not included.
The misaligned hill in the tanigumi route could been reduced to a difference of interpretation of .Rail commands in the CSV route parser. BVE happily ignores .Rail commands for one rail index if on the same line there already was a .Rail command for that rail. The CSV route parser instead strictly read the line from left to right, eventually overwriting the first .Rail command by the second. This behavior is now corrected to be consistent with BVE. The first aspects of the train internals have been layed out. Each car of a train has two axles, which have their own track follower. Position is accurately determined, the driver seat's view can be calculated and therefore the camera can follow the train. The train externals can be displayed. The car objects are correctly placed and rotated, make curves and pitches as expected. The pitch was previously not slanted for the camera, instead the camera would 'climb up' a hill. This is fixed. The camera can now look up and down correctly. The viewing distance is now adjusted for the front and back depending on the orientation of the camera. The camera can therefore now be rotated at will. It now seems to be appropriate to release a technical preview and to introduce a web site and forum. Initial coordination with the community is necessary from now on. The demo version 0.1 is complete. It can be set up to load other routes via external configuration file.
I wrote some articles about the internals of openBVE for the website, namely for the track and the train. The CSV object parser now ignores unnecessary arguments in commands and will assume 0 if an argument was not passed. The CSV parser is also a bit more tolerant, but not too much. Looseness seems to be required for better compatibility, but a more strict mode for developers would be a good idea for them to validate their route.
A high-precision timer has been added, but it still results in stuttering on some routes. The texture manager should be extended soon to not load all textures at startup, but to load them as required and disposing of them if they are not used for some time. The memory footprint would be reduced and could result in better performance, however loading textures at runtime will also cause some delay. As always, some compromises have to be found. The geometrical structure of the 3D panel has been extensively thought of and development has begun to be able to show some prominent parts of the cab by tomorrow. Some burdens in the CSV route parser have been worked on. The route parser basically ignores most errors and assumes missing arguments, but will strictly test against the existance of referenced structures.
The internal structure for car sections has been created. Each section can have multiple elements. Currently only the static element type is implemented. The old stub for displaying the exterior car object has been removed and is now implemented via the more general car/structure/element hierarchy. The mathematics in the structure world coordinates updater is slightly different from the camera updater that tries to follow the train. Therefore, the mismatch results in stuttered train following. Both algorithms will be replaced by one that unifies them. Overhaul of the texture manager: It now loads textures only when they are used for the first time. This results in faster loading and reduced memory footprint. The mechanism to unload textures that have not been used for some time is not currently implemented. Loading textures at run-time produces less delays than initially expected. Furthermore, OpenGL does not like textures that are non-powers of two, and when I tried loading the panel.bmp from a BVE 2 train, the framerate dropped from over 100 to only 3 frames per second on close-up view. The texture loader will need to resize the texture to the nearest power of 2, then all textures can be loaded without problems. The train sections and the camera now work perfectly together. It is quite nice to see a panel in front of you and being able to rotate around. Work can start on loading the actual BVE train.cfg via a suitable parser.
Initial work has been made with the train.dat and the panel parsers. The train.dat parser is currently used to look up the amounts of cars, their length, and the view coordinates for the cab to show up. The background image can be read from the panel.cfg and is more or less correctly mapped into 3D coordinates, taking the up/down-angle into account. Code is still required to restrict the camera view inside the cab, because now it is possible to freely look around, which is not well suited for BVE panels.
The Rotating element now works and can use a function script to calculate the angle to show at runtime. The BVE 2 panel parser can now display the speedometer and the clock using the Rotating element. The needles for the speedometer, hour, minute and second use textures that will be provided with the game, because BVE 2 does it with lines that only have a color and no texture. The function scripts used for the needles of the clock (as created by the BVE 2 panel parser) use some arithmetic to perform the kind of swinging that BVE 4 clocks also do when a needle advances to its next position. Backface culling has been implemented for the .AddFace commands and also the premature object disposal system employed by BVE to dispose of objects before they actually end. Needed for compatibility. The pressure gauge is now partially available in the panel parser. As the train internals are not simulated yet, the needles will currently stay at a fixed position.
I have now encountered some precision problems. When driving more than 10000m, this will become quite noticable: the panel components vibrate, which is very unpleasant. As I store the panel in world coordinates, but the panel is a relatively small thing, z-fighting also occurs when too far away from the origin. It seems that the floating point precision employed by the graphics hardware is much lower than I internally achieve via double precision in software. Thus, I need to make a hopefully simple change to the renderer. Instead of bringing the camera to the objects, I have to bring the objects to the camera. This should compensate for the precision loss in the rendering when driving very far, because objects would be close to the origin in the renderer. I will conduct the changes tomorrow, though, and hope that this will do it. Another interesting problem is rain and snow as employed by some BVE routes. Because the panel is a 3D object, the rain etc. can appear in front of the panel. I have yet to consider what is best to solve this issue. A simple overlay panel could have done it, however this would have required a separate compatibility layer for BVE panels instead of using the underlying 3D system. Did I have an actual 3D cab, the problem needs to be thought through anyway. For now, I consider it a minor problem. Also, some FreeObjs seem to be misplaced. Until the major problems are fixed, this one is minor issue, too. The renderer has been successfully adapted. The precision loss at greater distance is no longer an issue. Also, there was an error with the backface culling as some objects did not appear before. This is also corrected. I hope to resume work on the panels tomorrow.
The BVE 2 panel parser is now able to handle the pilot lamp. However, as the doors are not simulated yet, the lamp goes simply on and off to show that it's basically working. Also, I created some own needle graphics for the clock, the speedometer and the pressure gauges after I previously used the graphics from BVE 4 for testing the panel. The CSV route parser has been modified to directly support RW style and command names. The parser is therefore a unification of a CSV and RW parser and is able to handle both styles even in the same file. Some little adjustments and tests have still to be conducted.
VB6 number parsing is now employed in the CSV/B3D object parser. RW routes are now supported, however, due to the fact that the format is not documented by mackoy, there might be compatibility issues in the case I missed a command or an alternative way of phrasing it. Also, the route parser now uses VB6 number parsing which has also been prepared to accommodate the a:b:c style of writing distances as it has been proposed on the forum. The train manager is now able to handle a new SectionElement type, namely the TextureShifting element, which can shift the textures of its polygons in a specified direction. The BVE 2 panel parser has been upgraded to show the brake indicator via a TextureShifting element. However, the brake indicator will currently just cycle through its states as the necessary train internals are not present at the moment. With RW routes working and most of the panel at least showing up, the release of version 0.2 is close. It would be great if I found a way of adding the LED style of the speedometer and pressure gauge before the release. The function script interpreter can now handle tests (equal, greater, etc.) and conditionals. The digital indicator for BVE 2 panels is now available, too.
Some free objects were previously misplaced, because the route parser did not offset the objects vertically on inclines of other rails than rail 0. This has been corrected. I basically conducted a lot of tests with different routes today and made some adjustments to the parsers for better compatibility. Other than that, I enjoyed the results I achieved so far by driving and watching the train (6-car set) instead of actually working.
Stop points have been added to the stations. There can be as many stop points per station as desired, one for each amount of cars. For BVE stations, only one general stop point can be read from the route file, but is now supported via the Track.Stop command. The distance from the front of the train to the stop point is calculated and displayed in the debug output. Doors have been implemented. The user can open the left and right doors in the whole train manually, although internally, each car can have as many doors as wanted, and each car can be specifically told to open/close its left/right doors. Also, the Track.Station command is available to the same level as the Track.Sta command, and that is, only partially. As I decided to make the current state of development available to the public, version 0.2.0.0 has been released today.
I have added a preprocessor to the route parser in order to accomodate for the $Chr, $Rnd and $Sub commands. Another one has been made to sort the commands by the track position. Previously, if the commands were in random order, the parser didn't like it and produced some wrong results. A lot of more error checking has been added to the Track.Form and Track.Crack commands.
The cant in curves can be displayed, that is, both the train tilts and the camera tilts, however, train and camera do not quite match currently. Also, the mass and speed are not taken into account currently as a spring that performs realistically is yet to be implemented. Good physics will be something for the future, because it is not one of my strengths. Still, I have implemented some sort of spring that makes the cant perform more realistic in curves, that is, if the train is too fast, it will tilt in the other direction and shake its way back into a straight position once the curve is passed. Looks actually some sort of nice, but performs differently than in BVE. The camera misalignment still needs to be solved. I started to create some high-res textured signal graphics, not semi-hand-drawn as in BVE.
I have now implemented the electromagnetic straight air brake, with electropneumatic types none (無し), closing electromagnetic valve (締切電磁弁) and delay including control (遅れ込め制御). However, the closing electromagnetic valve type is displayed differently in the cab. According to mackoy's description, the brake cylinder should be zero above the control speed, when in fact in BVE it is not. My implementation follows the description (which I may have misunderstood), but performs functionally equally. The electric command brake needs still to be implemented as it is currently handled as an electromagnetic straight air brake, but still, trains can be controlled in a way very similar to BVE now, which I think, is a major step forward.
The texture manager now unloads textures that have not been used for around 45 seconds. This reduces memory consumption. Should they be needed again, the reload delay is basically negligible. The Track.Signal and Track.Sig commands are now partly parsed. The signal pole is shown when appropriate, but the actual signals are yet to come.
|