Fractal contours?

[Cpl Steiner]

Hi all,

I know that BFC have stated many times that the level of detail required to make maps in CMx2 is beyond the scope of any random map generator. However, one of the big chores faced by any map designer is the underlying topography of the terrain - in simple terms, the hills and valleys. Many beginners have great difficulty producing realistic contours and may end up producing billiard-table maps with little variation in elevation.

So, why not have a "half-way-house" and give the players an option in the editor to generate contours using well-established "fractal-landscape" algorithms? A parameter could be the relative "hilliness" of the landscape - from open desert to mountainous. I'm sure this would speed up the map-making process immensely.

Failing that - give the players some sort of "import height map" feature and a recommended third party landscape generator that generates the height map in the correct import file format?

Getting the contours right in CMx2 could be so much easier with something like this. You could just generate loads of random height maps until you got one that looked half decent, then tweak it from there.

Thoughts please.

[costard]

Hi Cpl Steiner,

I thought the fractal contour generation was based on an iterative process, therefore not giving a "random" landscape. So, ok for a section of beach front or mountain canyon, but no good for a forking river valley with drumlins and floating boulders. Random to some extent but generally giving a discernable pattern so not too interesting from a tactical point of view.

I know fractally generated wallpaper designs never took off...

[TheVulture]

There are lots of different random contour generating algorithms. Fractal ones are one option, but there are plenty of other ways to go about it, and different algorithms tend to produce different feels of landscape. Some are very good at mountainous features, others are very good at a kind of 'rolling hills' style. I coded one recently that tended to produce generally flat landscape with very roughly linear raised and lowered features, which actually did a reasonably good impression of British farmland (depending on the z-scale obviously), and often gave nice, tacically interesting maps with covered areas and important ridges for controlling large areas of the battlefield.

I'd love it if we got the ability to import at least contour maps. In an even better world, it'd be nice to be able to import full maps, but that would obviously require BFC coding up some long-hand uncompressed data format that we could generate independently, which would be read in and converted into the internal version.

I'm not expecting that though - within weeks of it going live, people will have produce QB generators based on it, and I imagine that the improved QB functionality of the next release is going to generate at least some of the sales desirability, and they might not want to undercut that with user-provided free versions...

[Thomm]

Importing/exporting would be nice.

One can feed the terrain elevation information into a raytracer and re-import a shaded texture, e.g.:

Best regards,

Thomm

[Michael Emrys]

One problem I see with that image, Thomm, is that the trees on slopes are not growing vertically. Gives it a funny, artificial look that I find distracting. Otherwise, not too bad.

Michael

[panzermartin]

I think it is just a matter of 3d perspective and angle of view.

[Thomm]

One problem I see with that image, Thomm, is that the trees on slopes are not growing vertically. Gives it a funny, artificial look that I find distracting. Otherwise, not too bad.

LOL, that is just perspective distortion that you are seeing. In fact, I re-shaded all terrain 'carpet' textures for "Squad Assault - Second Wave" back in the days using the procedure indicated above. Putting one light source with an incident angle of as low as 10 degrees really helped flesh out the contours of even the most moderate bumps in the terrain.

Nowadays, this procedure appears to be obsolete looking at the beautiful lighting of Drop Team and Theatre of War 2 maps.

Best regards,

Thomm

[Redwolf]

XML mumble map (or scenario) mumble import/export mumble.

[theFightingSeabee]

I'd be happy with being able to draw over a background image like, say, a contour map or a satellite image (both actually). That would work just fine I think.

[Battlefront.com]

Elevations are the easiest of all things for a map generator to make. It's everything else that is the problem Roads not only have to be connected correctly, but they have to make sense in terms of where they go and what they connect to. Farms aren't farms if they have a 8 story building next to them, no fields, and a stone wall that seems to have no purpose. So on and so forth.

Writing an import filter to take real world maps and translate them into terms that CM could understand won't work either. In theory it works, but the level of detail is generally not as much as CM needs. Therefore, CM would have to extrapolate and flesh out the details. That's probably more difficult than doing a random map generator.

The best way around this is to have "mega tiles" which are constructed by end users. These mega tiles would have certain attributes which CM would understand so that it could piece together maps that made sense. Some on-the-fly stuff would be needed to mesh particular elements, especially road type terrain, but if that's all Charles has to concentrate on then it probably won't be a huge deal. In other words, Charles can focus on a couple primary features and let all the details, which would be even harder to do right, be predefined by the players themselves.

Steve

[Cpl Steiner]

