Features

Make-believe Tanks: a Report from the Trenches of the VizSim Industry

Every training simulator has one or more instructor station computers. These computers and the software they run allow the instructor to create missions for the trainees to fulfill. This pretty much works like what you know from the mission preparation mode some tactical games feature. The instructor has a 2D or 3D tactical map of the world. It places AI enemies, determines their paths and how they react to events in the world. One example would be to tell an AI to open fire once it has a line of sight to a simulator. Further on the instructor may create obstacles like mine fields and other obstacles. Obviously civil simulators feature different mission goals.

Most instructor stations also have one or two computers visualizing 3D views as seen from inside the simulator. The instructor can either freely move around the world with a 3D mouse or attach to a vehicle or even switch to a mimic view from inside a vehicle.

The software responsible for rendering 3D real-time views is called CIG (Computer Image Generator) or simply IG, but is not called a render engine.

Most VizSim CIGs use a scene graph API of some flavor (e.g. VegaPrime from MultiGen www.multigen.com, Performer from SGI, or open source alternative e.g. OSG http://www.openscenegraph.org/). For those of you who are not familiar with scene graphs, it is a description of the world to render. The scene data is kept in a tree-like data structure. In the VizSim world SceneGraph APIs are usually prepared to use multiple processors or cores. A typical setup uses two threads each using one processor or core. Thread one does the culling, network polling and simulation for the next frame while thread two feeds OpenGL or D3D with the output from the culling thread from the previous frame.

On the hardware side, the VizSim people used to use multi-processor SGI hardware and often proprietary graphics hardware (costing $500,000 or more). When SGI went down and market pressure increased for more affordable hardware, this changed. High-end dual processor PCs with the highest-end graphics cards are now used.

When I joined the visualization team, it was using two commercially available SceneGraph APIs. They had lots of problems with code that worked around flaws and bugs inside these APIs. I was assigned the task to produce a prototype for a project that had to replace old custom CIG hardware with a PC-based CIG. It became pretty clear soon that none of the APIs used was able to give us enough performance, so we started to look for alternatives on the open source side.

In the VizSim world the most commonly used standard for 3D scenes/levels, or databases as VizSim people call them, is the OpenFlight file format from MultiGen. All open source solutions we looked at did back then did not have a loader that could load and display our reference databases without errors. In addition to that, their performance was not very encouraging.

We had implemented several render engines on top of OpenGL and D3D before. One of us started to implement an OpenFlight loader when all people that could say no were on holiday. After having implemented a basic loader we wrote code to optimize the resulting SceneGraph for throwing optimized geometry patches at OpenGL. It all worked out fine and after changing our code to use two processors/ threads we had twice the frame rate that the other APIs could produce.

The custom SceneGraph API is still used in its 3rd iteration now using cg, and OpenGLslang. Nobody has ever thought it was a bad idea to have a custom API. Especially as we had to pay a license fee for every computer we had to deploy the commercial scene graph software on.

The render engine business for simulators has in general the same goals as in the games industry. The pictures produced should look as real as possible and as nice and cool as possible. There are some differences though:

• We needed at last resolution 1280x1024 with at least 4xAA at constant frame rate of 60 or 30 fps. Anti-aliasing is very important for the VizSim industry and flickering artifacts due to aliasing are not acceptable.
  
• To further make life unpleasant we had to support a far clipping plane of generally 5.5kms or even more.
  
• In addition to a very large viewing distance we had to also render things near the camera e.g. the hull of the simulated tank.
  
  Optical devices in the tanks do provide views with very high magnification factors. Customers simply don't accept flickering artifacts that come from less than optimal z-buffer resolution at over 5000 meters. Therefore you have to find solutions to cope with these requirements. Just think about what these z-buffer issues do to techniques like stencil shadow or (post perspective) shadow maps.
  
• LOD is also one thing that is handled differently; it is in general not acceptable for LOD to spoil mutual line of sights. If one opponent sees you it is not allowed that a view dependent LOD algorithm prevents you from seeing the opponent and vice versa. I leave it to you to work out how that affects LOD construction and selection.
  
• Projection of views by projectors on non-planar projection screens have to be implemented. Since geometry-correcting projectors are extremely expensive, other solutions had to be found. Therefore we had to deal with edge blending and geometry correction in the CIG software. In addition to that, channels need to be in sync to provide one stable big virtual image.

All the requirements listed so far make it a challenge to design good CIGs for simulators. There is pressure to have the same quality and richness of effects in the simulators that games provide and we've already done our share to rectify that. We've even brought motion-captured, bone-animated and skinned characters to the VizSim world. We were , on the other hand, constantly fill-rate and/or memory limited, so every additional texture or pixel-shader/fragment-program instructions did hurt. It doesn't matter if the frame rate of a computer game fluctuates and even if it is jerky occasionally this is no killer for a game. Unfortunately this is not acceptable in the VizSim industry.

I've already talked about DIS. DIS defines a standard UDP datagrams that potentially allows plugging simulators from different vendors together into one simulation. Imagine being able to plug together game worlds from completely different game vendors to start a multi-player match. All types of vehicles and effects are covered by DIS there are even datagrams to describe flocks of shrimp – obviously for submarine simulation.

The problem keeping positions of distributed entities is solved in DIS via a mechanism that is also known to the games industry, the so called dead reckoning. The software managing an entity sends out position updates only if it knows that an extrapolation based on the previously sent position and speed generates an error bigger than an acceptable threshold. The jumps in position that happen when a new update comes are usually smoothed away on the CIG computers that also do the extrapolation.

Besides DIS custom RPC protocols are used that allow the simulation computers to talk to the CIG computers. For the project I worked on, I implemented a layer that accumulates RPC call and sends them all out at once via multicasting to 13 CIG computer displaying different views from inside the tank. The protocol is optimized to minimize handshakes between the simulation and the visualization.

As mentioned above, levels are called databases and are very big compared to most game worlds. In the VizSim industry the process to create databases and models like tanks, houses, vehicles and even human characters is more an engineering process than the creation of art. Textures are always scanned in. Models are built to match the dimensions of the original. Database creation is extremely expensive and the outcome can't compare to game assets. This is why most simulators don't look as good as games. You still see simulators with shoebox houses. The VizSim industry has so far not realized that it would need some paradigm shift to also embrace database creation as a process of creating art to achieve the quality of game assets. Game developers seem to be more personally involved with what they work on, whereas VizSim people just seem to do a job.

The tool used for database creation are tools that work on the OpenFlight™ file format and come from MultiGen. For newer and more detailed databases a Tool called TerraVista is used to transform height and features information to a set of OpenFlight™ tiles.

We have brought Maya on stage because we wanted properly animated characters, but it is only used for characters animation purposes and not for building databases or other objects. Character animation is another technology that is not up to game standards in the VizSim world. There actually is VizSim middleware like DI-Guy (www.bdi.com) for character animation, but they have just recently discovered things like facial animation or properly skinned characters.

Another thing we've tackled is automatic replacement of scene graph nodes containing trees with SpeedTree™ trees. Unfortunately we could only use this for demos because the in-house spatial index software could not be easily adapted to perform line of sight calculations with these trees – sigh!

The games community has started to take a more formal look at game projects and to treat them as software projects using techniques and processes from software engineering.

Software process is something the VizSim industry can't be imagined without, at least the military projects. It was actually the customers of the project I worked on that prescribed what kind of software process was needed in order to get the contract. It was a big issue to show that the in-house process could be mapped to their process and that we were compliant.

We really had requirements databases and documents describing in detail what each part of the simulators was supposed to do. Customers and their consultants did reviews of the design documents and the requirements. They also setup their own test procedures to finally test the system. These tests included full load and 24-48 hours tests to see if the system could really cope with a full day of training sessions.

Since I was in charge of the CIG subsystems for military simulators I also worked as an analyst transforming top-level customer requirements into testable and readable requirements. This is something I've never experienced in the game companies I've worked for – what comes close to this might be a good game design document.

The processes used are pretty rigid and old fashioned but that's how things work in the military business. It sometimes even seems as if all documents are only produced to keep the customer happy but not to increase the quality of the software. Note to never say ‘rapid development,' ‘agile methods' or ‘postmortem' – these are evil terms.

Company Culture

Just a few words about the company culture I experienced. Many VizSim industry companies are pretty big and have seem to have a big set of partially contradicting rules and regulations that make them shoot themselves in the foot from time to time. If you change from a small self-motivated team to a bigger company you have to prepare for a culture shock. Make sure to read The Career Programmer: Guerilla Tactics for an Imperfect World by Christopher Duncan before considering a move like that.

A remark that only applies to some VizSim industry companies: Hardware manufacturers have not realized that what actually gives their products a competitive edge is increasingly realized in software. They have already, without their knowledge, transformed into software companies or are on their way to become a software company. The thing is that they don't know about software engineering but only about building hardware and it sometimes shows.

_____________________________________________________

[back to] Instructor

join | contact us | advertise | write | my profile
news | features | companies | jobs | resumes | education | product guide | projects | store



Copyright © 2005 CMP Media LLC

privacy policy | terms of service