➟ Go back to October 2008.
➟ Proceed to December 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. |
I have continued to write documentation for the CSV route today, including the track-geometry-related commands and some signal-related commands.
The automatic air brake needed fine-tuning and still does. The adjustments I have made today allow for quicker brake releases and more controllable brake applications.
The built-in ATC is now able to detect the end of the ATC-equipped track (at the end of a suitable station) and will include this scenario in the calculation of a brake curve. This way, the train is progressively slowed down to come to a hold before the end of the ATC-equipped track.
The SetVehicleSpec call now gives correct information for the brakeNotches, atsNotch and b67Notch parameters during the plugin initialization for a train equipped with the automatic air brake, which was not previously the case.
Cylinders can now drop their top or bottom caps by using negative radii.
There are now two operational modes for sections. The value-based one, which was the previous default, takes a list of aspects and shows the smallest aspect higher than that of the following section. I added an index-based compatibility mode. Here, the aspect is chosen whose index corresponds to the amount of clear sections ahead until a red one is encountered. The value-based behavior keeps being the mode used for all sections created via the Track.Signal command, while the index-based behavior is used for Track.Section commands.
There was a problem in the route parser with the positioning of virtually all objects. The problem was especially prominent on pitched track where some object that would usually line up (e.g. a signal and its post), did not. As I have noticed what my geometric misconception was, I could fix the problem.
I have started to implement a 2D-alike cab using the underlying 3D system. Previously, you could only move in the cab. Now, rotating the 3D view will, as intended, keep the panel in line with the camera, but shift it in order to reflect the rotation akin to a billboard. Moving and rotating the view can be done simultaneously, meaning that the previous feature of movement is not compromised at all. I have not yet implemented a proper camera restriction, though.
The Object Viewer has been started and basically finished today. It allows to smoothly move and rotate the camera via the keyboard, and also via the mouse, though not smoothly. Objects can be added at any time, reloaded and an error report can be shown if desired.
The object parser has been added the new Scale, TranslateAll, ScaleAll and RotateAll commands. The Scale command allows to rescale all vertices created so far in the current mesh builder, while any of the xxxAll commands does not only apply to the current mesh builder, but also to all previous ones. This allows to easily translate, scale, mirror and rotate entire objects without the need for external tools.
The LoadTexture command for CSV/B3D files has been expanded to also allow for a nighttime texture to be specified. Files making use of this new feature will blend from daytime to nighttime in a similar way as panels do. If used as an exterior object, the transition is affected by the lighting conditions and the Track.Brightness command, and when used as any kind of object in the route file, it is sensitive to the lighting conditions only.
I have optimized the way polygons store their data slightly. Compared to my previous attempt a week or so ago, the changes were pretty minimal this time but save around 30 percent of data. I have profiled before and after and could confirm the savings this time. However, most of the memory is currently consumed by vertices. I think I can optimize this, too, but have not yet started to do so.
On the IIYAMA 2060 line, I previously noticed that all of the signals were not appearing in openBVE and started today to find out why. I initially suspected an X file incompatibility, but after more than an hour I found that the reason was much simpler. A Track.SigF command using x=0 should not force the signal to disappear, which is the case with the Track.Signal command, from which I derived this behavior. Now, signals appear as intended.
I made some slight changes to the way signal and timetable graphics are loaded so that they do not suffer any longer from loading delays as was previously the case. There was also a small bug in the motor sound table loading routine which allocated and reallocated dozens of megabytes for no apparent reason. I noticed this due to the CLR profiling which I did to compare the optimizations I carried out earlier.
Today, I wanted to start the mammoth-task of implementing a fully-functional camera restriction for the new billboard-like cabs. However, as it turned out, the implementation was much easier than I initially expected. My original plan was to derive a formula leading from panel coordinates over train coordinates, world coordinates to screen coordinates, and then solving that equation for camera yaw, pitch, position, etc. in order to determine the maximum amount of yaw etc. that is possible before the panel would move outside the screen. As a first step, I have derived the formula, so basically did what OpenGL would automatically do in hardware, but then I left it there and instead transformed the whole thing into a mere test checking whether or not the panel under the current circumstances would be covered by the screen. Now, whenever the camera is to be moved or rotated, the test is performed, and when it fails, a binary splitting algorithm is used to determine the farthest value that can be taken before the panel would not be covered by the screen. Sounds complicated, but is much simpler than what I originally imagined. I have adapted all necessary parts to ensure proper camera restriction if so desired. As a result of the billboarding technique used to keep the panel perpendicular to the line of sight, rotating the view by 180 degrees via turning off camera restriction gives a copy of the panel facing backward, which can be used as an intermediate way of driving the train backward while having a panel available. Just to summarize that the new billboard-cab allows for both movement and rotation, so that the driver's seat can be adjusted left/right/up/down/forward/backward and the view be rotated, leading to basically any view the player wants to have given the restrictions of a 2D panel.
Most parts of the camera code have been adapted to enable a smooth camera movement similar to Object Viewer. Some problems have also been corrected, including a still slightly off handling of FormC, RoofC and Crack, as well as an unnecessary series of KeyUp events that were passed to the plugins whenever modifier keys were pressed.
I started to rework large parts of the source code in order to change the way vertices, faces, meshes and objects are stored. While openBVE previously stored vertices for each face individually, this is now going to be reworked to store vertices per mesh only and thus to share vertices among faces for lower memory requirements.
A quick-fix solution has been implemented to prevent unrealistic wheel-lock at near-zero speeds.
I have successfully adapted World.cs, ObjectManager.cs, BveCsvB3dObjectParser.cs, BveXObjectParser.cs, BvePanelCfgParser.cs and BvePanel2CfgParser.cs to meet the requirements the new model of storing meshes and so on imposes.
The modules Game.cs, TrainManager.cs and BveCsvRwRouteParser.cs have been adapted, too. The only thing now missing is Renderer.cs, which needs to be given an almost complete rewrite in order to efficiently allow for the speed-ups that are possible with the new organization.
The relevant parts of the renderer have been completely rewritten and rendering the simulation works normally again. While I initially observed a huge performance penalty which I did not expect, I have now managed to even gain 30% more frames per second on some routes thanks to some optimizations. Additionally, I could confirm lower memory requirements via CLR profiler. The memory reductions that I anticipated are not yet achieved as many object files in use do not employ the optimization techniques for which the underlying system has been designed for. I intend to write a B3D/CSV/X optimizer which will be able to do the most crucial optimizations automatically upon loading the object and expect further memory reductions as a result.
I needed to observe that the previously reported performance increase was merely due to lighting being disabled all the time. When turning it on again, I still got a 20% frame rate bonus compared to the old implementation. Given that I only wanted to reduce memory consumption, this is still pleasant to notice.
The object optimizer has been written and integrated into the loading step. It is currently capable of merging meshes, materials and vertices.
I have conducted some first profiling regarding the savings the new object optimizer offers. While I can confirm memory reduction, the amount is slightly less than I imagined it to be. On some routes, I could notice 20% less amount of vertex memory needed, while on others, this was almost non-existent, suggesting that those latter routes already have optimized objects. I have also added the capability of removing unused materials and unused vertices to the object optimizer, even though the scenario is relatively unlikely.
Transparent color transparency has received some improvements. First of all, when mipmapping or anisotropic filtering is used, reduced versions of textures could appear to drop some of their details. This is due to the fact that image reduction can yield intermediate alpha values but mere yes or no, but the renderer was instructed to cut off alpha values as otherwise depth sorting would be needed even for transparent color transparency to appear correctly. I have now added a high quality option for transparent color transparency which ultimately adds faces using it to the alpha list in the renderer, which does depth sorting. This of course means that the improved quality comes at the cost of lower performance if transparent color transparency is frequently used. Second of all, if a transparent color was defined for a texture, but that texture did not contain the color, which is often the case for X files, faces using this texture would be added to the transparent color transparency list in the renderer, while now, the texture is flagged as not using transparency altogether.
Unfortunately, the current implementation of depth sorting is not sufficient to avoid some usually minor visual glitches that can occur for the new high quality transparent color mode and for alpha transparency in general. I have tried to come up with a better one but needed once again to realize that a geometrically correct depth sort is out of the scope of this project. The current implementation is actually already very well suited as an approximation, but as said not free of issues. I will thus rename the new transparency modes to sharp, the old implementation with sharp edges for textures using a transparent color, requiring no depth sort and thus avoiding the associated issues, and smooth, which offers better quality when using mipmapping or anisotropic filtering at the expense of some performance and some occasional glitches. The option is now available in the options menu.
Smooth camera movement has been added for the track camera, and also for zooming, which makes the goals I have set for a version 0.9.1 accomplished. As such, version 0.9.1 has been released today.
The fly-by modes were previously lacking the ability to move the camera forward and backward, which has been reimplemented. Additionally, the Options.SectionBehavior command has been introduced to choose between index-based and value-based behavior. The value-based behavior is simpler to handle when using sections with different aspects or different amount of aspects, but does not allow for all of the possibilities of the index-based behavior.
I have started to work on Route Viewer and have basically finished the basics. Routes and be loaded and reloaded, the camera can be moved and rotated, points of interest can be jumped to as well as stations, and some information like position and current station are displayed. Additionally, I have started working on a little extra allowing to preview the positions of various events, such as brightness changes, background image changes and so on, allowing to debug their exact positions in the route. Route Viewer also contains the sound subsystem, thus previewing sound effects such as Track.Doppler and Track.Announce are also possible.
Route Viewer has been further tweaked and the remaining images necessary for the event preview have been created.
Today, I decided to prepare the internals for the introduction of the animated object format. I have basically moved lots of code from TrainManager.cs to ObjectManager.cs in order to share most of the required code between the train section elements and the animated world objects.
I have written the parser for the animated object format to most parts and have also integrated animated world objects into the object processing pipeline. So far, state changes, translation, movement and rotation, including damping, are working. I also introduced two new commands to the CSV/RW parser in order to test the objects in route files.
Most of the time went into creating DemoRoute1 in order to demonstrate the features that were added during the last two days.
I have continued writing on the documentation, which I still hope to finish somewhere in my lifetime.
Litte progress on the documentation, but I fixed an alignment problem in the panel2.cfg parser.
I fixed some alignment issues in the panel2.cfg parser. Basically, the Origin parameter in the [This] section did not work properly. I have now also added the X value of the Origin parameter, which was previously lacking completely. The Y-difference between Origin and Center will now result in pitch changes and the X-difference as yaw changes. Additionally, I introduced the Yaw parameter to the [View] section in the panel.cfg file to achieve the same possibility with the panel.cfg.
➟ Go back to October 2008.
➟ Proceed to December 2008.
|
|
