Terrain in old flightsims

[andy_s]

Hi,

I am wondering how terrain in "golden age" of flightsimming was done? I mean in games like Janes F15, Janes F18, EF2000, JSF, Fleet Defender, F15 Strike Eage 3, Apache Longbow. Or never ones like the Thirdwire series? Were they done by creating the terrain from a single heightmap? How was it possible to have areas of 500km x 500km modeled? If it was heightmap based, what resolution did they use? I doubt it that in these times it was possible to have textures the size of 1024x1024 or even bigger. How is the problem solved with very big units, when the problem of floating point precision starts? I read in various forums that in huge game worlds, there is the problem of floating point precision. What would be necessary to say build a terrain with the size of 500kmx500km with sufficient detail/resolution for flightsim use? Is there an "easy" way or is the only way of doing it having multiple heightmaps and basically have the whole terrain tiled? I am not sure if this is the way it is done. For example, the terain editor for the Thirdwire games just imports a 512x512grayscale heightmap to build up the 500kmx500km terrain. The heightmap is created using DEM files. How is it possible to cover such a large area with only a 512x512 heightmap? It would mean the resolution of the mesh would be almost 1km, which seems way to sparse...How to deal with these floating point precision errors? I hope there is somebody who can explain what is exactely needed for a flightsim.

 

Thanks Andy

[YouGroove]

In old systems, the terrain wasn't detailled, if they used 1024*1024, they could just paint general terrain details only.

You can do the same but with bigger textures indeed in LE engine, and it should suffice for you to have some good detail amount i think !

Or you could use a drawing program and use some big resolution like 6000 + pixels and paint, then use some free program to cut your big image in several tiled ones like 512*512.

Than use that in the 3D engine i guess.

But with LeadWerks you can already make very big terrains. After is to you to set tup the scaling fo your plane bigger or more little to terrain to simulate that big distance world.

[Flexman]

Best way was/is camera relative rendering, all objects are transformed around the origin. Ogre3D has such a mode (with problems at time of writing). This is not possible with Leadwerks Engine for the reasons I'll go into.

 

Another technique is tread-milling. Microsoft Flight Simulator uses this technique, your position is reset as you cross the border of a terrain tile. This can be emulated at one level in Unity and Leadwerks by parenting objects to a tile-object and moving those tiles around the camera. In Leadwerks although you can't use the terrain or vegetation system with this technique so you need to build or load in your own terrain geometry.

 

There's a book just been published which explores all these concepts 3D Engine Design for Virtual Globes now available in electronic format. It touches on precision and z-buffer antics.

 

There's no magic bullet for precision, doubles instead of floats will get you a bit further but you need to be a bit radical. A lot of these off-the shelf 3D engines don't do radical well, they are so interconnected with physics, shaders and lighting.

 

Quadtree software produce a terrain editor called Grome that's well suited to editing huge terrains and exporting individual tiles (they call zones) and has been used for numerous console flying games (e.g. Ubisoft's Blazing Angels). I'm experimenting with this one. The main problem is the pipeline from Grome to Leadwerks and poor threading (just because you can do it in language X doesn't make it good).

 

I could write buckets on old simulations, some never did anything so fancy as the above. A lot didn't use heightmaps in the way they are often employed today as they pre-dated the hardware that heightmaps are optimised for. Constructing geometry on the fly from a dataset was the order of the day.

[Canardia]

Double instead of float would actually reach far enough even for the biggest games. The difference between float and double accuracy is enormous, over 2 times more accurate in all situations:

http://www.cplusplus.com/doc/tutorial/variables/

http://en.wikipedia.org/wiki/Double_precision_floating-point_format

http://en.wikipedia.org/wiki/Single_precision_floating-point_format

[andy_s]

thanks for the insight guys. So then it looks like LE is maybe not the right choice for a jetsim. Hopefully LE 3 will support such a terrain. Generally it seems to me that there is no such solution out of the box available in any of the engines I checked out.

Flexman, could you elaborate a little more on the old sims? Also, are you evaluating Grome to possibly change to another engine for your helo-sim?

[Canardia]

LE2 is still good, because it's damn fast and it supports any kind of game idea. You don't have to use the terrain feature, but you can use your own meshes for terrain. I also made a demo with over 10 million planets for LE2 using a simple SQLite database, it works in LE2. It uses semi-multithreading also, so all the CPU intensive things were done on other threads, but all LE2 commands on the main thread.

 

