The A2A Simulations Community

I've got a - probably rather silly - question, but since I'm totally ignorant of terrain-making, I'll pose it anyway...
What do all those colours on the map mean? Do they stand for a certain kind of tile, or something?

_________________
Runter kommen sie alle...

Yes, that's exactly it. Here are a few examples:

My very first attempt at terrain editing, when France was one big featureless golf course; the landuse pcx:



and the result:



Or, much more recently, Hurst Spit (Near the Isle of Wight) landuse as Rowan modeled it (sorry, don't have the in-game result):


How I edited that:


and what that looked like in-game:


and what it really looked like (sorry, the source site for this image is down for maintenance today but the picture should reappear shortly, I hope):


Well, meanwhile, here is what it looks like now, but it has changed a lot in the last century due to storms moving it around; also the google images tend to overemphasize the seabottom terrain, which at most viewing angles should just look like water: http://maps.google.ca/maps?hl=en&ie=UTF ... &z=14&om=1

Ah, thank you very much for the clarification

_________________
Runter kommen sie alle...

I am very interested in the outcome of this little project as I have lived and worked in Poole for 24 years.

Having the area as accurately replicated in this game will be a real treat for me.

Please continue to work on it and if you need any help, just holler

Thanks!!!

Sev

I am continuing to plug away on this project, daily. However, I have nothing new to show, as the last month has been taken up with correcting the first level compile errors in the map, polishing it up to be acceptable to the terrain renderer. These fixes are invisible on the map at the resolution shown here, so it won't look like anything has changed. However, as my creation method is to first do the art, trying to be as accurate as possible without regard to the demands of the renderer, I often break the rules, so there are a lot of repairs and corrections to do. The compiler only allows 250 white anchor dots per 256x256 pixel tile, and I will often find I've used up to 400 dots to achieve the fidelity to the landscape I'd like to have, so the corrections involve me reducing the detail on several tiles by close to half, while trying to retain the same appearance; that, along with lots of other repairs and adjustments to the fine detail of the map.

(All the regions shown on the land use pcx images here are drawn with straight line segments between white dots. The terrain renderer compresses this information to encode the position of each dot, and the direction of each line (maximum 4) extending from it. It then checks to see whether that is enough information to regenerate the image. Failure to regenerate is caused either by artist errors, such as too many points, or lines and dots not drawn following the rules, or by mtt2, the compiler, getting confused by configurations which seem to be drawn legally, but it apparently can't fathom. In any case, repair involves correction, recompile, repeat as necessary til no more errors are reported.)

That is great work you are involving your sharing with us. Keep it going! this will really add to BOB. A lot of hard work, but will be enjoyed by many!

Time to add another update indiscernably different from the last one:


What's new here is that this pcx has passed the first level compile test, and has several hundred fewer white dots than the last one, representing perhaps 30 hours of debugging (would have been fewer if I was more clever, and less reluctant to edit out my previous work). Now on to level two compile, and all the errors that crop up there...

PV you must be a very patient individual. It is unfortunate that complexity has to go as you weed out problem areas.

OK, time for the next milestone. The second level compile tests went quite quickly, so now it's on to the heightmapping. First, here is the heightmap as extracted from the terrain. You can see, comparing it with the terrain map above, that it is rather direly missing some bits!


Now, here is the same region in raw SRTM height data, after massaging into BoB terrain colour code format:

This will serve as the basis for the new heightmap, but it will require considerable tweaking. The rectangular blocks of constant height may look pretty small on this image, but at this scale, a plane is 1/20th the width of one block. That sort of grain size is OK for smooth inland regions, but isn't good enough for coastal cliffs, or small hills, or river channels, so the map will have to be hand sculpted to account for these details.

Hi, I'm new to BoB2; having just started flying some instant action missions, I've only seen flat land. Am I right in assuming that you will be adding height to BoB2 with your heightmap? Will it be part of 2.08 or later?

Is it possible to smooth out the terrain with an interpolation and noise filter, or will the whole thing have to be done by hand as you said? A median noise filter at 2 or 3 pixels really smooths the whole thing out, adding detail while maintaining shape. I've got no idea how the BoB2 engine works though, so it probably won't work. And you'll probably be doing something like this anyway.

Here's an example of what I mean using your heightmap in 3dsmax, the resolution of both the heightmap and the mesh are the same for each; the right half has a median noise filter at 2 pixels:




Awesome work, I really appreciate the dedication you and many others have shown to improving this game. You've done an enormous emount of work.

We've been slowly upgrading the terrain since we started wrestling with it on BoB1 in 2004. There is usually at least a bit of terrain upgrade to add to each patch release. Elaborating the landuse is much easier than tweaking the heightmap, so much more of the former has been done.
The problem is the opposite. We don't have a source of height data with sufficient detail - SRTM is one height value per rectangle on that image I posted above. The rectangles are 60x90m. You can't make cliffs or seacoasts with that sort of resolution. Here's a nice explanation (from WorldWind): http://www.worldwindcentral.com/wiki/Wo ... _should.3F

Also, while the Rowan data has an even lower detail, typically having perhaps only 6-10 data points per sq. km, it must be pointed out that the regions of SE England and NE France are rather flat to begin with. Most of it is below 60m, which from typical WWII operational altitude looks dead flat. The area I'm working on is one with a bit more relief, which is why I'm doing it. It will look much more interesting when you fly low over it, but you won't be able to see any of my height work from most of the altitudes you find yourself at in game.

It appears from your image you've misinterpreted the coding method, and the image I posted doesn't contain the correct data anyway, as it's been jpegged (even at 100%, jpeg corrupts colour value integrity). The SRTM data generates a very smoothly varying heightfield. BoB height data is coded by a hex count of colour data - 4cm per LSbit - red is the low bits, then green=256xLSbit. The original of the map I posted has SRTM data from 0 to 200m in one metre steps, while the original Rowan map shown above it has lower spatial resolution, but the height is in 4cm increments over approximately the same height range.

It's just a tiny fraction of what could be done with this engine, given more manpower. As the engine is quasi-open source (see Buddye's post regarding our relationship with Shockwave), it is truly unlimited what an ambitious volunteer could accomplish.

Gotcha, like I said, I've got no idea how it works for BoB2. Thanks for the explanation.

_________________
Vista 32-bit SP1 | AMD AM2 5200+ Dual Core | 3GB 800mhz Corsair RAM | 8800GTS 320MB GPU

The need for definition in the heightfield is why I've always advocated the 3rd party tools such as L3DT. Generating nice heightfields is the easy part, the headache is the terrain engine and how it makes use of what you give it. I still really like the idea of topo lines (fake blue line with white dots) for height data retention. I tried it on the Wake Is. map, it works but you have to do it by hand because of adding in the control points. I have taken SRTM and generated topo lines from it, but what happens is you start to run out of dots per tile in some cases. I don't think this is an issue where there is less relief and more undulation in the topography. PV, I realize it's too late for you to do it this way but you might try your idea out on another area.

Which idea is that?

...I am running out of dots per tile for many reasons, trying to sculpt detailed shorelines, cliff faces, and heightmapping all in the same area. I am progressing quite nicely now with the heightmapping, and I hope to have some interesting pictures to show, soon.

I've been quiet in this thread for a while, while chewing away at the Purbeck heightmap. Past time for an update. There is still lots to do, ironing out mtt2's stupidities, but the shape of the terrain is beginning to emerge. Here's a nice feature of the Purbeck coast, Worbarrow Tout, with the Gad cliffs behind:



here's an aerial of the genuine article: