20,741
edits
Canvas Map API: Difference between revisions
Jump to navigation
Jump to search
m
→Background
m (→Background) |
|||
| Line 3: | Line 3: | ||
== Background == | == Background == | ||
As of FlightGear 2.9, the base package contains additional [[Canvas]] helpers to help with the creation of navigational displays (map dialogs or map instruments). These are currently under development and will change rapidly during the next weeks and months, so that we can come up with a generic and re-usable design for different dialogs/instruments. | As of FlightGear 2.9, the base package contains additional [[Canvas]] helpers to help with the creation of navigational displays (map dialogs or map instruments). These are currently under development and will change rapidly during the next weeks and months, so that we can come up with a generic and re-usable design for different dialogs/instruments. | ||
== Status == | |||
{{cquote|I am planning to convert the MapWidget to use this code too, and then the NavDisplay. Support for PNG/texture icons as symbols will be needed for that, and I will also expose the 'route path' which is generated by C++ to Nasal, so a Canvas Path can be created from it. | |||
There's also a long-requested feature to use the replay-code to extract the historical aircraft position, which would be another kind of data to show. | |||
Deciding an API for limiting symbols / databoxes is going to be very important - the NavDisplay and MapWidget already have different solutions for that. In particular there's a notion of symbol priority - basically I sort the available symbols by priority, and the display can be limited to the most important 10/50/100. This is also the approach taken by some real world map displays. | |||
The MapWidget also checks to ensures data-boxes don't overlap where possible - I've no clue how to do that in the current canvas code, however.<ref>{{cite web |url=http://flightgear.org/forums/viewtopic.php?f=71&t=17625#p166894 |title=Using a canvas map in the GUI|author=Zakalawe |date=Wed Sep 19, 2012 12:34 pm}}</ref>|Zakalawe}} | |||
{{cquote|The route-path does need to be exposed - for something like a hold or DME arc, there is only one waypoint in the route, but the route-path contains a series of line segments showing the actual arc / intercept / procedure turn. This also allows for correct rendering of turn-ancticpated waypoints - in the future. | |||
But it's simply a list of lat,lon pairs so exposing it is really trivial - will get it done in the next few days. The Navcache changes are also in now, so papillion and I will look at porting the ground-radar to the canvas, and supporting the v860 pavement / taxiway primitives in the future. | |||
And yes, CanvasImage will be getting some improvements to support 2D panels via the Canvas for sure.<ref>{{cite web |url=http://flightgear.org/forums/viewtopic.php?f=71&t=17625#p166894 |title=Using a canvas map in the GUI|author=Zakalawe |date=Wed Sep 19, 2012 12:34 pm}}</ref>|Zakalawe}} | |||
{{cquote|Supporting multiple airports didn't seem too difficult after all the refactoring that I had done already, and it will also be needed for all the other efforts (mapwidget, navdisplay, route manager) so I gave it a quick try<ref>{{cite web |url=http://flightgear.org/forums/viewtopic.php?f=71&t=17625#p166894 |title=Using a canvas map in the GUI|author=Hooray |date=Wed Sep 19, 2012 12:34 pm}}</ref>|Hooray}} | |||
{{cquote|I did some experimental work on converting the map dialog last night - I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.<ref>{{cite web |url=http://flightgear.org/forums/viewtopic.php?f=71&t=17625#p166894 |title=Using a canvas map in the GUI|author=Zakalawe |date=Wed Sep 19, 2012 12:34 pm}}</ref>|Zakalawe}} | |||
{{cquote|I'm thinking about using a separate canvas for each symbol so that every instance of it is just a textured quad. For efficiency reasons it would be good to draw all symbols to a single canvas/texture and put all quads into a single node. So probably I'll add a new element type for putting quads into a single element which are all rendered at once. Maybe we can even use a geometry shader to just copy the positions to the GPU and generate the full quads with the shader. Ideas and suggestions are always welcome<ref>{{cite web |url=http://flightgear.org/forums/viewtopic.php?f=71&t=17625#p166894 |title=Using a canvas map in the GUI|author=TheTom |date=Wed Sep 19, 2012 12:34 pm}}</ref>|TheTom}} | |||
{{cquote| The issue there (at least based on the NavDisplay) is that there's quite high variance in the symbols, e.g. colour changes. For the ND I keep the symbols at greyscale, and colour them based on parameter data (active vs tuned vs inactive for navaids, for example) | |||
Definitely needs some thought, but I think it can be an upgrade - we don't need to get the design right immediately! I do like the idea of the Canvas managing the symbol cache texture, however, since generating it by hand (as the TCAS and ND currently require) is annoying.<ref>{{cite web |url=http://flightgear.org/forums/viewtopic.php?f=71&t=17625#p166894 |title=Using a canvas map in the GUI|author=Zakalawe |date=Wed Sep 19, 2012 12:34 pm}}</ref>|Zakalawe}} | |||
<references/> | |||
== Objective == | == Objective == | ||