Properly sized Satellite maps?

[freakjoe 3]

Hello there,

Just a quick question : How do I figure out what size my satellite map / layer mask should have?

For example if I had a 4096x4096 heightmap with 5m cell size, what would a good size for the texture map be?

Thanks in advice,

FreakJoe

[m1lkm8n 410]

So that's 20480 x 20480. That's a very large map. But if you do 20480x20480 that's a 1 to 1 ratio. Mine is 1024x8 which is 8192x8192 and I use that as my sat and layer mask size as well.

Bushlurker told me I could use a higher number like 16384x16384. Usually a 1to1 ratio I think is used most often

[bushlurker 45]

Basically you can use any square size that's easily dividable by your heightmap size...

As a general rule you'd want to use at least 1 pixel per meter for your Sat & Mask layer, so if your map is 20480 meters wide, then a 20480x20480 would be your "standard" size.

Often, the largest size you can use is dictated by what your graphics program can handle... Generally speaking, you'd struggle to create a 40960x40960 image, so if you were making some kind of enormous 4096x4096 x 10m cell monstermap, then you might need to settle for "worse" than 1 pixel per meter... That would start to look pretty cheesy...

Conversely, if you're making quite a small map, it's perfectly possible to use a Sat & Mask size that's a little "better" than 1 meter per pixel...

Eg: if you had a 1024x1024 x 5 meter heightmap for a 5120 meter terrain, you could use a 10240x10240 Sat & Mask size... that's still a pretty small image to handle and it works out at 0.5 meters per pixel - That would look pretty good!

(In fact, you can see these exact parameters and sizes in-game in my Carraigdubh terrain... a 5120 meter terrain with a 10240 pixel Sat & Mask - that's why it looks quite "hi-res").... (The CWR2 Islands are all "over-res" too... you can just tell by the screenshots)

As terrain sizes get larger, it's increasingly difficult to pull this "over-res" trick until finally you reach the monstermap sizes mentioned above...

* Note also there's a slight inherent "performance hit" by lumbering a terrain with an oversized sat layer... in the smaller sizes, such as Carraigdubh, it's hardly noticable, but again, as the terrains get bigger it becomes more obvious and therefore less practical...

a 4096x4096 heightmap with 5m cell size

There's an additional problem with the Visitor 4096x4096 terrain size... Apparently it's a little "bugged" and people have reported significant problems trying to place objects on this size terrain,,, A 2048x2048x10 meter terrain however, is the same overall size and would work OK...

B

[freakjoe 3]

Thanks again for the responses. I guess I get it.

Now, Bushlurker thanks for warning me about the problems with that certain terrain size.

Now I'm wondering though : Doesn't a smaller heightmap mean less possible detail and smaller problems like bumpy roads?

Thanks again,

FreakJoe

[bushlurker 45]

Now I'm wondering though : Doesn't a smaller heightmap mean less possible detail and smaller problems like bumpy roads?

The "dodgy 4096x4096 behaviour bug" in Visitor 3 PE is a pretty limiting factor for us mapmakers.. As you've noticed, there's more than one way of achieving a given map size. The "larger grid, smaller cell" option DOES enable better ground surface detail and, well, easier road smoothing, I guess, and - like so many other aspects of mapmaking - as long as you don't take it to extremes, higher-resolution is generally better.

Your main concern - as always - is performance Vs prettiness. Larger grids with more cells generally perform less well than smaller grids with larger cells, but as always, sensible compromises that avoid extremes are generally best.

Technically, there are ways around what is more properly called the "4096 object-placement bug"... SnakeMan successfully managed a few fully-covered 4096 experimental terrains recently, but the process involves all sorts of script-trickery and/or building stuff in a working area and then transposing the objects en masse to the dodgy areas... Seriously not for beginners I'd say... I wouldn't attempt it myself unless I really, really had to...

The 4096 bug is one of the more annoying ones we've come across in Visitor PE... Finding that to have been fixed and working is one of my more realistic hopes for a future BI Tools Suite release... There's a "Visitor 3 Standard" edition which is part of the VBS2 toolkit and it doesn't suffer from this bug afaik, so that would suggest that it IS a fairly simple bug and therefore just MIGHT get fixed in some hypothetical future toolkit... We hope.... ;)

Meantime, we compromise....

B

Edited February 17, 2013 by Bushlurker

[jakerod 254]

I'm not sure how much this would limit you later on but you could do a 2048 x 10m and then later on export/paste absolute all the objects from that onto a 4096 x 5m. I think height data is still editable in the "4096 Deadzone" but I could be wrong. I haven't really tried a terrain that big myself.

[freakjoe 3]

I'm not sure how much this would limit you later on but you could do a 2048 x 10m and then later on export/paste absolute all the objects from that onto a 4096 x 5m. I think height data is still editable in the "4096 Deadzone" but I could be wrong. I haven't really tried a terrain that big myself.

Sounds like an idea. Might just try that out once I'm done with everything that needs to be done prior to that.

[jakerod 254]

Sounds like an idea. Might just try that out once I'm done with everything that needs to be done prior to that.

And if you can't edit the terrain you could always export the heightmap and edit it in a terrain program.