4,400
edits
Advanced weather: Difference between revisions
m
Update forum links
m (Update forum links) |
m (Update forum links) |
||
| Line 104: | Line 104: | ||
* [http://forum.flightgear.org/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010) | * [http://forum.flightgear.org/viewtopic.php?f=5&t=8137 A smart cloud altitude algorithm] (05/2010) | ||
* [http://forum.flightgear.org/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010) | * [http://forum.flightgear.org/viewtopic.php?f=5&t=7591 Weather dynamics] (04/2010) | ||
* [http://flightgear.org | * [http://forum.flightgear.org/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010) | ||
* [http://flightgear.org | * [http://forum.flightgear.org/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010) | ||
* [http://flightgear.org | * [http://forum.flightgear.org/viewtopic.php?f=5&t=7358 A local weather system] (03/2010) | ||
== Connection with the Multiplayer system == | == Connection with the Multiplayer system == | ||
| Line 114: | Line 114: | ||
== Development == | == Development == | ||
* Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://flightgear.org | * Some users have expressed having problems when using the reset/new location facility, the local weather system should probably register listeners to /sim/signals/* and suspend/reset itself accordingly, so that all operations are gracefully interrupted? This may include releasing registered times and listeners, as well as terminating worker threads (once being used) [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94765] | ||
* Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://flightgear.org | * Dynamically examining the FG/Nasal APIs by running code that may cause exceptions, may also cause errors printed to the console, it would probably be a good idea to expose logging related variables to the property tree, so that the log system can be optionally muted in such cases, i.e. by introducing a "NONE" or "MUTE" logging priority [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&p=96439#p96370]. | ||
* The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://flightgear.org | * The feature-checking approach used by "compat_layer.nas" should probably be generalized and made available as a standard Nasal module, also for use by other scripts, as it provides a good method for handling backward compatibility [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&p=96439#p96358] | ||
* we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized. | * we could introduce another hash/namespace in the compat_layer module for Nasal based workarounds that are directly performance critical, so that the C++ implementation is prioritized. | ||
* for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that. | * for some uses, threading may provide a real performance benefit. However, we need to ensure that threading is always OPTIONAL, so that users can easily verify if potential problems are related to threading or not. Worker threads seem to be the easiest and safest way for doing that. | ||
* excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe. | * excessive use of the property tree for storing all sort of state variables is a potential performance bottleneck, it is usually better to directly use Nasal data structures. In addition, it is much easier to make use of worker threads when all data is available in Nasal space, especially given that the property tree (and basically all Nasal extension functions) are not designed to be thread safe. | ||
* to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://flightgear.org | * to be able to further optimize the system, it might be good to integrate some form of simple benchmark so that users can easily provide the results [http://forum.flightgear.org/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=165#p94801] (we talked about this in 9/2011, there are possibilities to provide this info automatically, but these would require modifying the core Nasal interpreter, and probably introducing some new instrumentation-specific opcodes, too - that doesn't seem to be a very popular idea at the moment, though). | ||
== Feature requests on the C++ side == | == Feature requests on the C++ side == | ||
| Line 131: | Line 131: | ||
=== Terrain related === | === Terrain related === | ||
* (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://flightgear.org | * (08/2012) provide an option to decouple terrain loading from visibility, so that geodinfo and the terrain presampler can also query terrain which is invisible [http://forum.flightgear.org/viewtopic.php?f=69&t=7358&start=525#p164198] [https://code.google.com/p/flightgear-bugs/issues/detail?id=848&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone]. | ||
* To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon. | * To check for wave conditions far from the original obstacle doesn't work well in Flightgear, because you can't rely on terrain far from your present location being loaded already. So by necessity one has to make it a more local phenomenon. | ||
=== Environment related === | === Environment related === | ||
* <del>(08/2012): Provide an option to disable the precipitation "layer" system [http://flightgear.org | * <del>(08/2012): Provide an option to disable the precipitation "layer" system [http://forum.flightgear.org/viewtopic.php?f=69&t=7358&start=525#p163627]: Local Weather has no precipitation rendering. This is due to the fact that the system uses its own layer altitude definition and a 3d definition of where rain is falling, whereas the precipitation rendering system uses a lowest altitude criterion. Since lowest layer altitude is always zero when local weather is running (it uses its own cloud altitude management and since clouds need to be placed with offset to the layer, it's easiest to make that layer zero) Local Weather has never rain unless you fly to the dead sea (not much chance of rain there either...). Could someone please provide a dumb rain and snow flag which alwaysrenders rain when that flag is set and leave it to the weather system to set/unset that flag as it sees fit? [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg35256.html] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg34300.html]</del> (fixed by Stuart) | ||
* (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone]. | * (06/2012) Sun is always painted on top of the skydome, you even see it through what is supposed to be terrain from high altitude. That's an issue for the maintainer of the sun code, it isn't curable via Nasal. See [https://code.google.com/p/flightgear-bugs/issues/detail?id=788&sort=-id&colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestone]. | ||