Not wanting to paint utopian pictures that in the end turns out not possible, there are quite a few things I believe could be improved by run-time, startup-time, or even as a preprocessing step before starting the game, for map generation.

I envision terrains to be just that, terrains. Any extra "features" added, such as roads, hedges, fields and rivers could more easily (and more compact) be expressed in simply plain-text files giving (just 2D even) coordinates, and whatever extra attributes needed (terrain ID, texture names/ID's, ) could also be introduced by such, quite small, plain-text files. We could then have (a number of?) pre-defined road/river types, with different width, slope, textures, river-water-flow-speed and so on.

I'd f.ex. expect to be able to see white-water in steeper areas, while very flat areas having quite slow water movement. Perhaps one could even scare a salmon or two out of the water doing a low-level fly-by?

What to me still is an open issue here, is how this should be done. Should it be a compiler of sorts, that's run before the game is starting, that takes as input terrain + and emits a new geometry for this in a cache directory, or could we be bold enough to try to generate this on-the-fly (or at least on program startup)? I don't know.

For commercial vendors they'd preprocess everything before shipping, but then they've also got the (to me questionable) "luxury" of 4.5GB distributions.

What I do know is that this could, in some cases quite noticably, reduce the amount of geometry (data) needed to express a map. This would result in less storage requirement and less bandwidth usage for map creators.

It could also open the door for maps created by mathematical models, even at runtime where terrain LODing would become second nature. To take it to an extreme, a map could be as small as a couple of hundred bytes describing the algorithm and a number of initial values and control points. If that map turned out "good", the next step could commence of augmenting it with roads, railroad tracks, rivers, seas (neither forced to be at sea-level, i.e. height=0).

I've also considered fractal compression of terrain and fractal generation of e.g. roads respectively. Also, obviously, simple B-splines (2D, basically following terrain).

Again, I'm "dreaming" a bit here, but I have seriously considered these options as additions to EECH. Should any of these ideas see the light of day, it could mean that "the next guy" having much "hotter" h/w than we do, could start up the game and get much more detailed terrain (in case it's generated), much more detailed textures (for e.g. generated terrain textures), and $DIETY knows what.

Just a few of the things I've been thinking about for a while. Take the ideas for what they are, and don't expect any of this.

when can you have this ready for us tamlin?

2 Paradaz:

as soon as it be done

i would like to volunteer to do some texture submittals if that is ok, i enjoy doing textures and use photshop8. when you are getting that far, please let me know.

regards

Sure, Inspector. Do you have my email? starshoy at rogers dot com

I do want to take some time actually playing this new sim rather than working on it

mine is d331jf1 at cox dot net

i am currently struggling with programming my HOTAS for this game ( i remember now i used a ch HOTAS and not my current x45 rig back then ) -suffering both game stutters and HOTAS view control speed problems (slow). as i test these issues trying to solve the probs i am getting a little flying time - but no real practice.

its gonna be a while here...... but i look forward to again meeting in the skies

regards

So do I. I can now take off and land but not much more than that
And I did not even start to program my X-45.
You have the same ICQ as before?

if you folks are serious...

how much do the required/desired DEM's cost? i might be willing to make a commuity donation.

yes, same icq, but that is another thing i need to install i should get to that soon, plus a voice program, i think they now use "teamspeak"?

anticipating our first engagement, i have made you a victory medal and can email you the .psd file if you want it in your game (RdBanner.psd)

For me the problem is not the money per se - DEMs are not very expensive, but I'd hate to pay $50 or $100 if the result cannot be used. The only existing terrain generator uses some particular kind of DEMs.
USGS made 1 degree DEMs are free and it is what I used for Aleutians, Alaska and this map . But they only cover USA territory.

I don't know what was used as a source for Kuwait or Lybia maps.

If I could get _workable_ Iceland, Murmansk or Kuril DEMs I'd (reluctantly ) pay for them $$.
But I am not ready to pay just for experiments

