I've done some simple tests today, and I can definitely say that the terrain itself is not the issue, the issues are the trees/random-buildings, and the textures and their usage.[1]
I've done a very bare materials file, one that assigns the same simple texture to all materials and disables everything else (effects, shaders, trees, buildings) on the terrain.
Results are as follows (for 16km, 32km and 70km visibilty, weather was disabled --prop:/environment/metar/data='NIL\n', I used the UFO so that I can see just what kind of memory the terrain is using, values in MB, linux 64bit)
- Code: Select all
visibility km 16 32 70
LRSB bare mat
tsync terrain 307 308 310
custom terrain 475 495 502
LOWI bare mat
tsync terrain 388 391 392
custom terrain 725 736 742
As you can see, while there's an increase in memory usage between terrasync terrain and custom terrain, it's not that dramatic as you might expect.
LOWI represents a mixed usecase, where there are a lot of custom objects. The first case is not that bad, just on the order of tens of MB of more memory used. The Custom testcase shows the real issue, ~300MB of memory used just by custom objects, almost as much as just the terrain mesh.
Now for comparison here's the data just for 16km of visibility for LRSB, with the default materials file, 1.5 trees density:
- Code: Select all
LRSB default mat
tsync terrain 800
custom terrain 1304
So just with terrain and models we're using 800MB with the default terrain. With the custom terrain the issue becomes bigger. Most of that increase is solely due to trees/random buildings in the default terrain case, and due to extra textures in the custom terrain case.
Now let's look how much an aircraft hits. You'd be surprised, but our aircraft models are actualy light
:
- Code: Select all
LRSB bare mat
tsync terrain 307
custom terrain 475
tsync terrain + IAR80 516.8
tsync terrain + Hurricane 447.5
Tsync terrain + b1900d 815.6
See that, just ~210MB for the IAR80, 140MB for the Hurricane and a whopping ~510MB for the b1900d (due to many big textures used for the effects, and due to the fact that those textures are kept uncompressed in RAM).
Notes:[1]As much as it's a neat feature, I consider (and this data confirms), that we shouldn't use the multiple choice of textures in the material files, we're only making a bad issue worse, the more the terrain is detailed, the more it will load extra textures for the same landclass.
side Note: Thorsten, don't take this the wrong way, but you really need to do something about all that math in the vertex shaders. With default terrain, the test materials-file, enabling the atmospheric scattering completely destroyed performance dropping fps in the 20-30 range, while with just the transition shader enabled it stayed capped at 60fps due to vsync being enabled (it was likely higher than that), no matter how much terrain thus vertex data there was to process.
In conclusion, we have two separate issues. One already known, and most likely fixable, is that random-buildings/trees eat a lot of memory.
The second one, we waste a lot of memory with uncompressed textures, and thus with extra textures entries in the materials file, or with detailed scenery models.
How the second one should be solved I don't know...
Thorsten: The hard crash limit for a 32bit process would be around 3.2GB of memory used by that process IIRC. That can easily mean 5GB of total memory used. Monitor the fgfs process memory usage and see when it crashes.