Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search

Feature Requests / Proposals / Ideas (view source)

Revision as of 09:31, 29 October 2009

1,452 bytes removed ,  29 October 2009
m
→‎Major Requests
Line 174: Line 174:
* texture cropping support for 2D panels (see mailing list archives for discussions)
* texture cropping support for 2D panels (see mailing list archives for discussions)
* <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'''
* 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.
* 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])
Line 185: Line 184:
* add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear
* add moving map functionality to FlightGear (i.e. integrate atlas natively into FlightGear), so that a basic map can be directly shown within FlightGear
* add support for adding, placing and modifying scenery objects within the scenery dynamically at runtime-possibly using the property tree to enumerate all active scenery objects, so that attributes can be changed at runtime
* add support for adding, placing and modifying scenery objects within the scenery dynamically at runtime-possibly using the property tree to enumerate all active scenery objects, so that attributes can be changed at runtime
* eventually, it may become desirable to add unit testing support to those FlightGear subsystems/components that can be considered stable and that are thus unlikely to change significantly anytime soon, that way it should become much easier to track development problems early.
* 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).
* the current (2D/3D) cockpit panel code is not yet particularly efficient, would be good if someone could optimize it some more
* the current (2D/3D) cockpit panel code is not yet particularly efficient, would be good if someone could optimize it some more
* add support for tutorials/lessons (think, flight school) to FlightGear (see earlier mailing list discussions for details) '''(Note - tutorials have already been added; check the Help menu in the default C172 or Lightning)'''
* add support for tutorials/lessons (think, flight school) to FlightGear (see earlier mailing list discussions for details) '''(Note - tutorials have already been added; check the Help menu in the default C172 or Lightning)'''
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim)  would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16047.html]
* More and more often, users of other flight simulators with lacking scenery support (such as Aerowinx Precision Sim)  would like to use FlightGear in conjunction with their commercial simulator in order to create a FlightGear-based visual scenery representation. To some extent this works already quite well due to the possibility to provide an external/null FDM. However it is not uncommon to see more or less significant differences in the underlying databases (navaids, terrain, airports/runways),so that for example, navaids in other simulators do not match the positions in FlightGear and vice versa. Likewise, for airports and runways. Currently, the only workaround is to manually hardcode corresponding offsets in order to compensate for this. However, in the long run it would be nice if there was a standardized mechanism in FlightGear to automatically align databases for navaids, airports, runways, terran and possibly also important scenery objects (landmarks). This could probably be based on a mechanism to allow other simulators to request/send positional information for a navaid, airport/runway so that FlightGear could automatically compensate for differences by auto-aligning the corresponding coordinates at runtime. Preferably, something like this would be exposed via a network interface (i.e. telnet) so that it would become very straight forward to interface with FlightGear. In the long run, such a facility would also make it possible to use different sets of underlying data in FlightGear easily. [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16047.html]
* Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view.
* Allow arbitrary custom views to be rendered to a texture, so that the created texture can be used to create instruments that feature some sort of "outside view", i.e. an advanced HUD or the external view of an A340 (camera mounted on the tail), this would enable us to show external views on an instrument in the cockpit panel. We only need something that allows us to define a custom instrument layer type that gets its contents from a specific user defined (or global) view.
* 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
* Extend the RenderTexture class to provide support for Frame Buffer Object based rendering to a texture, this is a relatively new way to support rendering to texture for platforms or OpenGL (driver) implementations that do not offer native RTT support, as it is the case for many older Linux cards: http://openvidia.sourceforge.net/fbo.shtml
* Extend the RenderTexture class to provide support for Frame Buffer Object based rendering to a texture, this is a relatively new way to support rendering to texture for platforms or OpenGL (driver) implementations that do not offer native RTT support, as it is the case for many older Linux cards: http://openvidia.sourceforge.net/fbo.shtml


MILSTD
2,561

edits

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

Navigation menu