➟ Proceed to July 2009.
To make it short, I have implemented this optimization technique, and am impressed by the performance boost this gives. I have observed anything from 10% to 50% increases in frame rates, depending on the route used. A small bottleneck is that loading routes takes a bit longer due to the optimizations that are carried out. For most routes, this is negligible, but on others, the loading process takes significantly longer.
Eventually, the current openBVE 1 code base will be thrown away, but until openBVE 2 is ready, it will take some time, presumably until somewhere next year. I find it to be a wasted effort continuing to add to openBVE 1 for this reason, but there is something that would have been a wasted effort not to add: 3D cabs. Since the beginning, openBVE 1 internally stores 3D cabs, but does not yet expose any formats to fully utilize them. As a consequence, I have decided to make the relatively small effort to fully expose 3D cabs in openBVE 1 via the animated object format. I have made some minor programming, and as a consequence, there can now be a panel.animated file in the train folder, which takes precedence over panel2.cfg and panel.cfg, and it is really just an ordinary animated object file. There will need to be some additions to the set of variables in animated object so that power levers etc. can be fully animated. I have started a thread on the forum to discuss these additions. The renderer needed to undergo some changes. Previously, the renderer kept track of faces to be rendered in four distinct layers: opaque, transparent, alpha and overlay. The first three are for world objects, while the overlay layer is for flat cabs. The overlay layer is always rendered on top of the scenery so that objects like rain or tunnel walls cannot be accidentally rendered in front of the panel. However, with 3D cabs, this approach does not fully work as faces are not necessarily parallel, which was the assumption with the overlay layer. As such, I have adapted the renderer to have six layers now, namely opaque, transparent and alpha, all three in both scenery and overlay variants. The scenery layers are rendered first, then are the overlay layers. There is some special code to handle flat panels (with parallel faces) just as efficiently as before, so legacy panels will not have any performance drawbacks. Camera restriction is not present in 3D cabs, obviously, but there are some other changes as well. First of all, the ATS/ATC lamps that are part of the in-game UI are now gone for 3D cabs. The reason is simply that legacy cabs were never given the ability to include those lamps directly in the panel. For increased realism, there should be no UI elements whatsoever, and as a first step, any 3D cab which wants to use the default safety systems will need to provide its own lamps as part of the cab, just as any panel which uses a custom plugin needs to do, too, anyway. Personally, I would like to abandon power/brake/reverser and door indicators, too, for the simple reason that those things should be part of the cab. However, I leave this to public discussion on the forum. The current plan is that there will be a development series v1.1 which will be open to public testing, is adapted to the needs, and will eventually result in a stable v1.2 series. I expect the v1.1 series to debut within this month, and the stable v1.2 series somewhere between July and August.
How is openBVE 2 progressing, you might wonder. Well, as I am about to implement the most delicate part of it - the renderer - it is taking some time. In openBVE 1, objects are managed based on their track position, implying a 1D world of non-intersecting track. For example, it is not possible to form a loop and pass below or above previous parts of the rails as their track position would be considered to be behind the camera. To allow for a truly 2D world with a free roving camera, I am considering a grid-based or quad-tree-based approach instead of using track positions. Of course, there are some design choices to be made, which is why I am taking my time to do this part right. Assuming that we only had opaque faces, things are almost straight-forward. Assuming that the world is devided into a grid of squares (or rectangles), and assuming that every polygon can be uniquely assigned to a block (because it does not span into any other block), then a post-processing step after loading the route would simply create a list of objects that are associated to a particular block. Whenever that block is in visual range, a display list would be compiled and could be reused for the duration of visibility of that block. Only blocks that come into visual range would need to create their display lists anew. The rendering order of blocks would not matter anyway with opaque faces, but preferrably near to far to make good use of the z-buffer. A small problem arises however when the assumption that each object is uniquely inside one block fails. If the block the object is associated to is not considered in visual range, but the object itself would be, then that object might be rendered too late. If each of those objects would be attached to multiple blocks, the object might be rendered multiple times unless this situation is specially handled, which is unlikely to be efficient with the idea of display lists that don't change. To make a long story short, I will come directly to my conclusion. Every object will still be assigned a unique block even if it extends onto other blocks. However, each block computes its geometric center and circumcircle that encapsulates all associated object. Checking whether a block is in visual range is easy that way, but the block might be a bit larger just to accomodate some overhanging objects. This should not generally be a problem as I would not expect a single face to span more than a few (dozen) meters. Animated objects, e.g. moving or rotating objects, are quite easy to handle as long as they are opaque as well. As long as they are in visual range, each animated object can be one display list which can be moved and rotated in its correct position by using a matrix transformation on the entire display list, which is easy to do with OpenGL, and has no performance implications. To summarize, a good renderer is easy to create as long as everything stays opaque. The actual problem arises, of course, with transparent faces, meaning those with anything in-between full opaqueness and full transparency, i.e. alpha. I am not going to spare you the long story on this. Depth sorting has always been a problem, and if one wants to optimize for display lists, then things simply are not allowed to change very often. If I needed to recreate a display list every frame, that would be equivalent to using immediate mode. A grid-based object management leads to the idea of rendering blocks from far to near. Assuming that there is only one alpha face inside a block, and assuming that such faces only exist within a single block without overhanging, such a method can be made working by carefully determining the rendering order of the blocks. Unfortunately, neither needs there be just one alpha face inside one block, nor do faces need to exist inside just one block. Things get more complicated when considering that animated objects (including train exteriors) can move and rotate freely in the scene, which obviously can change the rendering order. More importantly, static scenery and animated objects cannot be rendered separately, but need to be rendered in an interleaved fashion, i.e. all faces that are alpha need to be considered in a single step. I am not aware of a perfect real-time solution for depth sorting. However, the rendering order is unlikely to change every frame, and even if something changes, it will only affect a few number of faces at a time. As such, I would want to split the list of all alpha faces into multiple sections, depth sort the entire list on every frame, and only if any of the sections actually change between frames, recreate a display list, where there would be one display list per such section. The sections themselves could be simply rendered in order. This basically addresses the problem of change in conjunction with display lists as long as changes don't occur frequently, but does not address the actual depth sorting. Just as currently depth sorting is not perfect, it won't be either in openBVE 2.
➟ Proceed to July 2009. |