Honestly, I don't get the benefit of GPU terrains, they use more FPS and they are not even 3D. With a number of GPU instanced models you are still using the GPU and you are fully 3D capable, and you can do infinite terrains or universes.

[Flexman]

LE or any other off-the shelf engine isn't suited for a jetsim but not impossible.

 

Grome is an editor, not an engine (although they do license the engine used in the editor). Our use of Grome is about assessing how we can use LE to scale a game up to 100x100km. It's sole purpose is to take large world terrains and slice them up into single meshes, these meshes would be used in place of the built in Terrain object (the LE Terrain object can only have one instance and is not moveable). The down side is that you also have to dump the awesome performance friendly vegetation system. But you shouldn't need it for a jet sim.

 

LE is about as capable as any other engine in this regard. You can look and look and never find anything ready to roll your own sim. A jet game maybe. Lots of games with fighter aircraft cheat like crazy, using perspective and scaling tricks. They give you the impression they are flying at 500 kts but if you measure how much terrain they cover per second you'll realised they are moving slowly compared to a real jet fighter. Video games are all smoke and mirrors. Apache Air Assault had bushes the size of houses. Look at the fighters in Battlefield 3 videos, they are pulling turns at indicated speeds that would take miles in real life.

 

My project doesn't need more than the maximum terrain sizes allow so the only issue has been how to deal with the precision and z-buffer problems that do occur and you have eluded to. Z Buffers are the weakest link, so long as you keep camera near and far distance in a range that's retains precision you solve a lot of z fighting problems. But if you want a visible horizon out to 6 or 8km then your camera near distance needs to be 6m. Which is terrible if you're sat in a vehicle, most of it would vanish. To workaround that you have a couple of tricks,

 

First, you adjust the camera range dynamically, the close to the ground you are the nearer the horizon appears. And the near camera distance can be inches away.

Second, your vehicle is not part of the outside world, it's a portalised object. this is what I do in my helicopter game.

 

Let me elaborate on how we do the portalised vehicles, I don't want to put you off, it's not as bad as it sounds, no matter what engine you run with, you need to get your hands dirty. Our vehicle interiors are 3D meshes separate from the exterior. The cockpit interiors are positioned at the origin in their own world; the render cycle first updates the outside world, then we do some frame buffer copying to a cockpit buffer. There's a lot of fiddly code to match up lights, camera and movement (action?). The final composite is an illusion but near perfect. This is how it's done in most simulations. This delivers a rock solid cockpit interior free from precision and z-buffer issues, plus environment objects such as trees, water, rain, particles, can never intrude into the vehicle space.

 

The way we did it was highly technical from the art aspect, you can't see the join, even use TrackIR to lean out of the cockpit when the doors are open. Getting all that to work was specific to the kind of game we were making. But it can be done (and is done) in other engines.

 

If you're studying technologies for the purposes of simulation games you'll have come across Outerra which is the poster-child of how far you can take GPU and procedural content generation. Many of the techniques used are starting to find a foothold in other applications now. For example logarithmic depth buffers are used in Google Earth and it wouldn't surprise me to see a Unity mod for that.

 

Other techniques for rendering long camera distances include multi-frustrum rendering (example: Infinity The Quest for Earth) which I have tried in Leadwerks but the cascaded shadow maps were a disaster, I couldn't get them to match up at all but just because I couldn't get it to work but that doesn't mean it's not possible, my patience just ran out and some swear words were used.

 

So far the best option for large terrains using Leadwerks engine would be the treadmill approach. This is something I'm considering for Leadwerks 3D when it's released. So long as streaming mesh data in is supported, this should be

 

One final word, simulations use two co-ordinate systems (sometimes 3), your real world co-ordinates, and your interior 3D engine co-ordinates.

 

You might find this link interesting, it's a White Paper on Microsoft's Terrain Technology. I would recommend looking through it. Even if you have no intention of developing ellipsoidal worlds many of the techniques I've mentioned are covered.

 

Microsoft Global Terrain Technology

[frednaar]

