FlightGear 3.0 backlog: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (→‎Related Discussions: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40267.html)
(Switch to the {{forum url}} and {{forum link}} templates for all forum links.)
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{GitStatus}}
{{GitStatus}}
{{Draft}}
{{WIP}}


{{cquote|To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that.
{{cquote|To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that.
Line 9: Line 6:
work reasonably correct. I can't tell if that's the case for Rembrandt as I didn't have the time for any tests over the last 12 month or so.
work reasonably correct. I can't tell if that's the case for Rembrandt as I didn't have the time for any tests over the last 12 month or so.
<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html |title=Next FlightGear release (Feb. 17 2013)|author=Torsten Dreyer |date= Sun, 02 Dec 2012 12:18:19 -0800}}</ref>|Torsten Dreyer}}
<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38888.html |title=Next FlightGear release (Feb. 17 2013)|author=Torsten Dreyer |date= Sun, 02 Dec 2012 12:18:19 -0800}}</ref>|Torsten Dreyer}}
{{cquote|and "pre-announce" 3.0 as the Feb 2014 release to give us just a little more time to prepare and make the 3.0 as polished as possible.  After all, it'll be the third major release in 15 years<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40357.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Tue, 25 Jun 2013 14:48:56 -0700}}</ref>|Stuart Buchanan}}
{{cquote|many aircraft developers in particular would want to perform some extra TLC before a major release.  Externally, 3.0 is going to be
considered a bigger deal than 2.12.0.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40357.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Tue, 25 Jun 2013 14:48:56 -0700}}</ref>|Stuart Buchanan}}
{{cquote|Declaring that the Feb 2014 release will be 3.0 now will give everyone plenty of notice, and might encourage efforts to fix bugs in the next 6 months.  I'm aware that my FG development time is more limited these days, and given activity on this list I suspect I'm not alone, so this time might be quite useful.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40357.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Tue, 25 Jun 2013 14:48:56 -0700}}</ref>|Stuart Buchanan}}


<references/>
<references/>


== Items ==
== Items ==
Please only add items that have a corresponding mentoring core developer, or items that have been marked as accepted in the issue tracker: https://code.google.com/p/flightgear-bugs/issues/list?can=2&q=FeatureRequest%20status%3Aaccepted
Please only add items that have a corresponding mentoring core developer (=someone willing and able to work on it), or items that have been marked as accepted in the issue tracker: https://code.google.com/p/flightgear-bugs/issues/list?can=2&q=FeatureRequest%20status%3Aaccepted
 
