There are many topics and discussions on this subject, but rather than append this to one or more of them, I thought I’d create a topic specifically aimed at suggestions for LM to consider to assist with the usability of Prepar3D V5. While I don’t assume I have ideas that LM hasn’t had, it seems better to share than sit silently, so here you go…
Fundamentally, this is a User Experience issue rather than a VRAM issue. In almost all current DX12 titles, there are two key features that developers have included in order to assist in managing VRAM in the DX12 environment. I would like to strongly encourage the LM team to consider these for subsequent version updates of V5: VRAM Budget Calculator & VRAM Over-Budget Management.
First up is the VRAM Budget Calculator. Basically, it is a horizontal bar graph style indicator (or similar display) included in the settings menu that displays in real terms the VRAM implication of each setting choice made by the user. I have spent the last six weeks learning how not to crash v5 by learning what the VRAM implications of each setting are – Enhanced Atmospherics at Low, Medium, High, Ultra; Textures at 1024, 2048 and 4096; LOD at Medium and High; Shadows on or off for various objects (simobjects, vegetation, buildings, etc); Dynamic Lighting on or off; HDR on or off; water quality; antialiasing (2xSSAA, 4xSSAA, 8xMSAA, etc); AI traffic. Each and every one of these uses a discreet amount of VRAM, yet there is no way from a UX perspective to know how much is too much without trial and error; and unfortunately, the ‘error’ results in a CTD 9 out of 10 times, creating corruption and lots of frustration. Here’s are two great examples of how other DX12 titles offer the user guidance on VRAM:
and
Basically, just a meter that tells you how much VRAM you’re going to use with these settings at the current location in the current aircraft. Without this capability, v5 presents a very negative user experience because the user is left to guess what the usability implications are of given settings. This is a function of DX12, since in DX11 the OS managed the VRAM budget and shipped textures to the shared GPU memory as Beau explained early on. With DX12 the responsibility for this is with the application, so the application needs to provide the user with the information to make informed settings choices.
Second up is VRAM Over-Budget Management. Again, in all other DX12 titles that I’ve used, the application does NOT crash to the desktop or fail the GPU when the VRAM budget is exceeded. This, again, is simply a User Experience issue. The developers of other DX12 titles have built in the capability for the application to actively manage VRAM utilization by removing or downscaling textures or other capabilities to live within the VRAM budget available to the application. As an example, I’m flying along using 4.0/7.1GB and I start my descent towards Los Angeles. As textures, traffic, buildings and other objects begin to render, my VRAM starts creeping up. I have no way of knowing how high it will go in advance. When the VRAM bucket fills up, the application should employ logic to dynamically reduce texture qualities or features in order to preserve the integrity of the application, rather than simply letting it crash with a device failure. At 6.5GB/7.1GB, if 0.9GB of textures need to be loaded, the application should say, ‘wait, I need more space, I am reducing Enhanced Atmospherics from High to Medium to gain back 0.5GB to make space, now I can load the textures…’ and so on; this should be a dynamic, temporary adjustment that is reversed when budget is available. A simple hierarchy can be built to enable the application to choose what to change, on the fly, in order to satisfy the VRAM requirement – and in the meantime, it can NOT load the textures that will push it over budget. The application knows how much VRAM is available, it knows what it needs to load next, so it can calculate whether this will result in a crash or not before it happens – now it just needs the logic to make that adjustment. Again, this is a typical feature of every other DX12 application I’ve used and I can’t imagine a reason why this would not be possible for Prepar3D v5.
While I’m sure there are others, these are two core UX features that should be considered as mandatory when developing in DX12. The advancements in v5 are fantastic and the team should be proud of the progress; the performance improvements are real, and the addition of Enhanced Atmospherics and WaterWorks is fantastic. Now we just need some UX enhancements to allow the user to make educated settings choices and to prevent the application from going over the VRAM budget. Hopefully this is helpful and directional for the team and I’m looking forward to seeing what’s improved in HF2 and future sub-versions of Prepar3D v5.