After looking at terrain issues in many off the shelf engines for a flight sim I came to the conclusion that possibly the best approach would be a combination of scaling terrain distances down (i.e. using 1m scale on the engine to represent 10m or even 90m) and --if necessary-- reset the world center after player XYZ position reaches certain values (this last step might not be necessary)

 

This approach might impact on physics but physics can also be easily "scaled down" by increasing for the same amount the object mass (and therefore, forces and moments being equal, scaling down accellerations and velocities),

 

You would also need being able to access the physics engine moments of intertia (which are accesible in Newton but for some reason not accessible in Leadwerks yet, even though josh could easily add them to the engine), this will affect how fast an object rotates after an inpulse.

 

 

As Flex says a simulation is a way of cheating anyway but in a credible way, so why not have your jet plane being scaled down to a bee flying over your backyard...

 

 

Fred

[andy_s]

Thanks a lot flexman and frednaar, this was very interesting to read! I also thought about using the scaled down world, so that my aircrafts have the size of 1m. But would it then not be very difficult to get enough detailed terrain?

It seems like just not using the LE terrain object and instead using separate terrain meshes seems a way to go. I thought about this before as well, but then thought that probably because of performance issues this will not work, as i suppose the LE terrain object is way more optimized to render a terrain than just an exported mesh out of some 3d package.

Flexman, it seems you have a lot of experience with flightsims. Have you been working on some of them in the past?

[Flexman]

Problem with adjusting scale universally is that you just end up moving the decimal point but the precision problems remain. Say you reduce it by a factor of 10, your near camera object, say you're on the runway, runway markings which might be 1m away, are now 10cm away in real-world and game units. In Leadwerks there's a slight problem, load up the editor, turn on debug physics mode, add an object to a scene and then scale it. Have a look at what happens. *spoiler* the physics shape doesn't scale - oh my */spoiler*

 

 

The Virtual Earth book I linked to in my earlier post has some downloadable programs which let you explore this very thing, by adjusting parameters, scale, zbuffer and double/float precision, you can see the results on an actual globe. And it's not always intuitive and often not pretty.

 

I might have had some experience. If you want to buy Empire Interactive's Enemy Engaged Apache Havoc or Comanche vs Hokum, they are available from Good Old Games. There's a little bit of me in those. I also worked at Microprose UK for a while and wrote mission tools for Janes Longbow 2 Apache helicopter simulator.

 

Frednaar is working with me on the physics modelling on the Apache in Combat-Helo using his own blade element theory flight model aka HTR or Helicopter Total Realism which is a free Microsoft FSX add-on that replaces the Microsoft flight model with something much more realistic. It's available in the forums at Hovercontrol.com

 

I got a plug in there for you Fred

 

 

About exported meshes. If you try and use a 3D modelling program to take a DEM and turn it into a gridded hightmap mesh, it won't work. As you suggest, performance will be TERRIBLE. Detail is a problem. Actually let me re-phrase that. Detail IS THE problem. It's worth assessing just how much you need for your particular game. Irregular triangle meshes are they way to go if you're going with terrain slices, large flat areas can be covered in just a few triangles with mountain tops having more detail. A tool like Grome (I'm really NOT a salesman for them, just citing recent experience) t exports these kinds of meshes. EEAH (Enemy Engage Apache Havoc) used this kind of irregular triangle mesh terrain. Also the terrain slice meshes will have to be loaded "on the fly" as you move around unless your world is small enough to pre-load them. This potentially will cause stuttering or pausing unless it's done on another thread. Then you have the problem of textures on these slices. If your game is fine with 1024 textures covering a terrain tiles you can add noise layers or even throw in some instanced objects to add clutter.

 

 

If you want to go the way of generating your terrain geometry at run-time then the technique use in FSX is solid. FSX built the terrain vertex buffers over several frames, and it was double buffered so the next terrain was being assembled while using the current one is being used.

[frednaar]

Problem with adjusting scale universally is that you just end up moving the decimal point but the precision problems remain. Say you reduce it by a factor of 10, your near camera object, say you're on the runway, runway markings which might be 1m away, are now 10cm away in real-world and game units. In Leadwerks there's a slight problem, load up the editor, turn on debug physics mode, add an object to a scene and then scale it. Have a look at what happens. *spoiler* the physics shape doesn't scale - oh my */spoiler*

 