Starshoy,
I can assign texture IDs and colors algorithmically and make tree files if you want. You're also welcome to the program that does it if you want to modify/tweak it yourself. I've added a few texture IDs to your Alaska map and Maverick has made new textures so soon you'll get an idea how that works out.

I think I'm almost finished with side projects so I will start doing all the grunt BED work on my Grand Canyon map. The US southwest canyon country is my favorite in real life so ...

One thing you may be interested in is a special debug executable that records to a file the position of your helo when you hit the z key. So, you can fly around your map pressing the z key everywhere you want to place a sam or building and then plug all the values from the file into the BED. I think this will save me a lot of trials and errors with sam placement.

Craigmire, ii would be very helpful, saving me a lot of tedious work. At what stage does it work? I mean, "normally" you assign landcover (and roads) in terrain editor, then generate the map. Fully automatic assignment however may contradict to necessity of some "handpainting" under towns, FARPS or other special places.

It automatical assignment further editable?

Tamlin,
I like that utopian picture even if it can't be done but I'm sure you can do it. Sounds ambitious to the point of overwhelming to me but nothing is impossible for the person who doesn't have to do it.

Since you know the rendering nuts and bolts, would going to one of the new terrain systems that are already well developed (in progress) be possible? I've seen a few on the web where it looks like they apply a large aerial photo over a mesh rather than a texture mapped to polygon system.

Do you think you can figure out how to take text file coordinates and sink a river channel into an existing Rob Fox style map, with a set of triangles for river botton and a set for river bank, with some sort of tags so the texture assignment can be made, and do the same thing for roads? That would be totally amazing. All your ideas sound amazing, more power to ya.

Starshoy,
It's a one way deal. Plot the four corners and cover with a single texture and then use the auto-assign from there. You couldn't go back and modify the auto-assigned because the TEG uses the Rob Fox native file intermediate step. The way I deal with airbases, farps, and towns is to use the flattening tool in the TED and make all these areas absolutely flat. Then when I auto-assign, since the program calculates the slope, I stay away from or change as desired any poly that has slope = 0. That is how I keep the trees off the farps and airbases. So far it looks like all the user maps I've monkeyed with have the farps and airbases well flattened. If you wanted buildings on a slope you might get a tree sticking halfway out of a building but that would be rare and not the end of the world. You can also put holes in the slope range or figure some other way to finagle your result (ex. eliminate a sector or two). It's a small program and easy to modify. Right now I'm working on coloring the sea a lighter color close to shore on your Aleut map to make a shallow water effect.
P.S. If you look at Beach's article on eech he posted some shots of the Grand Canyon to give you an idea. I think the gouraud shading of eech can be used to good effect.

cc.

Yes, of course all FARPs and airbases have to be totally flat and there is no problem if towns will consist of a flat level, or several flat levels.

So I am looking forward to get your tool

Also - what do you think about roads - won't they be covered with tress or something like that? Roads generally cannot be all flat.

Craigmire,
There are a few obstacles to what I dreamed up.

First and foremost it's the memory requirements for terrain geometry. It's likely no secret that the maps in EECH is of the size making most "conventional" games blush. If someone has played e.g. GTA: SA and think that map is massive, then... well, yeah, OK, it is. But at approx. 36km^2 it's a dwarf compared to EECH's smallest map (Yemen) that is IIRC rougly 138 times as large.

Some games can get away with plain height-maps (think DEM), but for something as massive as EECH we'd speak about insane memory requirements. Even if we reduced terrain resolution to 1m, it would require (if my calculations are correct) almost five billion height sample points. For Yemen.

Assuming we kept 16-bit height data, that's 9.25GB.

Clearly that's not an option.

What also makes EECH quite, not to say very different from many games is they often have the luxury of swapping geometry as you move across the landscape as there isn't anything interesting going on at the other side of the map they need to simulate, and the viewing distance isn't very far. EECH can't do that, at least not the same way - and anyway it isn't doing it (currently).

