![]() I basically installed it, loaded the first plane (cessna 172), got the joystick going, and there it all was. ![]() ![]() And with very little setting up on my side. Lights lining roads, wow! I think stars and moon looked good too.Īll that was without stutters of any kind. But all variations ranging from whispy ground fog to thick impenetrable clouds. Many shades of yellor and orange.Īnd sun shining through clouds looked good too.Ĭlouds were good anyway. But shadows of clouds was also a great progress over fsx. In fsx colours in distance are same as close by. And becoming "vague colours" in distance as in real life. Many more different shades of colour in scenery. In flightgear it took a very long time to realise that not all was 3d!! In fsx, with low amount of 3d autogen the city looks like brown mud. I think I even say cranes in the distance at a loading dock in a harbour.Īlso, city ground textures where no 3d buildings showed looked more like buildings then in fsx. Highrise buildings througout whole visibility range. I think there's a few things that made it like a breath of fresh air: So while I'm on the one hand happy about your observations, I can't really honestly say I share the sentiment - in my view there's much that could be improved in how FG handles the terrain.Įdit: I'm not quite sure why the forum software added links to 'terrain mesh' - I hope that is as it should be. (I understand X-plane fills the other cores by running actual flight dynamics for Ai-traffic - which gives you an impression of a fully-utilized computer, but probably doesn't overly change the experience for the user so much.) So I believe currently some obvious things can be threaded out of the main loop (and it's also possible to do that in scripting space), but FG is a far cry from having efficient multicore utilization. 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 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |