Grebbeberg - WIP terrain

[DualJoe 10]

Hello arma community members.

I've started a little project to see if I could make my own "map" for Arma. I'm Dutch so I figured why not try some Dutch scenery, which I will try to recreate as fateful as possible in the Arma2 engine, sticking close to a 1:1 scale.

I'm posting this thread to get some feedback and advise as I go along. After trying various different tools for terrain editing from the wiki and this forum I've ended up using Blender for pretty much everything and then exporting to a greyscale heightmap. Maybe I could expand on this if someone is interested in using the sculpting options in Blender for terrain editing or is interested in my workflow. Keep in mind this is my first try at terrain making in arma, I am however somewhat familiar with Blender.

I've chosen a small area 8km x 8km around the hill called de Grebbeberg for a couple of reasons.

First it's small (which may make it possible to work at a smaller cell-size), but also because it's a very interesting area. It is pretty diverse terrain (for Dutch standards anyway) with a river, channels, dykes, but also the hill as the main strategic area.

Also it is an historically important area and key part of the Dutch defensive line called the Grebbelinie. In the Netherlands it is most famous from World War 2, where the German army concentrated it's forces on this area and the Dutch even managed to fight them to a standstill for 3 (whole) days. The germans suffered some pretty hefty losses and nicknamed the hill der Teufelsberg (devils mountain) which I'm considering of using as a name.

I'll try to post some screenshots later today.

I need some help with the following:

First up, materials. I have gotten a simple version of the map into visitor3 and copied the materials from the tutorial island of the wiki. The terrain even shows up in buldozer with my crude satellite image as texture, but after packing it in a pbo and running it in arma2oa I get an error message about not finding an rvmat with a lot of zeros and I get a white untextured terrain. Any ideas on how I could solve this problem?

Also when placing a unit in the editor and previewing the map, a couple of seconds after the map has started, my player character suddenly gets injured for no apparent reason, sometimes even dying on the spot. I'd like to know what could be causing this.

Last I've got some questions about cell-sizes and performance. Ideally I'd like to use the smallest cell-size possible so I can add in trenches and gullies and such, but still have a pretty decent framerate albeit with a short view distances. I've searched the net but I couldn't find anything about a limit for cellsizes. Smallest cell-size for this map in a 1 to 1 scale would be 2m in a 4096x4096 grid. Before I waste a lot of time making small details I'd like to know how far I can go, before running into memory problems or something like that. Any insight in this is more than welcome.

Another peculiar thing I've noticed is that framerates seem to be heavily affected by the smoothness of the terrain without changing cell or grid size. My first tests were with a low bit depth grayscale image and not using the full range from black to white, the result was a very ugly blocky landscape made up from flat terraces instead of smooth hills and horrible framerates. Later I managed to produce a better quality heightmap which resulted in a smooth landscape and proper slopes but surprisingly also a much improved framerate. Does that mean that for a decent framerate I'll also have to take into account the number of changes in elevation before deciding on a cellsize?

EDIT

Google drive link with fairly recent versions of this WIP

Edited October 11, 2012 by DualJoe
Probably first place people will look for a link

[mr burns 132]

I'm Dutch so I figured why not try some Dutch scenery, which I will try to recreate as fateful as possible in the Arma2 engine, sticking close to a 1:1 scale.

Sounds great!

Most important question first: will there be coffeeshops? :D

[DualJoe 10]

Ha, I won't stop anyone from adding what they want once it is done, but don't expect a lot of intense figthing when there are coffeschops around.

Little update (with and without satellite image and transparent waterplane):

Small section of the map, because I have limited ram I had to split the thing up. This the area east of the hill (part the hill is still visible) and north of the river. I expect most of the activities on the map will be in this area. This is the area between the river and the winterdyke, should the water in the river rise this area would mostly flood, but I'm afraid that won't be possible in the arma engine.

The rest is not as detailed as this yet, but it's getting there. If I find the time I'll work on it some more this weekend. I'm pleasantly surprised how easy and fast sculpting a terrain is. Way more intuitive than working with 2d heightmap or some of the other terrain editors I've tried. Being able to toggle the googlesatmap on and off is a big plus as well.

[Col. 10]

Good luck, man! :D This could turn out nice!

[bushlurker 46]

An interesting approach - Blender for terrain modelling!... interesting...