EECH needs the full geometry in every sector having any kind of vehicle in it, due to the "non-cheating" nature of e.g. autopilots. AFAIK the autopilot of e.g. all helicopters needs to, at every game "tick" (of which there can be many for a single frame), be able to query the terrain for height information. This is always done using the high-resolution geometry. I've been thinking of ways to reduce these requirements, and I might have some ideas in the area. I need to do some simulations and try these ideas out first.

These memory requirements explain why the EECH terrains are "Free Form Polygons". You can create a triangle covering e.g. 100m^2, while still having the option to model small terrain features at up to 3.125cm resolution.
(for the club of useless knowledge I might add this is basically how e.g. the mentioned GTA also works)

One of the ideas I've been playing around with would be some kind of (fast) function generating terrain data on the fly, so that given map x,y coord's you'd get a height. The problem here is of course finding a function (or more likely, class of functions) creating good looking terrains within a finite time. Should such algorithms turn up it could, maybe even would, reduce terrain geometry memory requirement by several orders of magnitude, as you could query this function for terrain height for each vehicle on auto pilot - as opposed to having to have the whole terrain geometry in RAM, walk through lists of triangles, finding the right triangle, and then calculate the height of a point on the plane described by the triangle.

It would also make terrain LODing much easier, as you could just sample at higher resolution the closer you get.

Now over to your questions.

Since you know the rendering nuts and bolts, would going to one of the new terrain systems that are already well developed (in progress) be possible?

Possible, of course. Feasible, or even beneficial? I honestly don't know. As EECH have this "all geometry for sectors with vehicles must stay in RAM" requirement, I suspect it could become ... interesting, to try to make them play nicely together. Especially without starting to require 2GB or more of RAM. It is however obviously worth researching.

Do you think you can figure out how to take text file coordinates and sink a river channel into an existing Rob Fox style map

