Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search
m
deleting more navdb related items in order to move them to a dedicated page
m (Removing items related to the navdb)
m (deleting more navdb related items in order to move them to a dedicated page)
Line 217: Line 217:
* <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'''
* <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'''
* when aircraft are very low, the terrain/scenery looks only rarely convincing due to the fact that flat textures are applied to surfaces in order to illustrate vegetation, however this works only properly for higher altitudes, so it would be desirable if we could add support for dynamic vegetation modeling, so that grass, trees and other plants are dynamically created within a certain proximity. (NOTE: [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15388.html  this is currently (01/2008) being tackled])
* when aircraft are very low, the terrain/scenery looks only rarely convincing due to the fact that flat textures are applied to surfaces in order to illustrate vegetation, however this works only properly for higher altitudes, so it would be desirable if we could add support for dynamic vegetation modeling, so that grass, trees and other plants are dynamically created within a certain proximity. (NOTE: [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg15388.html  this is currently (01/2008) being tackled])
* the navdb should eventually become a true SGSubsystem, it needs some serious revamping
* it would be very useful if there was a spatial wrapper provided on top of the navdb, so that spatial queries can be easily used to ''efficiently'' search the navdb [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg01453.html]
* basically all subsystems should be fully "suspend-able" and "reinit-able" at runtime, there are currently various subsystems that will consume CPU cycles even though they are not in fact necessarily required, affecting FlightGear's performance negatively. This is particularly the case for non-SGSubsystem based systems.
* basically all subsystems should be fully "suspend-able" and "reinit-able" at runtime, there are currently various subsystems that will consume CPU cycles even though they are not in fact necessarily required, affecting FlightGear's performance negatively. This is particularly the case for non-SGSubsystem based systems.
* the navdb & airports wrappers should eventually be moved to simgear, there are meanwhile various programs (i.e. atlas,taxidraw,fgsd,fgrun) relying on the very same code-using the copy&paste approach. It would be much cleaner and better if simgear could provide the corresponding functionality. That way, we would also only have to fix any issues (i.e. changes in Robin Peel's db format) on ONE central place, rather than having to edit multiple code bases to fix bugs or add features
* add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details)
* add support for inter-texture copying to allow users to copy parts of a texture to another texture (see mailing list dicussions for details)
* The current Property Tree code is not thread safe, sooner or later it may come in handy if this feature was added (FWIW, threaded PropertyTree implementations are provided by these two open source libraries: [http://pocoproject.org/poco/info/index.html poco] [http://www.boost.org boost])
* The current Property Tree code is not thread safe, sooner or later it may come in handy if this feature was added (FWIW, threaded PropertyTree implementations are provided by these two open source libraries: [http://pocoproject.org/poco/info/index.html poco] [http://www.boost.org boost])
2,561

edits

Navigation menu