a question to the devs about large terrain

[Arma3goodCPUlowFPS 12]

hello, in this topic, you can see that i have tested and uploaded various terrain sizes for arma 3 and wrote my test results there:

http://forums.bistudio.com/showthread.php?187362-Large-Terrain-Test-Collection

terrain sizes i have tested in arma 3:

122km x 122km

204km x 204km

307km x 307km

409km x 409km

600km x 600km

2800km x 2800km

now the result in short was: the bigger the terrain is, the more bugs appear (you can read in my test result which bugs appear).

i feel that the bugs are more engine/game related than terrain builder related (except the low quality texture, that is more terrain builder related but have questions for that too). now my questions to the devs:

- is this a game/engine related bug ?

- if this is a game/engine related bug, can you explain what is causing it ?

- do you plan to fix the bugs and/or adding support for large terrain ?

for the texture thing:

- would it work if i would add high quality textures in for example 4096x4096 resolution instead of smaller resolutions ? would it automatically increase the quality of the texture in game ?

thanks

[brightcandle 114]

Performance wise my feeling is that smaller is better at this point, altis is just too large and cluttered for its own good and runs poorly. Bigger is not better, I would rather run 4 maps of 1/4 of the size than one big map most of the time.

[badluckburt 78]

The body moving left to right and the gun shaking have to do with floating point numbers and how processors handle them.

At some point they start rounding them off and that's when you see all sorts of magic happen. As far as fixing goes, no clue if BI is interested in that or if it would be worth the trouble (mind you, I'm NOT against big maps :) I know some people would love those sizes, just more of an infantry guy myself). I do believe 64-bit would solve that but I doubt A3 will ever be compiled to that.

As for the rest, it probably has to do with the amount of data that needs to be handled.

How many satellite and mask tiles do you get from those bigger maps? The algorithm that has to swap those out during gameplay probably isn't optimized to handle the number of files.

[Arma3goodCPUlowFPS 12]

The body moving left to right and the gun shaking have to do with floating point numbers and how processors handle them.

At some point they start rounding them off and that's when you see all sorts of magic happen. As far as fixing goes, no clue if BI is interested in that or if it would be worth the trouble (mind you, I'm NOT against big maps :) I know some people would love those sizes, just more of an infantry guy myself). I do believe 64-bit would solve that but I doubt A3 will ever be compiled to that.

As for the rest, it probably has to do with the amount of data that needs to be handled.

How many satellite and mask tiles do you get from those bigger maps? The algorithm that has to swap those out during gameplay probably isn't optimized to handle the number of files.

dwarden said that they want to add 64bit in a topic in this section (it was the topic "why do we have such low fps in multiplayer (MP vs SP FPS)" that was the name if i remember correct).

i have 25 tiles of sat & mask.

btw, i asked someone about the texture since he worked on a big map too (but abadoned it because it was too buggy) and he had very good textures, he told me that in the config it can be defined (need to ask him again because shit steam has no chat-backup). so there is a workaround to get HQ textures for any size, but for the rest there is no fix.

Performance wise my feeling is that smaller is better at this point, altis is just too large and cluttered for its own good and runs poorly. Bigger is not better, I would rather run 4 maps of 1/4 of the size than one big map most of the time.

my performance is on the big terrains the same as of altis. i played the seattle map from take on helicopters in arma 3 which is 60km x 60km and include over 2 million objects and it ran fine for me, just like altis/stratis. if you talk about multiplayer, then i agree that FPS can decrease there but i never played MP nor im interest in MP, im more a SP player or doing stuff in the editor.

[Arma3goodCPUlowFPS 12]

here is a video about the large terrain shaking issue (shaking gun etc):

and please vote this up:

http://feedback.arma3.com/view.php?id=21230

[badluckburt 78]

I know about the 64-bit server but nothing about the client, if so then

Ofcourse it won't magically fix everything but it should certainly add to stability.

25x25 tiles (if I understood you correctly) isn't that bad in my opinion but it's still a lot of data to handle. But who knows what the future holds, if we do ever get macro terrains that work perfectly, we're definitely going to need more auto-generating stuff. It would take an insane amount of time to properly fill up those sizes you tested.

And on a side-note, doesn't earth curvature come into play at the highest of those sizes at the least?

---- edit

Just watched the video, that's almost shirley floating point rounding 'errors' but if they're working on a 64-bit client I wouldn't fuss about it too much as that should fix the problem. I'm not even sure it's possible to sort out for 32-bit without some workaround which they probably want to avoid, for now I'd just stick to the biggest terrain it can handle properly or maybe with a little shaking. I can't see them giving this any huge priority over anything to be honest.

