4,400
edits
Feature Requests / Proposals / Ideas: Difference between revisions
Jump to navigation
Jump to search
m
Feature Requests / Proposals / Ideas (view source)
Revision as of 17:37, 2 December 2010
, 2 December 2010Bot: Automated text replacement (-CVS +Git)
m (→Major Requests) |
m (Bot: Automated text replacement (-CVS +Git)) |
||
| Line 103: | Line 103: | ||
=== Visuals === | === Visuals === | ||
* not fully animated 3D models (this depends on the aircraft being used) | * not fully animated 3D models (this depends on the aircraft being used) | ||
* insufficient weather modeling and -effects (as of 11/2008, shader-based 3D clouds were added to | * insufficient weather modeling and -effects (as of 11/2008, shader-based 3D clouds were added to Git/HEAD) | ||
* non-standard GUI, not too appealing to many users | * non-standard GUI, not too appealing to many users | ||
* no realistic water modelling (improving in OSG branch as of 11/2007, in fact there's [http://helijah.free.fr/water/ very promising work] going on since 01/2008) | * no realistic water modelling (improving in OSG branch as of 11/2007, in fact there's [http://helijah.free.fr/water/ very promising work] going on since 01/2008) | ||
| Line 139: | Line 139: | ||
=== Intermediate Requests === | === Intermediate Requests === | ||
* <del>switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)</del> | * <del>switch completely to [http://www.libsdl.org/ SDL] (or [http://www.andesengineering.com/Producer/ OpenProducer]?) for I/O handling (many more possibilities and better support than plib/GLUT can offer)</del> Git/HEAD is now based on osgviewer | ||
* support additional transformation type to allow cropping and cutting off of textures, useful for example for things like a rose vs. arc mode HSI representation | * support additional transformation type to allow cropping and cutting off of textures, useful for example for things like a rose vs. arc mode HSI representation | ||
* <del>it might be a good idea to add another routine to SimGear that can optionally check textures to match the 'power of two' requirement and emit a console warning if that's not the case. This will make it easier for developers to track down texture size related problems.</del> also now handled by OSG | * <del>it might be a good idea to add another routine to SimGear that can optionally check textures to match the 'power of two' requirement and emit a console warning if that's not the case. This will make it easier for developers to track down texture size related problems.</del> also now handled by OSG | ||
* add new command to nasal interpreter to allow playing of sound files (see mailing list discussions) | * add new command to nasal interpreter to allow playing of sound files (see mailing list discussions) | ||
* <del>implement a "failure/crash" (limits?) subsystem that can be XML-configured with tailored values and limits for specific aircraft (i.e. max allowable speeds in various configurations, max allowable pitch up/down, roll angle, g load etc.). That way, it would be up to aircraft authors to provide such limits for their aircraft in some sort of easily modifiable XML file and FlightGear could optionally honor these values at runtime (currently, it is no problem to extend the gear or flaps at ridiculously high speeds, or crash-land an airliner and keep flying afterwards-this would certainly add a good portion of realism to FlightGear and could still be kept entirely optional).</del> this has been basically implemented via the the limits Nasal module, see [[Howto: Define speed limits]] (there's now also failures.nas in | * <del>implement a "failure/crash" (limits?) subsystem that can be XML-configured with tailored values and limits for specific aircraft (i.e. max allowable speeds in various configurations, max allowable pitch up/down, roll angle, g load etc.). That way, it would be up to aircraft authors to provide such limits for their aircraft in some sort of easily modifiable XML file and FlightGear could optionally honor these values at runtime (currently, it is no problem to extend the gear or flaps at ridiculously high speeds, or crash-land an airliner and keep flying afterwards-this would certainly add a good portion of realism to FlightGear and could still be kept entirely optional).</del> this has been basically implemented via the the limits Nasal module, see [[Howto: Define speed limits]] (there's now also failures.nas in Git) | ||
* <strike>add openGL wrapper commands to the Nasal interpreter, so that users can make use of basic OpenGL calls (the primitives at least) from their scripts, optionally allow to render to a texture rather than directly to the screen, i.e. useful for things like a scripted display (CDU/moving map)</strike> Don't try to bypass the SceneGraph, instead, use proper interfaces/modelling.. | * <strike>add openGL wrapper commands to the Nasal interpreter, so that users can make use of basic OpenGL calls (the primitives at least) from their scripts, optionally allow to render to a texture rather than directly to the screen, i.e. useful for things like a scripted display (CDU/moving map)</strike> Don't try to bypass the SceneGraph, instead, use proper interfaces/modelling.. | ||
* add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft (what is this supposed to mean?) | * add support to enable users to disable 3D cockpit rendering for multiplayer/AI aircraft (what is this supposed to mean?) | ||