Still - if you're familiar with Blender then I don't see why not - heightmaps are just meshes basically, and if you're used to thinking in those terms it's a perfectly valid approach!

Have you checked to see what satellite DEM's are available for the area? with a bit of luck there might be adequate ASTER coverage of the area - that would give you a ready-made "accurate to 32m" real-life ground mesh which you could then refine to as much detail as your cellsize will allow...

That brings me on to your other questions - and you have a few!

I'm not sure whether to answer them all here... if I do it'll involve a lot of techie terrainbabble which more properly belongs in the Map Editing section - a Mod will likely come along and just move your thread there where it would more properly belong... That might not be what you want, if you're planning on some open discussion of your ongoing project, in a place where you might actually get a few readers!... the Mapmaking section is usually "quiet" ;)

It might be better if you assemble all your questions and do a separate post in the Mapmakers section - actual mapmakers may actually see it and you'll get more help faster without confusing the A&M Discussion guys with stuff they don't wanna know...

PS 4096x4096 @ 2m will play like a pig, plus have other issues... for an 8km area you might need to go for 1024x1024 @ 8m - 2048x2048 @ 4m might be ok...

PS#2 - Have a read thru this - it covers most of the basic practical stuff...

B

Edited October 14, 2011 by Bushlurker

[DualJoe 10]

Oops, hadn't occured to me to check under the Arma2 section for a terrain subforum, I picked this one because I saw some other folk posting their island threads here. Maybe this thread should be moved then.

@Bushlurker: Whoa, you've got some impressive examples there, nice work, I'll try those out asap to check the framerates.

Oh another tip, maybe Sculptris would be better suited for sculpting terrains, it's free to download at the pixologic site and has a very easy UI. I didn't use it this time, because I needed to follow a reference image. Also I'm familiar with Blender, but it took me quite a while to get used to the Blender interface (and now I have to start all over again with the new Blender).

I did get srtm and Aster height info for the area. Unfortunately the Aster data for my region is damaged with large bands of missing data and srtm is too crude for my needs. Also Aster seems to have some odd quirks, where forested areas are interpreted as valleys and water pits as high peaks.

In the end I did use one of the geotiff images as my utm base reference and projected the other reference images onto that. I also used Blender for this, because I couldn't figure out the GIS-apps that supposedly can very easily georeference and reproject images to UTM.

Eventually I found a website with a googlemaps style representation of heightmaps made with lasermeasurements. I took a couple of screengrabs, merged them in The Gimp (no not the movie character) and then manually replaced the elevation colors with my own grayscale ones. This helped in giving me a starting point, but looking back I could have saved an enormous amount of time if I had gone straight to blender.

Okay here's what I have sofar, the hill sections are still very crude and I have to adjust those to arma sealevel. I haven't even started on the north and south areas:

I'll try getting this ingame first to experiment with cellsizes. I've exaggerated some features in case I need larger cellsizes. Pending the results I may do another detailing round.

Got to say though with each level of increased detail the workload seems to double. I already feel like I've walked 8km a couple of times over. I'm starting to feel a new found respect for the amount of work Bistudio put in their maps with all the detailed villages and cities.

Edited October 15, 2011 by DualJoe

[_William 0]

Interesting choice. Look forward to the result.

Will you model the historic terrain (once you get to grips with the editors and content pipeline), or stick with today's satellite data? Rhenen town seems to have grown considerably compared to 1937 aerial photographs, such as this. Great site, btw.

[DualJoe 10]

@_William: I've downloaded pretty much every remotely useful image from that site. My intent is to make the May 1940 version, but as you said I have to figure out the whole pipeline first. Ideally I'd like to include stuff like the trenches and destroyed buildings. Simulating a war in a picture perfect town with even the windows intact kills a lot of the immersion for me. But first I want to figure out a nice balance between terrain detail and framerate, it also depends on how much time I can spend on it. At the very least I'd like to have cobblestone roads and little things like that. Leaving out the "Kazematten" would almost be blasphemous.

Not much to show today, I'm currently working through Bushlurkers excellent tutorial.

I've tried copying SgtAce tutorial configuration and edited it to suit my terrain and naming. While doing this, I think I may have found the main culprit for low framerates. It probably is the texture per meter setting, from what I've learned modding for other games is that textures tend to have a far greater impact on framerates than polycount. I am getting very decent framerates in buldozer now, which loads the textured version of the terrain just fine. However once I pack the map and try to load it in game I get an rvmat error and the game crashes shortly after.