While I don't know who Rob Fox is - yes, I could probably do that. That's btw basically what Razorworks themselves likely did (you don't think they manually edited all roads and river polygons, do you? :-) ). Should this turn out possible, and fast enough to do at runtime, it could have another benefit. Terrain geometry could be greatly reduced for non-visible sectors with helicopters flying over them, with the obvious speed-up of height-over-terrain lookups.

I've also had this idea of automatic LOD for this, so at a distance shallow rivers or roads quite close in height to the surrounding terrain surface could be rendered a little "faked". Just a single quad with a texture containing both banks and the surface. As you get closer, it would switch to a more complex geometry of both banks and the surface, and separate textures for them.

But this is so far only brain-storming.

It occured to me that you could do all the hand painting of land covers you wanted before you started the auto stuff and use those IDs to leave those polys alone.

I have several versions of the tool and I'll send you the latest I've been using on Aleut which has most functions for you to look at. There is a 2D array that has to be hardwired to the specific map size but after that you just have modify for your geography and what you want to do.

There is the possibility of a tree being in the middle of a road but the trees need to be fairly sparse anyway and I'm guessing a tank or car could go through a tree like I've seen them go through a building.

Working with a new map I have a plan to put the roads in last after the final trees are on the map. Then I will fly the map with my drone chopper and record all the points for the roads avoiding all obstacles.

Thanks. So I will wait to play with your tool.
Regarding (invisible yet) roads, I think they could be added in several iterations. If the result of automatic population is not satisfactory in some areas I could simply flatten or handpaint the source once more and repeat.

On the other hand, since roads are described before the final generation as simple text files, may be your tool could in the future just avoid planting trees along those lines?

BTW I can see two post Apocalyptic scenarios. One, would describe events soon after the big one, and use more or less conventional skins. It is much easier to make.

On the other hand, more distant "Fallout"/"Mad Max" type scenario, could be real fun with wierder paint jobs. Corresponding voice acting could indeed make it EECH 3 (or EECH 2050 )

What is your vision for the planned map closer to?

First, a lot of terrain data is free, at least for the US: http://www.terrainmap.com/rm39.html and
http://data.geocomm.com/dem/demdownload.html
up to even 10m resolution.

Fully automatic generation is not an option for a couple of reasons I think. First it is not only the location where you are but everything you see so I wonder if you gain anything, first trying so find out what the pilot sees, then inventing all that terrain. It must be iterative because after you generated the terrain you again will have to check whether all the viewspace is filled, else generate more terrain etc. Second the terrain has to be the same each time you fly over it (so where is the advantage?). Terrain generating algorithms (which certainly exist, see e.g. here or google for terrain generator) are often fractal + perlin noise based and have random generators. The fractals add the detail that make the terrain credible. However, they often look a bit lunar landscape like (things you see on the cover of fantasy books). This would run havoc with any texturing and placement of objects. Not to speak of rivers and roads. Already the rivers are rediculous as they are now, often flowing upwards or not at the lowest point bu halfway on the slope. For me (as a geographer) to fly in existing terrain adds a great deal to the game (but others may think otherwise).

If you look at google earth and the speed at which terrain is rendered and textured it is amazing, and NASA's worldwind does the same and comes with code I think

A regular DEM is not an option, far too many points as Tamlin points out. An irregular spaced polygon terrain is still the answer, adding detail where it matters. You can select what you render though, leaving out triangles if they are below a certain resolution.

In fact I am quite happy with the terrain as it is(except for the stupid rivers), a lot of detail can be simulated by texturing, the eye is easily fooled.

A way in between could be to resort to a 30x30 or 50x50 m dem (which amounts to 9.5 Gbyte/2500=3.8 Mbyte) which is still too much to keep all in memory but a lot less, and add detail "on the fly". The detail could be bitmap info, like you have repeated textures but these are not only stuck on the terrain, but also used to generate details... a sort of bumpmapping

The visualization would obviously cache the results for an area around the viewpoint, and only discard such results once far away enough to not see them.

I was hoping for an O(1) function. I'm not actually aware of any such function, but as I mentioned, it was an utopic idea.


Among other things, I was thinking of it as a RAM vs CPU tradeoff. It would also take out all currently hard-coded terrain features from the actual maps (such as hedges, roads and so on) from the data currently required to iterate to find terrain heights for autopilots, why my hope was the end result of more CPU to generate but less to parse would cancel each other out.

Right. I was obviously thinking of a PRNG, to get repeatable results. Having RNG-based map generation would result in quite interesting confusion in multi-player.
- Hey, how could you shoot me? I was behind a mountain, at 10 ft radar altitude!
- No way, you were hovering at 1260 ft above a lake! I eyeballed you at 20 clicks!


For my idea, terrain texturing would obviously have to be automated (with aids and overrides from a human, of course). For object and "special" area placements I'd expect object geometry and texture coordinates to be possible to express however one likes. Say you want an airstrip somewhere. The geometry and texturing for that would obviously have to be manually configured, and override the generated terrain geometry for that area. Whether or not this would actually work is another matter.

Good point, and one I hadn't considered. This single fact could indeed complicate matters even more.

Then we're clearly talking about two different things.

I was thinking that from a map creators (physical person) POV s/he could play around with initial values until something interesting fell out the other end. Then lock those initial values (lets say PRNG seeds + selection of generation functions) and start adding detail.

This would obviously be fictious terrains, and would not satisfy people looking for real world emulation.

For real-world terrain, DEM data would obviously be more appropriate. It would however, at least if the current terrain.ffp format is used, also put a much larger burden on the map creator (the person), as s/he would have to either manually or by using some tool convert the terrain grid elevation data into the FFP format to reduce memory load (and CPU consumption for looking up terrain height), and then "paint" all the meshes with appropriate terrain ID's.

However, whatever approach is used here to generate the terrain, the two approaches would still share the common need for post-processing to add e.g. rivers, roads, fields and so on.

For the case one emits terrain.ffp files, this would be one or more off-line tool(s) modifying the terrain and hard-coding in the additions, while I was thinking of (examining the possibility) to do this on-the-fly. But this is only an idea. I don't know how practical it'd be.

With only 3.8MB I don't think you have to worry.

Anyway, it seems what you have in mind can be done within the framework of the existing code. What I've been thinking of is possibly completely off-the-wall, and in any case requires a rather extensive update of the terrain code.