Jump to content
Sign in to follow this  
victim913

Dumb map size question

Recommended Posts

Making this to the point...When I create a new project I see the options for the size of map. 128, 256, 512, 1024, 2048, 4096.

But I know some of the BI maps aren't those sizes. Do I have to make a map those 6 sizes? I was under the impression that you can make maps any size. Maybe I can load an xyz that was bigger than 2048 but less than 4096, and since it's bigger than 2048 I would be able to put it on the 4096 size? But not have to make it the entire 4096?

Oh, one more thing. If that last one works, do all maps have to be square or can they be rectangle? or slightly not square?

Thanks

Share this post


Link to post
Share on other sites

All heightfields have to be square, and in one or the other of those sizes...

Where you can vary the size of the final island is in the "Cell Size" you choose...

EG:

1024x1024 with a 10m cellsize = 10.2x10.2km final terrain

256x256 with a 50m cellsize = 12.8x12.8km terrain (Classic OFP size)

4096x4096 with a 8m cellsize = 32.7x32.7km terrain

Typical maps use a 10m cellsize...

*edit*

Since I have an hour :eek: to wait until photoshop saves my latest sat_lco effort, I'll expand slightly on this reply...

This "mapsize" thing is a fairly fundamental decision you have to make early on in your island project... it's not easy to backtrack and change your mind afterwards without potentially losing a lot of work, so it's best to make sure you know what you want and to get it right first time...

Effectively, you're deciding TWO aspects of your terrain at this stage... actual Ground Extents - map Size, plus the number of individual ground cells you'll use across that Ground Extent...

Ground Resolution, in other words...

You can use several different sets of figures to achieve the same size terrain, with fairly visible differences in results... for example, I've recently helped out on a couple of "older terrain" conversions - one from VBS1 and one from OFP...

These used a fairly low-res 256x256 heightmap, with each cell representing 50m on the ground...

I "resampled" these to 1024x1024 cells, with each cell representing 12.5m on the ground...

Smaller cells, and more of them... obviously this makes it easier to achieve smoother hills, etc and if you add up the numbers you'll see the actuall terrain extent is exactly the same ... effectively, I increased the Ground Resolution, while keeping the actual island size (and therefore, cunningly, all object coordinates, etc :D exactly the same)...

Following this logic, going to a 2048x2048 with 6.25m cells would have been even better!

Trust me, I tried - but here we hit a Visitor 3 limitation... it doesn't accept .xx values...

So - another example...a 1024x1024 terrain with 10m cellsize is exactly the same as a 2048x2048 with 5m cellsize - but the latter terrain is basically twice the Ground Resolution... 4096x4096 with a 2.5m cellsize would also be the exact same actual Terrain Extent, but would be double the resolution again! - better still???

Well - maybe not...

When you get down to these sort of ultrasmall cell sizes, significant performance issues start to appear...

There's no point having lovely ground detail when the FPS is all to hell... which seems to be one of the effects of too small a cell size.... another is stability... Beton's famous 2m (or was it 1m?) cellsize experiment a while back showed this pretty clearly...

Proving Grounds is another less extreme example... a roughly 2km x 2km terrain? it should totally fly FPS-wise - yet it doesn't...

It's all that hi-detail bumpy ground... the engine canny take it, Captn...

For these reasons, community terrains are often 10m cellsize... you can achieve reasonably detailed terrain, and you'll get no ridiculous performance issues... BIS used a classic 2048x2048x10m cell on Sahrani, for example...

More recently they've been creeping lower... Takistan, for example, is definitely sub-10m... not sure exactly... looks like 7 or 8m maybe...

The general rule is to avoid extremes... Huge maps with very small cells will perform like a pig - small maps with very big cells will look like a jumble of lego blocks rather than a terrain...

Choose wisely!

B

Edited by Bushlurker

Share this post


Link to post
Share on other sites

oh man, thank you for the detail. I think I actually understand what is going on. Thankfully we have people like you who try to actually help people instead of pointing and running. Even in the Visitor manual it doesn't explain what some of the values mean. I guess they figure anyone using it should know something. But not me.

So if I am to understand you, I am thinking that the size of my xyz being a 20480 has nothing to do with the 2048 map size in visitor.? I thought they were the same. I thought the xyz had to be the map size.

So I think you said;

If I choose a 2048 x 2048 I will have a map with 2048 squares going left and right an 2048 squares going up and down.

Then my cell size is how big each square will be. 10 meters for each square would mean that my map will have room for 20480 meters side to side, and up and down?

