Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search

Feature Requests / Proposals / Ideas (view source)

Revision as of 09:39, 29 October 2009

3,050 bytes removed ,  29 October 2009
→‎Huge Requests
Line 183: Line 183:


=== Huge Requests ===
=== Huge Requests ===
* <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/ )


== Related content ==
== Related content ==
MILSTD
2,561

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/16966"

Navigation menu