The best way around this is to have "mega tiles" which are constructed by end users. These mega tiles would have certain attributes which CM would understand so that it could piece together maps that made sense. Some on-the-fly stuff would be needed to mesh particular elements, especially road type terrain, but if that's all Charles has to concentrate on then it probably won't be a huge deal. In other words, Charles can focus on a couple primary features and let all the details, which would be even harder to do right, be predefined by the players themselves.

Thanks Steve.

Q1. Using the mega-tile system, how would contours work? If players do contours on each individual tile but they all have to be the same height at the edges so they mesh, won't this result in odd "wargame table" looking maps? My solution would be to apply a subtle fractal algorithm to the finished whole to make it look less strange.

Q2. How will mega-tiles be introduced to CMx2? Will they appear only in a future CMx2 title such as the Normandy one, or will they be retrofitted into previous titles such as CM:SF?

By the way, I've just played around with a manual form of fractal contour mapping in CM:SF and the results were surprisingly good. I put locked height tiles of different elevation on each corner of the map and then added a fifth in the middle which was not quite the mean of all the others (i.e. it introduced a bit of a warp in the map). This resulted in a grid of four "mega-tiles" for want of a better word. I then repeated the process for the centres of each of these and so on. The result was quite satisfying. Try it if you get the chance.

[Michael Emrys]

The best way around this is to have "mega tiles" which are constructed by end users. These mega tiles would have certain attributes which CM would understand so that it could piece together maps that made sense. Some on-the-fly stuff would be needed to mesh particular elements, especially road type terrain, but if that's all Charles has to concentrate on then it probably won't be a huge deal. In other words, Charles can focus on a couple primary features and let all the details, which would be even harder to do right, be predefined by the players themselves.

This sounds a bit like the geomorphic mapboards of Squad Leader. That might not be an entirely bad idea if it can be made to work. I once bought a bunch of blank hex maps to see about making some more realistic maps than the cramped ones that came with the game and looked like courses for some weird kind of miniature golf. Mine would have also joined at the edges, and being much larger would have had more naturalistic terrain on them. The catch is that they would also have required a larger playing area. Of course on a computer, with its ability to zoom and scroll, that would be less of a problem.

Michael

[Thomm]

By the way, I've just played around with a manual form of fractal contour mapping in CM:SF and the results were surprisingly good. I put locked height tiles of different elevation on each corner of the map and then added a fifth in the middle which was not quite the mean of all the others (i.e. it introduced a bit of a warp in the map). This resulted in a grid of four "mega-tiles" for want of a better word. I then repeated the process for the centres of each of these and so on. The result was quite satisfying. Try it if you get the chance.

This sounds very interesting!

I tried once to reverse-engineer the elevation generation algorithm, but gave up when I got the feeling that there is some degree of randomness involved. But your experiment makes me want to try again ...

The mega-tile concept smells of over-engineering. But who knows ... if the interface is supporting it well enough ...

Elevation map input would be great of course, but I am not so sure how a fixed set of elevation data would interact with the CM:SF elevation algorithm. In principle, all pixels of the elevation map could be translated to "locked" elevation settings in CM:SF, but I am not so sure if the results would be satisfactory. Better would indeed be a contour line import function, where "black" means "free" terrain node and "grey" codes the elevation level for the contour line.

Best regards,

Thomm

[Cpl Steiner]

This sounds very interesting!

I tried once to reverse-engineer the elevation generation algorithm, but gave up when I got the feeling that there is some degree of randomness involved. But your experiment makes me want to try again ...Thomm

You should; the results I got were quite reasonable for not much effort, and on the plus side there were few locked tiles which might help game and/or loading performance.

The algorithm I used is called "diamond-square" (see diagram):

I'm not convinced by the diamond-square analogy but if you look at the above diagram and take into account that black points are most recently added and grey ones pre-existing, you can get the gist of the procedure. Each time you add a point you are trying to pick the mean of the surrounding points +/- a random factor. The random factor is larger the more distant the surrounding points are. Luckily for us, CM:SF calculates the mean for you in the map editor, so you just have to slightly increase or reduce the value showing to introduce your random factor. I just chose values myself but rolling dice would be better. What you end up with is a fairly chaotic rolling landscape. It helps if you add brush/foliage/ground texture to highlight the effect.

[Thomm]

Another reason why it would be nice to have an import facility is the existence of terrain erosion models ...

http://skagit.meas.ncsu.edu/~helena/gmslab/viz/erosion.html

Interesting link collection (in German)

http://www.imagico.de/terlinks_g.html

Best regards,

Thomm

[Spooner]

