1,360
edits
Advanced weather: Difference between revisions
Jump to navigation
Jump to search
→Related Discussions
m (adding links to related discussions (from flightgear forums)) |
|||
| Line 90: | Line 90: | ||
as this will make the pressure at position <i>i</i> equal to <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same. | as this will make the pressure at position <i>i</i> equal to <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same. | ||
= Related Discussions = | == Related Discussions == | ||
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010) | * [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010) | ||
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010) | * [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010) | ||
| Line 98: | Line 98: | ||
(should be written by someone who knows what the Multiplayer system can and cannot do) | (should be written by someone who knows what the Multiplayer system can and cannot do) | ||
== Feature requests on the C++ side == | |||
To aid current development, a few features would be nice to have from the C++ side for good performance of the code: | |||
* cloud transformations: Two view-axis based model transformation routines are available with an xml animation tag with the billboard animation. The problem is that neither of those is very useful for cloud models. It would probably help a lot in terms of performance to have more transformations available which are more suitable for cloud models: 1) one-axis position vector based rotation (yaw) 2) two-axis position vector based rotation which does not roll the model (yaw and pitch). Each of those should optionally support the specification of ranges (i.e. pitch only between -20 and +20 deg) and also a minimal distance beyond which the model is not rotated any more. 3) and 4) one and two axis position vector based rotations as above which blend at small distance into view-axis based rotations (these are computationally more expensive, but appear more realistic at small distances). Possibly even more transformations. | |||
* weather properties: Make visibility, wind direction, windspeed, turbulence, thermal lift, pressure, temperature and humidity in an easy way writable from Nasal. Most (except thermal lift) are currently indirectly writable by writing the config and calling environment reinit, but that's not a good solution. | |||
* terrain elevation: For thermal convection and barrier clouds, rapid sampling of terrain elevation is needed. Can there be a way to rapidly receive terrain elevation info only in Nasal for a whole set of pre-specified coordinates which performs better than geoinfo() calls? | |||
* terrain exposure to sun: Again, for thermal convection, a frequent problem involving lots of trigonometry would be - given a coordinate, find a 100 m x 100 m square area around that point. Find the orientation of that area in space (i.e. compute its normal). Given the time and date as input, compute the position of the sun, and based on surface normal and sun angle, compute the amount of thermal energy flux through the surface compared to the maximal one (i.e. when the sun is directly overhead flat terrain, surface normal || sun angle). So, a function f(coordinates, time, date) which returns a number between 0 (no sun exposure, e.g. during night) and 1 (maximal sun exposure). Computing this in Nasal a few 1000 times might be unreasonably expensive... | |||