Chicago O'Hare V2 will be the first result of our previous announcement about dropping support for old 32 bit simulators and concentrating on Prepar3D4:
http://www.fsdreamteam.com/forum/index.php/topic,16116.0.htmlWe believe that, once this will be released, users will understand the importance of this decision, that we shared with other highly regarded developers, and why we were always been hampered by the requirement to remain compatible with FSX, even in the latest sceneries (KMEM, KCLT, KSDF) that had several P3D enhancements, but were still made to be backward compatible.
This is our first scenery that not only couldn't be made with FSX, but doesn't come with any of the previous baggage or old legacy code. It's not something just recompiled with with the P3D4 SDK, but it really *exploits* what P3D4 has to offer to the fullests, and has been designed from the ground up to work in P3D4 only.
Let starts with the most important benefits:
Ground texturesAs discussed in this thread:
http://www.fsdreamteam.com/forum/index.php/topic,17445.msg122378.html#msg122378Since FSX, all developers always faced with several equally disappointing alternatives, either using slow FS8 code, or use very fast FSX code that would cause heavy flickering if the polygons are not "cured" in realtime while flying, or having issues of visible raised layers. Since we usually do large airports for big liners, we always prioritize fps, which required to use FSX materials and act with the software to prevent flickering, but this couldn't always work, especially when using non-standard cameras, or with some other 3rd party addons. But the alternative to get back to ancient FS8 code was an even worse choice, in our view.
Doing something native for P3D4, without worrying to port it to FSX, will fix the issue once and forever. The ground scenery will be made with native P3D4 code, with no requirement of having to adjust the ground polygons height in real-time, which will fix all flickering issues and will allow the sim to load the scenery faster and in multi-threading, since we'll just use a standard .BGL for the ground textures, with no fancy extra processing required.
Thanks to P3DV4 LUA scripting, we'll have multi-seasonal variations and other changes, like variable water puddles, using just 100% standard SDK methods.
Multiple UV ChannelsAlthough this might seem a very minor tech detail, it's probably one of the biggest deals, that had the most profound impact on design, and it's what prevents a conversion to FSX. P3DV4 is the only sim that allows to specify a 2nd channel for UV Mapping, and we are using it to fix one of the biggest headaches in airport design.
Before, developers had to face a very hard choice, between making a scenery with high resolution textures, which would otherwise look very repetitive, or having larger scale details, adding "personality" like dirt, oil marks, scratches, baked ambient occlusion, with a lower resolution. When trying to do BOTH, it would come at a significant performance cost, since the usual method until today was to have separate layers with stacked polygons and different materials, one for the base (repetitive) texture, and another (or even more of them), added on top of it, for the added details. Stacked polygons and overlapped materials have a cost in fps.
With P3D and multiple UV channels, you can eat your cake and have it too, because there's NO added polygons or multiple materials: the blending between the repetitive base and the personality details will be made by the Shaders provided by the sim itself, running highly optimized GPU code, instead of adding polygons and materials so, everything it's as fast as it can be, without having to choose between resolution and preventing repetition.
DirectX 11 C++ renderingThis is the feature we are most proud of, and I daresay NO scenery out there has ever tried this. Until today, trying to draw text in the sim has been extremely painful, and made with very inefficient methods. Let's take the GSX Docking System, for example. In order to draw different textual information, it has to use LOTS of parts that are switched on/off, depending on the value of some variable, the so called "visibility scripts", and each time we need to add a new kind of information, such as the name of a new airplane model, a new part must be added, increasing their number, without even counting the inconvenience of having to re-export the model again, and distribute it to users. And the code it's very inefficient code, since we first must set a variable in the sim (using either Simconnect or the Gauge interface), then the sim will have to run the script, which is parsed AT EVERY FRAME, to check the variable and turn on/off the different parts, depending on the value of the variable. We have over 160 different parts in the GSX Docking System! Visibility scripts can be costly, that's why a complex airplane with hundreds of moving parts in the VC will slow down your fps: the script checking the visibility and the animations takes its toll on performances, even if the parts themselves might not be very complex.
With P3DV4, the native PDK (Plugin Dev Kit), allows to Render To Texture, meaning a C++ plugin can use native DirectX 11 code to write directly inside a texture! Instead of hundreds of polygons that will be turned on/off by a slow interpreted visibility script, we just render the texture over a single polygon, just like the sim does, with blazing fast compiled C++ code. And we can write whatever we like to, using any font family, style, color, etc.
With O'Hare, we are using DirectX 11 for the following, never seen before, features:
Working Information panels As seen in the video, for the first time ever, an airport scenery has working info panels that displays informations about the gate, like their real life counterparts. They alternate between showing temp/pressure, INS stand coordinates, Flightplans with DEP/DEST airport and ETD for AI planes, and DEP/DEST airports for the User Airplane, if a standard Flight Plan is active.
Thanks to the deep integration of all our software, they cooperate nicely with GSX so, for example, stand INS coordinates are filled up automatically from the scenery AFCAD parking position, since GSX already got that data from the AFCAD (and it will update automatically if the parking is edited), and if GSX is doing an operation, the Info display will show the progress for the current GSX operation, so you'll know when (for example) Boarding has completed, without having to open the GSX menu, which will add to the immersion factor.
This is also highly optimized in C++, so we have about 150 Info Panels all over the airport, all working with AI and the user airplane, with no visible impact on fps, because only the closest ones to your own viewpoint will be updated, and we also simulated a visual cone of view, like a real screen, to optimize the viewing distance even more.
Individual gate numbers on Jetways While this feature has already been seen on other sceneries, not many of them have 170+ jetways like O'Hare so, if we tried to do it in the "normal" way, the fps cost would have been extremely high, because each individual gate number indicator would have to be a different object, mapped to a different portion of a texture, and possibly the whole jetway would have to be modeled individually. No chance to do this on O'Hare, with so many jetways so, if we had to do the scenery for FSX too, we would probably cut out the individual numbers on jetways.
Instead, thanks to our new DirectX11 Render To Texture text engine, and in combination with a new feature in SODE that allows to model a jetway to be a combination of multiple modular elements, we gained a lot of benefits, both in performances AND in ease of development because:
- Instead of modeling each jetway individually, the number indicator is a separate object. But that's just the first optimization.
- Instead of having many number indicators, all identical except the texture mapping to display the right gate number, we just WRITE the Gate Number itself into the (single) object. GSX already knows the gate number so, what's better than that ? And we can use any font family installed in the system, in every possible style and combination of background and foreground colors, all in blazing fast C++ DirectX 11 code, which it's even faster, considering that jetway numbers don't update either, so the text it's drawn only once when the scenery loads, then it has absolutely zero fps impact. And, if the Gate Number would ever change for any reason (new AFCAD, user edits), the number on jetway will change too, automatically.