I just want a very simple material so I can test the terrain, but apparently I'm doing something wrong. Trouble is I'm not getting any error messages in any of the preceding steps, which makes it a lot harder to locate my mistake.

[bushlurker 46]

Not much to show today, I'm currently working through Bushlurkers excellent tutorial.

I've tried copying SgtAce tutorial configuration and edited it to suit my terrain and naming.

A good approach all round... my tutorial provides a more complex example island to progress to after Sgt Ace's - it has multiple textures & clutters, etc... the tutorial itself is presented in the form of a walkthrough designed to talk you through the process of... copying the structure and adapting the files to suit your own project!

... so that's a good one to check out for individual file-by-file adapting instructions...

the "missing .rvmat with lots of zeros in the name, followed by a crash when testing in-game error" is quite common....

Occasionally, it's just BinPBO playing up - try binarizing two or three times in a row with the same settings - then test ingame...

...occasionally, it's like BinPBO misses stuff on the first run... emptying your tempfolder occasionally helps too....

Far more frequently though, this error happens becauseBinPBO couldn't find your "Layers" folder... this is full of sat image "tiles, and - .rvmats!

It's generated when you "import satellite and mask" and it's location is dictated by a path you specify in "Project Preferences" in Visitor... (Path to textures)

It's one of the many things you'll need to repath when you're adapting an existing project to use as a structure for your own...

You'll have encountered this path when you did Sgt Ace's tut (and mine) - it should point to inside your "Data" folder - where a "Layers" folder will be created...

a wild guess... your path needs to be something like...

(P:\) DualJoe\Grebbeberg\Data

Make sure that path is in there...

Make sure the "Layers" folder is being created correctly in that "Data" folder...

... try BinPbo again....

B

[bad benson 1733]

just a wild guess since i don't know any details but you should check your settings in visitor. there is a common error causing rvmat issues. somewhere along the line u are asked in visitor if u want "text" or "binary". if u plan to binarize your pbo u should use "text" and if not use "binary". it's a long time ago i had this problem so i'm not sure about the details. just check the tutorials again. they should include that part. it has something to do with visitor kind of pre-binarizing the rvmats i think.

EDIT: oh he was faster and wrote much more :D

Edited October 15, 2011 by Bad Benson

[DualJoe 10]

Yes! Bushlurker, thank you!

I got it ingame, framerates are acceptable on my system. Screenshots mosty with 2600 viewdistance (was playing around with the setting to test framerates). Maybe I should let other people test the map as well.

Still some oddities, like water shining through some surfaces although they are about a meter above "sealevel", but the heights are very close to real life now.

Hmm, nice line sight from the hill, pretty obvious why the Germans had a hard time here.

Anyway, this is a big motivational boost for me.

EDIT:

Some reallife photos from the net for comparisson.

1939 - http://www.grebbeberg.nl/index.php?page=photo&pid=1061

more recent:

http://v3.cache3.c.bigcache.googleapis.com/static.panoramio.com/photos/original/3263629.jpg?redirect_counter=2

http://v22.lscache3.c.bigcache.googleapis.com/static.panoramio.com/photos/original/14486398.jpg

http://v7.lscache5.c.bigcache.googleapis.com/static.panoramio.com/photos/original/22255862.jpg

I'm a little surprised how close to reality it already is.

Edited October 15, 2011 by DualJoe

[Chill xl 10]

Great job m8, interesting location you have chosen. Nice progress screens, looking really good.

The sea that shines trough comes from the tides which are rendered at a just above sealevel (0m-1m height). Basicly the tides are not completely level with the water rise a bit above and land is not taken into account. Which means that water, sea and tides come up when the land level is at or near sealevel (0). Only way to solve is to raise the whole land by 1-1,5m.

My map, torabora uses a 5m cellsize and i believe not many have performance problems with it. I have a few map projects around that are on 3m and 4m cellsize, after i tested with a 1m cellsize. 1, cellsize is very tough but i believe a 4m cellsize should work pretty good for most and give nice detail to the map. I really like the small cellsize maps, the detail in the surface with small bumps and dips are really great for infantry fights.

Keep up the good work :)

Edited October 17, 2011 by Chill xl

[DualJoe 10]