=== A more lightweight base package ===
{{cquote|<nowiki>For the next release (3.0, I think), I want to reduce the size of the
installers by making parts of the base package optional. Some are easy, like AI
Traffic and ATC chatter - the first time you enable that feature, we'll
download (well, terra-sync, really) the relevant files. If you don't use the
feature, you don't download the files ever.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40754.html|title=<nowiki>[Flightgear-devel] Textures separation, cleanup</nowiki>|author=<nowiki>James Turner</nowiki>|date=<nowiki>Tue, 17 Sep 2013 15:12:46 -0700</nowiki>}}</ref>|<nowiki>James Turner</nowiki>}}
 
<references/>
 
=== Random Buildings ===
{{cquote|<nowiki>in V3.0 I plan to change this. Instead of using a scatter-gun
approach to placement and a mask, random building location will be
read directly from the mask, defined by a single pixel.  The color
(actually blue value from 0-255) will define the size of building
(small medium, large), and the red channel the rotation.
 
So instead of a material designer blocking out a large area for random
buildings to be placed within, they will define the specific location
for each random building.
 
Creating masks is going to require quite a bit more work in the "new
world", but the end result should be better.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40758.html|title=<nowiki>[Flightgear-devel] Upcoming Random Buildings changes</nowiki>|author=<nowiki>Stuart Buchanan</nowiki>|date=<nowiki>Wed, 18 Sep 2013 08:40:47 -0700</nowiki>}}</ref>|<nowiki>Stuart Buchanan</nowiki>}}
 
<references/>
 
=== FGCom (F-JJTH) ===
* [[Integrating FGCom]]
 
=== Nasal (Philosopher & Hooray) ===
* expose hooks to access more internals, i.e. for better diagnostics (parser,codegen,VM)
* better debugging, profiling and introspection support
* provide some form of dialog to show running callbacks (timers/listeners) and their impact on performance (fps, latency)
* look at making the existing GC generational


=== Weather (Thorsten) ===
=== Weather (Thorsten) ===
Line 21: Line 59:


* <del>a redesign of the weather interfaces, basically going to the unified weather system people have been talking about - some ideas and brainstorming urgently  needed! (backed by Thorsten and Stuart)</del>  {{Done}} (by Stuart and Vivian for 2.12)
* <del>a redesign of the weather interfaces, basically going to the unified weather system people have been talking about - some ideas and brainstorming urgently  needed! (backed by Thorsten and Stuart)</del>  {{Done}} (by Stuart and Vivian for 2.12)
{{cquote|<nowiki>rain layers still do not drift with the wind and will be eventually
displaced from their cap clouds. I've discussed this previously with James who
suggested that a generic way of spawning AI objects (which can get a velocity)
from Nasal rather than the current way of spawning non-AI models from Nasal
which can not drift would perhaps be a solution. I don't know what the status
of this is.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40911.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}


=== Long-standing bugs ===
=== Long-standing bugs ===
Line 37: Line 82:


=== Eye Candy ===
=== Eye Candy ===
{{cquote|<nowiki>unway and other lights do not appear in the effect framework, hence they
get fogged inconsistently with what Atmospheric Light Scattering is doing. I
think a cheap fix would be to fade them to transparent rather than to fog
color, otherwise they'd need to appear in the effect framework and then I could
write a consistent shader to treat them. I don't know what is preferable. The
same issue persists with particles, although that isn't as severe in terms of
showing realistic low visibility for IFR (it's a bit of a spoiler then the
runway lights are always visible...).</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40911.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>the sun is currently pretty much always drawn, in particular also if it is
below the horizon - which means that it shows inside the 'terrain' when the far
away terrain is just painted onto the skydome. The sun also shows 'through' a
cloud layer if the cloud layer is invisible because it is fogged. I think a
property control whether the sun (moon) should be rendered would solve this.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40911.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>exposing the moon phase somewhere as a property would be nice, then the
moonlight night lighting could be made automatically - currently it's property
controlled and one needs to edit the property by hand to see it</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40911.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>following a forum discussion about lightmaps for city and suburban terrain,
my idea would be to use the urban effect for this (which has that functionality
already) and run a version of the urban shader without the relief effect if
random buildings are on. That appears to be working fine:
{{forum url|t=21059}}
FredB - is this a modification to the urban effect you can agree with?</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40911.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>there's still a 'crack' in the sky visible when the skydome shader is used.
Based on the color of the crack which just shows the color of the default
sunlight underneath (which the skydome shader can't possibly know), I believe
this is really a fault line in the geometry and that it can't be fixed within
the shader code.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40911.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}


Then maybe some cool, but not so important features to make things complete:
Then maybe some cool, but not so important features to make things complete:
Line 51: Line 127:


Let me be the first to admit that it's much more fun doing my own stuff the way I like and then just merge it in. But if we can find consensus about any plan having to do with integration of new features and making it all work together, then I'm willing to reserve the majority of my coding time for working towards that goal. Would this be something to aim for in a 3.0 release?
Let me be the first to admit that it's much more fun doing my own stuff the way I like and then just merge it in. But if we can find consensus about any plan having to do with integration of new features and making it all work together, then I'm willing to reserve the majority of my coding time for working towards that goal. Would this be something to aim for in a 3.0 release?
== CMake Build System Issue ==
FlightGear versions <= 3.0 are known to have a cmake build system issue related to NOT automatically reconfiguring the SG/FG sources after updating the version files in in $SG_SRC and $FG_SRC, which basically means that using "git pull" to update your source trees (via the d&c script) will create the latest binaries, but they may not be looking for the right base package data, because the source trees are still using the old version files. This has been encountered by various contributors, including at least one core developer.
To work around this issue, simply switch into your SG/FG build directories and reconfigure each tree by running "cmake ." - for further info, see {{forum link|p=186647}} {{forum link|p=186942}}.
=== Misc ===
* add a standalone Nasal interpreter for people to play with Nasal without requiring a full FG sessions (Philosopher & Hooray)
* add the "Nasal Internals" docs (Philosopher & Hooray)


== Related Pages ==
== Related Pages ==
Line 57: Line 142:
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37547.html A plan for a 3.0 release?]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37547.html A plan for a 3.0 release?]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40267.html Feature freeze 2.12]
* [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40267.html Feature freeze 2.12]
<references/>
[[Category:FlightGear backlogs|3.0]]

Latest revision as of 10:37, 6 June 2019

Current release: 2020.3.19 (18 Oct 2023)
Next release: 2020.3.20
See release plan for details.
Cquote1.png To get to the 3.0 goal sometime in the near future, it's probably a good idea to create a backlog of open items in the wiki and link the release plan document to that.

As usual, we don't have to be perfect for a new major release number. But the new features being the reason for the new major number should work reasonably correct. I can't tell if that's the case for Rembrandt as I didn't have the time for any tests over the last 12 month or so.

[1]
— Torsten Dreyer
Cquote2.png
Cquote1.png and "pre-announce" 3.0 as the Feb 2014 release to give us just a little more time to prepare and make the 3.0 as polished as possible. After all, it'll be the third major release in 15 years[2]
— Stuart Buchanan
Cquote2.png
Cquote1.png many aircraft developers in particular would want to perform some extra TLC before a major release. Externally, 3.0 is going to be considered a bigger deal than 2.12.0.[3]
— Stuart Buchanan
Cquote2.png
Cquote1.png Declaring that the Feb 2014 release will be 3.0 now will give everyone plenty of notice, and might encourage efforts to fix bugs in the next 6 months. I'm aware that my FG development time is more limited these days, and given activity on this list I suspect I'm not alone, so this time might be quite useful.[4]
— Stuart Buchanan
Cquote2.png
  1. Torsten Dreyer (Sun, 02 Dec 2012 12:18:19 -0800). Next FlightGear release (Feb. 17 2013).
  2. Stuart Buchanan (Tue, 25 Jun 2013 14:48:56 -0700). Re: [Flightgear-devel] reminder: entering feature freeze now.
  3. Stuart Buchanan (Tue, 25 Jun 2013 14:48:56 -0700). Re: [Flightgear-devel] reminder: entering feature freeze now.
  4. Stuart Buchanan (Tue, 25 Jun 2013 14:48:56 -0700). Re: [Flightgear-devel] reminder: entering feature freeze now.

Items

Please only add items that have a corresponding mentoring core developer (=someone willing and able to work on it), or items that have been marked as accepted in the issue tracker: https://code.google.com/p/flightgear-bugs/issues/list?can=2&q=FeatureRequest%20status%3Aaccepted

A more lightweight base package

Cquote1.png For the next release (3.0, I think), I want to reduce the size of the installers by making parts of the base package optional. Some are easy, like AI Traffic and ATC chatter - the first time you enable that feature, we'll download (well, terra-sync, really) the relevant files. If you don't use the feature, you don't download the files ever.[1]
— James Turner
Cquote2.png
  1. James Turner (Tue, 17 Sep 2013 15:12:46 -0700). [Flightgear-devel] Textures separation, cleanup.

Random Buildings

Cquote1.png in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Creating masks is going to require quite a bit more work in the "new world", but the end result should be better.[1]
— Stuart Buchanan
Cquote2.png
  1. Stuart Buchanan (Wed, 18 Sep 2013 08:40:47 -0700). [Flightgear-devel] Upcoming Random Buildings changes.

FGCom (F-JJTH)

Nasal (Philosopher & Hooray)

  • expose hooks to access more internals, i.e. for better diagnostics (parser,codegen,VM)
  • better debugging, profiling and introspection support
  • provide some form of dialog to show running callbacks (timers/listeners) and their impact on performance (fps, latency)
  • look at making the existing GC generational

Weather (Thorsten)

  • lightfields and Rembrandt working together
  • lightfields properly supported by Basic Weather Done Done (by Stuart for 2.12)
  • lightfields integrating well with other shaders (For example, I know that the random vegetation doesn't work with lightfield shaders, and the fix that Emilian put together to allow the random buildings to work was a workaround rather than a full fix. I think this is probably something you and I will need to work on together to fix.) [1] Done Done (by Stuart and Thorsten for 2.12)
  • a redesign of the weather interfaces, basically going to the unified weather system people have been talking about - some ideas and brainstorming urgently needed! (backed by Thorsten and Stuart) Done Done (by Stuart and Vivian for 2.12)
Cquote1.png rain layers still do not drift with the wind and will be eventually displaced from their cap clouds. I've discussed this previously with James who suggested that a generic way of spawning AI objects (which can get a velocity) from Nasal rather than the current way of spawning non-AI models from Nasal which can not drift would perhaps be a solution. I don't know what the status of this is.[1]
Cquote2.png

Long-standing bugs

Then some fixes for long-standing, not really critical but annoying bugs

Eye Candy

Cquote1.png unway and other lights do not appear in the effect framework, hence they get fogged inconsistently with what Atmospheric Light Scattering is doing. I think a cheap fix would be to fade them to transparent rather than to fog color, otherwise they'd need to appear in the effect framework and then I could write a consistent shader to treat them. I don't know what is preferable. The same issue persists with particles, although that isn't as severe in terms of showing realistic low visibility for IFR (it's a bit of a spoiler then the runway lights are always visible...).[2]
Cquote2.png
Cquote1.png the sun is currently pretty much always drawn, in particular also if it is below the horizon - which means that it shows inside the 'terrain' when the far away terrain is just painted onto the skydome. The sun also shows 'through' a cloud layer if the cloud layer is invisible because it is fogged. I think a property control whether the sun (moon) should be rendered would solve this.[3]
Cquote2.png
Cquote1.png exposing the moon phase somewhere as a property would be nice, then the moonlight night lighting could be made automatically - currently it's property controlled and one needs to edit the property by hand to see it[4]
Cquote2.png
Cquote1.png following a forum discussion about lightmaps for city and suburban terrain, my idea would be to use the urban effect for this (which has that functionality already) and run a version of the urban shader without the relief effect if random buildings are on. That appears to be working fine: {{forum url|t=21059}} FredB - is this a modification to the urban effect you can agree with?[5]
Cquote2.png
Cquote1.png there's still a 'crack' in the sky visible when the skydome shader is used. Based on the color of the crack which just shows the color of the default sunlight underneath (which the skydome shader can't possibly know), I believe this is really a fault line in the geometry and that it can't be fixed within the shader code.[6]
Cquote2.png

Then maybe some cool, but not so important features to make things complete:

  • lightning (and thunder?) for thunderstorms
  • windsocks moving with ground wind rather than wind at aircraft position

Ideally, making full use of things we already have to present the best possible scenery

  • regionalized random building types
  • dedicated texture packs for the main vegetation zones
  • exploit the placement mask possibilities fully

And then, ship 3.0 with (finally) the next edition of a world scenery release, so we can really present much better visuals! So, personally I'd like 3.0 to be a release that doesn't only have cool features, but also cool features which work basically everywhere and a release that doesn't have the current snags like 'this doesn't work with that, and the GUI is counter-intuitive and so on.

Let me be the first to admit that it's much more fun doing my own stuff the way I like and then just merge it in. But if we can find consensus about any plan having to do with integration of new features and making it all work together, then I'm willing to reserve the majority of my coding time for working towards that goal. Would this be something to aim for in a 3.0 release?

CMake Build System Issue

FlightGear versions <= 3.0 are known to have a cmake build system issue related to NOT automatically reconfiguring the SG/FG sources after updating the version files in in $SG_SRC and $FG_SRC, which basically means that using "git pull" to update your source trees (via the d&c script) will create the latest binaries, but they may not be looking for the right base package data, because the source trees are still using the old version files. This has been encountered by various contributors, including at least one core developer.

To work around this issue, simply switch into your SG/FG build directories and reconfigure each tree by running "cmake ." - for further info, see [2] This is a link to the FlightGear forum. [3] This is a link to the FlightGear forum..

Misc

  • add a standalone Nasal interpreter for people to play with Nasal without requiring a full FG sessions (Philosopher & Hooray)
  • add the "Nasal Internals" docs (Philosopher & Hooray)

Related Pages

Related Discussions


  1.  (). .
  2.  (). .
  3.  (). .
  4.  (). .
  5.  (). .
  6.  (). .