When selling toolkits, we run into the same kind of problems that people selling hammers have. Most people won’t believe that the tool can build a house unless I show them a house built with the tool. With our software toolkits, many customers want to see the possibilities that the API is capable of. Because of this, many of the demos that we create have a touch of customization to them, some more than others. However, we always do it in a way that a customer can replicate when they are working with our APIs and we do it through the magic of plugins. Demos including dynamic terrain and video streaming are all implemented as plugins. (continued...)

On a quick walk around the show floor here at ITEC 2012 in London, I was excited to see the number of partners and other product vendors demonstrating new integrations between their products and ours:

1) Antycip Simulation is demonstrating a new dynamic ocean visualization plug-in to VR-Vantage, based on their MyOcean3D technology.  This plug-in generates realistic-looking waves by using fast-fourier-transform techniques to generate a dynamic height field, encoding the height field in a texture, and passing the texture to custom shader code running on the GPU.  The shader supports vertex displacement both vertically (for crests and troughs) and horizontally (for curling and breaking wave tips).  In the demonstration, a ship simulated by VR-Forces bobs and rocks realistically on the waves.  This is accomplished through a dynamic form of "ocean clamping", where a simple physics model is run in VR-Vantage to offset the ground-truth positions and orientations published over HLA by VR-Forces.  The MyOcean3D plug-in to VR-Vantage is already in use at one customer site, and we are interested in hearing whether you'd like to see this become part of the standard product offering.

The weather in Atlantic city is definitely IFR conditions ("Instrument Flight Rules" - or for us recovering army helicopter pilots, "I Follow Roads"). There's zero visibility and clouds all the way down to the surface. I'm not the least bit worried though, I'm at the Air Traffic Controller's Technical Symposium with a large number people who are used to landing aircraft of any size in these conditions.

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.

This is the 6th and final part in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. If you’re interested in learning how to make better use of your RID file, check out the previous posts in this series as well.

Part 1 – RID Consistency Checking
Part 2 – The Advantages of MTL
Part 3 – Utilize Environment Variables
Part 4 – Modularizing Your RID 
Part 5 – Programmatic Configuration 

Make sure you know what parameters your federate is actually using

Anyone who spends any time configuring RID files is bound to make a mistake from time to time. I know I do, and a large number of the questions we get in support are configuration issues as well. Even if you think you’ve setup your RID file correctly, there are some parameters that can be overridden by the RTI Assistant or programmatically by your federate code. That means examining the RID file doesn’t always tell you exactly how a federate is configured. So how can you tell? Well, there’s a RID parameter for that, of course!

This is part 5 in my series of blog posts on RTI RID configuration tips. Check out the previous posts in this series, and stay tuned for more to come.

Part 1 – RID Consistency Checking 

Part 2 – The Advantages of MTL

Part 3 – Utilize Environment Variables 

Part 4 – Modularizing Your RID 

Change RID parameters programmatically in HLA 1516-2000 and HLA Evolved

The RID file isn’t the only way to specify RTI configuration parameters. Many people don’t know that RID parameters can also be specified programmatically by the federate. Unfortunately there was no mechanism for this in the HLA 1.3 API, but in 1516-2000 such a mechanism was added, and the same idea was kept in HLA Evolved (though the API for it changed). In HLA 1516-2000 and HLA Evolved, the standard included a way to pass a string or series of strings to the RTI to be used in RTI initialization. Since RTI configuration is different for every RTI, the standard left it to RTI developers to determine how these strings were used. As a result, this is one of the few areas of the API that will work differently from RTI to RTI. So if your federate needs to operate with multiple RTIs, you may want to consider other configuration options or have a switch in your code based on what RTI you are using. So how can you use these strings with the MÄK RTI?

VR-Vantage 1.4 is here - bringing with it support for a new compiler MSVC++ 10 64 bit! This meant upgrading OpenSceneGraph (to version 3.0.1) and many other dependencies (Silverlining and DI-Guy for starters). Additionally a few smaller capabilities were added:

We now support HLA Evolved, allowing VR-Vantage applications to play in exercises with modular FOMs. We also added more examples and better documentation for the developer's toolkit (a trend you will see continue over the next several releases). There are also a few customer requests in here too: an object count panel, a space attach mode for attaching to satellites, an option for linear model scaling, and a way to use images for 2D symbols instead of fonts.

This is part 3 in my series of blog posts on RTI RID configuration tips. Each of these tips, unless otherwise noted, works in HLA 1.3, HLA 1516-2000, or HLA Evolved. Check out the previous posts in this series, and stay tuned for more to come.

Part 1 – RTI RID Configuration Tips: Consistency Checking

Part 2 – RTI RID Configuration Tips: the Advantages of MTL

Lookup environment variables within your RID

If you’ve followed me through parts 1 and 2 in this series, you may have noticed a theme: managing multiple RID files is a pain. Whether it’s ensuring consistency between the various RID files involved in a single federation, or maintaining separate configurations to be used in different federations, whenever you’re managing multiple RID files you’re bound to run into the occasional hiccup. The goal of these posts is to help you reduce these hiccups and help you identify them when they occur.

As anyone who has edited a RID file for the RTI can tell you, there are a lot of different parameters available to customize how you want the RTI to function. It can be pretty overwhelming. Over the years we’ve tried to make RTI configuration as simple as possible, while still preserving the ability for users to get their hands dirty with the nitty-gritty details of RTI operation. To this end we’ve tried to choose default settings that make sense, and we created the RTI Assistant to allow you to quickly and easily edit the most commonly used connection parameters from a simple GUI. Hopefully that helps many of you stay out of the RID file as much as possible, but chances are at some point you will have to take the plunge and delve into it. To help you out when that day comes, I’ll be writing a series of blog posts with tips and tricks that will hopefully come in handy. I’m not going to go through each parameter in detail. Instead I’m going to cover some general configuration techniques and tips on debugging potential RID issues. If you have a question about individual RID parameters, please see the back of the RTI Reference Manual or drop us an email at support@mak.com. Unless otherwise noted, all of the tips I’ll be discussing can be used for all HLA versions: HLA 1.3, HLA 1516-2000, and HLA Evolved.

During our work in the modeling and simulation space we're often introduced to some very cool technologies. Some are synergistic with MÄK's and others can be enhanced when used in combination with our own. 

One such technology was developed by a research corporation in upstate NY.  The innovation involves a unique approach speech synthesis.  It provides the ability to synthesize and manipulate natural sounding speech in multiple voices. The technology will allow users to synthesize a speaker from a short recorded sample and from that generate many hundreds of individual speakers. Ultimately, this will deceive a human listener into believing the synthesized speech was produced by a live human. This capability is of great interest to the intelligence community as it will help train linguists in the collection of accurate intelligence from communication intercepts and in the understanding of rare dialects.