Thanks for the info, Bushlurker also gave me some tips in the official terrain-editing thread. By the way, there seem to be quite a high number of Dutchmen active on this forum.

I'm aiming for 2 meter cell size, which I'll try to compensate with a lower resolution texture. Ideally I'd like to incorporate some historic ditches and trenches, which I doubt will look convincing in 4 meter steps.

But before that I'll have to upgrade my pc, I've reached the end of what she can handle. I even tweaked the hell out of my Linux setup and used a different memory manager for Blender, but I'm just 1 Gb of ram short for the next level of detail. I've started working on small parts, but that's taking to much time and concentration.

I was looking for a ram-upgrade, but for double the price it seems that I can upgrade my entire system to a 6 core 8 Gb set. I think it's about time for an upgrade then, I'll collect some information tonight and go to the shop tomorrow, so I should be up to speed again pretty soon.

[HR4 Elite 10]

This looks great, looking forward to making some missions for it..

.

[DualJoe 10]

Have to be a little patient, apparently I ordered my RAM-upgrade just as the store ran out of stock. In the mean time I've been researching the other parts of terrainmaking and texturing and noticed that the biki articles aren't very in depth. Leaving me with a number of new questions.

First about the xyz-format, are there any known converters for this xyz-format to and from more standard 3d-fileformats (like .obj)?

I can work with the png/pbl set for now, but I wouldn't mind the increased control of a 3d-mesh. I can imagine that even a 16bit grayscale image would limit the heightresolution in case of more extreme terrain differences.

Second about textures. As I understand it now there are 3 textures visible on the terrain. Close by the texture defined in the rvmat for that type of terrain, then a (alphamapped?) detailmap texture further away and then in the distance the big satellite image covering the whole world. Is this correct? I've only seen people talk about a single detail-texture. Is it possible to have more of these detail-textures, one for each of the 4 types of terrain? Also I'd like to know at what distances these transitions occur. This would allow me to guestimate a minimum texture-size I could get away with for maximum performance and acceptable quality.

While I'm at it, does the large worldwide satellite texture affect the terrain color right at your feet? If not, is there another way to make color-variations possible instead of having the exact same looking 3/4 materials covering the entire world?

Also in the biki there was quite a bit of talk about blue lines, blue and such, accompanied with a number of puzzling formulas, which left me completely baffled. Do I have to do something else than just creating a single big texture-image? Thinking about the memory limit of arma2, does this also mean there's a size limit to the satellite image?

Edited October 22, 2011 by DualJoe

[bushlurker 46]

hi again...

First about the xyz-format, are there any known converters for this xyz-format to and from more standard 3d-fileformats (like .obj)?

No idea on this one...

I can imagine that even a 16bit grayscale image would limit the heightresolution in case of more extreme terrain differences.

65535 possible values gives you a 0 > 655 meter heightrange at centimeter accuracy - you're probably safe ;)

Second about textures. As I understand it now there are 3 textures visible on the terrain. Close by the texture defined in the rvmat for that type of terrain, then a (alphamapped?) detailmap texture further away and then in the distance the big satellite image covering the whole world. Is this correct?

More or less, yeah...

I've only seen people talk about a single detail-texture. Is it possible to have more of these detail-textures, one for each of the 4 types of terrain?

Each terrain type has it's own MCO texture, plus there's an "overall" one that acts on the satellite layer at middle distance... - look for "ground textures MCO" and "Middle MCO" in my Beginners Guide...

Also I'd like to know at what distances these transitions occur.

That's user-definable in your terrain config or you can inherit values from a base terrain like Chernarus or Utes... the "inheriting" trick means you only define the parameters which you want to be different - the rest you'll get whatever the base terrain has - ambient wildlife, lighting, whatever... I think I babble briefly about the concept in the "config.cpp" section of my Beginners Guide...

This would allow me to guestimate a minimum texture-size I could get away with for maximum performance and acceptable quality.

Decent ground textures are usually 2048x2048 though for simpler or repetitive ones you can get away with 1024x1024.

Satellite layer resolution is a different matter - a general rule for decent quality is 10x the resolution of your heightmap/mesh - so, for a 1024x1024 ground mesh, you'd use a 10240x10240 satellite image... you could go higher for greater detail...

Limiting factor is the size of image your Art program will handle... Photoshop doesn't like anything bigger than about 300,000x300,000 px...