Edited January 9, 2015 by BadLuckBurt

[Arma3goodCPUlowFPS 12]

I know about the 64-bit server but nothing about the client, if so then

Ofcourse it won't magically fix everything but it should certainly add to stability.

25x25 tiles (if I understood you correctly) isn't that bad in my opinion but it's still a lot of data to handle. But who knows what the future holds, if we do ever get macro terrains that work perfectly, we're definitely going to need more auto-generating stuff. It would take an insane amount of time to properly fill up those sizes you tested.

And on a side-note, doesn't earth curvature come into play at the highest of those sizes at the least?

here: http://forums.bistudio.com/showthread.php?185001-Why-do-we-have-such-a-low-FPS-in-multiplayer%28MP-performance-vs-SP-performance%29/page3

idk if you mean this. i hope client 64-bit will come too.

and yes, earth curvature come into play

Edited January 9, 2015 by Arma3goodCPUlowFPS

[badluckburt 78]

Thanks for the link, just skimmed through it. It'll probably be a while if it ever sees the light of day going by Dwarden's replies there but it would certainly expand the lifespan and the possibilities of the engine.

The only thing we need then is a 32 CPU PC to please the AI's CPU time and away we go simulating full scale battles :P

[Arma3goodCPUlowFPS 12]

anyway, if nothing going to change in future, we still can use max 307km x 307km (with small bugs ofcourse, but mostly not noticeable, or if some people love playing with noticeable bugs, then we can go even further) which is enough for large scale combat and Nuclear, Biological & Chemical warfare (which requires big terrains for such WMD´s)

but it would be nice if we could go further and playing the terrains bugfree. i would love to make a huge terrain based on a mix between libyan desert, urban, iraq desert & urban and afghanistan mountains bugfree

[chrisb 196]

I can see why extra large terrains would be good for armour and air, not so much for infantry. Although I am a terrain fanatic.

I play Space Engineers, o.k. its space, however. They had serious problems concerning shaking ships, but it depended on how far from start position you were. All was stable at 200kms or under. But at around 700kms, for me and my setup, the ships would start shaking and you couldn't really build anything in space due to this. Problem was thought to be engine based.

Now SE has gone fully procedurally generated, plus I run on 64bit (they run 32 & 64 bit), they have zero shaking and you can build anywhere, well certainly, upto the distances I have travelled so far. The game world stands at present at 150,000,000,000 km's. Or infinite at the ship speeds you can travel, no jump gates or anything yet. Mind boggling but great.;)

But I don't suppose PG is an option for this series..:(

[ceeeb 147]

I'm not a programmer, but as I understand it the issues described are due to the (OFP through Arma 3) game engine using single precision floating point numbers. This issue affects all terrains, irrespective of size - the further from [0,0,0] an object is, the greater the precision issues become. It is likely not only a visual issue either, simulation precision is also reduced.

Presumably changing the engine to use double precision floating point numbers would solve this issue, but it would also severely affect performance. Switching to a 64 bit engine may well reduce the performance cost, but I really don't know enough to say.

BI's Arma content has always focused on higher detail, smallish terrains. I personally feel this is a good choice, given the engine's low performance with high dynamic object counts. If you really want to use huge terrains, take a look at the capabilities of VBS 3.

Edited January 10, 2015 by ceeeb

[jakerod 254]

What is your m/px on your mask for the terrains? Your insanely large pine cone issue can probably be traced back to that. In short, each pixel turns into one texture. If you have 5m/px then the texture becomes 5m x 5m changing a once 1/5m pine cone into a meter long pine cone. If you want regular sized textures you need to do a 1m/px mask.

BI's Arma content has always focused on higher detail, smallish terrains. I personally feel this is a good choice, given the engine's low performance with high dynamic object counts. If you really want to use huge terrains, take a look at the capabilities of VBS 3.

There is so much that I want to say about that terrain but will refrain. Don't go looking to VBS for solutions to your problems. The objectives of each are different

[badluckburt 78]

BI's Arma content has always focused on higher detail, smallish terrains. I personally feel this is a good choice, given the engine's low performance with high dynamic object counts. If you really want to use huge terrains, take a look at the capabilities of VBS 3.

I know it looks very cool but that will never make it into Arma. Over the years, those two engines grew apart so much and a lot of the stuff implemented for VBS is requested by their customers: