20,741
edits
Advanced weather: Difference between revisions
Jump to navigation
Jump to search
→Feature requests on the C++ side
| Line 121: | Line 121: | ||
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: | 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: | ||
=== Environment related === | |||
* 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. | * 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. | ||
| Line 129: | Line 131: | ||
'''Another note''': There is already a proposal for a related patch [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=90#p82805] which needs to be reviewed/reworked and hopefully committed at some point. Also, we have talked about other ways for speeding up the whole thing even more: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=30#p71125]--[[User:Hooray|Hooray]] 12:09, 3 August 2010 (UTC) | '''Another note''': There is already a proposal for a related patch [http://flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=90#p82805] which needs to be reviewed/reworked and hopefully committed at some point. Also, we have talked about other ways for speeding up the whole thing even more: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=7358&st=0&sk=t&sd=a&start=30#p71125]--[[User:Hooray|Hooray]] 12:09, 3 August 2010 (UTC) | ||
=== Cloud placement === | |||
* 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: | * 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: | ||
| Line 135: | Line 139: | ||
:* 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. | :* 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. | ||
=== Performance bottlenecks === | |||
For reference, the main performance bottlenecks in v0.81 seem to be: | For reference, the main performance bottlenecks in v0.81 seem to be: | ||