While I'm at it, does the large worldwide satellite texture affect the terrain color right at your feet?

It DOES tint the actual ground texture - slightly - it can also be set to tint or not tint the clutter models on an individual basis - see my Beginners Guide again - cfgClutter.hpp section.

It doesn't recolour the ground textures entirely though, a frequent mistake is to have the satellite layer too different from the actual ground texture - then you see it change as you approach... not good...

If not, is there another way to make color-variations possible instead of having the exact same looking 3/4 materials covering the entire world?

The limit is 4 different materials per "Ground Segment" - usually 512x512 pixels of satellite image... in a different segment, you can have different ground textures... CWR2 Everon for example, has 12 different ground textures in use... Sand, 2 different grasses, 2 different forest floors, roadside gravel, old concrete, cobblestones, farmyard, ploughed fields and harvested hayfields... and Rock...

The Wiki explains that segment thing quite well...

Segments, and the fact they overlap slightly, is also the reason for the BlueEdge thing - which you don't need to worry about for satellite importing purposes - that'll come later when you want to export map images from Visitor... same page in the Wiki

Thinking about the memory limit of arma2, does this also mean there's a size limit to the satellite image?

Size limit in Photoshop, more likely...

B

Edited October 23, 2011 by Bushlurker

[DualJoe 10]

Thanks again for taking the time to answer me Bushlurker.

I read your pdf-tutorial a couple of times and read the Biki pages repeatedly, maybe because of the similar names, but somehow it just didn' t land. Or as the Dutch saying goes, the quarter(It's all about the money) didn't drop.

Hmmm, Photoshop, damn, up till now I managed to work around this particular requirement, because I can't justify the price for it compared to my use for it. I' m not too keen on the less legal download options, I'd rather go for free alternatives like The Gimp. I'll see how far I can go once my ram-upgrade arrives, or get really creative.

[bushlurker 46]