I did look at the map file format used in SF, in order to be able to import height-map data a little while ago. It seemed that although there was a clear file-header that contained readable binary data such as width and height of the map, the area where I assumed the actual height-map was stored seemed to be encrypted (or compressed, but whatever, it wasn't obvious how to read it). We don't need to ask BF to spend a lot of time making import tools for us, but they could either release the format of the mission file or even just allow the file to be saved in an unencrypted form so we could decode it for ourselves. The latter is more usual, since I suspect there is some issue with actually releasing proprietary information like that, but modders often backwards engineer formats in order to use them themselves.

Personally, I'd like to see 4km maps more the norm in the game, rather than being something that is avoided because editing a large map is so terribly difficult in BFs 2D editor. I understand why BF haven't made a complex terrain editor, but being able to import XYZ or image height-maps into the game, perhaps from satellite data or from 3rd party editors, would be a great boon, even if all the actual hard work came from the community.

I'm sure there are many other uses we could put a knowledge of the file format too, of course, such as our own QB system (which wouldn't be in-game, but would create the individual missions out of game).

(I've written a tool to help convert OFP maps to ArmA and am working on creating a deformable terrain system for ArmA, which shows what can be done with a bit more information, even if it is backwards engineered! I'd probably be able to work on SF community tools, but without any starting point, I can't do this).

EDIT: I'm not complaining that SF haven't released the required information, since it is their info to do with as they please. Just really saying that it is a bit unrealistic to expect them to spend a lot of time making tools, especially the sort that are often made by the community, rather than making the game itself.

[Redwolf]

I did look at the map file format used in SF, in order to be able to import height-map data a little while ago. It seemed that although there was a clear file-header that contained readable binary data such as width and height of the map, the area where I assumed the actual height-map was stored seemed to be encrypted (or compressed,[...]

CM map and scenario data has always been at least compressed if not encrypted. You can easily tell by the fact that it doesn't compress more.

The only way to go for import/export is a mouse remote control and an OCR software, IMHO.

[akd]

Personally, I'd like to see 4km maps more the norm in the game, rather than being something that is avoided because editing a large map is so terribly difficult in BFs 2D editor. I understand why BF haven't made a complex terrain editor, but being able to import XYZ or image height-maps into the game, perhaps from satellite data or from 3rd party editors, would be a great boon, even if all the actual hard work came from the community.

Here, here!

[Battlefront.com]

Some answers in random order...

Map importation won't work. As I said before, the filters would have to understand the terrain being fed to it and match it with the available terrain in the game. Since maps that are being fed in won't have the sort of details that CM has, it's simply not a practical solution. We looked into this years ago when it was a requirement from a potential military client. With them paying enough for us to offload it to another programmer... sure, it's possible. Short of that it won't be considered.

The file format for CM (of all flavors) has always been compressed to minimize RAM and disk footprints, as well as reducing I/O and Internet transmission times. We'll never open up the file format because it introduces cheating to the game and that's something we've always hated about hackable file formats. This is a philosophy we've had since before we made CMBO and it shows no signs of changing

Yes, the Mega Tile approach was inspired by various Avalon Hill and tabletop wargames, particularly Panzer Leader. Panzer Leader is the one I think of most since that's the one I'm personally familiar with.

The idea is that the Mega Tiles will come with no height information. Instead, the topography is generated randomly according to user settings just like CMx1. Then the Mega Tiles are selected, based on user settings, and laid over the topographical info. Roads and rivers would then be laid out according to the topography and/or the topography gets modified to accommodate them. Not sure which yet

It's definitely not "over engineered" as this is the easiest way for us to get great looking maps with significant details. Of course, people can also play on user created maps just like in CM:SF.

Steve

[tc237]

Is the height map used in CM:SF a grayscale heightmap like other games?

[Battlefront.com]

Not sure what you mean there tc237.

Steve

[dan/california]

Would some way to import at least basic terrain contour data be that difficult? I don't question that it would require some work, but it really does seem like a worthwhile thing to put on the list.

[Battlefront.com]

It would be possible, of course, but not worthwhile when compared to the hundreds of requests we have in hand that we feel would add value to the game. Creating elevations in the Editor is the easiest part of making a map, so there really isn't much gain to be had by importing elevations alone.

Steve

[SlapHappy]

Not sure what you mean there tc237.

Steve

He's referring to a method for using 8-bit or 16-bit greyscale maps to denote changes in height contours. Like this:

http://math.hws.edu/eck/cs324/f02/lab9/mars_bumpmap_sphere.jpg

TOW uses this method for defining it's two heightmaps it uses for each textured game map.

[Battlefront.com]

Cool... that's what I thought he meant The answer is, obviously, no. The heights are adjusted manually and directly similar to CMx1. We're not going to change that.

Steve