4,400
edits
(→How the whole thing works: http://flightgear.org/forums/viewtopic.php?f=71&t=21139) |
m (Update forum links) |
||
| Line 17: | Line 17: | ||
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. | 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 | 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://forum.flightgear.org/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. | {{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. | ||
| Line 23: | Line 23: | ||
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. | 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 | And yes, CanvasImage will be getting some improvements to support 2D panels via the Canvas for sure.<ref>{{cite web |url=http://forum.flightgear.org/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 | {{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://forum.flightgear.org/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 | {{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://forum.flightgear.org/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 | {{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://forum.flightgear.org/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) | {{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 | 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://forum.flightgear.org/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}} | ||
| Line 376: | Line 376: | ||
== Also see == | == Also see == | ||
* http://flightgear.org | * http://forum.flightgear.org/viewtopic.php?f=71&t=21139 | ||