The Gimp will be all you need for almost any task... I'm lucky enough to have scrounged a license for a creakingly old version of Photoshop from friends who work in IT services at my local Uni, but I learned Gimp specially for a ground textures tutorial I'm currently writing (can't have a tutorial relying on bought software!!), and it did everything I needed...

Apparently "paint.net" is also a viable alternative, though I haven't checked that out... Gimp is probably your best bet... you'll need a normals/bumpmap plugin plus a hi-pass filter plugin... both freely available.... but worry about them when you get to individual ground textures stage...

B

[pathetic_berserker 4]

+1 to GIMP, I have used educational versions of PS, but only the GIMP at home, it's good. Don't think I ever had a show stopper using PS files in GIMP either, and it has a big following so a quick google will answer almost any question.

[DualJoe 10]

There's one thing that doesn't make sense to me though. I can understand that you'd want to increase texture resolution to compensate for lack of geometry when using a large cell size. But why would you want to increase texture-sizes when you're increasing the geometry resolution, by using a rule of thumb like 10x the heightmap? Since the engine only supports up to 4096x4096 grids, consequently the heightmap resolution is also capped at 4096x4096 pixels. However 10x that resolution and you're already working with an almost 16 Gigabyte sized image (single white layer). Talking about the size inside a program like Gimp, not the compressed filesize on disk.

The article on the wiki is a bit dated on this topic talking about adjusting OFP-maps to Armed Assault, but they do talk about pixels/meter as a guideline, which makes more sense to me. I'm only going for an area of 8kmx8km. For 1m/px resolution, that would mean a sat-image of 8192x8192 pixels would have the same visual quality as Sahrani.

I have no idea what m/px resolution is used on the Arma2 maps, but because I'm aiming for high resolution geometry, maybe I can get away with an Arma-level of detail terraintexture.

For people working on huge maps, this could be a problem, unless you have an absurd amount of RAM. Maybe vector-based image editors would be a better better choice then, could be something to look into. Another possibility would be to use a very fast ssd as swap-disk.

[bushlurker 46]

There's one thing that doesn't make sense to me though. I can understand that you'd want to increase texture resolution to compensate for lack of geometry when using a large cell size. But why would you want to increase texture-sizes when you're increasing the geometry resolution, by using a rule of thumb like 10x the heightmap? Since the engine only supports up to 4096x4096 grids, consequently the heightmap resolution is also capped at 4096x4096 pixels. However 10x that resolution and you're already working with an almost 16 Gigabyte sized image (single white layer). Talking about the size inside a program like Gimp, not the compressed filesize on disk.

... I may have confused the issue here... the "10x, 20x" thing becomes obvious if you're using the popular L3DT for generating basic satellite & mask "basemaps" since its resolution selector works as a basic multiplier of the heightmap you feed it in the first place...

m/px is probably a more accurate way of measuring things, since the "classic" 10m cell (such as Sahrani) is now considered a little "low res"...

Since the engine only supports up to 4096x4096 grids, consequently the heightmap resolution is also capped at 4096x4096 pixels.

Indeed... Grid sizes are preset - 128, 256, 512, etc - up to 4096... however, 4096x4096 seems to be problematic from a technical point of view... Visitor doesn't like them much... It'll load, and even binarize out and run in-game, but when you come to place actual objects in Visitor, there's been many reports of problems placing and manipulating objects on certain areas of a 4096x4096... notably the bottom left quarter of the map...

It could be we're hitting some sort of engine limitation there - or possibly a Visitor 3 bug... either way, it's why theres not many "fully dressed" 4096x4096 terrains around... an ok size for flyboy maps though...

I'm only going for an area of 8kmx8km. For 1m/px resolution, that would mean a sat-image of 8192x8192 pixels would have the same visual quality as Sahrani.

Indeed again, though - Sahrani is considered a little "lo-res" now.

The practical limit with Satellite layers is the art package you use... if you can find one that'll handle 40960x40960 you could probably use that - though in general it's best to avoid extremes of anything...

However - with your example above - I'd be thinking along the lines of 0.5m/px - a 16384x16384 Sat & Mask layer... That will look just lovely in-game, and the higher resolution means that there'll be more "segments" - it'll be easier to cram on more surface texture types...

I have no idea what m/px resolution is used on the Arma2 maps, but because I'm aiming for high resolution geometry, maybe I can get away with an Arma-level of detail terraintexture.

It's that underlying geometry resolution which can potentially be the big drag on FPS & performance - not so much the satellite layer resolution... when I started working on Everon for CWR2, the first thing I did was to make two test versions - one with 10240 sat layer - the other with 20480 - then I got a couple of people to test it... there was literally no more than a couple of FPS difference between them, and 20480 looked twice as nice!

Mondkalb, my trusty CWR2 cohort, is currently working on Nogova - he likes to measure in m/px too...

Since for various reasons, these "OFP ports" have to be 12.5m cells, he'll be using a 25600x25600 satellite resolution (0.5m/px)... looks even nicer than Everon/Malden with their 20480x20480 and again, FPS hit is fairly minimal...

25600x25600 is getting close to the practical working limit for most Art packages though - loading and saving can take quite a while...

... so much for satellite resolution...

Actual ground geometry resolution is potentially more problematic... In small sizes you can get away with very small cell sizes... take a look at Prowler.Wolf's Battle of the Bulge terrain... 2m ground cells! Trenches! - and it plays well!...

But - it's only 1kmx1km...

Multiply that kind of resolution out to larger grid sizes and... well... as far as I know nobody's tried it to see what kind of performance you'd get... Maybe Prowler has?

B

Edited October 24, 2011 by Bushlurker

[DualJoe 10]

Visitor not taking 4096x4096 grids, wow, that's a pretty major bug then. Shouldn't stuff like that be mentioned in the wiki?

I can imagine people not willing to test that stuff. Would be pretty irritating finding out it doesn't work after spending a lot of work to get there.

I did test with 4096 and as you said I got it in game, but haven't tested placing objects and such. 1kmx1km would be cutting it really close for what I'm trying to do, even if I'd scale down the terrain from real life.

I'm expecting my RAM-upgrade tomorrow, then I'll have enough memory to be able test some of those high end maps (can't work on very large images at the moment). Had to pull some very creative stunts to get the map to where it was in the screenshots, which was about half the resolution I'm going for.

[DualJoe 10]

Is there a way to procedurally place objects to test if the map will work?

I really, really want to try 4096x4096 with 2m cellsize.

Currently my heightmap is around 4meter resolution and tried to cut some canals, but if I place them at a slight angle I get ugly artifacts.

I may have mentioned this before, but buldozer/visitor seems to be very sensitive about gradients in the heightmap. The first heightmap I tried may have been an 8 bit image exported from wilbur, anyway it had very noticeable banding/terracing in wilbur and horrendous performance in arma2. First thing I tried was a couple of blur-filters in Wilbur to get rid of the banding and performance increased dramatically. Finally I managed to figure out how the displacement baking worked in Blender and how to get the 32 bit floating point images converted to 16 bit png, which resulted in the terrain from the screenshots I posted earlier (very smooth but without the loss of detail from blurring). Framerates went up again. (Wilbur always produces banding/terracing for me on imported png heightmaps almost as if Wilbur imports at 8bit instead of 16).

All these tests were done with the same 4096x4096 grid and the only real difference was in the smooth gradients of the grayscale image. This seems to imply that not only the height-value of each point is important, but also the differences relative to the surrounding vertices. It feels like the Arma2 engine has an optimization for smooth surfaces, which only works up to a certain angle. Break this angle often and your framerate suffers. Kind of like how smoothing and smoothgroups results in much better performance on the videocard than the same object flatshaded.

Edited October 25, 2011 by DualJoe

[DualJoe 10]

Got my 8 gigs of ram and I am currently switching my toolchain from binary to compiling from source, which in the case of Blender and Gimp leads to an incredible increase of performance. I can highly recommend this for anyone working with opensource programs.

For example I can now fluently sculpt the complete 8km² terrain in 2m per vertex resolution, while with the binary version my pc gets bogged down with just 1/6th the area in that resolution. I get a comparable speed increase with Gimp as well, 16kx16k as smooth as working on an icon sized image. The binary version was unworkably slow and laggy with the same sized image.

Still searching for a nice application to convert 32bit openexr to 16 bit png grayscale, the one I'm using now is cumbersome and unstable.

No ideas on how to run an automated object test on the map? I haven't been able to find any other info about 4096x4096 being problematic.

I do have another question though. Is there a rule of thumb, or did anyone test how much performance decreases when placing objects like houses and trees?

I'm worrying that I can't change the grid and cellsize after placing the objects. Which would mean that I'd lose all my work if I have to change it in the future. Currently on pc from a couple of generations back (core2duo e8500 and nvidia 560 Ti), framerates never drop below 60 on the 4096x4096 map with 2 meter cellsize, viewdistance around 1600m and 1920x1200 resolution. I'm only using the SgtAce grass material/clutter for now and have no objects. I did turn off SSAO.

Would the framerate be halved or more if I dress it up comparable to Chernarus country side or the Utes island? Meaning a couple of small forests, predominantly farm fields and couple of small towns and some buildings here and there.

NB

When using google-satelite images, beware to edit out the watermarks. I just noticed some huge google branding while flying over my terrain, which wasn't that obvious while stitching the image.

[DualJoe 10]

Little update, mostly meant as a personal log and maybe get feedback in an early stage.

May not look like much, but it was a lot of work to stitch back all the previously separated areas and then adjust the entire map to arma2-sealevel while retaining most of the small detail (I'll get to digging out all those ditches in the top right down to sealevel when I get to those areas). The dark color represents the upper arma2-waterwash-effect limit. I'm now working on increasing the detail level one area at a time.

In the previous version I made mess of the old 18 century defensive positions at the base of the hill (the pointy bits), which I have now corrected. So both sides of the canal at the base of the hill are practically finished including the sand road which you can just make out if you watch closely.

I've now remade this area as close to the reference material I've found sofar.

Next I think I'll concentrate on the area to the right of the pointy bits, and recreate them based on a couple of areal-photos from around 1930/40. Not because I'm anal about an exact recreation, but I suspect that the current marshy situation, may hinder gameplay more than I anticipated (didn't expect the distances to be that long). Got mixed feelings about the subject though. Part of me really likes some of the interesting features it has now, which I haven't seen in other arma maps. Like being unable to go prone, slower movement when the water gets to chestlevel and having to find a route with enough foothold so you don't end up swimming losing the abilty to fire until you regain foothold.

EDIT

Pretty close if you ask me. I've been doing some tests with the AI and I discovered that they will not swim across even a small patch of seawater. Bit disappointing, but I could work around it by making a couple of area's just deep enough to walk across.

EDIT2

Pretty amazing how much information can fit into one little image. Rest of the (defensive) waterline to the north is now present, but the level is detail is getting to be a Pita. So much for thinking that a small 8kmx8km map would be easy.

Edited October 30, 2011 by DualJoe