Some believe in HLA and distributing the computation work, others (like myself) point out that rendering is usually 95% of the work anyway, so whether you thread out the remaining 5% doesn't really matter so much and any gain you may have might well be eaten by the overhead you need to keep threads in sync. There's two schools of thoughts among the developers. With shadows I'm not sure which ones you mean - cloud shadows only go out to 30 km or so (usually in reality they're not visible much farther either), vegetation shadows go out as far as the vegetation LOD range because they're just extra quads added to a tree.Īnd related to multi core, when did FlightGear see the light of day. Overlay objects (lights on the roads, buildings, vegetation.) are loaded at 'their' LOD range (which the user can configure) - they're not actually visible out to infinity, but often they're introduced in up to 10 LOD groups, so the whole chunk never pops at once, there's just gradually 'more' stuff appearing when you get closer. The texture resolution can be fairly coarse, because the actually visible texture at high rendering quality is a composite of six different textures and procedural noise, some of which generate details as small as a few cm - in terms of GPU memory and loading times, that's rather efficient. Terrain textures are utilized for whole regions, so usually they need to be loaded once at startup, remain resident in GPU memory and are by and large just used when a new chunk of mesh is loaded, it's rare they need to be loaded. Also, particularly 'heavy' terrain (lots of vegetation requested, or the OSM2CIty real building coverage overlay) often makes this happen at lower visibilities.īut for ~150 km visibility, the bare terrain mesh is reasonably simple, so it loads fast (especially from an SSD). You can easily (dependent on your systems specs) make the terrain loading process visible - certainly something like the X-15 climbs fast enough such that when requesting 600 km arc-top visibility, you see the circle of terrain mesh expanding around you. So it seems to me others are just doing worse (?) Though I believe the loading queue for the 3d renderer is of the few things that can utilize multiple cpus - I'm not sure that's the default setting though. at a distance 20% larger than current visibility). I'm actually surprised at your question - I wouldn't have described FG in such terms myself, and in fact some two years ago I wrote a long comment on the developer's list how the lack of LOD for the terrain mesh is one of our biggest problems (of course, now loading terrain from SSD into the 8GB of memory of a high-performance GPU, it ceased to be an issue again.)īut the fact remains that it is conceptually not a 'good' scheme - it just loads the terrain mesh when requested (i.e. What's the secret? Why does everything load so effortlessly?
0 kommentar(er)
