VR-Vantage Performance Overview
This page is a high-level overview to help you answer the following questions:
Why isn’t VR-Vantage performing well?
How many copies of VR-Vantage can I run on a given machine? How many instances will I need?
Can I render X number of channels on this machine?
This topic applies to VR-Vantage, VR-Engage, and the VR-Forces GUI Engine.
Overview
3D graphics performance in VR-Vantage is complex and getting the specific answers to your questions above will often require you to understand how VR-Vantage works—to some degree—but also undertand your terrain composition and exactly what your requirements are. MAK is often not able to specifically answer “Can I get 60 Hz performance with this specific configuration” without a complete understanding of your program. We always recommend you try and play with things. This document is designed to help you get started.
User Documentation
Please note that the VR-Vantage User Guide and help have a chapter on VR-Vantage performance optimization (Chapter 9 in the PDF). Please read it. Most of the items listed in there are fairly detailed configuration options that impact performance, but often in minor ways. This document serves as a high-level overview.
Frame Rate and Scene Smoothness
3D graphics engines render frames. Each frame is a picture. Performance is often measured by two things: FPS (frames per second) and smoothness. Smoothness is generally measured by variation between two or more successive frame render times. So if you produce exactly one frame every 16 ms with no variance, you have a perfect 60 FPS scene. It will look smooth. If your frame production averages 16 ms per frame, you can still have a 60 FPS scene, but if the variance is extremely high—or contains random pauses—you will see stutter and the scene will not seem smooth. Some people report this as poor performance (it is, but you should note the difference).
The things needed to render a frame
To render a frame on your scene, the following steps need to happen:
Data Assembly
DISK access things:
Terrain needs to be loaded. If the terrain is paged, it's possible parts of the terrain need to be loaded from disk. This may or may not require work every frame.
Models need to be loaded. New models, like missiles or planes, appearing in the scene need to be loaded from disk. This may or may not require work every frame.
Network access things:
Model Positions need to be updated. This may or may not require work every frame.
CPU things:
The scene needs to be culled (on the CPU). You may have 100 miles of terrain loaded with thousands of models. There needs to be a general pass through the scene with some understanding of where the camera is looking to say, “I need this stuff over here, and not that stuff over there.” This happens on the CPU. There is GPU culling, but this is a very broad pass to generally figure out what is needed. This is a very important step
Data is passed to the GPU. This happens on the CPU. While this is a very complicated process with a lot of detail, it's important to note that the application will gather up assets, generate command lists for the GPU, and pass a bunch of stuff to the GPU.
GPU things:
The data that is passed to the GPU is stored in VRAM, culled, and rendered. Individual pixel colors are generated and a whole buffer is passed to the monitor to render the frame. There is amazing complexity here but, for the sake of understanding performance, you should understand that the GPU is doing a lot of work to assemble textures and generate pixels.
Hardware that impacts performance
Disk speed, System Memory, CPU speed, CPU threads, GPU video memory, GPU speed, all impact performance.
When your system isn’t performing well, typically one of the above things is limiting you. If you are limited by the CPU, adding a faster GPU or adding more GPU memory will not make your scene faster. If you are using a terrain database that is overly complicated with millions of small files in it, then adding a faster CPU or GPU will not help you. Knowing which will help you decide how you can improve things.
Generally, items 1 and 2 are limited by disk and CPU thread count. Items 4 and 5 are limited by CPU speed. Item number 6 is limited by GPU capabilities.
An underpowered GPU will generate crashes if there is not enough VRAM, but will also throttle total render time based on how many pixels need to be rendered. If you are driving 8k pixels with a lot of shading and complex textures, your GPU may be limited.
If you just have a lot of stuff in your scene and your terrain is poorly organized, then the CPU may be limited.
Measuring Performance
Measuring performance isn’t always easy, but here are some good ways to start. Press F2 multiple times until you see this display:
The performance overlay (above) will show you generally how much time per frame is being spent on the GPU (in orange). And the CPU (Cull/Draw). You have approximately 16ms to get a 60 Hz scene. In this picture, the engine is able to render a 60 Hz scene, but most of the time is spent on the GPU. To improve things significantly, it may make sense to upgrade the GPU. If the GPU time were 3 ms, and the Cull was 15 ms, then you have a problem where your scene is complex and improvements could come from a faster CPU clock, or a more optimized terrain.
In Summary
Understanding 3D performance is complicated, and this document is just the beginning. But please understand it and, when you work with us to understand more, you can see how these different constraints can impact your performance in different ways.