I will say there's few things in favor of FG's scenery, that there's no other sim, WWI era or otherwise, that has captured the look of the Somme Valley. Most sims make the river as a snaking strip of water.
I'm way out of my depth here, but my problems with flight sim terrain are, 1) the mapping algorithms are "one size fits all" rather than being scaled to the "density" of terrain features in a particular area or what you actually want to do with the map, 2) mapping algorithms prioritize relatively crude elevation data over other map features which can be much more important to gameplay.
Broad swaths of more or less accurate major natural terrain features are fine for high level flying, but for ground attack and "slow and low" flight, the "human terrain" and minor natural terrain features become more important than the mountains in the distance.
Can I land in that pasture without wrecking my plane? If so, can I avoid that line of telephone poles if I try to take off again? Is the ditch deep and wide enough that my plane will slide into it, rather than over it, when I belly land? Is the mud so deep in that bog that my plane will flip and break my neck if I accidentally make a wheels-down landing? Can I get a decent shot at that train hiding in the railway cut? Are the treelines on each side of that road far enough apart than I can land on the road or make a low-level strafing pass along its length without removing my wingtips?
I propose that, at least for maps of built-up or "subtle" terrain defined by minor shifts in elevation and closely-spaced, narrow, terrain features (e.g., treelines, hedgerows, or minor rivers), it is more logical to prioritize "linear" terrain like streams, roads, railway cuts, and property lines, and "point" features like ponds and town centers, over elevation. You make those features look and act like they're supposed to using algorithms (mostly simple fractals for natural features), and then you fill in the elevation information around them.
For example, imagine a simple map where you've got a railroad cutting straight through treeless steppe terrain linking two towns, with a road running next to the railroad which mostly follows the contour of the terrain. First, you define the railroad object, say that it can't be any wider than about 5 meters per line including embankments and that its slope can't be anything greater than ~2%. The roadway gets generated as a mathematical object which automatically creates cuts and embankments based on SRTM data.
For the road, you do something similar, but accept that you can have a greater slope before you must make cuts or embankments and that it can curve more sharply to follow the terrain. You generate it as another object which uses essentially the same processes as for the railroad. Anyone "driving" along the road will find that it "behaves" like it should.
For the towns, you place two or more base points on the map and "grow" the town's limits using a suitable fractal pattern. As long as there is solid ground, towns will grow organically, based on population, along roads and rivers, and will go around steep hills and woods before growing "into" them. Once you've got the "city limits" of each town, you can generate minor roads within it. Once you've got minor roads, you can generate property lines and then use a different algorithm to generate buildings and other features on the property. Tweak the algorithms slightly to get settlement patterns, property lines, and building patterns for different cultures and periods. Big rectangles and squares with widely spaced farmsteads for the American Midwest, centralized villages surrounded by long skinny farm fields for Eastern Europe, terraced hillside rice fields for Java.
Still other algorithms could be used to generate the shape of treelines, power grids, minor water features, drainage ditches, etc.
Once you've defined your hydrography, transport networks, settlement patterns, and major landmarks, only then do you use STRM 10m data to "fill in the gaps."
For wilderness areas, you can sort of go the opposite direction to generate minor but important objects. Start with the SRTM data, but assume that there will be significant height variation within each 10m based on the sort of terrain you're modeling. For example, for swampland that's 1m ASL on average, you could assume that you've actually got slow-moving streams every X meters (break out an algorithm for that) with +/-1 m random variations in the height of the terrain between them. The +1 m areas get generated as hummocks, the -1m areas get generated as water/rushes.
Finally, you could have "point centered" features which override SRTM data within the areas they cover. That way you can recreate historical coastlines and treelines, and add or remove anthropogenic features like towns or reservoirs based on time period.
The bad news is that datasets which map the sort of linear and point features I'm talking about are either propriety or don't exist. The good news is that terrain generation algorithms are open source, readily available, and fairly simple. The potentially good news is that you could scan or carefully photograph a paper roadmap (or, maybe even topographic maps or more abstract maps like maps of railroad networks) and use image recognition software to identify the meaning of the various "lines on the map." You could then overlay that data over 10m SRTM data to get more or less accurate maps for areas of interest. Using latitude and longitude coordinates for known "point features" you can accurately place SRTM maps without overlap.
Fans could create linear and point feature generation algorithms to expand the database of existing terrain types. Aditionally, they can import textures and digitize data from historical maps. This would quickly provide a decent database for modern populated areas as well as historical maps of areas of interest.
Perhaps this is all too "pie in the sky" to be workable, but it would represent a novel approach towards flight sim terrain generation. And, as long as the "bare bones" are in place, it might solve some problems.
Author
Topic: Weekly progress report (Read 127827 times)
