We are still waiting on some use cases with people’s settings used. We haven’t received any yet on our discord ticketing system were we can help you out and step through this in a programmatic way. Without this detail we cant progress. NZCH works well on the majority of systems and during our testing. Everyone’s setups are very different as we know. People are running all sorts of things from traffic mods, GSX, heavy CPU and main thread hitters like the Fenix a320, photogrammetry on, Other Simconnect modules.
We are looking at constructing a version that has a reduced draw call count, while this work is a priority this will be available in time but at the moment our workload is focused on fixing our other products first that were hit by the WU photogrammetry and other changes. 98% of our customer base is using NZCH with no issues but we do acknowledge there are a few who want to be able to turn things down because of the way they operate their system configuration. We will do something here.
Verticies testing with the engine doesn’t have a large impact on FPS due to the way the Asobo engine handles vertices. Reducing interior detail has little no to effect on the FPS and especially with the way we have LODed the whole interior(s). EG you’re not drawing interior models from other sides of the airport. For example, a cockpit will have several million vertices. I think you’re looking at around 20 -30,000 vertices per interior model in NZCH. Our world scripting system only uses about 2 fps for all of the world vehicle and people animations. This really leaves two things, VRAM texturing or draw call count.
VRAM and memory usage has been run through, the texturing used is only about 300-350mb, projected mesh is around 800mb however is tied to the Terrain Level of Detail scaler and is well optimised with the way the engine loads ground texture detailing through qaudtree divisible load scaling.
Second thing is the draw call count. Being that the larger number of objects and the LOD system needs to bring these in and out of display but it does also need to understand that these objects are still addressable on the load table.
I am pasting this MSFS performance section from our website just as a FYI. Also at the bottom there is what us developers use to run our developments against when it comes to sliders and texture resolutions and the hidden normals, ORM maps.
MSFS Performance Guide
Performance
This performance guide is relevant to all aspects of Microsoft Flight Simulator 2020, not just NZA Simulation’s products.
NZA’s products use the latest in 2D and 3D technologies to ensure an airport that will look beautiful now and into the future. Because of this some low-end systems will notice a small performance hit when using our scenery.
Because of this we optimise it for “High End” pre-set for the majority of users with Mid to high-end PCs as per the MSFS SDK documentation using various LODs and optimisations.
If you are trying to run high-fidelity aircraft, scenery, photogrammetry and the base game itself all at the same time you may find you are running out of Video Memory, especially with 8GB or less of VRAM.
The simulator does a good job at handling this if the developers have optimised their add-on, but you may need to lower some settings in some areas of the world.
The following Settings in the simulator you may find useful:
- Object Level of Detail Slider – Adjusts the range objects will load in high resolution textures and high detail models. Our development process is optimised around an object LOD range setting of 100.
- Terrain Level of Detail – 100 is the default on High preset. With High Resolution Mesh data and Photogrammetry, even with a high end PC you may find that reducing this back down fixes a few issues. The Downside of this is the Apron textures are also affected. But we are working on assisting Asobo to split this out into separate sliders, however this is a massive engine change on their end.
- Texture Resolution – Will help with VRAM considerably. Ultra is full texture resolution, High is 0.5x Normal and ORM Textures, Medium & Low 0.5x the Base Colour textures also.
- Photogrammetry can use 2GB+ of Memory, if it’s not something you wish to use, it can be switched off in the Settings/Data Tab.
- If you have a Modern GPU (NVidia RTX) you can enable DLSS2.0/3.0 to get increased performance.
Note: Some users with high end GPUs, such as 3080ti’s have reported issues using GeForce Experience. This has fixed FPS issues for them. This is untested – maybe this could be due to running ShadowPlay and limited VRAM/Clock Speeds.
Reviewing Texture Quality And Memory Usage
When reviewing the texture quality in Microsoft Flight Simulator, it is important to be aware that the in-game graphics settings can affect this. The highest quality settings are meant for users with a top tier GPU, which typically have 8GB+ of GPU memory. The lowest quality settings are meant for users with a low-tier GPU, which could have as little as 2GB of GPU memory.
Microsoft Flight Simulator will automatically reduce the texture resolution of textures loaded into memory based on these in-game texture quality settings. This saves on the texture memory used for those with less GPU memory available but will result in a more “blurry” display when viewing up close. The table below describes how the texture quality level modifies the texture dimensions:
Quality |
Albedo |
Others |
ultra |
1x |
1x |
high |
1x |
0.5x |
med |
0.5x |
0.5x |
low |
0.5x |
0.25x |
A typical texture budgets for aircraft (including cockpits) is between 150MB for small aircraft and 600MB for large aircraft. Since the *.DDS
format is a GPU-ready format, the size of the textures on disk is more or less what the game will be using in texture memory. Thus, the texture memory used by your add-ons can easily be determined by looking at the package output’s texture folders.
Keep in mind that the above information is quite scalable when you start talking about loading lots and lots of mods. When you have a ton of mods all stacked on top of each other, and some developers not exactly adhering to standards.