VR-Forces 4.3.1 is a major maintenance release that greatly improves VR-Forces 3D visualization while simultaneously fixes a number of important defects.
VR-Forces is built using the VR-Vantage graphics engine. This release incorporates the significant improves to visualization found in VR-Vantage 2.0.1, such as:
We've just launched RadarFX, our new Synthetic Aperture Radar (SAR) simulation and visualization product! We built it in conjunction with our partner, JRM Technologies.
In the real world, a SAR sensor is typically attached to an aircraft or satellite. A SAR system generates photograph-like still images of a target area by combining radar return data collected from multiple antenna locations along a path of flight. Requests from users on the ground define the target area to be scanned, and other parameters used to generate and return the image.
To draw a frame, VR-Vantage needs to a) build/update the scene graph, b) organize the scene graph and send it to the GPU, and c) have the GPU render the scene. There are a bunch of other steps like loading terrain from disk (or across the network), processing network packages (DIS/HLA or CIGI), but for the most part those occur in other threads. I will address each of these issues in future posts. For the moment, let’s just focus on static scenes devoid of entities. Let’s look at *this* scene:
We are excited to release VR-Exchange 2.4, a major feature release that enforces our commitment to supporting the latest protocols and the largest exercises with MÄK products. Here are a few of the changes we made with this release:
A week ago, I wrote a blog entitled “Do I need a new graphics card?” to answer the common question: Will I get better performance if I just upgrade my graphics card? In the blog, I discussed the difference between CPU and GPU bound scenes, and made the point that if you are CPU bound, getting a new graphics card will not help much. Typically scene performance will improve more with better terrain organization.
While that is all true, there is one additional problem you may encounter that will spoil performance and can be addressed by upgrading hardware: running out of video memory. VR-Vantage 2.0.1 now tracks your total video memory, how much you are using, and if any of your textures have been pushed out of memory (evictions). Once you have consumed all of your video memory, the card will start swapping textures off the card and into the system memory. This is incredibly slow and will seriously affect frame rate. Scenes that were fast may all of a sudden have a 100ms draw time.
To see how your scene is performing, turn on your Performance Statistics Overlay (found in Display Settings -> Render Settings). You would want to see something below 80% usage. As you move around in your scene, if the memory consumption gets up to 100%, or you start seeing Evictions, then your performance is being seriously affected by a lack of memory.
Frequently we get questions about hardware requirements for customers who are trying to use VR-Vantage as an IG for a specific program. Typically, the customer is looking to achieve 60 frames per second (FPS) in VR-Vantage and their scene is rendering slower than they would like/expect. They have read the MÄK Blog about minimum hardware yet didn’t find the answer they were looking for.
Over the years, many of us have been conditioned to assume that buying newer/better hardware will yield better performance; if your performance isn’t up to snuff, just buy something newer. This often works – new GPUs are released yearly, often with phenomenal performance improvements. The cost for this new hardware is low compared to the total program cost, so upgrading can make sense. That said, most terrains used in the Modeling & Simulation community aren’t particularly complicated and so should run really fast even on old hardware. So how can you figure out if it’s your terrain that is slowing you down or if it’s your graphics card that is the culprit? This blog will try to answer that question for you.
To understand where your bottleneck is, you need to understand if your application is CPU or GPU bound. For this blog I will use the term “CPU” to mean not just the physical processor, but also the process of organizing and passing information to the GPU. Simply put, VR-Vantage can be bottlenecked in many places: collecting information from the network, updating the scene graph, sending information to the GPU, or the GPU itself may be bottlenecked trying to render the actual scene. Of these possible bottlenecks, upgrading your video card will only help the final case. That means if your scene is slow for any reason besides the final render step, you need to optimize your scene’s content and configuration, not by buying a better graphics card.
Last week, MÄK was pretty excited to release of VR-Forces 4.0.3, which included HLA Evolved support! At this point the complete MÄK Product lineup supports the latest version of the HLA Standard.
This means that users who want to build federations that take advantage of FOM Modules and other HLA Evolved features will now be able to do it with VR-Forces. FOM Modules is a particularly powerful feature. It allows subgroups of Federates in a larger Federation to share FOM extensions without propagating the FOM extensions to everyone; most federates that don’t use the module can completely ignore it knowing that they will get the information they require in the base FOM, while the subgroup will get information from the base FOM as well as the model.
While FOM Modules and other compelling features are encouraging several major sectors of the HLA market to move to HLA Evolved, many existing federations remain firmly tied to HLA 1.3 or DIS. VR-Forces remains firmly committed to supporting each of these interoperability choices. You can rest assured, whichever simulation interoperability choices you make, MÄK stands behind you.