1,360
edits
Advanced weather: Difference between revisions
Jump to navigation
Jump to search
→Feature requests on the C++ side
| Line 108: | Line 108: | ||
== Feature requests on the C++ side == | == Feature requests on the C++ side == | ||
Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms discussion] from 06/2010. | Intended as a base for discussions on how to implement particular features in the C++ code. Also see [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8365 Weather algorithms discussion] from 06/2010. | ||
As of version 0.81, the local weather system runs on a high-end system, but has problems on slower machines and could use performance boosts from implementing some features which currently are done from Nasal in C++. Guiding principles for that should be <b>performance</b>, <b>accessibility</b>, a <b>clear structure</b> and <b>backward compatibility</b>. The decision if a particular function should be implemented on the C++ level should be investigated with these in mind - usually performance is served better from C++, but Nasal structures remain more accessible. For example, cloud configurations (assembling a vector of coordinates where to place clouds) can usually be done in Nasal in a single frame and thus the performance boost when porting to C++ is marginal. On the other hand, cloud configurations are crated by functions which turn a set of parameters into cloud positions, and it is useful to have quick access to the parameters and functions to tune the system to reproduce a real sky better and better without the need to recompile the code. Thus, cloud configuration computations are an example for structures which should probably not be ported to C++. | |||
Based on an idea by Hooray, version 0.81 of the local weather package has low-level function calls gathered in a separate Nasal file <b>compat_layer.nas</b>. The idea is that C++ counterparts for these are supplied, along with Nasal structures which check if the Flightgear core has the functionality and call the C++ function if the functionality is there while they use current Nasal implementations if no C++ structures are available, thus ensuring backward compatibility to Flightgear 2.0.0. Anyone interested in porting a structure to C++ could then start to implement one of the functions found there. These functions are: | |||
* calls to set the environment (temperature, visibility, turbulence, pressure, dewpoint, thermal lift). It would seem a good idea if the environment subsystem could be structured in such a way as to accept direct input from Nasal via the property tree (and switches its own interpolation routines off) if a particular property is set. | |||
* | * interactions with the terrain - chiefly samling terrain elevation for large vectors of coordinates | ||
* | * calls to place cloud models into the scenery, to remove them and to change their position. Compared with the standard Flightgear 3d clouds, placing and moving models from Nasal seems exceedingly slow. However, local weather uses some features for which it is not obvious if they are supported by the way the standard 3d clouds are implemented. These are: | ||
* | :* a 'cloudlet' is not a single texture, but a complete *.ac model. This allows to make multi-layered cloudlets and opens the possibility to make sure that one type of cloud texture is always seen in front of another (for example, a diffuse haze could always be before a well-structured cloud top, such that the top seems to emerge from the haze). This is a *very* useful feature for designing clouds, and is also non-trivial to get via explicit placement rules. | ||
:* clouds need to be identified by various means. For movement, the system needs to know all clouds in the visual field, for deletion all clouds with given tile index, for evolution (not implemented yet) all cloudlets which belong to a particular Cumulus cloud. Internally, this is done by storing pointers to the cloud property node in various arrays, such that simply using the right array ensures that the correct cloud is referenced for an operation. Any C++ implementation should preferably allow similar referencing by pointer from Nasal or provide equivalent functionality to replace what the pointer array is for. | |||
For reference, the main performance bottlenecks in v0.81 seem to be: | |||
* rotating cloud models towards the viewer. This scales with the number of vertices, and is currently done by the shader. Performance is needed whenever clouds are in the field of view. Probably performance here can not be improved significantly and this is an upper limit for the number of distinct clouds which can be in the field of view - for denser cloud population, larger textures containing a group of clouds can be used. | |||
* moving clouds with the wind. This scales with the number of cloudlets in the field of view and is done by Nasal. performance is needed whenever dynamical weather is on and clouds are in the field of view. Currently, the Nasal code limits the max. number of clouds in the loop to avoid a dramatic drop in framerate, which means that not all clouds in the visual field may be processed. | |||
* generating a cloud configuration. This is only a siginficant issue for convective clouds, where several thousand terrain coverage calls need to be done. More performance is needed in more detailed terrain (custom France for example). Performance is only needed when a weather tile is generated, so unlike in the previous cases, performance loss occurs over a finite time interval, after which things get back to normal | |||
* sampling terrain elevation (as above, just no terrain coverage, only elevation data is needed) | |||
* placing clouds into the scenery. Performance is reduced while the flightgear core lets clouds appear in the scenery | |||
* deleting clouds. A brief drop in framerate (usually less than a second) occurs when a large amount of information is deleted from the property tree. | |||
== Current development status == | == Current development status == | ||