Periodically, MÄK reassesses platform support for our product line. We consider a platform a paired version of compiler and OS. For example, Windows 7 and MSVC++ 8 is a single platform, while Windows 7 and MSVC++9 is a different platform.  In order to support the most popular and stable platforms while maintaining commitment to quality products, we need to limit the total number of platforms we support as part of the standard product offering.

In general, when deciding to support or not support a platform we consider a number of factors:

I am pleased to announce the extension of the VR-Forces 3.12.x maintenance period to December 31st, 2012. While we have seen many customers quickly migrating to the VR-Forces 4.x platform, MÄK understands there are still many other customers who face complex schedules and tight budgets who have not been able to upgrade their VR-Forces 3.x based products yet. As a customer focused company, it’s MÄK’s goal to be as responsive as possible to customer needs. We believe this extension will provide the time needed for many customers to upgrade while still supporting existing systems. 

Of course, MÄK is also committed to helping our customers understand the upgrade process. VR-Forces 4.x has a completely improved and redesigned front end, so we understand the upgrade process can be intimidating. MÄK is currently helping customers understand and work through the challenges faced by an upgrade - we want to help you too. While we are helping customers through the normal support channels (support@mak.com), we are also proactively helping through private customer-focused webinars and customer visits. If you are interested in working with us through any of these processes, please don’t hesitate to contact your sales representative (sales@mak.com).  

Today I wanted to give you another glimpse of some technology which is coming to MAK products like VR-Forces and VR-Vantage: streaming feature data.

Future versions of VR-TheWorld server will be able to load and stream geospatial feature data, including VMAP, .shape, and S57, among others. There are many applications for streaming feature data, but one of the better ones is to use to to generate richer terrains from raw source data. Currently VR-The World, VR-Vantage, and VR-Forces support streaming imagery and elevation source data. Adding streaming feature data will allow for the automatic extrusions of buildings and the placement of line, point, and areal models on top of the streamed imagery. It means when you walk off your embedded hand modeled open flight terrain (See Blog “How to get your terrain embed”), you will still be in a 3D world full of fairly rich objects.

By Brett Wiesner - We know we needed to get a linux build of VR-Vantage out to customers ASAP but we felt like sneaking in a few more features along the way was a good idea. We will release VR-Vantage 1.3.1 around the end of July with support for Red Hat Enterprise Linux 5 and also some great new capabilities like zoom and terrain scaling.

With zoom, you can magnify the view and see things that are far away without changing the observers location. This is useful for UAV sensor applications, ground based binocular views or even periscopes!

If you have upgraded to a new version of the MAK RTI, you have probably noticed that the RTI include paths have changed. This means that MS Visual Studio project files which worked with pre 4.0 RTI versions likely no longer work. This problem manifests itself when your previously compiling application can no longer find RTI.hh or some other standard RTI header file.

Recently we have been seeing widespread Windows 7 adoption by our customers, we are internally moving to it too. However, we have noticed some very strange behavior on Windows 7 with some of our applications.

The most significant problem we have run into is extremely slow startup times for the MAK RTI. This problem is usually obvious; the RTI Assistant will take between 3 and 15 minutes to load.

As many of you may have seen, we just released MAK RTI version 4.0.1. This release fixed two significant problems with MAK RTI version 4.0 on Linux. We recommend all customers who are using version 4.0 move quickly to version 4.0.1 to prevent additional problems. Today I wanted to take a moment and explain in more detail the nature of the problems.

Recently one of our customers contacted us for consulting on how to setup a large federation that would scale up to 1000 federates. Here is how we setup their federation for scaling to large numbers of federates.

Upon first arriving, we took a look at their Federation Object Model (FOM) to get an idea of what types of objects and interactions they were sending through the RTI and how much data was being used.

Occasionally we receive a support request asking for the latency of a message in the RTI.  Answering these questions is difficult as there are many factors which can affect RTI latency. Not least of these is the network itself and the tick rate of the federate. These are probably the two largest factors in determining latency.

Frequently people write to support and say “My RTI Crashed!”, or they write “I have 10 federates, and the RTI is installed on Machine X.” When I read sentences like these I sometimes cringe. I cringe because RTIs really don’t crash; a component of your RTI crashed. Maybe I cringe because I have been working with RTIs for a very long time.