View source for Proposals:Scenery related

{{Stub}}
This is meant to become a summarized list of all feature requests/suggestions related to the FlightGear Scenery system, it is largely based on [[Feature Requests / Proposals / Ideas]] (where all related items were deleted) and may not be up to date with the most recent developments in CVS, your help in updating and maintaining this list is appreciated!

* the draw-otw property works only properly for 2D panels, other types of panels will also be excluded from being rendered if that propery is set to false
* Allow crucial and performance related startup parameters (i.e. static LOD) to also be configured at runtime dynamically, so that there is no restart required for such changes to take effect
* adjusting the viewpoint and distance may result in the view going below the terrain/scenery (unverified as of 04/2009)
* Fix the tile loader: increasing the visibility to relatively high values (>100km) will significantly slow down FG (and rightly so), however resetting this to a normal value of 5 or 10 km afterwards does not reset the tile caching properly, so that FlightGear maintains high CPU utilization-this problem can currently only be solved by restarting FG. (unverified as of 04/2009)
* Consider providing support for runtime-configurable texture complexity/diversity, so that users can chose the min/max amount of different (terrain) textures displayed at a time, this may improve performance for lower end machines and simulatenously offers users with more powerful machines to make use of such capabilities
* add support for pilot-controlled runway lighting [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg23548.html]
* provide support for additional 3D cloud types to improve realism
* improve visual weather effects (fog, rain, snow etc)
* improve metar integration for 3D clouds (metar works basically only with 2D clouds properly) (unverified)
* add support for cloud shadows
* extend support for dynamic feature scaling [http://sourceforge.net/tracker/?func=detail&aid=1905510&group_id=583&atid=350583]
* tile cache reload should optionally also reload the stg files, so that scenery designers have it easier to verify their work at runtime without having to restart FlightGear
* <del>add texture paging support to simgear/flighgear</del> handled by OSG now
* <del>provide textures for all 4 seasons</del> available
* <del>provide dialog to switch seasons at runtime</del> available
* <strike>add support for enhanced water modeling, so that we can start implementing water aircraft with floats etc.</strike>-'''in progress as of 11/2007'''
* improve water effects [http://forum.flightgear.org/viewtopic.php?f=6&t=2440&st=0&sk=t&sd=a]
* implement support for dynamic LOD customization for aircraft at runtime, so that the detail level of aircraft models can be dynamically reduced/increases (the poly count, that is) on demand, currently multiplayer aircraft need to have their own separate (reduced) 3D model, so it would probably make sense to think about implementhing some sort of runtime configurable LOD algorithm that can return any 3D model with a customized detail level. This has been discussed various times on the mailing list (and is currently being discussed again).
* Currently, roads and rivers do not yet have a realistic curvature when their direction changes, rather there are pretty visible corners, it would be nice if someone could look into this in order to come up with a method to smoothen the directional transistion, so that a realistic curve can be rendered

* <strike>factor out current plib based scenegraph to allow [http://www.mail-archive.com/flightgear-devel@flightgear.org/msg15761.html integration with other scenegraphs], such as OSG (OpenSceneGraph). Adding support for OpenSceneGraph to FlightGear would also add support for mult-head displays, multiple rendering contexts as well as distributed rendering. If you are interested in this idea please make sure to search the mailing list archives at http://www.flightgear.org for "OpenSceneGraph", "OSG", "SSG" to get an impression of previous discussions about this topic.</strike> '''NOTE: FlightGear has been branched and the main branch is based on OSG'''
* factor out scenery system to allow integration with other scenery systems (see mailing list discussions) [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg13125.html Demeter discussion]
* factor out terrain system to allow integration with alternative terrain engines (see mailing list discussions)
* revamp scenery/terrain system in order to favor a non-tile based approach (see mailing list discussions concerning the use of quadtrees,octrees,kd-trees: http://www.sdss.jhu.edu/htm/index.html
* add support to optionally favor dynamic airport/runway creation at runtime over the pre-tesselated approach that is currently used, this would allow users to easily modify airports, possibly even at runtime-without having to re-create the corresponding scenery tile to make the changes take effect
* 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.
* 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/ )

[[Category:Code Cleanup]]