I believe decimal precision errors on floats (and doubles) happens when you use large numbers as the computer moves (floats) the comma to make space for higher digits and deletes lower digits rounding them up or down, this is why you have errors when you move away from the origin but not close to the origin

I believe the phys file should be adjusted accordingly before importing the mesh into the engine (you have to import a very small jet...) .... but well you are the expert ... I am just exploring LE as you know...

 

This could also be an idea for a different flight sim, where you fly around garden chairs and tables, this should make for fun dogfights...

[Flexman]

Indeed. The flying around tables and chairs is a good analogy for what flying is like in Battlefield 3. In Leadwerks as you move past the 20,000 unit mark those rounding errors start to creep into the shadows causing jitters. That's different from the camera range but if you're not going to have a long distance to the horizon then you keep the precision.

 

OH I must say, I fell in LOVE with EGGplanes, cute versions of F14s and A10s shaped like eggs. That would be a great little game to knock out if you had a small army of artists.

 

Egg Planes - Google Gallery

[andy_s]

Wow so you were actually working on one of the helo games I spent a lot of time with back in the day! I checked out Grome, it seems to be a very nice editor.So the way to use it for a flightsim would be that a huge terrain is created in Grome, say with the size of 500km x 500km. Then Grome tiles this terrain and exports the tiles. Say the tilesize would be 50km x 50km, so Grome would export 100 meshes, and for each mesh it's textures? Then in the engine, one would have to load in the corresponding meshes depending on where in the gameworld the aircraft currently is?

 

What I plan to create is something like the old dos game Fleet Defender, so actually most of the world would be ocean and at the edge of the map there would be landmass. I thought on setting the game to the northern scandinavian peninsula, or maybe the mediterranean. If a big part of the gameworld is an ocean, does it make it easier to create a big world? I mean, as there is much less terrain, would I maybe get away even without tiling and just have a big world where i place the terrain mesh at an edge?

 

Thanks a lot for your posts so far, it's very interesting to read from such experienced devs.

[paramecij]

You can easily re-create the scaled physics bodies at run time in code, not really real-time with lots of objects, but at least you can do it at load time. (and avoid having multiple files for same model). That's how I currently do it.

 

But it seems to me that the physics shape doesn't need to scale -if you only want to scale your whole world uniformly (all objects by the same amount), you can do so independently of physics if you also scale the position of the objects, after updating physics.. not sure how feasible this would be in LE, maybe adjusting position in UpdateMatrix callback, or parenting the meshes to world origin pivot and scaling that after physics could do the trick, but probably too many problems (octree, culling, lods, terrain, vegetation, lightning, ..)? .. just a quick thought while reading Flexman's spoiler

[Guest Red Ocktober]

i took the brute force simplistic approach in creating my infinite world... but my issue was less problematic than yours, seeing as i only needed to have an infinite water surface represented...

 

my approach was to use a 3 x 3 treadmill type system (with 9 copies of the same water mesh), where the center grid (grid position 5) would always be positioned at the world center, and was always surrounded by on grid on all sides...

 

when the view moved past a certain point, a new center grid position was determined, a new center grid was set, and the bottom (or top, or left or right) grid would be repositioned at the top (or bottom, or left, or right) of the group...

 

add a fog to mask out the ends of the group, and there ya have it... you should never run outta water...

 

 

works fine where the surface is the same all the time... would not be the ideal solution for a sim that needs to map real world or varied terrain features... although a talented coder could adapt this simple logic work in such where such a requirement existed...

 

also... depending on the size of each grid mesh... the view distance would diminish to a point as the altitude increased, in odrer to maintain the illusion...

 

--Mike

[Flexman]

Yeah, once you sort out the details of your co-ordinate system (game world <> engineXYZ) you can start to work on the treadmill. @Mike I didn't know that's what you'd done, cool to hear you got it working OK.

 

One caveats using tiled terrain meshes; automatic occlusion/culling. Make tiles too big and you'll loose the benefit of object culling, to small and you have a lot more tiles. Finding a size that works for all altitudes might be tricky. But over the sea it should be fine, you eliminate a lot of issues there. Make something flexible so it's easy to adjust the tile size in case you have to workaround culling/performance issues later.

 

- Rich

[andy_s]

Thanks guys for all the replys, I have now some directions to go for the next weeks.