Why does the scenery engine need to ultimately choose between vector-based and photoscenery when rendering, based on old Microsoft FSX design? Most users today use photoscenery, with spectacular results, except for when you are on or very near the ground.
Since photoscenery is useful at only above a few thousand feet AGL (and above), and Vector scenery useful only below about the same altitude, wouldn’t it make sense for the scenery module to be smart enough to render the best hybrid based on AGL? All the scenery objects (.bgl and texture) are all “out there”, it’s just a matter of the scenery engine making the best of both worlds (not meaning to over-simplify the development effort to do this, of course).
Near the ground I want to see all the buildings, trees, traffic, detailed night lighting (such as street lights), and all the rest of ground level detail. Vector-based scenery has all this stuff. But at higher altitudes, give me the photoscenery, (maybe with proper night lighting bleeding through). It would be nice if the switch over altitude point could be softened a bit, rather than a sudden pop, similar to how weather might change over time.
There could be a setting or two in the config file to:
1. Select the scenery mode: Hybrid mode (Dynamic vector/photoscenery), or Current mode (as it exists now).
2. The AGL altitude value at which the scenery would switch from vector to photoscenery (and vice versa).
3. Perhaps these settings belong in the aircraft.cfg, since they are based on altitude and/or aircraft flying preferences.
This effort, if taken on by LM, would be the greatest thing since, well, 64-bit...(and thank you, LM, for that).
Rendering best mix of Vector vs. Photoscenery based on AGL
Re: Rendering best mix of Vector vs. Photoscenery based on AGL
If you are asking about marrying 3D objects to photoscenery, this is a scenery developer job. Orbx TrueEarth 3D scenery products do great job of this.
Stiletto2
Stiletto2
Re: Rendering best mix of Vector vs. Photoscenery based on AGL
When Orbx has a product offering for my region (California), I will consider using it as an interim solution. Thank you for that bit of information.
However, in the bigger picture, I believe a more beneficial solution is to modify the scenery engine to logically adapt “render fit smart” to the existing worldly data, e.g. scenery (photoscenery or vector based), terrain textures, and what else have you, and render it accordingly, in a real-time hybrid based on flying conditions (situation) in the simulator.
Simply put, use what we got (a lot of data property invested already), and not proliferate with even MORE data coming onto the scene, just for the purposes of overcoming shortcomings of decade-plus outdated architecture and strategy. As the software grows to a smarter capability, the evolution of compatible cleaner and tighter data can proceed forward also.
Isn’t this the way technology should evolve and lead us forward? Furthermore, isn’t the vast existing treasure trove of FSX- structured scenery, texture, and objects the REAL reason that P3D continues to remain in high demand? The advance to 64-bit saved us all from its extinction, but the real value is that everyone has too much invested to just throw it ALL away and start over. LM can once again, save the day for us, and secure their market by stepping up to the challenge of re-working the scenery and texture engine components. Of course, it is a big job, but so worth it, and the time is right, before the matrix of third-party products gets even more befuddled, particularly if the master plan of development from LM is kept too secretive.
However, in the bigger picture, I believe a more beneficial solution is to modify the scenery engine to logically adapt “render fit smart” to the existing worldly data, e.g. scenery (photoscenery or vector based), terrain textures, and what else have you, and render it accordingly, in a real-time hybrid based on flying conditions (situation) in the simulator.
Simply put, use what we got (a lot of data property invested already), and not proliferate with even MORE data coming onto the scene, just for the purposes of overcoming shortcomings of decade-plus outdated architecture and strategy. As the software grows to a smarter capability, the evolution of compatible cleaner and tighter data can proceed forward also.
Isn’t this the way technology should evolve and lead us forward? Furthermore, isn’t the vast existing treasure trove of FSX- structured scenery, texture, and objects the REAL reason that P3D continues to remain in high demand? The advance to 64-bit saved us all from its extinction, but the real value is that everyone has too much invested to just throw it ALL away and start over. LM can once again, save the day for us, and secure their market by stepping up to the challenge of re-working the scenery and texture engine components. Of course, it is a big job, but so worth it, and the time is right, before the matrix of third-party products gets even more befuddled, particularly if the master plan of development from LM is kept too secretive.