I'm glad you said resolution. Because then I think of my monitor, and level of detail when changing resolution, instead of squares on a map. I thought of it more as coordinates. I had no idea it was the resolution of the terrain and how it smoothes it out or not.

And if I have a xyz that was 20480 that would fit exactly. If I had a map that was smaller like 10240 that wold mean each square would end up measuring 5 meters not 10 even though the cell size would still say 10? And stretching the map out like that decreases the detail? Instead of shrinkiing a map down from 4096 to a 2048 size.

So if that is right, or close to it, I need to understand how the terrain gets put on the map. I thought it just lays down exactly what the xyz says. Does that mean 1 cell will be 1 size? Meaning that 1 cell will not change height. On te south end of the cell it's height is 4 and the north size is 4.3?

A user map "Tora Bora" comes to mind. I don't think that there is a flat spot anywhere on that map. It's really bumpy. It will be hard to find any flat spot as big as a house. So does that mean that it had a higher resolution? Maybe each cell was 5 meters or less?

Am I right to assume that terrain that may have steep mountains will need smaller resolution in order to make the transition in height more natural? If not, using a lower resolution like 50 meters on a map like that would create odd looking steps rather than natural mountains?

Thanks

Share this post


Link to post
Share on other sites

Hi again...

You're almost there!

If I choose a 2048 x 2048 I will have a map with 2048 squares going left and right an 2048 squares going up and down.

...Yup... Think of your HEIGHTMAP (xyz file) as a 2048x2048 cell spreadsheet - the X and Y numbers determine the position of each cell, and the Z value in every cell is the height of the ground at that point...

Then my cell size is how big each square will be. 10 meters for each square would mean that my map will have room for 20480 meters side to side, and up and down?

...that's it exactly...

Does that mean 1 cell will be 1 size? Meaning that 1 cell will not change height. On te south end of the cell it's height is 4 and the north size is 4.3?

This is where the spreadsheet/grid analogy breaks down a little - it's not so much a chessboard where each actual square is a set height - its more like a flexible fishing net, and those height values apply to the corners - the vertices of the grid... it's a "mesh" in other words...

Am I right to assume that terrain that may have steep mountains will need smaller resolution in order to make the transition in height more natural? If not, using a lower resolution like 50 meters on a map like that would create odd looking steps rather than natural mountains?

Pretty much correct again... rather than steps it'll look triangulated and jagged (it's a mesh, remember?), but yeah - the coarser the resolution - the more meters per "cell", then the clumsier everything will look... smaller detail ridges or ditches aren't possible - even small hills get tricky.....

So... gnerally you want more and smaller cells - bearing in mind that you don't want to go too low - or theres definite stability and performance problems... I probably wouldn't advise anything lower than 5-8m per cell... 10m is the most popular compromise...

Then - bear in mind that the engine only understands a limited set of "spreadsheet sizes" - 256x256, 512x512, 1924x1024, 2048x2048 and 4096x4096... so you have to consider both factors at the same time...

...an imaginary procedure using obvious sizes might be...

I want to make a 10km square area... it's quite a mountainous area with a tricky coastline - I'll need hi res ground and it's worth the potential performance hit... I'll use the preset 2048 size with a 5m cell - 2048x5 = 10240m = 10.2km

or... its a smooth low lying desert island with no major abrupt height changes - I'll use the preset 1024 size with 10m cells and benefit from slightly better performance... 1024x10 = 10240 = 10.2km

So far everything that's been talked about is the HEIGHTMAP or DEM... it's the underlying mesh or model of the terrain which gives it it's shape... just like under the texture of the tank model it's a wireframe mesh... same idea...

Islands use the texture idea too... what you actually see when you're flying across the landscape is the "Satellite layer" or "Sat_lco"... this is basically just a big hi-res photo or picture file which is draped over the heightmap model...

Typically - this sat layer has a much higher resolution than the underlying model... a typical figure would be 10x the resolution of the underlying heightmap...

So... if your heightmap is 1024 cells, and each cell is representing 10m, then a good sat layer resolution would be 10 times that - a 10240x10240 bitmap image.... then, each pixel of that image will correspond to 1 meter on the ground...

From a decent height, that'll look pretty good, and goes a long way to disguising the mesh underneath.....

... another figure to contend with there.... ;)... don't worry about that one right away though... I just mentioned it in case it helps you understand why 10m per pixel seems impossibly crude - yet that's what Sahrani was, and it looked OK... what you see is the 1m per pixel Sat Layer... the mesh underneath was much less.....

So - to summarise once again using the typical figures...

You make a HEIGHTMAP of say, 1024x1024 pixels/points - each pixel is representing 10m... it's a 1024x1024 file or image - but it represents 10240x10240 meters in-game

On top of that you'll overlay a Sat Lco ten times the size - it'll be a 10240x10240 image - each pixel will colour 1m of ground in-game

... then theres another layer... the "Mask_lco" - it matches the Satellite layer, and it controls what textures and clutter happen underfoot... since it matches the Sat layers 1pixel = 1m in game resolution, that means you can dictate texture and clutter underfoot on a per meter basis (with some significant limitations)... but that's yet another story... first things first and that's sculpting the actual landscape itself...

If you haven't done so already I strongly recommend you work your way thru Sgt Ace's Tutorial... this leads you thru all the basic steps necessary to get a terrain in-game... all required files are provided (though since it's a lightweight demo it doesn't feature that 10x hi-res sat_lco I mentioned above) and it illustrates how all the different files relate to each other... an essential introduction to the whole procedure...

Good luck!

B

Edited by Bushlurker

Share this post


Link to post
Share on other sites

Wow I have smoke coming out of my ears. As soon as I comprehend all that, I'm sure i'll have more questions. But it seems pretty straight forward. Now i'll try some of it and see what happens.

Thnaks.

My next question will likely be about setting up the vegetation and stuff. But one step at a time.

Share this post


Link to post
Share on other sites

i always give the idea / visualisation of a cloth draped over a square, on that square are sticks distributed evenly on a grid that hold up the cloth. In this, the cloth is the surface and the length of the sticks determine how high the cloth is being held to form for example a bump or hole. The more sticks you have dsitributed over the grid, the more detail is in the surface.

My map consists of 2048x2048 "sticks" to hold up the cloth, the sticks are spaced 5 meters apart from each other making it a 10.2 x 10.2 km/2 map.

Edited by Chill xl

Share this post


Link to post
Share on other sites

...A noob strikes again... :(

As we are close to release our map, I have this issue with borders regarding size of my sat_lco picture, which I've never undertood...

Project Parameters

Terrain grid size = 2048

Terrain cell size (meters) = 10.0

Terrain size (meters) = 20480 x 20480

Satellite grid calculator

Satellite Image

Image size (pixels) = 4608 x 4608 (i tried with this size this time)

Image resolution (m/pixel) = 4.444

Segment size (pixels) 512

Segment size (meters) = 2275.556

Segment overlap (pixels) = 16

Segment overlap (meters) = 284.444

Satellite Grid

Calculated =199.111

Proposed = 192

Segment overlap (proposed) = 80.000

Base (active) texture layer = 40m x 40m

When displaying an image of 4608*4608 and i have unsharp borders with 42px and 186px margins left on both sizes (total = 228px off)

Here you can see an image of NW border with 42px unwanted margin...

http://i56.tinypic.com/14ne0ix.png

So, can anyone tell me which size may fit at this size? I already have a 20480x20480 sat pic but I do not want to use such big image, so I would really appreciate any suitable more tiny size, and this map looks fine with 4096x4096 pic...

Perhaps I am doing something wrong here. but before I've tried with 4096x4096, 5120x5120, 8192x8192, 16384x16384... and still viewing ugly borders... :(

Greetings! :)

Edited by Robster

Share this post


Link to post
Share on other sites

Hi Robster...

4608x4608 seems a strange size to use...

4096x4096 seems quite small for a 2048x2048x10m terrain but if you reckon that's OK then theres no reason why you shouldn't be able to use it...

Try these settings...

rob1.png

...click "Apply Proposed" and it should work OK unless theres a problem elsewhere... you'll need to reimport the appropriate 4096x4096 Sat & Mask after changing the settings of course...

B

Share this post


Link to post
Share on other sites

Did you see the uploaded pic? it's a tipycal 512x512 px frame, you know, from vis...

Well, i have an awkward empty space, I mean, "no painted", at south and east borders... it's annoying since I am stuck with these kind of details just for release this one...

there goes an ingame view... as you may see still can view placed objects over there, but my sat pic does not cover that part ... wtf!!!

http://i53.tinypic.com/xgehyd.jpg

EDIT: BTW that's not a satout pic fail... cause these tiled images begin to appear with no objects...

---------- Post added at 12:30 AM ---------- Previous post was Yesterday at 11:04 PM ----------

eee

http://forums.bistudio.com/showthread.php?t=111131

http://forums.bistudio.com/showthread.php?t=116247

Edited by Robster

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×