20,741
edits
Line 89: | Line 89: | ||
=== A Canvas-based Map dialog === | === A Canvas-based Map dialog === | ||
<!-- | |||
{{WIP}} | {{WIP}} | ||
--> | |||
As part of increasingly adopting our [[Canvas]] 2D rendering framework and in order to help [[Unifying the 2D rendering backend via canvas]], the canvas-based [[Map]] dialog is currently being overhauled by Philosopher and Hooray, who are hoping to finalize this in time for 3.2 - the hard-coded [[Map]] dialog will obviously remain functional for at least one full release cycle until it can be phased out by a pure [[Nasal]]/[[Canvas]] based solution using the new [[MapStructure]] framework. Currently, this is all still just available in the '''canvas-hackers''' team clone on gitorious - but we're hoping to implement the main missing features within the next few weeks. | As part of increasingly adopting our [[Canvas]] 2D rendering framework and in order to help [[Unifying the 2D rendering backend via canvas]], the canvas-based [[Map]] dialog is currently being overhauled by Philosopher and Hooray, who are hoping to finalize this in time for 3.2 - the hard-coded [[Map]] dialog will obviously remain functional for at least one full release cycle until it can be phased out by a pure [[Nasal]]/[[Canvas]] based solution using the new [[MapStructure]] framework. Currently, this is all still just available in the '''canvas-hackers''' team clone on gitorious - but we're hoping to implement the main missing features within the next few weeks. | ||
Line 101: | Line 102: | ||
Internally, the code rendering the screen shots shown below is 100% identical with the back-end code by Gijs' [[NavDisplay]] for rendering mapping layers, and it's already making use of symbol instancing, i.e. caching, to support faster updates and better frame rates/performance. Also, we can already show multiple '''independent''' instances of such dialogs/maps/instruments at the same time. | Internally, the code rendering the screen shots shown below is 100% identical with the back-end code by Gijs' [[NavDisplay]] for rendering mapping layers, and it's already making use of symbol instancing, i.e. caching, to support faster updates and better frame rates/performance. Also, we can already show multiple '''independent''' instances of such dialogs/maps/instruments at the same time. | ||
Furthermore, we're also exploring the possibility of supporting interactive layers, these would be layers that respond to GUI events (mouse for now). Initially, this will be primarily needed for supporting zooming/panning functionality, which is already supported by the existing airport selection dialog. But we've also seen some interesting discussions on the forum about extending the [[Map]] dialog to include navigation tools for flight planning purposes, like for example having an interactive protractor. | Furthermore, we're also exploring the possibility of supporting interactive layers, these would be layers that respond to GUI events (mouse for now). Initially, this will be primarily needed for supporting zooming/panning functionality, which is already supported by the existing airport selection dialog. But we've also seen some interesting discussions on the forum about extending the new Canvas-based [[Map]] dialog to include navigation tools for flight planning purposes, like for example having an interactive protractor. | ||
After reviewing the requirements to make this happen, we've come to the conclusion that we're almost | After reviewing the requirements to make this happen, we've come to the conclusion that we're almost there - the MapStructure framework can already load and display most SVG images, and animating them to respond to GUI events is also supported through [[Canvas - Event Handling]]. So it's really just a matter of integrating things a little more and coming up with some helpers for "interactive" or even "editor" layers, which should also come in handy for the [[FlightGear Missions and Adventures]] effort, an experimental layer has already been added to display tutorial targets as a conventional MapStructure layer. | ||
Conceptually, it may even be possible to dynamically place 3D models via geo.put_model() by using an interactive MapStructure layer that turns screen coordinates into lat/lon pairs and uses them in the put_model() call. | Conceptually, it may even be possible to dynamically place 3D models via geo.put_model() by using an interactive MapStructure layer that turns screen coordinates into lat/lon pairs and uses them in the put_model() call. This could certainly be the foundation for a run-time object placement tool, e.g. for placing scenery models or even AI traffic, which should come in handy for the [[Tutorials]] system, the advanced weather system or even the [[Bombable]] add-on. | ||