Feature Requests / Proposals / Ideas: Difference between revisions
Jump to navigation
Jump to search
→Huge Requests
Hellosimon (talk | contribs) No edit summary |
|||
| Line 130: | Line 130: | ||
* implement algorithms to feature dynamically adjustable (C)LOD/resolution for terrain data, as plans are being discussed to increase the resolution depth for upcoming scenery builds (SRTM), this would probably come in handy to allow users to adjust the terrain detail level according to their needs and hardware specs, otherwise we would probably face significant performance hits on lower end hardware, that is why it would make sense to allow users to configure the terrain resolution they'd like to use at runtime (i.e. 70% rather than 100% terrain features) | * implement algorithms to feature dynamically adjustable (C)LOD/resolution for terrain data, as plans are being discussed to increase the resolution depth for upcoming scenery builds (SRTM), this would probably come in handy to allow users to adjust the terrain detail level according to their needs and hardware specs, otherwise we would probably face significant performance hits on lower end hardware, that is why it would make sense to allow users to configure the terrain resolution they'd like to use at runtime (i.e. 70% rather than 100% terrain features) | ||
* Have FlightGear become its own IDE (integrated development environment) by allowing users to create and modify instruments directly within FlightGear, this would probably require a revamped (or more feature-rich) GUI toolkit than PLIB's PUI. Eventually, it would be desirable to allow users to pick instruments from the base package and place them at runtime on panels. For the majority of users this would be an essential steps towards improved usability. | * Have FlightGear become its own IDE (integrated development environment) by allowing users to create and modify instruments directly within FlightGear, this would probably require a revamped (or more feature-rich) GUI toolkit than PLIB's PUI. Eventually, it would be desirable to allow users to pick instruments from the base package and place them at runtime on panels. For the majority of users this would be an essential steps towards improved usability. | ||
* add support for automatically created scenery objects to populate the scenery dynamically at runtime (autogen-like), this could add quite a portion of realism to FlightGear without having to model scenery manually using fgsd, yet one could still use fgsd for areas where people are willing to contribute. All other scenery should by default be populated using autogen buildings and objects (references: http://www.infinitylab.com.au/research/prototypes.htm http://vterrain.org/Culture/BldCity/procedural.html | * add support for automatically created scenery objects to populate the scenery dynamically at runtime (autogen-like), this could add quite a portion of realism to FlightGear without having to model scenery manually using fgsd, yet one could still use fgsd for areas where people are willing to contribute. All other scenery should by default be populated using autogen buildings and objects (references: http://www.infinitylab.com.au/research/prototypes.htm and http://vterrain.org/Culture/BldCity/procedural.html and http://pcity.sourceforge.net/ ) | ||
== Proposals Post 1.0 == | == Proposals Post 1.0 == | ||