New FighterOps screenshots

[SUBS17]

Finally after a couple of quiet months XSI has finally released some more screenshots of placeholder 3d models. It sort of gives you an idea of the detail involved in making a buisy airfield.
http://www.fighterops.com/screenshots/P ... c2006.html

Check out the van , I wonder if its getting a flight model too.

[SUBS17]

Developers Diary Edition 17

--------------------------------------------------------------------------------

Dev Diary 17:

Sorry for the delay in this edition of the Dev Diary, unfortunately a number of events have conspired to delay this edition, not the least of which was the meltdown of my PC which has thrown a spanner in the works.

Fortunately our intrepid developers have not had any such disasters and continue to strive forward towards the completion of Fighter Ops.

Some of the notable additions this month come from the Art team, with the completion of the T6II and T38C models. I'm sure you will all agree that these are looking absolutely fantastic! Art work continues on the UH60, HH60, C17 as well as airbase and civilian vehicles. Work is also continuing on shader technologies as well as skeletal animations.

The Flight Model team have made good progress, the Hydraulic systems are completed, including detailed failures and details such as pressure changes with rapid control inputs. The Oxygen systems were also completed this month by the Flight Model team. Work is currently underway on canopy systems along with the ongoing airframe and powerplant projects.

Our coding team has made substantial progress, with the completion of the first stage of the DirectX graphics engine, further UI work, a number of components are now completed in the first and second iterations, including the network code, input and sound modules. The terrain code is now well into it's second iteration with tools to view larger areas of terrain mesh for testing purposes. Work is underway as I write this to include vector data for roads and such into this tool, and shortly texturing will be added. Detailed design and planning work has been completed on the dynamic weather engine. Work has already started on bringing all of these components together for the second major prototype which will mark a fairly large milestone on the road to the first Alpha and Beta versions of Fighter Ops. Bug squashing and fine tuning continues on the flight model code, which should be ready for integration very soon.

Our lead coder, Babak, has been kind enough to do a short write up on some of the aspects of the terrain engine:

Introduction

In a flight simulator that aims to be deep and realistic, handling terrain is much more than rendering the ground using fancy 3D rendering techniques. Apart from the visual aspect, other modules such as weather and AI are greatly influenced by the terrain engine. The fact that terrain data is going to be used by other modules makes its design and implementation very difficult. Let me explain. In order to be able to render the terrain efficiently, the terrain content needs to be processed and stored in a certain way. Another module such as the weather engine might need the terrain data to be structured and stored in a different manner. These two preferred methods of terrain data representation are not necessarily compatible and may lead to contradictions. As an obvious solution, one might create a complete separate version of the terrain data for every module that needs to use it. The sheer size of the terrain data prohibits creating and storing it more than once. The solution is to create a format that is usable by all of the modules using the content.



Terrain Contents

So what does terrain data contain in Fighter Ops? What exactly does the word terrain refer to? In Fighter Ops, terrain content consists of the following:

a) elevation data
B) raster textures
c) vector data

Elevation data consists of a large set of samples taken as a uniform grid from the Earth surface. Each sample is a number which specifies the altitude (from sea level) of the sample. What this amounts to is a two dimensional matrix of numbers that approximate the surface of the Earth.

Raster textures are the actual raster bitmaps that are overlaid on the terrain. The nature of these textures is the same as a photograph stored as a JPEG, GIF, BMP or any other common raster format. In Fighter Ops, raster textures aren't simple pre-prepared bitmaps that are overlaid on the terrain mesh. The process of creating and rendering raster textures is a complicated one.

Vector data is a very convenient way to describe data such as roads, rail tracks and landmarks. A straight road for example, is represented by its end-points. A road with curves and bends is approximated by a series of straight lines. The advantage of using a vector format instead of raster bitmaps to represent this type of information is size and precision. If one tries to represent and store a road by drawing it on a bitmap, only a very small percentage of the bitmap will be used and also when zooming in, the road will get pixilated very quickly and will be unusable at high zooms. On the other hand, if a vector format is employed, only the coordinates of the end points need to be stored and a program displaying the road can render it at any required zoom level.


Flat or Spherical?

When creating terrain, the common solution is to render the terrain on a flat plane the way terrain is done on most current flight simulations. This approach will work very well when the game is focusing on one specific area on the globe or a number of separate theaters. All sorts of problems appear when attempts are made to model very large or global terrain. Also flying or viewing the terrain at very high altitudes is bound to cause problems and finally, simulating the trajectories of orbiting entities such as satellites will be a nightmare.

Creating a flat representation of global terrain cannot be done in such a way to accurately portray every part of the terrain. When looking at a typical map of the Earth, you will see that the accuracy of the map decreases the farther you move from the equator toward the poles. In such maps, Antarctica and Iceland for example are much larger than they really are. Alternatively, a map created for a polar region like Antarctica is only good for that region and in such a map, moving towards the equator will decrease the accuracy significantly. If the focus is always on a single area of the globe, a suitable flat projection can be used for that area but as soon as you move away from the area, that accuracy will drop dramatically. In the event of a very long flight, to maintain accuracy, the projection needs to be changed as the aircraft is flying from one area to the next. This lack of consistency will make various calculations in the simulation difficult if not impossible to carry out.

An alternative method is to deal with global terrain the way it really is: as a sphere. Spherical terrain will solve the projection problem and relieve us from creating multiple projections for different parts of the terrain. If we represent the terrain as a sphere, we can always create flat projections as needed for localized missions and campaigns. Also on increasing the altitude, the spherical nature of the terrain will automatically become visible without the need to replace the original terrain with something that looks realistic at that altitude.

We have adopted the spherical representation of terrain in Fighter Ops. This method allows us to seamlessly simulate very long distance, high altitude and even orbital trajectories with ease and provides us with accurate, consistent terrain globally.
__________________
Julian "Buckshot" Leonard
XSI Executive - VP Operation