6,566
edits
Canvas development: Difference between revisions
Jump to navigation
Jump to search
Finished converting all forum links to use templates.
(Switch to the {{forum url}} and {{forum link}} templates for all forum links.) |
(Finished converting all forum links to use templates.) |
||
| Line 68: | Line 68: | ||
{{FGCquote | {{FGCquote | ||
|I'll get a Raspberry Pi soon, so I will probably try to also run the canvas there <br/>I've just seen that the Raspberry Pi has hardware accelerated OpenVG support, so we won't need ShivaVG and the path rendering should be quite efficient. | |I'll get a Raspberry Pi soon, so I will probably try to also run the canvas there <br/>I've just seen that the Raspberry Pi has hardware accelerated OpenVG support, so we won't need ShivaVG and the path rendering should be quite efficient. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=199485}} | ||
|title=<nowiki>Re: </nowiki> | |title=<nowiki>Re: </nowiki> | ||
|author=<nowiki>TheTom</nowiki> | |author=<nowiki>TheTom</nowiki> | ||
| Line 79: | Line 79: | ||
This OSG discussion may also be of interest for anybody pursuing this venture: [http://forum.openscenegraph.org/viewtopic.php?t{{=}}12175&view{{=}}next http://forum.openscenegraph.org/viewtop ... &view{{=}}next]<br/> | This OSG discussion may also be of interest for anybody pursuing this venture: [http://forum.openscenegraph.org/viewtopic.php?t{{=}}12175&view{{=}}next http://forum.openscenegraph.org/viewtop ... &view{{=}}next]<br/> | ||
And specifically: [https://code.google.com/p/osgrpi/ https://code.google.com/p/osgrpi/] | And specifically: [https://code.google.com/p/osgrpi/ https://code.google.com/p/osgrpi/] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=199487}} | ||
|title=<nowiki>Re: </nowiki> | |title=<nowiki>Re: </nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 680: | Line 680: | ||
|1= once we've parsed an SVG, is there a way to re-use the structure? This would have to be copy by value rather than passing a pointer, because we'd want these structures to be independently controllable for each MFD, so we need multiple instances of the corresponding canvas elements. | |1= once we've parsed an SVG, is there a way to re-use the structure? This would have to be copy by value rather than passing a pointer, because we'd want these structures to be independently controllable for each MFD, so we need multiple instances of the corresponding canvas elements. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=283428}} | ||
| title = <nowiki>Re: Best way to learn Canvas?</nowiki> | | title = <nowiki>Re: Best way to learn Canvas?</nowiki> | ||
| author = <nowiki>Thorsten</nowiki> | | author = <nowiki>Thorsten</nowiki> | ||
| Line 692: | Line 692: | ||
|1= 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) | |1= 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) | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=167286}} | ||
| title = <nowiki>Re: Using a canvas map in the GUI</nowiki> | | title = <nowiki>Re: Using a canvas map in the GUI</nowiki> | ||
| author = <nowiki>zakalawe</nowiki> | | author = <nowiki>zakalawe</nowiki> | ||
| Line 704: | Line 704: | ||
|1= 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 | |1= 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 | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=167264}} | ||
| title = <nowiki>Re: Using a canvas map in the GUI</nowiki> | | title = <nowiki>Re: Using a canvas map in the GUI</nowiki> | ||
| author = <nowiki>TheTom</nowiki> | | author = <nowiki>TheTom</nowiki> | ||
| Line 717: | Line 717: | ||
Tom has mentioned a sprite cache for instancing, that would work great as a solution but I don't know if he or anyone else has worked on it. | Tom has mentioned a sprite cache for instancing, that would work great as a solution but I don't know if he or anyone else has worked on it. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=191841}} | ||
| title = <nowiki>Re: Dynamic duplication of elements</nowiki> | | title = <nowiki>Re: Dynamic duplication of elements</nowiki> | ||
| author = <nowiki>zakalawe</nowiki> | | author = <nowiki>zakalawe</nowiki> | ||
| Line 729: | Line 729: | ||
|1= I will add a new element type to render symbols from a "Cache-Texture" to improve speed of canvasses showing lots of symbols like eg. the navigation display. You will basically be able to set position (maybe rotation) and index of the symbol in the cache-texture and possibly a color for each instance... | |1= I will add a new element type to render symbols from a "Cache-Texture" to improve speed of canvasses showing lots of symbols like eg. the navigation display. You will basically be able to set position (maybe rotation) and index of the symbol in the cache-texture and possibly a color for each instance... | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=193925}} | ||
| title = <nowiki>Re: How to display Airport Chart?</nowiki> | | title = <nowiki>Re: How to display Airport Chart?</nowiki> | ||
| author = <nowiki>TheTom</nowiki> | | author = <nowiki>TheTom</nowiki> | ||
| Line 741: | Line 741: | ||
|1= just wondering if it is possible to duplicate a SVG element in Nasal? I'd like to draw a symbol only once in the SVG and then place multiple instances of it on my display. They need to be unique elements, as I'd like to animate them independently. I've looked for "duplicate" or "copy" in the API, but didn't find anything... | |1= just wondering if it is possible to duplicate a SVG element in Nasal? I'd like to draw a symbol only once in the SVG and then place multiple instances of it on my display. They need to be unique elements, as I'd like to animate them independently. I've looked for "duplicate" or "copy" in the API, but didn't find anything... | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=191829}} | ||
| title = <nowiki>Dynamic duplication of elements</nowiki> | | title = <nowiki>Dynamic duplication of elements</nowiki> | ||
| author = <nowiki>Gijs</nowiki> | | author = <nowiki>Gijs</nowiki> | ||
| Line 753: | Line 753: | ||
|1= way to easily instantiate a symbol/geometry/group multiple times, in a cached fashion, without eating up unnecessary memory for multiple independently-animated instances of a symbol | |1= way to easily instantiate a symbol/geometry/group multiple times, in a cached fashion, without eating up unnecessary memory for multiple independently-animated instances of a symbol | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=191831}} | ||
| title = <nowiki>Re: Dynamic duplication of elements</nowiki> | | title = <nowiki>Re: Dynamic duplication of elements</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 765: | Line 765: | ||
|1= I'm currently not sure if we can share the canvas elements across displays, so I've made copies of everything for each display. | |1= I'm currently not sure if we can share the canvas elements across displays, so I've made copies of everything for each display. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269330}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Richard</nowiki> | | author = <nowiki>Richard</nowiki> | ||
| Line 779: | Line 779: | ||
But for the time being, Canvas does not support anything like that. | But for the time being, Canvas does not support anything like that. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269332}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 791: | Line 791: | ||
|1= It's also lead me onto wonder if instancing could be generally useful (as we have a quite a lot of items in the scenery that are the same model); but to be honest I've not really got enough of a clue how the culling would work. | |1= It's also lead me onto wonder if instancing could be generally useful (as we have a quite a lot of items in the scenery that are the same model); but to be honest I've not really got enough of a clue how the culling would work. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269313}} | ||
| title = <nowiki>Re: optimizing random trees: strong effect on performance ?</nowiki> | | title = <nowiki>Re: optimizing random trees: strong effect on performance ?</nowiki> | ||
| author = <nowiki>Richard</nowiki> | | author = <nowiki>Richard</nowiki> | ||
| Line 803: | Line 803: | ||
|1= this is one of the most common feature requests related to Canvas | |1= this is one of the most common feature requests related to Canvas | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=269333}} | ||
| title = <nowiki>Re: Canvas::Element Instancing at the OSG level</nowiki> | | title = <nowiki>Re: Canvas::Element Instancing at the OSG level</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 817: | Line 817: | ||
We could also expose a method to "finalie" a Canvas Element, at which point its osg data variance may be changed to be STATIC instead of DYNAMIC - this could for example apply to background images and other static overlays. | We could also expose a method to "finalie" a Canvas Element, at which point its osg data variance may be changed to be STATIC instead of DYNAMIC - this could for example apply to background images and other static overlays. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=265607}} | ||
| title = <nowiki>Canvas::Element Instancing at the OSG level</nowiki> | | title = <nowiki>Canvas::Element Instancing at the OSG level</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 832: | Line 832: | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=277018}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 846: | Line 846: | ||
Looking specifically at some of the most complex Canvas-based avionics we have in FlightGear, things like Avidyne Entegra R9 will be difficult to update easily once such a dedicated element becomes available - but people can easily make that possible by using a single helper function/class that handles the update/animation semantics, and which isolates the remaining code from any internals - so that things like an animated bar can be easily delegated to OSG/C++ code as soon as the corresponding OSG classes are mapped to a dedicated Canvas element: [[Canvas Sandbox#CanvasAnimation]] | Looking specifically at some of the most complex Canvas-based avionics we have in FlightGear, things like Avidyne Entegra R9 will be difficult to update easily once such a dedicated element becomes available - but people can easily make that possible by using a single helper function/class that handles the update/animation semantics, and which isolates the remaining code from any internals - so that things like an animated bar can be easily delegated to OSG/C++ code as soon as the corresponding OSG classes are mapped to a dedicated Canvas element: [[Canvas Sandbox#CanvasAnimation]] | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=277018}} | ||
| title = <nowiki>Re: Space Shuttle</nowiki> | | title = <nowiki>Re: Space Shuttle</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 882: | Line 882: | ||
|We've been discussing phasing out the hard-coded splash screen and replacing it with a Nasal/Canvas Wrapper showing a decoration-less window, with a CanvasImage and CanvasText elements - the splash screen itself can already be disabled via a property, so showing a corresponding Canvas window should be fairly straightforward. <br/> | |We've been discussing phasing out the hard-coded splash screen and replacing it with a Nasal/Canvas Wrapper showing a decoration-less window, with a CanvasImage and CanvasText elements - the splash screen itself can already be disabled via a property, so showing a corresponding Canvas window should be fairly straightforward. <br/> | ||
For details, see: | For details, see: | ||
* | * {{forum link|p=200146|title=Splash Screens + Canvas}} | ||
* | * {{forum link|p=214463|title=Use Nasal to Randomize Splash Screens}} | ||
This isn't currently prioritized - but it's fairly straightforward, and will help us with unifying the 2D rendering back-end via Canvas, so it's going to happen sooner or later - and any experimental code should help us prototype this, so that we can get rid of the corresponding C++ code. | This isn't currently prioritized - but it's fairly straightforward, and will help us with unifying the 2D rendering back-end via Canvas, so it's going to happen sooner or later - and any experimental code should help us prototype this, so that we can get rid of the corresponding C++ code. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=226559}} | ||
|title=<nowiki>Re: How does serviceable and failures work?</nowiki> | |title=<nowiki>Re: How does serviceable and failures work?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 903: | Line 903: | ||
{{FGCquote | {{FGCquote | ||
| I have a plane and when you start it up I would like it to pick a custom splash screen, but instead of having the same splash screen every time it would pick one at random and display it. So someone could make multiple splash screens for a plane and the nasal script would randomly pick one of them. I was thinking it could be a custom nasal script right in the -set file or it would call up a .nas file. I don't see why this couldn't be done using nasal, but I don't know how to write the code. Anybody want to give it a shot? | | I have a plane and when you start it up I would like it to pick a custom splash screen, but instead of having the same splash screen every time it would pick one at random and display it. So someone could make multiple splash screens for a plane and the nasal script would randomly pick one of them. I was thinking it could be a custom nasal script right in the -set file or it would call up a .nas file. I don't see why this couldn't be done using nasal, but I don't know how to write the code. Anybody want to give it a shot? | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214463}} | ||
|title=<nowiki>Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>jonbourg</nowiki> | |author=<nowiki>jonbourg</nowiki> | ||
| Line 914: | Line 914: | ||
<br/> | <br/> | ||
The existing scheme is hard-coded and cannot be scripted. The only kind of flexibility it provides is that it can randomly select splash screens for aircraft that don't have a corresponding entry set. Otherwise, even splash screen updates are hard-coded, despite being property-based. | The existing scheme is hard-coded and cannot be scripted. The only kind of flexibility it provides is that it can randomly select splash screens for aircraft that don't have a corresponding entry set. Otherwise, even splash screen updates are hard-coded, despite being property-based. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214465}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 928: | Line 928: | ||
<br/> | <br/> | ||
Listen for initialization to finish. | Listen for initialization to finish. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214466}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>hvengel</nowiki> | |author=<nowiki>hvengel</nowiki> | ||
| Line 937: | Line 937: | ||
{{FGCquote | {{FGCquote | ||
| this is the kind of thing that is trivial to do in Canvas using 5 lines of code, and changing an image is just the equivalent of a .set/setprop() call basically. So I wouldn't spend too much time working around this limitation - as can be seen, making the splash screen 100% dynamic at run-time isn't exactly rocket science using Canvas. The really hard work has already been done by TheTom. Thus, disabling the hard-coded splash screen and showing a GUI dialog without window decoration, would give aircraft developers all the flexibility they need - they could even fetch stuff via http easily | | this is the kind of thing that is trivial to do in Canvas using 5 lines of code, and changing an image is just the equivalent of a .set/setprop() call basically. So I wouldn't spend too much time working around this limitation - as can be seen, making the splash screen 100% dynamic at run-time isn't exactly rocket science using Canvas. The really hard work has already been done by TheTom. Thus, disabling the hard-coded splash screen and showing a GUI dialog without window decoration, would give aircraft developers all the flexibility they need - they could even fetch stuff via http easily | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214467}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 946: | Line 946: | ||
{{FGCquote | {{FGCquote | ||
|What I want as an aircraft dev and perhaps this is true of others as well is a standardized way to do this in the *-set.xml like: 1. Set either a splash screen image (just like the current set up for backwards compatibility but perhaps discourage this so that it goes away at some point) or a splash screen image directory in the *-set.xml file. If this is set this to use a single image then it works just like it does now. If this is set to a splash screen image directory then it rotates through the images in that directory. So it is one line of XML like the current setup that allows for rotating splash screen images. The aircraft devs shouldn't have to do more than that even if the alternative is only 5 lines of nasal code. IMO those 5 lines of canvas/Nasal code should be a standard part of the FG start up and the functionality should just be there and be a one liner to use. | |What I want as an aircraft dev and perhaps this is true of others as well is a standardized way to do this in the *-set.xml like: 1. Set either a splash screen image (just like the current set up for backwards compatibility but perhaps discourage this so that it goes away at some point) or a splash screen image directory in the *-set.xml file. If this is set this to use a single image then it works just like it does now. If this is set to a splash screen image directory then it rotates through the images in that directory. So it is one line of XML like the current setup that allows for rotating splash screen images. The aircraft devs shouldn't have to do more than that even if the alternative is only 5 lines of nasal code. IMO those 5 lines of canvas/Nasal code should be a standard part of the FG start up and the functionality should just be there and be a one liner to use. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214473}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>hvengel</nowiki> | |author=<nowiki>hvengel</nowiki> | ||
| Line 955: | Line 955: | ||
{{FGCquote | {{FGCquote | ||
|I think the best way to go WRT configurability is to use the same node (/sim/startup/splash-texture) for either a single file, a single directory, or a single URL (HTTP), and then allow several of these nodes, from which a list of images would be drawn up and a random one chosen. That way it's simple and backwards-compatible yet still supporting the features you want. This would require less than 60 LOC to support from Nasal (including some other features) and could be loaded ASAP with early Nasal. | |I think the best way to go WRT configurability is to use the same node (/sim/startup/splash-texture) for either a single file, a single directory, or a single URL (HTTP), and then allow several of these nodes, from which a list of images would be drawn up and a random one chosen. That way it's simple and backwards-compatible yet still supporting the features you want. This would require less than 60 LOC to support from Nasal (including some other features) and could be loaded ASAP with early Nasal. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214475}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Philosopher</nowiki> | |author=<nowiki>Philosopher</nowiki> | ||
| Line 962: | Line 962: | ||
}}{{FGCquote | }}{{FGCquote | ||
|I think the best way to go WRT configurability is to use the same node (/sim/startup/splash-texture) for either a single file, a single directory, or a single URL (HTTP), and then allow several of these nodes, from which a list of images would be drawn up and a random one chosen. That way it's simple and backwards-compatible yet still supporting the features you want. This would require less than 60 LOC to support from Nasal (including some other features) and could be loaded ASAP with early Nasal. | |I think the best way to go WRT configurability is to use the same node (/sim/startup/splash-texture) for either a single file, a single directory, or a single URL (HTTP), and then allow several of these nodes, from which a list of images would be drawn up and a random one chosen. That way it's simple and backwards-compatible yet still supporting the features you want. This would require less than 60 LOC to support from Nasal (including some other features) and could be loaded ASAP with early Nasal. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214475}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Philosopher</nowiki> | |author=<nowiki>Philosopher</nowiki> | ||
| Line 973: | Line 973: | ||
<br/> | <br/> | ||
I still find it amazing how often aircraft devs keep coming up with this - but technically, I agree that it would make sense to get rid of certain C++ code and make it more flexible | I still find it amazing how often aircraft devs keep coming up with this - but technically, I agree that it would make sense to get rid of certain C++ code and make it more flexible | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214476}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 982: | Line 982: | ||
{{FGCquote | {{FGCquote | ||
| I just always thought it would be neat if you could make a set of splash screens for a particular aircraft and it would simply pick one of them at startup. It's just one of those neat to have, but not necassary things. | | I just always thought it would be neat if you could make a set of splash screens for a particular aircraft and it would simply pick one of them at startup. It's just one of those neat to have, but not necassary things. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214477}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>jonbourg</nowiki> | |author=<nowiki>jonbourg</nowiki> | ||
| Line 991: | Line 991: | ||
{{FGCquote | {{FGCquote | ||
|this (and much more!) will be trivial to do in a few months time using Nasal once the "reinit Nasal early" work has materialize/stabilized a little more - and it will not involve any C++ at all, like Philosopher said: it will probably be just ~30 lines of Nasal code looking for certain XML tags in your aircraft-set.xml file, and maybe an option to run your own Nasal code in case you want to do anything fancy. | |this (and much more!) will be trivial to do in a few months time using Nasal once the "reinit Nasal early" work has materialize/stabilized a little more - and it will not involve any C++ at all, like Philosopher said: it will probably be just ~30 lines of Nasal code looking for certain XML tags in your aircraft-set.xml file, and maybe an option to run your own Nasal code in case you want to do anything fancy. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214478}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,002: | Line 1,002: | ||
<br/> | <br/> | ||
I think technically, it's just a new placement mode that we need here, and maybe supporting loading *.nas from $FG_ROOT/Textures/Splashs - i.e. we could simply recognize *.nas as an extension for the splash-texture tag in aircraft-set.xml tags and then directly attach a single canvas. | I think technically, it's just a new placement mode that we need here, and maybe supporting loading *.nas from $FG_ROOT/Textures/Splashs - i.e. we could simply recognize *.nas as an extension for the splash-texture tag in aircraft-set.xml tags and then directly attach a single canvas. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=200153}} | ||
|title=<nowiki>Re: Splash Screens + Canvas</nowiki> | |title=<nowiki>Re: Splash Screens + Canvas</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,014: | Line 1,014: | ||
I think a new splash screen "placement" would make a nice tutorial for the wiki<br/> | I think a new splash screen "placement" would make a nice tutorial for the wiki<br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=207322}} | ||
|title=<nowiki>Re: Splash Screens + Canvas</nowiki> | |title=<nowiki>Re: Splash Screens + Canvas</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,030: | Line 1,030: | ||
So this could be greatly simplified by supporting Nasal & Canvas. So I may revisit this depending on progress in the FGCanvas/Nasal-initialization department, and spare time obviously.<br/> | So this could be greatly simplified by supporting Nasal & Canvas. So I may revisit this depending on progress in the FGCanvas/Nasal-initialization department, and spare time obviously.<br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214577}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,041: | Line 1,041: | ||
<br/> | <br/> | ||
Once this is in place, we can safely remove the hard-coded splash screen | Once this is in place, we can safely remove the hard-coded splash screen | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214611}} | ||
|title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | |title=<nowiki>Re: Use Nasal to Randomize Splash Screens</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,057: | Line 1,057: | ||
{{FGCquote | {{FGCquote | ||
|we've seen half a dozen of glass cockpit related efforts over the years - including stuff like OpenGC (early 2000s) and FGGC (mid 2000s), and quite a few others in the meantime.<br><br>At the end of the day, this always meant that we had competing, and even conflicting, technology stacks involved - where one technology (instrument/MFD) would not work within the other run-time environment. Canvas, coupled with HLA (or even just remote/telnet properties), has the potential to solve this once and for all. | |we've seen half a dozen of glass cockpit related efforts over the years - including stuff like OpenGC (early 2000s) and FGGC (mid 2000s), and quite a few others in the meantime.<br><br>At the end of the day, this always meant that we had competing, and even conflicting, technology stacks involved - where one technology (instrument/MFD) would not work within the other run-time environment. Canvas, coupled with HLA (or even just remote/telnet properties), has the potential to solve this once and for all. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=212636}} | ||
|title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | |title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,066: | Line 1,066: | ||
{{FGCquote | {{FGCquote | ||
|ultimately, HTML5/Canvas + JavaScript isn't going to be hardware-accelerated in the form that FlightGear's Canvas system is. Then again, what you mentioned regarding HTML5/JavaScript support isn't all that far-fetched either - OSG can certainly already render WebKit views to a texture. So this is, once again, one of those cases where FlightGear turns out to be a very much disorganized, with even conflicting solutions being worked on by different contributors- obviously, this isn't the first time, and it's also not going to be the last time something like this happens. I think we simply have to embrace the opportunity and see what prevails. <br>From my standpoint, having -yet again- different types of instruments that are specific to an external run-time environment is very much a maintenance nightmare. | |ultimately, HTML5/Canvas + JavaScript isn't going to be hardware-accelerated in the form that FlightGear's Canvas system is. Then again, what you mentioned regarding HTML5/JavaScript support isn't all that far-fetched either - OSG can certainly already render WebKit views to a texture. So this is, once again, one of those cases where FlightGear turns out to be a very much disorganized, with even conflicting solutions being worked on by different contributors- obviously, this isn't the first time, and it's also not going to be the last time something like this happens. I think we simply have to embrace the opportunity and see what prevails. <br>From my standpoint, having -yet again- different types of instruments that are specific to an external run-time environment is very much a maintenance nightmare. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=212636}} | ||
|title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | |title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,075: | Line 1,075: | ||
{{FGCquote | {{FGCquote | ||
|meanwhile, Canvas is our most solid and most unified approach to tackle those challenges, without them being specific to an external run-time environment, while still providing all the theoretical benefits, plus quite a few more. | |meanwhile, Canvas is our most solid and most unified approach to tackle those challenges, without them being specific to an external run-time environment, while still providing all the theoretical benefits, plus quite a few more. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=212636}} | ||
|title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | |title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,084: | Line 1,084: | ||
{{FGCquote | {{FGCquote | ||
|The main advantage of standalone applications using HTML/CSS/JS/AJAX is that they run on almost every browser without the need for installation of software. My prototype PFD runs on iOS, Android, Windows, Linux, OSX by just punching a URL into the browser's address field. | |The main advantage of standalone applications using HTML/CSS/JS/AJAX is that they run on almost every browser without the need for installation of software. My prototype PFD runs on iOS, Android, Windows, Linux, OSX by just punching a URL into the browser's address field. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=212670}} | ||
|title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | |title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | ||
|author=<nowiki>Torsten</nowiki> | |author=<nowiki>Torsten</nowiki> | ||
| Line 1,093: | Line 1,093: | ||
{{FGCquote | {{FGCquote | ||
|Being able to run such things in any supported browser is obviously pretty cool, and often time, people don't really need full hardware acceleration. The thing that I find a little difficult is the lack of consistency - obviously, glass/MFD support is something that's been lacking in FG pretty much since the very beginning. <br><br>And I find the idea very compelling not to have -yet again- different "code bases" implementing semantically equivalent instruments/functionality, like a PFD and/or ND, EICAS/EFIS or EFB displays.<br><br>Thus, I am really interested in supporting efforts like the work that Gijs and Hyde have done with the NavDisplay: It supports multiple instances per aircraft, and can easily be integrated with other aircraft - and it is even prepared to support different styling, and different types of NDs. The way the NavDisplay/MapStructure efforts have evolved meanwhile, the work originally written by a single guy (Gijs) can now be used in a ton of places ...hese displays are not longer aircraft or instrument specific, and can directly be used in '''any''' FlightGear dialog, PUI or Canvas.<br><br>The other issue with a purely "W3C-based" approach is that we'd need to become fairly creative once it comes to supporting modern avionics/MFD features, such as for example tail view cameras or even providing full GUI support along the lines of ARINC 661. Canvas has become sort of a technology enabler, it is not so much about end-user features, but it's become a platform that ties together features that were previously implemented in a very inconsistent fashion, one that also didn't exactly improve our degree of OpenGL compatibility due to a ton of legacy code all over the place, often not even using OSG StateSets etc. | |Being able to run such things in any supported browser is obviously pretty cool, and often time, people don't really need full hardware acceleration. The thing that I find a little difficult is the lack of consistency - obviously, glass/MFD support is something that's been lacking in FG pretty much since the very beginning. <br><br>And I find the idea very compelling not to have -yet again- different "code bases" implementing semantically equivalent instruments/functionality, like a PFD and/or ND, EICAS/EFIS or EFB displays.<br><br>Thus, I am really interested in supporting efforts like the work that Gijs and Hyde have done with the NavDisplay: It supports multiple instances per aircraft, and can easily be integrated with other aircraft - and it is even prepared to support different styling, and different types of NDs. The way the NavDisplay/MapStructure efforts have evolved meanwhile, the work originally written by a single guy (Gijs) can now be used in a ton of places ...hese displays are not longer aircraft or instrument specific, and can directly be used in '''any''' FlightGear dialog, PUI or Canvas.<br><br>The other issue with a purely "W3C-based" approach is that we'd need to become fairly creative once it comes to supporting modern avionics/MFD features, such as for example tail view cameras or even providing full GUI support along the lines of ARINC 661. Canvas has become sort of a technology enabler, it is not so much about end-user features, but it's become a platform that ties together features that were previously implemented in a very inconsistent fashion, one that also didn't exactly improve our degree of OpenGL compatibility due to a ton of legacy code all over the place, often not even using OSG StateSets etc. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=212672}} | ||
|title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | |title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,102: | Line 1,102: | ||
{{FGCquote | {{FGCquote | ||
|Who knows, maybe there's even a way that we can find a compromise to optionally integrate both worlds to /some/ degree - i.e. we could serve Canvas-based textures as PNGs to a browser and actually let users decide on which side they want to use "native" FlightGear solutions, and where they'd prefer to use W3C options instead. <br><br>Obviously, JavaScript is in many ways superior to Nasal, and the way Nasal is integrated in FG, we cannot easily write async code either.<br><br>Being able to stream Canvas images/video to an external browser/viewer (via a worker thread) would also allow us to support a variety of other interesting use-cases, such as UAV stuff, OpenCV post-processing etc. The only thing that's missing to pull this off is a new placement type that exposes a canvas as either an osg::Image buffer that is serialized to a browser-format like PNG, or to some video stream. At that point, a browser could -in theory- even render live FG camera views streamed via UDP to implement a browser-based instructor console that can view individual Canvas MFDs/instruments, but even scenery views.<br><br>This kind of stuff has been discussed a number of times, and even Curt & Tim agreed (in the pre-canvas days) that this would be cool to support at some point: [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|http://wiki.flightgear.org/Canvas_Devel ... ter_Vision]] | |Who knows, maybe there's even a way that we can find a compromise to optionally integrate both worlds to /some/ degree - i.e. we could serve Canvas-based textures as PNGs to a browser and actually let users decide on which side they want to use "native" FlightGear solutions, and where they'd prefer to use W3C options instead. <br><br>Obviously, JavaScript is in many ways superior to Nasal, and the way Nasal is integrated in FG, we cannot easily write async code either.<br><br>Being able to stream Canvas images/video to an external browser/viewer (via a worker thread) would also allow us to support a variety of other interesting use-cases, such as UAV stuff, OpenCV post-processing etc. The only thing that's missing to pull this off is a new placement type that exposes a canvas as either an osg::Image buffer that is serialized to a browser-format like PNG, or to some video stream. At that point, a browser could -in theory- even render live FG camera views streamed via UDP to implement a browser-based instructor console that can view individual Canvas MFDs/instruments, but even scenery views.<br><br>This kind of stuff has been discussed a number of times, and even Curt & Tim agreed (in the pre-canvas days) that this would be cool to support at some point: [[Canvas_Development#Placement.2FElement_for_Streaming:_Computer_Vision|http://wiki.flightgear.org/Canvas_Devel ... ter_Vision]] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=212672}} | ||
|title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | |title=<nowiki>Re: Instruments for homecockpit panel.</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,117: | Line 1,117: | ||
<br/> | <br/> | ||
If we could extend the Canvas system to get an osg::Image for any canvas, we could easily create such screen shots procedurally and serialize them to disk. GUI dialogs could basically become self-documenting, because we could just annotate a canvas procedurally and write the image to a file that can be used in the manual/wiki | If we could extend the Canvas system to get an osg::Image for any canvas, we could easily create such screen shots procedurally and serialize them to disk. GUI dialogs could basically become self-documenting, because we could just annotate a canvas procedurally and write the image to a file that can be used in the manual/wiki | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213146}} | ||
|title=<nowiki>Serializing a Canvas to an osg::Image</nowiki> | |title=<nowiki>Serializing a Canvas to an osg::Image</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,149: | Line 1,149: | ||
{{PatchAvailable|url={{forum url|p=317448}}}} | {{PatchAvailable|url={{forum url|p=317448}}}} | ||
[[File:Fg-multiview-demo.png|right|thumb|OSG slave camera rendered to an TextureRectangle | [[File:Fg-multiview-demo.png|right|thumb|OSG slave camera rendered to an TextureRectangle {{forum link|p=260733}}]] | ||
{{Note|People interested in working on this may want to check out the following pointers: | {{Note|People interested in working on this may want to check out the following pointers: | ||
| Line 1,183: | Line 1,183: | ||
|1= if we ever get multi-view capability, or even use a crude method of simply making the FLIR display "full screen" and hence don't need multi-view capability (that's how FLIR in ArmA 2 actually works, since it didn't have picture in picture capability). Now that i think about it, a similar approach could be used to create a cheap method of a terrain avoidance radar display. | |1= if we ever get multi-view capability, or even use a crude method of simply making the FLIR display "full screen" and hence don't need multi-view capability (that's how FLIR in ArmA 2 actually works, since it didn't have picture in picture capability). Now that i think about it, a similar approach could be used to create a cheap method of a terrain avoidance radar display. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=279696}} | ||
| title = <nowiki>Re: ALS night vision (and others)</nowiki> | | title = <nowiki>Re: ALS night vision (and others)</nowiki> | ||
| author = <nowiki>clipper996</nowiki> | | author = <nowiki>clipper996</nowiki> | ||
| Line 1,195: | Line 1,195: | ||
|1= Taxi Camera on navigation display (as seen on FSX and X-Plane) | |1= Taxi Camera on navigation display (as seen on FSX and X-Plane) | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=273904}} | ||
| title = <nowiki>Thanks</nowiki> | | title = <nowiki>Thanks</nowiki> | ||
| author = <nowiki>CaptainTech</nowiki> | | author = <nowiki>CaptainTech</nowiki> | ||
| Line 1,207: | Line 1,207: | ||
|I have to create two master cameras to controls the two different views in two different scene rendering dynamically. | |I have to create two master cameras to controls the two different views in two different scene rendering dynamically. | ||
but flightgear only using viewer class . This is createing one master camera no.of slave cameras. but i need CompositeViewer class. how to use CompositeViewer class in flightgear and how to render through CompositeViewer class. | but flightgear only using viewer class . This is createing one master camera no.of slave cameras. but i need CompositeViewer class. how to use CompositeViewer class in flightgear and how to render through CompositeViewer class. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=227827}} | ||
|title=<nowiki>How to create 2 master camera and 2 views in flightgear 3.0</nowiki> | |title=<nowiki>How to create 2 master camera and 2 views in flightgear 3.0</nowiki> | ||
|author=<nowiki>Divi</nowiki> | |author=<nowiki>Divi</nowiki> | ||
| Line 1,214: | Line 1,214: | ||
}} | }} | ||
{{FGCquote|1= any idea how loan to wait for this is add in canvas (with custom render options)?|2= {{cite web | url = | {{FGCquote|1= any idea how loan to wait for this is add in canvas (with custom render options)?|2= {{cite web | url = {{forum url|p=260791}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>www2</nowiki> | date = Oct 16th, 2015 }}}} | ||
{{FGCquote|1=I think we need soon add this to canvas for camera.|2= {{cite web | url = | {{FGCquote|1=I think we need soon add this to canvas for camera.|2= {{cite web | url = {{forum url|p=261575}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>www2</nowiki> | date = Oct 24th, 2015 }}}} | ||
{{FGCquote | {{FGCquote | ||
| Line 1,230: | Line 1,230: | ||
|Back when the whole Canvas idea was originally discussed, none of the people involved in that discussion stepped up to actually prototype, let alone, implement the system - so it took a few years until the idea took shape, and the developer who prototyped and designed the system went quite a bit further than originally anticipated - but I think it's safe to say that not even Tom was foreseeing the increasing focus on GUI and MFD use-cases, as well as as the increasing trend to use it for mapping/charting purposes. | |Back when the whole Canvas idea was originally discussed, none of the people involved in that discussion stepped up to actually prototype, let alone, implement the system - so it took a few years until the idea took shape, and the developer who prototyped and designed the system went quite a bit further than originally anticipated - but I think it's safe to say that not even Tom was foreseeing the increasing focus on GUI and MFD use-cases, as well as as the increasing trend to use it for mapping/charting purposes. | ||
So the original focus on 2D rendering is/was very valid, and the system is sufficiently flexible to allow it to be extended using custom elements for rendering camera/scenery views at some point. All the community support and momentum certainly is there, and I'm sure that TheTom will gladly review any contributions related to this. | So the original focus on 2D rendering is/was very valid, and the system is sufficiently flexible to allow it to be extended using custom elements for rendering camera/scenery views at some point. All the community support and momentum certainly is there, and I'm sure that TheTom will gladly review any contributions related to this. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=228972}} | ||
|title=<nowiki>Re: How to create 2 master camera and 2 views in flightgear</nowiki> | |title=<nowiki>Re: How to create 2 master camera and 2 views in flightgear</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,239: | Line 1,239: | ||
{{FGCquote | {{FGCquote | ||
|The external camera and closely related rear view mirror has been asked for very many times and the consensus is that is quite feasable. However, the problem is that nobody with the relevant skills has yet taken up the challenge. My understanding is that most (but not all) of the interfaces are already there. | |The external camera and closely related rear view mirror has been asked for very many times and the consensus is that is quite feasable. However, the problem is that nobody with the relevant skills has yet taken up the challenge. My understanding is that most (but not all) of the interfaces are already there. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=217353}} | ||
|title=<nowiki>Re: Gear view in cockpit computer</nowiki> | |title=<nowiki>Re: Gear view in cockpit computer</nowiki> | ||
|author=<nowiki>Alant</nowiki> | |author=<nowiki>Alant</nowiki> | ||
| Line 1,250: | Line 1,250: | ||
I do know that omega95 and a few other aircraft developers are highly interested in supporting this feature - but as was said previously, it will involve C++ changes.<br/> | I do know that omega95 and a few other aircraft developers are highly interested in supporting this feature - but as was said previously, it will involve C++ changes.<br/> | ||
While I wouldn't necessarily say that we're lacking people with the skills to make this happen (we have at least half a dozen of developers who know perfectly well how to do this) - it's mainly a matter of different priorities for the time being - airliner development has never been a priority for FlightGear core developers - even though some aircraft developers are suggesting otherwise - but the truth is that the relatively high number of "airliners" in FlightGear is mainly because that's what many of our younger aircraft developers are interested in - still, there are many core features/building blocks missing to fully develop modern cockpit displays - in FlightGear terms, Canvas is a fairly recent and even "novel" addition. | While I wouldn't necessarily say that we're lacking people with the skills to make this happen (we have at least half a dozen of developers who know perfectly well how to do this) - it's mainly a matter of different priorities for the time being - airliner development has never been a priority for FlightGear core developers - even though some aircraft developers are suggesting otherwise - but the truth is that the relatively high number of "airliners" in FlightGear is mainly because that's what many of our younger aircraft developers are interested in - still, there are many core features/building blocks missing to fully develop modern cockpit displays - in FlightGear terms, Canvas is a fairly recent and even "novel" addition. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=217517}} | ||
|title=<nowiki>Re: Gear view in cockpit computer</nowiki> | |title=<nowiki>Re: Gear view in cockpit computer</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,261: | Line 1,261: | ||
Please keep in mind that it took several years to materialize for the Canvas system itself - the original proposal got first discussed pre-2010, and it got prototyped by TheTom in early 2012. In other words, even good ideas may have a certain "shelf life" and may need to grow momentum/demand to be recognized as such :D <br/> | Please keep in mind that it took several years to materialize for the Canvas system itself - the original proposal got first discussed pre-2010, and it got prototyped by TheTom in early 2012. In other words, even good ideas may have a certain "shelf life" and may need to grow momentum/demand to be recognized as such :D <br/> | ||
So nobody is saying that the idea to add this to Canvas would be bad - quite the opposite actually: We'd all agree that this would be a great feature to have and that FlightGear would improve significantly - but for the time being core development resources are allocated elsewhere, and external core contributors are also more interested in other aspects of the simulator. | So nobody is saying that the idea to add this to Canvas would be bad - quite the opposite actually: We'd all agree that this would be a great feature to have and that FlightGear would improve significantly - but for the time being core development resources are allocated elsewhere, and external core contributors are also more interested in other aspects of the simulator. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=217517}} | ||
|title=<nowiki>Re: Gear view in cockpit computer</nowiki> | |title=<nowiki>Re: Gear view in cockpit computer</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,272: | Line 1,272: | ||
i need to create 2 window with different view.<br/> | i need to create 2 window with different view.<br/> | ||
for example window1 show cockpit view and window2 show tower view | for example window1 show cockpit view and window2 show tower view | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=216736}} | ||
|title=<nowiki>create window</nowiki> | |title=<nowiki>create window</nowiki> | ||
|author=<nowiki>sgb110</nowiki> | |author=<nowiki>sgb110</nowiki> | ||
| Line 1,285: | Line 1,285: | ||
<br/> | <br/> | ||
This is actually one of the longer-standing feature-request, that even pre-dates Canvas in its current form - the original idea to implement this, is detailed at (particularly, see Zan's comments): [[Howto:Use_a_Camera_View_in_an_Instrument]] | This is actually one of the longer-standing feature-request, that even pre-dates Canvas in its current form - the original idea to implement this, is detailed at (particularly, see Zan's comments): [[Howto:Use_a_Camera_View_in_an_Instrument]] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221460}} | ||
|title=<nowiki>Re: Gear view in cockpit computer</nowiki> | |title=<nowiki>Re: Gear view in cockpit computer</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,293: | Line 1,293: | ||
{{FGCquote | {{FGCquote | ||
|I think, but I'm not really sure, that FligthGear does not support two different views even if you have two windows. | |I think, but I'm not really sure, that FligthGear does not support two different views even if you have two windows. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=216740}} | ||
|title=<nowiki>Re: create window</nowiki> | |title=<nowiki>Re: create window</nowiki> | ||
|author=<nowiki>ludomotico</nowiki> | |author=<nowiki>ludomotico</nowiki> | ||
| Line 1,304: | Line 1,304: | ||
<br/> | <br/> | ||
But we've had a number of aircraft developers, who would also require this functionality for implementing mirrors and/or tailcam views rendered to instruments, or FLIR-type views. All of these wouuld be possible to support once the view manager is refactored such that it can [[Canvas_Development#Supporting_Cameras]] | But we've had a number of aircraft developers, who would also require this functionality for implementing mirrors and/or tailcam views rendered to instruments, or FLIR-type views. All of these wouuld be possible to support once the view manager is refactored such that it can [[Canvas_Development#Supporting_Cameras]] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=216741}} | ||
|title=<nowiki>Re: create window</nowiki> | |title=<nowiki>Re: create window</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,313: | Line 1,313: | ||
{{FGCquote | {{FGCquote | ||
|And then I have the biggest challenge in the aircraft, the Dynon Skyview SV-D1000 display, which has a PFD, a Terrain Map (not that hard as we already have code from the GPS), Engine Controls and the control center for the aircraft's ''TruTrak'' Autopilot System. The challenge here is synthetic vision. Which means I need to either be able to render 3D terrain view to texture, OR be able to create my own 3D terrain view with projection calculations. | |And then I have the biggest challenge in the aircraft, the Dynon Skyview SV-D1000 display, which has a PFD, a Terrain Map (not that hard as we already have code from the GPS), Engine Controls and the control center for the aircraft's ''TruTrak'' Autopilot System. The challenge here is synthetic vision. Which means I need to either be able to render 3D terrain view to texture, OR be able to create my own 3D terrain view with projection calculations. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=153438}} | ||
|title=<nowiki>Re: Jabiru J-170 (DEVELOPMENT)</nowiki> | |title=<nowiki>Re: Jabiru J-170 (DEVELOPMENT)</nowiki> | ||
|author=<nowiki>omega95</nowiki> | |author=<nowiki>omega95</nowiki> | ||
| Line 1,322: | Line 1,322: | ||
{{FGCquote | {{FGCquote | ||
|We're waiting for the Canvas Properties 2D drawing API and Camera View so we can create the PFD. | |We're waiting for the Canvas Properties 2D drawing API and Camera View so we can create the PFD. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=158690}} | ||
|title=<nowiki>Re: Jabiru J-170 (DEVELOPMENT)</nowiki> | |title=<nowiki>Re: Jabiru J-170 (DEVELOPMENT)</nowiki> | ||
|author=<nowiki>omega95</nowiki> | |author=<nowiki>omega95</nowiki> | ||
| Line 1,331: | Line 1,331: | ||
{{cquote|I'm looking to replicate a camera with a fixed viewpoint from the aircraft. For example looking directly down. | {{cquote|I'm looking to replicate a camera with a fixed viewpoint from the aircraft. For example looking directly down. | ||
Is there a way I can use some scripting method to call a new window displayed in the bottom right hand side of the screen showing a fixed camera view, without having to edit the preferences for my machine? I'd like it to be easily distributable. <ref>{{cite web |url= | Is there a way I can use some scripting method to call a new window displayed in the bottom right hand side of the screen showing a fixed camera view, without having to edit the preferences for my machine? I'd like it to be easily distributable. <ref>{{cite web |url={{forum url|p=203145}}|title=Sub window view|author=Avionyx|date=Wed Mar 12, 2014 7:08 am}}</ref>|Avionyx }} | ||
{{cquote|I was wondering if it were possible to restrict the camera output to only one half of the running FG window? I'm hoping to do this so that I may have the map and route manager GUIs active in the other half, so that they aren't obscuring the camera view (and also have the entire HUD visible). So basically, half the window straight down the center - left half is just black, right half is the camera. | {{cquote|I was wondering if it were possible to restrict the camera output to only one half of the running FG window? I'm hoping to do this so that I may have the map and route manager GUIs active in the other half, so that they aren't obscuring the camera view (and also have the entire HUD visible). So basically, half the window straight down the center - left half is just black, right half is the camera. | ||
| Line 1,337: | Line 1,337: | ||
Although this would also be solved if there were an external FG dynamic navigational map program, that also displayed waypoints... (I don't think there is one, right?). | Although this would also be solved if there were an external FG dynamic navigational map program, that also displayed waypoints... (I don't think there is one, right?). | ||
Additionally, I would love to hear that this question can be answered with Nasal, as I really can't afford to edit the source code and recompile (it's for a project, and I have no admin rights on the laboratory machines).<ref>{{cite web |url= | Additionally, I would love to hear that this question can be answered with Nasal, as I really can't afford to edit the source code and recompile (it's for a project, and I have no admin rights on the laboratory machines).<ref>{{cite web |url={{forum url|p=198735}}|title="Half" the FG window?|author=seabutler|date=Fri Jan 24, 2014 5:38 am}}</ref>|seabutler }} | ||
{{cquote|I'm trying to debug reflection shader I'm working on. I have a camera attached to a scene graph, which pre-renders (osg::Camera::PRE_RENDER) scene into offscreen surface (osg::Camera::FRAME_BUFFER_OBJECT); For a debugging purposes I have to see the result of that render pass. | {{cquote|I'm trying to debug reflection shader I'm working on. I have a camera attached to a scene graph, which pre-renders (osg::Camera::PRE_RENDER) scene into offscreen surface (osg::Camera::FRAME_BUFFER_OBJECT); For a debugging purposes I have to see the result of that render pass. | ||
| Line 1,382: | Line 1,382: | ||
|Canvas is another excellent example for the dilemma that Rembrandt is facing: we've been wanting to support dedicated camera/sub-cameras passes for years, and it was thanks to Zan's work that this became possible a while ago, but all of the main rendering guys back then (Mathias, Tim and Fred) were completely unaware of this work, despite agreeing that they wanted to see this integrated - so Rembrandt pre-dated Zan's work. And equally, some of the features implemented in other areas of FG would be better implemented by adapting Zan's code, which is something that Zan, Fred and Mathias agreed on back then. Yet, so the problem is not lacking an agreement, it is having someone to do the integration work.<br/> | |Canvas is another excellent example for the dilemma that Rembrandt is facing: we've been wanting to support dedicated camera/sub-cameras passes for years, and it was thanks to Zan's work that this became possible a while ago, but all of the main rendering guys back then (Mathias, Tim and Fred) were completely unaware of this work, despite agreeing that they wanted to see this integrated - so Rembrandt pre-dated Zan's work. And equally, some of the features implemented in other areas of FG would be better implemented by adapting Zan's code, which is something that Zan, Fred and Mathias agreed on back then. Yet, so the problem is not lacking an agreement, it is having someone to do the integration work.<br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221015}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,391: | Line 1,391: | ||
{{FGCquote | {{FGCquote | ||
|Given all the recent development, the most natural development to take place would be modularizing it by splitting it up and re-implementing it on top of Zan's newcamera work - at that point, the integration layer would be much more modular, and could even be integrated with Canvas, which is another natural development step, simply because all the stuff that people cannot currently do, would become possible, without being tied to a particular rendering framework or even scenery engine. | |Given all the recent development, the most natural development to take place would be modularizing it by splitting it up and re-implementing it on top of Zan's newcamera work - at that point, the integration layer would be much more modular, and could even be integrated with Canvas, which is another natural development step, simply because all the stuff that people cannot currently do, would become possible, without being tied to a particular rendering framework or even scenery engine. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221015}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,403: | Line 1,403: | ||
It is indeed lack of consistency and integration that is the main challenge here - because all of these features were developed at a different point in time, and people were usually only interested in making one thing work, instead of unifying those solutions (effects + newcamera branch + Canvas). And it is indeed a lot of work to do this properly - a unified approach takes a lot of time and energy. | It is indeed lack of consistency and integration that is the main challenge here - because all of these features were developed at a different point in time, and people were usually only interested in making one thing work, instead of unifying those solutions (effects + newcamera branch + Canvas). And it is indeed a lot of work to do this properly - a unified approach takes a lot of time and energy. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221193}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,419: | Line 1,419: | ||
Like wlbragg said: we don't necessarily need to use a lot of dedicated C++ support code to implement alternate rendering schemes like Rembrandt, the main hooks required to support arbitrary -and fully dynamic- schemes is already in place. <br/> | Like wlbragg said: we don't necessarily need to use a lot of dedicated C++ support code to implement alternate rendering schemes like Rembrandt, the main hooks required to support arbitrary -and fully dynamic- schemes is already in place. <br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221223}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,432: | Line 1,432: | ||
<br/> | <br/> | ||
But as has been said by a number of people already, doing all the integration work can be really tedious and frustrating. | But as has been said by a number of people already, doing all the integration work can be really tedious and frustrating. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221223}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,441: | Line 1,441: | ||
{{FGCquote | {{FGCquote | ||
|Internally, a Rembrandt buffer is not much different from any other RTT context - Canvas is all about rendering to a dynamic texture and updating it dynamically by modifying a sub-tree in the property tree - but its primary primitives are 1) osgText, 2) shivaVG/OpenVG paths, 3) static raster images, 3) groups/maps - none of these would be particularly useful in this context. But Zan's newcamera work could be turned into a new "CanvasCamera" element to allow camera views to be rendered to a Canvas, including not just scenery views - but also individual rendering stages. Canvas itself maintains a FBO for each texture, which is also the mechanism in use by Rembrandt. Tim's CameraGroup code is designed such that it does expose a bunch of windowing-related attributes to the property tree - equally, our view manager is property-controlled. | |Internally, a Rembrandt buffer is not much different from any other RTT context - Canvas is all about rendering to a dynamic texture and updating it dynamically by modifying a sub-tree in the property tree - but its primary primitives are 1) osgText, 2) shivaVG/OpenVG paths, 3) static raster images, 3) groups/maps - none of these would be particularly useful in this context. But Zan's newcamera work could be turned into a new "CanvasCamera" element to allow camera views to be rendered to a Canvas, including not just scenery views - but also individual rendering stages. Canvas itself maintains a FBO for each texture, which is also the mechanism in use by Rembrandt. Tim's CameraGroup code is designed such that it does expose a bunch of windowing-related attributes to the property tree - equally, our view manager is property-controlled. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221229}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,451: | Line 1,451: | ||
|Meanwhile, we ended up with Canvas as an abstraction mechanism for FBO management via properties - so integrating Canvas would indeed be a logical choice, unrelated to any particular manifestation like ALS or Rembrandt - integrating these technologies would primarily mean that new features could be prototyped without necessarily having to customize the hard-coded renderer logic - including things like our hard-coded skydome for example, which could be implemented in fgdata space then - which would not just be relevant for efforts like Earthview (orbital flight), but also make other things possible that would currently require a fair amount of tinkering with the C++ code.<br/> | |Meanwhile, we ended up with Canvas as an abstraction mechanism for FBO management via properties - so integrating Canvas would indeed be a logical choice, unrelated to any particular manifestation like ALS or Rembrandt - integrating these technologies would primarily mean that new features could be prototyped without necessarily having to customize the hard-coded renderer logic - including things like our hard-coded skydome for example, which could be implemented in fgdata space then - which would not just be relevant for efforts like Earthview (orbital flight), but also make other things possible that would currently require a fair amount of tinkering with the C++ code.<br/> | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221229}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,462: | Line 1,462: | ||
<br/> | <br/> | ||
The CameraGroup.cxx file is basically begging to be refactored sooner or later. None of this needs to involve Canvas, it would just be a straightforward and generic approach to do so, but certainly not mandatory - Zan's original work was implemented using directly XML and the property tree - however, Canvas contains a few helpers to make this increasingly straightforward, requiring very little in terms of code (e.g. PropertyBasedElement as a container for subsystems implemented on top of the property tree). | The CameraGroup.cxx file is basically begging to be refactored sooner or later. None of this needs to involve Canvas, it would just be a straightforward and generic approach to do so, but certainly not mandatory - Zan's original work was implemented using directly XML and the property tree - however, Canvas contains a few helpers to make this increasingly straightforward, requiring very little in terms of code (e.g. PropertyBasedElement as a container for subsystems implemented on top of the property tree). | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=221229}} | ||
|title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | |title=<nowiki>Re: Orbital Makes the Sky Black</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,469: | Line 1,469: | ||
}} | }} | ||
{{FGCquote|1= As has been said previously, the proper way to support "cameras" via Canvas is using CompositeViewer, which does require a re-architecting of several parts of FG: [[CompositeViewer Support]]Given the current state of things, that seems at least another 3-4 release cycles away. So, short of that, the only thing that we can currently support with reasonable effort is "slaved views" (as per $FG_ROOT/Docs/README.multiscreen).That would not require too much in terms of coding, because the code is already there - in fact, CameraGroup.cxx already contains a RTT/FBO (render-to-texture) implementation that renders slaved views to an offscreen context. This is also how Rembrandt buffers are set up behind the scenes.So basically, the code is there, it would need to be extracted/genralied and turned into a CanvasElement, and possibly integrated with the existing view manager code.|2= {{cite web | url = | {{FGCquote|1= As has been said previously, the proper way to support "cameras" via Canvas is using CompositeViewer, which does require a re-architecting of several parts of FG: [[CompositeViewer Support]]Given the current state of things, that seems at least another 3-4 release cycles away. So, short of that, the only thing that we can currently support with reasonable effort is "slaved views" (as per $FG_ROOT/Docs/README.multiscreen).That would not require too much in terms of coding, because the code is already there - in fact, CameraGroup.cxx already contains a RTT/FBO (render-to-texture) implementation that renders slaved views to an offscreen context. This is also how Rembrandt buffers are set up behind the scenes.So basically, the code is there, it would need to be extracted/genralied and turned into a CanvasElement, and possibly integrated with the existing view manager code.|2= {{cite web | url = {{forum url|p=260810}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>Hooray</nowiki> | date = Oct 17th, 2015 }}}} | ||
{{FGCquote|1= And then, there also is Zan's newcameras branch, which exposes rendering stages (passes) to XML/property tree space, so that individual stages are made accessible to shaders/effects. Thus, most of the code is there, it is mainly a matter of integrating things, i.e. that would require someone able to build SG/FG from source, familiar with C++ and willing/able to work through some OSG tutorials/docs to make this work: [[Canvas Development#Supporting Cameras]]On the other hand, Canvas is/was primarily about exposing 2D rendering to fgdata space, so that fgdata developers could incorporatedevelop and maintain 2D rendering related features without having to be core developers (core development being an obvious bottleneck, as well as having significant barrier to entry).In other words, people would need to be convinced that they want to let Canvas evolve beyond the 2D use-case, i.e. by allowing effects/shaders per element, but also to let Cameras be created/controlled easily.Personally, I do believe that this is a worthwhile thing to aim for, as it would help unify (and simplify) most RTT/FBO handling in SG/FG, and make this available to people like Thorsten who have a track record of doing really fancy, unprecedented stuff, with this flexibility.Equally, there are tons of use-cases where aircraft/scenery developers may want to set up custom cameras (A380 tail cam, space shuttle) and render those to an offscreen texture (e.g. GUI dialog and/or MFD screen).|2= {{cite web | url = | {{FGCquote|1= And then, there also is Zan's newcameras branch, which exposes rendering stages (passes) to XML/property tree space, so that individual stages are made accessible to shaders/effects. Thus, most of the code is there, it is mainly a matter of integrating things, i.e. that would require someone able to build SG/FG from source, familiar with C++ and willing/able to work through some OSG tutorials/docs to make this work: [[Canvas Development#Supporting Cameras]]On the other hand, Canvas is/was primarily about exposing 2D rendering to fgdata space, so that fgdata developers could incorporatedevelop and maintain 2D rendering related features without having to be core developers (core development being an obvious bottleneck, as well as having significant barrier to entry).In other words, people would need to be convinced that they want to let Canvas evolve beyond the 2D use-case, i.e. by allowing effects/shaders per element, but also to let Cameras be created/controlled easily.Personally, I do believe that this is a worthwhile thing to aim for, as it would help unify (and simplify) most RTT/FBO handling in SG/FG, and make this available to people like Thorsten who have a track record of doing really fancy, unprecedented stuff, with this flexibility.Equally, there are tons of use-cases where aircraft/scenery developers may want to set up custom cameras (A380 tail cam, space shuttle) and render those to an offscreen texture (e.g. GUI dialog and/or MFD screen).|2= {{cite web | url = {{forum url|p=260810}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>Hooray</nowiki> | date = Oct 17th, 2015 }}}} | ||
{{FGCquote|1= tail cams are slaved cameras, so could be using code that already exists in FG, which would need to be integrated with the Canvas system, to be exposed as a dedicated Canvas element (kinda like the view manager rendering everything to a texture/osg::Geode).There's window setup/handling code in CameraGroup.cxx which sets up these slaved views and renders the whole thing to a osg::TextureRectangle, which is pretty much what needs to be extracted and integrated with a new "CanvasCamera" element - the boilerplate for which can be seen at: [CanvasThe whole RTT/FBO texture setup can be seen here: http://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/CameraGroup.cxx#l994That code would be redundant in the Canvas context, i.e. could be replaced by a Canvas FBO instead.The next step would then be wrapping the whole thing in a CanvasCamera and exposing the corresponding view parameters as properties (propertyObject) so that slaved cameras can be controlled via Canvas.Otherwise, there is only very little else needed, because the CanvasMgr would handle updating the Camera, and render everything to the texture that you specified.|2= {{cite web | url = | {{FGCquote|1= tail cams are slaved cameras, so could be using code that already exists in FG, which would need to be integrated with the Canvas system, to be exposed as a dedicated Canvas element (kinda like the view manager rendering everything to a texture/osg::Geode).There's window setup/handling code in CameraGroup.cxx which sets up these slaved views and renders the whole thing to a osg::TextureRectangle, which is pretty much what needs to be extracted and integrated with a new "CanvasCamera" element - the boilerplate for which can be seen at: [CanvasThe whole RTT/FBO texture setup can be seen here: http://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/CameraGroup.cxx#l994That code would be redundant in the Canvas context, i.e. could be replaced by a Canvas FBO instead.The next step would then be wrapping the whole thing in a CanvasCamera and exposing the corresponding view parameters as properties (propertyObject) so that slaved cameras can be controlled via Canvas.Otherwise, there is only very little else needed, because the CanvasMgr would handle updating the Camera, and render everything to the texture that you specified.|2= {{cite web | url = {{forum url|p=260812}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>Hooray</nowiki> | date = Oct 17th, 2015 }}}} | ||
{{FGCquote|1= As can be seen by the screen shots above, the code for doing this sort of stuff is readily available in FG.Obviously, someone interested in this, would need to know how to patch/build FG from source, i.e. after making C++ modifications, some of this is touching OSG (cameras and offscreen rendering specifically).Otherwise, it's relatively straightforward: CameraGroup.cxx already contains code to render a static camera to a texture, which is stored in a TextureMap named _textureTargets - internally, this is used for building the distortion camera - however, you can also exploit this to render an arbitrary camera view to a texture.At the Canvas level, you would then have to call the equivalent of '''flightgear::CameraGroup::getDefault()''' - this would be done at the FGCanvasSystemAdapter level, i.e. adding a getter function there, which returns the TextureRectangle map.Once you have a texture rectangle, you can also get the osg::Image for it, and that can be assigned to a Canvas image.Admittedly, that's a little brute force, but it should only require ~30 lines of code added to SG/FG to add a static camera view as a Canvas raster image.Ideally, something like this would be integrated with the existing view manager, i.e. using the same property names (via property objects), and then hooked up to CanvasImage, e.g. as a custom '''camera://''' protocol (we already support canvas:// and http(s)://)So some kind of dedicated CanvasCamera element would make sense, possibly inheriting from CanvasImage.And it would also make sense to look at Zan's new-cameras patches, because those add tons of features to CameraGroup.cxxThis would already allow arbitrary views slaved to the main view (camera) So as you can see, PagedLOD/CompositeViewer don't need to be involved to make this happen.|2= {{cite web | url = | {{FGCquote|1= As can be seen by the screen shots above, the code for doing this sort of stuff is readily available in FG.Obviously, someone interested in this, would need to know how to patch/build FG from source, i.e. after making C++ modifications, some of this is touching OSG (cameras and offscreen rendering specifically).Otherwise, it's relatively straightforward: CameraGroup.cxx already contains code to render a static camera to a texture, which is stored in a TextureMap named _textureTargets - internally, this is used for building the distortion camera - however, you can also exploit this to render an arbitrary camera view to a texture.At the Canvas level, you would then have to call the equivalent of '''flightgear::CameraGroup::getDefault()''' - this would be done at the FGCanvasSystemAdapter level, i.e. adding a getter function there, which returns the TextureRectangle map.Once you have a texture rectangle, you can also get the osg::Image for it, and that can be assigned to a Canvas image.Admittedly, that's a little brute force, but it should only require ~30 lines of code added to SG/FG to add a static camera view as a Canvas raster image.Ideally, something like this would be integrated with the existing view manager, i.e. using the same property names (via property objects), and then hooked up to CanvasImage, e.g. as a custom '''camera://''' protocol (we already support canvas:// and http(s)://)So some kind of dedicated CanvasCamera element would make sense, possibly inheriting from CanvasImage.And it would also make sense to look at Zan's new-cameras patches, because those add tons of features to CameraGroup.cxxThis would already allow arbitrary views slaved to the main view (camera) So as you can see, PagedLOD/CompositeViewer don't need to be involved to make this happen.|2= {{cite web | url = {{forum url|p=261665}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>Hooray</nowiki> | date = Oct 25th, 2015 }}}} | ||
<references/> | <references/> | ||
| Line 1,508: | Line 1,508: | ||
|1= Could canvas be used to take a view from a certain area in a certain direction and render it onto a fuselage--in other words, to create a reflection? | |1= Could canvas be used to take a view from a certain area in a certain direction and render it onto a fuselage--in other words, to create a reflection? | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270547}} | ||
| title = <nowiki>Using Canvas to create reflections</nowiki> | | title = <nowiki>Using Canvas to create reflections</nowiki> | ||
| author = <nowiki>MIG29pilot</nowiki> | | author = <nowiki>MIG29pilot</nowiki> | ||
| Line 1,556: | Line 1,556: | ||
{{FGCquote | {{FGCquote | ||
|I think getting large amount of data into a shader on a per frame basis may be a bit tricky. I could imagine using a texture but it will have to be copied to or updated in the graphics card memory for each frame which probably is fairly expensive. OTOH you'd get wakes and all if you succeed. | |I think getting large amount of data into a shader on a per frame basis may be a bit tricky. I could imagine using a texture but it will have to be copied to or updated in the graphics card memory for each frame which probably is fairly expensive. OTOH you'd get wakes and all if you succeed. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=216243}} | ||
|title=<nowiki>Re: Export water/wave surface geometry</nowiki> | |title=<nowiki>Re: Export water/wave surface geometry</nowiki> | ||
|author=<nowiki>AndersG</nowiki> | |author=<nowiki>AndersG</nowiki> | ||
| Line 1,697: | Line 1,697: | ||
* http://en.wikipedia.org/wiki/OpenGL_Shading_Language | * http://en.wikipedia.org/wiki/OpenGL_Shading_Language | ||
* http://www.cuboslocos.com/tutorials/OSG-Shader | * http://www.cuboslocos.com/tutorials/OSG-Shader | ||
* | * {{forum url|t=22166}} | ||
* | * {{project infrastructure|forum|urn=search.php?keywords=canvas+shader|link=no}} | ||
* | * {{project infrastructure|forum|urn=search.php?keywords=canvas+shaders|link=no}} | ||
* | * {{project infrastructure|forum|urn=search.php?keywords=canvas+effects|link=no}} | ||
| Line 1,729: | Line 1,729: | ||
there's also been talk about possibly supporting a dedicated PDF element eventually: | there's also been talk about possibly supporting a dedicated PDF element eventually: | ||
{{FGCquote|1= Hmmm, I'm now wondering about a | {{FGCquote|1= Hmmm, I'm now wondering about a {{forum link|p=214381|text=canvas PDF viewer}}!|2= {{cite web | url = {{forum url|p=257936}} | title = <nowiki>Re: Space Shuttle</nowiki> | author = <nowiki>bugman</nowiki> | date = Sep 18th, 2015 }}}} | ||
{{FGCquote|1= Now to see what happens with the | {{FGCquote|1= Now to see what happens with the {{forum link|p=258879|text=EFB ideas and the canvas PDF support}}.|2= {{cite web | url = {{forum url|p=p259019}} | title = <nowiki>Re: Space Shuttle</nowiki> | author = <nowiki>bugman</nowiki> | date = Sep 28th, 2015 }}}} | ||
{{FGCquote | {{FGCquote | ||
| Line 1,743: | Line 1,743: | ||
<br/> | <br/> | ||
Also see this related discussion on the XP forum: [http://forums.x-plane.org/?showtopic{{=}}46676 http://forums.x-plane.org/?showtopic{{=}}46676] | Also see this related discussion on the XP forum: [http://forums.x-plane.org/?showtopic{{=}}46676 http://forums.x-plane.org/?showtopic{{=}}46676] | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=213159}} | ||
|title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | |title=<nowiki>Re: 777 EFB: initial feedback</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,750: | Line 1,750: | ||
}} | }} | ||
{{FGCquote|1= It may make sense to revisit this idea, supporting a subset of PDF would not be too difficult, but it would be better to really use a PDF library and OSG's built-in suport for rendering a PDF to a texture, which could the be easily turned into a new Canvas Element, as per the example at: [[Canvas Development#Adding a new Element]]The coding part is relatively straightforward (basically copy&paste), but getting the dependencies/cmake magic right for all supported FG platforms would probably require a bit of work.|2= {{cite web | url = | {{FGCquote|1= It may make sense to revisit this idea, supporting a subset of PDF would not be too difficult, but it would be better to really use a PDF library and OSG's built-in suport for rendering a PDF to a texture, which could the be easily turned into a new Canvas Element, as per the example at: [[Canvas Development#Adding a new Element]]The coding part is relatively straightforward (basically copy&paste), but getting the dependencies/cmake magic right for all supported FG platforms would probably require a bit of work.|2= {{cite web | url = {{forum url|p=258282}} | title = <nowiki>Re: 777 EFB: initial feedback</nowiki> | author = <nowiki>Hooray</nowiki> | date = Sep 21st, 2015 }}}} | ||
{{FGCquote|1= the whole EFB idea has also been discussed previously, with a focus on using Canvas and Nasal - analogous to how Richard's MFD framework is just a front-end on top of Canvas/Nasal. Obviously, this approach (it not using Phi), has the limitation that it can only display stuff inside the fgfs main window.But we do have code/prototypes doing EFB handling using Nasal & Canvas|2= {{cite web | url = | {{FGCquote|1= the whole EFB idea has also been discussed previously, with a focus on using Canvas and Nasal - analogous to how Richard's MFD framework is just a front-end on top of Canvas/Nasal. Obviously, this approach (it not using Phi), has the limitation that it can only display stuff inside the fgfs main window.But we do have code/prototypes doing EFB handling using Nasal & Canvas|2= {{cite web | url = {{forum url|p=258879}} | title = <nowiki>Canvas MFD framework vs. EFB functionality</nowiki> | author = <nowiki>Hooray</nowiki> | date = Sep 27th, 2015 }}}} | ||
{{FGCquote|1= More recently, another idea is to add dedicated PDF support to the core Canvas system, so that arbitrary PDF files can be rendered onto a Canvas: | {{FGCquote|1= More recently, another idea is to add dedicated PDF support to the core Canvas system, so that arbitrary PDF files can be rendered onto a Canvas: {{forum url|p=258282}} |2= {{cite web | url = {{forum url|p=258879}} | title = <nowiki>Canvas MFD framework vs. EFB functionality</nowiki> | author = <nowiki>Hooray</nowiki> | date = Sep 27th, 2015 }}}} | ||
If you are interested in working on any of these, please get in touch via the canvas sub forum first. | If you are interested in working on any of these, please get in touch via the canvas sub forum first. | ||
| Line 1,777: | Line 1,777: | ||
For example, there's been talk about possibly adding the following additional primitives at some point. However, none of these are currently a priority or being worked on by anybody: | For example, there's been talk about possibly adding the following additional primitives at some point. However, none of these are currently a priority or being worked on by anybody: | ||
* support for a vertical mapping mode (e.g. to create Vertical Situation Displays or flight path evaluation dialogs), would probably make sense to use [http://trac.osgeo.org/proj/ PROJ4] for additional projcetion support? | * support for a vertical mapping mode (e.g. to create Vertical Situation Displays or flight path evaluation dialogs), would probably make sense to use [http://trac.osgeo.org/proj/ PROJ4] for additional projcetion support? | ||
* support for [[Howto:Use a Camera View in an Instrument|rendering scenery views]] (e.g. for tail cameras or mirrors etc) | * support for [[Howto:Use a Camera View in an Instrument|rendering scenery views]] (e.g. for tail cameras or mirrors etc) {{forum link|p=158690}} {{forum link|t=21192}} {{Issue|1250}} | ||
* support for ESRI shapefiles (instead of using shapelib, it would make sense to use GDAL/OGR here, or directly the {{abbr|OSG|OpenSceneGraph}}/ReaderWriterOGR plugin) [http://trac.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/ogr] (FlightGear/osgEarth now depends on GDAL, so should be straightforward dependency-wise): | * support for ESRI shapefiles (instead of using shapelib, it would make sense to use GDAL/OGR here, or directly the {{abbr|OSG|OpenSceneGraph}}/ReaderWriterOGR plugin) [http://trac.openscenegraph.org/projects/osg/browser/OpenSceneGraph/trunk/src/osgPlugins/ogr] (FlightGear/osgEarth now depends on GDAL, so should be straightforward dependency-wise): | ||
* support for GeoTIFF files or terrain height profiles using the tile cache | * support for GeoTIFF files or terrain height profiles using the tile cache | ||
* rendering 3D objects | * rendering 3D objects | ||
* support for ortographic moving map displays, e.g. using atlas | * support for ortographic moving map displays, e.g. using atlas {{forum link|p=201955}} (ideally using[[CompositeViewer Support]]): | ||
There is already support for creating multiple osgviewer windows in FlightGear, this is commonly used in multiscreen setups - to support the creation and usage of [[Howto:Configure camera view windows|osgviewer windows]] in Canvas, we would need to look into adding a new placement type to the canvas system, so that osgviewer/OS windows can be created and controlled via the canvas system and a handful of placement-specific properties | There is already support for creating multiple osgviewer windows in FlightGear, this is commonly used in multiscreen setups - to support the creation and usage of [[Howto:Configure camera view windows|osgviewer windows]] in Canvas, we would need to look into adding a new placement type to the canvas system, so that osgviewer/OS windows can be created and controlled via the canvas system and a handful of placement-specific properties {{forum link|t=2985}}. | ||
== Placements == | == Placements == | ||
| Line 1,830: | Line 1,830: | ||
Also see | Also see {{forum link|p=201862|title=Photoscenery via Canvas?}} and {{forum link|p=206581|title=A project to create a source of free geo-referenced instrument charts}} | ||
{{FGCquote | {{FGCquote | ||
| Line 1,873: | Line 1,873: | ||
|For the sake of completeness, and I am not saying that you should do this (and it almost certainly going to be much worse performance-wise than any shaders) - but if you want the shadow to be accurate despite potential terrain sloping, you could apply a Canvas texture onto the surface (admittedly, this is much more straightforward in the case of an actual 3D model like a carrier) - otherwise, you'll also want to use a workaround and attach the texture to the 3D model (aka main aircraft). But people have been using Canvas for all sorts of purposes, including even liveries: [[Howto:Dynamic_Liveries_via_Canvas]] | |For the sake of completeness, and I am not saying that you should do this (and it almost certainly going to be much worse performance-wise than any shaders) - but if you want the shadow to be accurate despite potential terrain sloping, you could apply a Canvas texture onto the surface (admittedly, this is much more straightforward in the case of an actual 3D model like a carrier) - otherwise, you'll also want to use a workaround and attach the texture to the 3D model (aka main aircraft). But people have been using Canvas for all sorts of purposes, including even liveries: [[Howto:Dynamic_Liveries_via_Canvas]] | ||
But unlike glsl/shaders, a Canvas is not primarily a GPU thing, i.e. there's lots of CPU-level stuff going on affecting performance. | But unlike glsl/shaders, a Canvas is not primarily a GPU thing, i.e. there's lots of CPU-level stuff going on affecting performance. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=230005}} | ||
|title=<nowiki>Re: 2D shadow on ground?</nowiki> | |title=<nowiki>Re: 2D shadow on ground?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 1,995: | Line 1,995: | ||
{{FGCquote | {{FGCquote | ||
| I have a project using flightgear to simulate the real 3D flight scenario, get the images and process the with image processing algorithms. So what I want are the coordinates of the airplane and the coordinates of the camera. I encountered some problems when I was trying to set my own view points. | | I have a project using flightgear to simulate the real 3D flight scenario, get the images and process the with image processing algorithms. So what I want are the coordinates of the airplane and the coordinates of the camera. I encountered some problems when I was trying to set my own view points. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=218358}} | ||
|title=<nowiki>Render image in Flightgear</nowiki> | |title=<nowiki>Render image in Flightgear</nowiki> | ||
|author=<nowiki>yanzhang</nowiki> | |author=<nowiki>yanzhang</nowiki> | ||
| Line 2,014: | Line 2,014: | ||
{{FGCquote|1= The problem is not the decoder but the encoder. I don't have a fast-enough real-time video encoder that lives happily in the FG main loop. I have experimented with ffmpeg which was promising, but it ended up on the very bottom of my backlog :-/ We can do MJPEG stream, try to use /screenshot?stream=y as the screenshot url. MJPEG is ugly and a resource hog but works reasonable well for image sies of probably 640x480. Scale down your FG window and give it a try.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34534457/ | title = <nowiki>Re: [Flightgear-devel] phi interface updates</nowiki> | author = <nowiki>Torsten Dreyer</nowiki> | date = Oct 12th, 2015 }}}} | {{FGCquote|1= The problem is not the decoder but the encoder. I don't have a fast-enough real-time video encoder that lives happily in the FG main loop. I have experimented with ffmpeg which was promising, but it ended up on the very bottom of my backlog :-/ We can do MJPEG stream, try to use /screenshot?stream=y as the screenshot url. MJPEG is ugly and a resource hog but works reasonable well for image sies of probably 640x480. Scale down your FG window and give it a try.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/34534457/ | title = <nowiki>Re: [Flightgear-devel] phi interface updates</nowiki> | author = <nowiki>Torsten Dreyer</nowiki> | date = Oct 12th, 2015 }}}} | ||
People interested in doing UAV work that involves computer vision (e.g. using OpenCV, see {{Issue|924}}, | People interested in doing UAV work that involves computer vision (e.g. using OpenCV, see {{Issue|924}}, {{forum link|t=16015|hilit=opencv}}, {{forum link|p=192817}}) will probably also want to look into using a dedicated Canvas placement for this, in combination with adding a dedicated Canvas::Element to render scenery views to a texture using [[CompositeViewer Support]] - these two features would provide a straightforward mechanism to export a live video stream of FlightGear via a dedicated port. | ||
{{Note|There were several early attempts at bringing streaming capabilities to FlightGear in the pre-{{abbr|OSG|OpenSceneGraph}} days that are meanwhile unmaintained, e.g.: | {{Note|There were several early attempts at bringing streaming capabilities to FlightGear in the pre-{{abbr|OSG|OpenSceneGraph}} days that are meanwhile unmaintained, e.g.: | ||
| Line 2,024: | Line 2,024: | ||
|Is there generally the possibility to use image-processing-algorithms in NASAL? I mean things like FFT, convolution or a sobel-operator...<br/> | |Is there generally the possibility to use image-processing-algorithms in NASAL? I mean things like FFT, convolution or a sobel-operator...<br/> | ||
This is not only for image-processing of course, but will be used often for this. And it is not only for Images!, also for other 2d-datas like a terrain-representation to detect edges there or so... | This is not only for image-processing of course, but will be used often for this. And it is not only for Images!, also for other 2d-datas like a terrain-representation to detect edges there or so... | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=226101}} | ||
|title=<nowiki>"Image-Processing" or FFT in NASAL/FG ???</nowiki> | |title=<nowiki>"Image-Processing" or FFT in NASAL/FG ???</nowiki> | ||
|author=<nowiki>St.Michel</nowiki> | |author=<nowiki>St.Michel</nowiki> | ||
| Line 2,089: | Line 2,089: | ||
{{cquote|I want draw something in the front face of the FlightGear view, but I don't wan to recompile / modify any codes, so, if the FlightGear could give me a interface to draw something myself through DLL, that's perfect.<ref>{{cite web |url= | {{cquote|I want draw something in the front face of the FlightGear view, but I don't wan to recompile / modify any codes, so, if the FlightGear could give me a interface to draw something myself through DLL, that's perfect.<ref>{{cite web |url={{forum link|t=22995}}|title=<nowiki>One suggestion: FlightGear wolud support plugins like this!</nowiki>|author=CHIV|date=Thu May 08, 2014 3:03 am}}</ref>|CHIV}} | ||
<references/> | <references/> | ||
| Line 2,139: | Line 2,139: | ||
|1= I stumbled across what is perhaps closer to the core of the issue in a flight over the North Pole. Flightplan legs are rendered as great circle segments, so long legs are drawn with a curve. Somewhere, the flightplan has to be flattened into a map view. It appears that this is easy to do over short distances in lower latitudes, but becomes increasingly difficult over long distances with a bigger component of Earth's curvature involved. The map view is not really geared for polar routes, so the leg that goes over the pole has an extreme curve drawn in it. And when that leg was in range, the frame rate dropped from 25-30 down to 8-12. Once it went out of range, frame rate was back to normal. It seems like calculating curvature may be the rate-limiting step. | |1= I stumbled across what is perhaps closer to the core of the issue in a flight over the North Pole. Flightplan legs are rendered as great circle segments, so long legs are drawn with a curve. Somewhere, the flightplan has to be flattened into a map view. It appears that this is easy to do over short distances in lower latitudes, but becomes increasingly difficult over long distances with a bigger component of Earth's curvature involved. The map view is not really geared for polar routes, so the leg that goes over the pole has an extreme curve drawn in it. And when that leg was in range, the frame rate dropped from 25-30 down to 8-12. Once it went out of range, frame rate was back to normal. It seems like calculating curvature may be the rate-limiting step. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=227835}} | ||
| title = <nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | | title = <nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | ||
| author = <nowiki>tikibar</nowiki> | | author = <nowiki>tikibar</nowiki> | ||
| Line 2,148: | Line 2,148: | ||
{{FGCquote | {{FGCquote | ||
|1= I narrowed this down to the way map segments around the curving earth are calculated in the canvas ND. I added a hard coded distance limiter to it that restored the calculation speed as long as no leg was longer than about 800 nm. Hooray suggested an approach that was more dynamic, but I never got around to working on it. Bottom line, it's not a graphics card issue but a calculation issue. I've seen it in both the 757 and 747-8 series using the canvas ND. | |1= I narrowed this down to the way map segments around the curving earth are calculated in the canvas ND. I added a hard coded distance limiter to it that restored the calculation speed as long as no leg was longer than about 800 nm. Hooray suggested an approach that was more dynamic, but I never got around to working on it. Bottom line, it's not a graphics card issue but a calculation issue. I've seen it in both the 757 and 747-8 series using the canvas ND. | ||
The old thread about it is here: | The old thread about it is here: {{forum link|t=24894}} | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275605}} | ||
| title = <nowiki>Re: Root Manager consumes a lot of Frame Rate</nowiki> | | title = <nowiki>Re: Root Manager consumes a lot of Frame Rate</nowiki> | ||
| author = <nowiki>tikibar</nowiki> | | author = <nowiki>tikibar</nowiki> | ||
| Line 2,160: | Line 2,160: | ||
|1= Gijs provided a patch to fix the hard-coded [[Map dialog|Map dialog]] (and possibly the ND), it's the projection code that is causing this - as far as I know, Gijs' patches never got integrated with the Canvas system, my original suggestion was to extend the canvas projection code so that projection code can be implemented in the form of Nasal code and/or property rules. | |1= Gijs provided a patch to fix the hard-coded [[Map dialog|Map dialog]] (and possibly the ND), it's the projection code that is causing this - as far as I know, Gijs' patches never got integrated with the Canvas system, my original suggestion was to extend the canvas projection code so that projection code can be implemented in the form of Nasal code and/or property rules. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275624}} | ||
| title = <nowiki>Re: Route Manager consumes a lot of Frame Rate</nowiki> | | title = <nowiki>Re: Route Manager consumes a lot of Frame Rate</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 2,193: | Line 2,193: | ||
{{FGCquote | {{FGCquote | ||
|Supporting a few common GIS projections would seem useful though, i.e. integrating Proj4 - and if we really want to create a 3D projection, we'd probably be better off by rendering the scene to a texture and using canvas shaders then to add flight path info that way. | |Supporting a few common GIS projections would seem useful though, i.e. integrating Proj4 - and if we really want to create a 3D projection, we'd probably be better off by rendering the scene to a texture and using canvas shaders then to add flight path info that way. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=215002}} | ||
|title=<nowiki>Re: Cannot use .setText on SVG text element</nowiki> | |title=<nowiki>Re: Cannot use .setText on SVG text element</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,202: | Line 2,202: | ||
{{FGCquote | {{FGCquote | ||
|There's a projection library available called "proj4", it comes with a number of different projections, we may absorb that into simgear and use it for projection handling - which would free us from having to implement/test and maintain our own | |There's a projection library available called "proj4", it comes with a number of different projections, we may absorb that into simgear and use it for projection handling - which would free us from having to implement/test and maintain our own | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214897}} | ||
|title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | |title=<nowiki>Re: NavDisplay & MapStructure discussion (previously via PM)</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,212: | Line 2,212: | ||
|We've already fixed that in the (old) map dialog, by using an azimuthal equidistant projection (see [[images/7/71/Map_north_pole_route.jpg|screenshot]]). Porting the projection to Canvas is on my todo list. Such a projection is much much better for navigational use. | |We've already fixed that in the (old) map dialog, by using an azimuthal equidistant projection (see [[images/7/71/Map_north_pole_route.jpg|screenshot]]). Porting the projection to Canvas is on my todo list. Such a projection is much much better for navigational use. | ||
Curves in routes are not calculated by Canvas, nor by the ND though. It's the route manager that splits up a route in segments in order to get smooth transitions. | Curves in routes are not calculated by Canvas, nor by the ND though. It's the route manager that splits up a route in segments in order to get smooth transitions. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=227838}} | ||
|title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | ||
|author=<nowiki>Gijs</nowiki> | |author=<nowiki>Gijs</nowiki> | ||
| Line 2,221: | Line 2,221: | ||
{{FGCquote | {{FGCquote | ||
|The new ND uses the actual route-manager paths, which allows it to draw holdings, flyby waypoints (thanks to James recent work) etc. But we'll need the azimuthal projection anyway, so I'll bump my todo list | |The new ND uses the actual route-manager paths, which allows it to draw holdings, flyby waypoints (thanks to James recent work) etc. But we'll need the azimuthal projection anyway, so I'll bump my todo list | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=227845}} | ||
|title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | ||
|author=<nowiki>Gijs</nowiki> | |author=<nowiki>Gijs</nowiki> | ||
| Line 2,234: | Line 2,234: | ||
<br/> | <br/> | ||
Ideally, we would expose the projection as a property for each Map so that it can be changed dynamically. | Ideally, we would expose the projection as a property for each Map so that it can be changed dynamically. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=227932}} | ||
|title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,244: | Line 2,244: | ||
Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides. | Gijs was looking for an outline that follows the shape of the text, which is what backdrop provides. | ||
For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now | For his solution, see the two diffs below. He didn't add the full range of backdrop options, just outline for now {{forum link|p=214275}}. | ||
{{FGCquote | {{FGCquote | ||
|And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes).<br/> | |And this is how it looks in FlightGear now :-) Notice how the overlapping waypoints are easier to read (this image is a little exaggerated with all those fixes).<br/> | ||
<br/> | <br/> | ||
(see the [http://i.imgur.com/dqMzBS4.png linked image]) | (see the [http://i.imgur.com/dqMzBS4.png linked image]) | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=214268}} | ||
|title=<nowiki>Re: osgText backdrop</nowiki> | |title=<nowiki>Re: osgText backdrop</nowiki> | ||
|author=<nowiki>Gijs</nowiki> | |author=<nowiki>Gijs</nowiki> | ||
| Line 2,386: | Line 2,386: | ||
{{FGCquote | {{FGCquote | ||
|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 | |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 | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=167264}} | ||
|title=<nowiki>Re: Using a </nowiki> | |title=<nowiki>Re: Using a </nowiki> | ||
|author=<nowiki>TheTom</nowiki> | |author=<nowiki>TheTom</nowiki> | ||
| Line 2,395: | Line 2,395: | ||
{{FGCquote | {{FGCquote | ||
|I'm also interested in any performance issues. For example a canvas is always redrawn if any property changes within the current frame, even if the same value is just written again or changes are too small to be noticeable. Also if a property of a hidden element/group is changed, the canvas is redrawn. Maybe checking if properties have changed enough will gain some speed, but I'm not sure if this will be noticeable at all (only if always the same values are written to the tree...) | |I'm also interested in any performance issues. For example a canvas is always redrawn if any property changes within the current frame, even if the same value is just written again or changes are too small to be noticeable. Also if a property of a hidden element/group is changed, the canvas is redrawn. Maybe checking if properties have changed enough will gain some speed, but I'm not sure if this will be noticeable at all (only if always the same values are written to the tree...) | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=193941}} | ||
|title=<nowiki>Re: How to display Airport Chart?</nowiki> | |title=<nowiki>Re: How to display Airport Chart?</nowiki> | ||
|author=<nowiki>TheTom</nowiki> | |author=<nowiki>TheTom</nowiki> | ||
| Line 2,404: | Line 2,404: | ||
{{FGCquote | {{FGCquote | ||
|I will add a new element type to render symbols from a "Cache-Texture" to improve speed of canvasses showing lots of symbols like eg. the navigation display. You will basically be able to set position (maybe rotation) and index of the symbol in the cache-texture and possibly a color for each instance... | |I will add a new element type to render symbols from a "Cache-Texture" to improve speed of canvasses showing lots of symbols like eg. the navigation display. You will basically be able to set position (maybe rotation) and index of the symbol in the cache-texture and possibly a color for each instance... | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=193925}} | ||
|title=<nowiki>Re: How to display Airport Chart?</nowiki> | |title=<nowiki>Re: How to display Airport Chart?</nowiki> | ||
|author=<nowiki>TheTom</nowiki> | |author=<nowiki>TheTom</nowiki> | ||
| Line 2,413: | Line 2,413: | ||
{{FGCquote | {{FGCquote | ||
|Regarding spatial queries, on the nav-cache side, delta queries would be complex to support. What the C++ NavDisplay does is keep a persistent list which is updated infrequently - only when a setting changes (range, view options config), or when the aircraft moves > 1nm. In C++, computing the delta of two arrays is fast | |Regarding spatial queries, on the nav-cache side, delta queries would be complex to support. What the C++ NavDisplay does is keep a persistent list which is updated infrequently - only when a setting changes (range, view options config), or when the aircraft moves > 1nm. In C++, computing the delta of two arrays is fast | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=193275}} | ||
|title=<nowiki>Re: How to display Airport Chart?</nowiki> | |title=<nowiki>Re: How to display Airport Chart?</nowiki> | ||
|author=<nowiki>zakalawe</nowiki> | |author=<nowiki>zakalawe</nowiki> | ||
| Line 2,422: | Line 2,422: | ||
{{FGCquote | {{FGCquote | ||
|I guess we need to come up with some heuristics at the C++ level for selectively updating/rendering parts of the route that are visible/relevant (i.e. not necessarily visible, but part of a visible line segment) | |I guess we need to come up with some heuristics at the C++ level for selectively updating/rendering parts of the route that are visible/relevant (i.e. not necessarily visible, but part of a visible line segment) | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=227587}} | ||
|title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,431: | Line 2,431: | ||
{{FGCquote | {{FGCquote | ||
|if it's just as fast, it's rendering / rasterization that is probably taking so long, which would mean that we'd need to explore selective updating/rendering of nodes that are neither visible, nor connected to anything visible (line segments). | |if it's just as fast, it's rendering / rasterization that is probably taking so long, which would mean that we'd need to explore selective updating/rendering of nodes that are neither visible, nor connected to anything visible (line segments). | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=227628}} | ||
|title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | |title=<nowiki>Re: Canvas ND performance issues with route-manager</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,492: | Line 2,492: | ||
There are some calls going over parents where no interface is "rechable" or defined. | There are some calls going over parents where no interface is "rechable" or defined. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=201607}} | ||
| title = <nowiki>extra500 - Avidyne Entegra 9 IFD - approach</nowiki> | | title = <nowiki>extra500 - Avidyne Entegra 9 IFD - approach</nowiki> | ||
| author = <nowiki>D-Leon</nowiki> | | author = <nowiki>D-Leon</nowiki> | ||
| Line 2,504: | Line 2,504: | ||
|1= complex MFD instruments like the G1000 series or the Avidyne Entegra R9 are better not implemented directly, but using a "bottom-up" approach, where you identify all required building blocks (e.g. screen component, page component) and build higher level components on top. Otherwise, there will be very tight coupling at some point, so that it will be really easy to generalie/maintain the underlying code (look at D-LEON's comments above). | |1= complex MFD instruments like the G1000 series or the Avidyne Entegra R9 are better not implemented directly, but using a "bottom-up" approach, where you identify all required building blocks (e.g. screen component, page component) and build higher level components on top. Otherwise, there will be very tight coupling at some point, so that it will be really easy to generalie/maintain the underlying code (look at D-LEON's comments above). | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=231068}} | ||
| title = <nowiki>Re: Project Farmin [Garmin Flightdeck Frame work]</nowiki> | | title = <nowiki>Re: Project Farmin [Garmin Flightdeck Frame work]</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 2,515: | Line 2,515: | ||
{{FGCquote | {{FGCquote | ||
|Canvas & Nasal are still fairly low-level for most aircraft developers, to come up with good -and fast displays (code)- people still need to be experienced coders, and familiar with FlightGear scripting and Canvas technologies/elements and the way performance is affected through certain constructs. So far, we now have the means to create the corresponding visuals, but there's still quite some work ahead to re-implement existing hard-coded displays - but to implement a compelling jet fighter, including a credible cockpit, you would need more than "just" the visuals, i.e. lots of handbooks/manuals, building blocks for creating systems and components, and scripting-space frameworks to help with the latter.The best option to pave the way for this is to keep on generalizing existing code, so that instruments support multiple instances, multiple aircraft, and multiple "sensors". | |Canvas & Nasal are still fairly low-level for most aircraft developers, to come up with good -and fast displays (code)- people still need to be experienced coders, and familiar with FlightGear scripting and Canvas technologies/elements and the way performance is affected through certain constructs. So far, we now have the means to create the corresponding visuals, but there's still quite some work ahead to re-implement existing hard-coded displays - but to implement a compelling jet fighter, including a credible cockpit, you would need more than "just" the visuals, i.e. lots of handbooks/manuals, building blocks for creating systems and components, and scripting-space frameworks to help with the latter.The best option to pave the way for this is to keep on generalizing existing code, so that instruments support multiple instances, multiple aircraft, and multiple "sensors". | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211061}} | ||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,524: | Line 2,524: | ||
{{FGCquote | {{FGCquote | ||
|Regarding "de-skilling", that's exactly the point of introducing more specific frameworks on top of Nasal and Canvas, developed by more experienced programmers, usable by less-experienced contributors, who often don't need any programming experience at all (see for example Gijs' ND work, which can now be integrated and used with different aircraft, without requiring ANY coding, it's just configuration markup, analogous to XML, but more succinct) | |Regarding "de-skilling", that's exactly the point of introducing more specific frameworks on top of Nasal and Canvas, developed by more experienced programmers, usable by less-experienced contributors, who often don't need any programming experience at all (see for example Gijs' ND work, which can now be integrated and used with different aircraft, without requiring ANY coding, it's just configuration markup, analogous to XML, but more succinct) | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211083}} | ||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,535: | Line 2,535: | ||
<br/> | <br/> | ||
That is exactly why people are working towards more targeted frameworks on top of Nasal/Canvas - but it's a process that is very much still in progress, and probably will be for at least another 2-3 release cycles. | That is exactly why people are working towards more targeted frameworks on top of Nasal/Canvas - but it's a process that is very much still in progress, and probably will be for at least another 2-3 release cycles. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211169}} | ||
|title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | |title=<nowiki>Re: Does FlightGear has Multiplayer Combat mode?</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,542: | Line 2,542: | ||
}} | }} | ||
{{FGCquote|1= currently, I am inclined to state that Canvas is falling victim to its own success, i.e. the way people (early-adopters) are using it is hugely problematic and does not scale at all. So we really need to stop documenting certain APIs and instead provide a single scalable extension mechanism, i.e. registering new features as dedicated Canvas Elements implemented in Nasal space, and registered with the CanvasGroup helper - absent that, the situation with Canvas contributions is likely to approach exactly the dilemma we're seeing with most Nasal spaghetti code, which is unmaintainable and is begging to be rewritten/ported from scratch.Which is simply because most aircraft developers are only interested in a single use-case (usually their own aircraft/instrument), and they don't care about long-term potential and maintenance, i.e. there are now tons of Canvas based features that would be useful in theory, but which are implemented in a fashion that renders them non-reusable elsewhere: [[Canvas Development#The Future of Canvas in FlightGear]]So at the moment, I am not too thrilled to add too many new features to Canvas, until this is solved - because we're seeing so much Nasal/Canvas code that is simply a dead-end due to the way it is structured, i.e. it won't be able to benefit from future optimiations short of a major rewrite or tons of 1:1 support by people familiar with the Canvas system. Which is why I am convinced that we need to stop implementing useful functionality using the existing approach, and instead adopt one that is CanvasElement-centric, where useful instruments, widgets, MFDs would be registered as custom elements implemented in Nasal space (via cppbind sub-classing).If we don't do that, we will continue to see cool Canvas features implemented as spaghetti code monsters that reflect badly upon Nasal and Canvas due to lack of of design, and performance.|2= {{cite web | url = | {{FGCquote|1= currently, I am inclined to state that Canvas is falling victim to its own success, i.e. the way people (early-adopters) are using it is hugely problematic and does not scale at all. So we really need to stop documenting certain APIs and instead provide a single scalable extension mechanism, i.e. registering new features as dedicated Canvas Elements implemented in Nasal space, and registered with the CanvasGroup helper - absent that, the situation with Canvas contributions is likely to approach exactly the dilemma we're seeing with most Nasal spaghetti code, which is unmaintainable and is begging to be rewritten/ported from scratch.Which is simply because most aircraft developers are only interested in a single use-case (usually their own aircraft/instrument), and they don't care about long-term potential and maintenance, i.e. there are now tons of Canvas based features that would be useful in theory, but which are implemented in a fashion that renders them non-reusable elsewhere: [[Canvas Development#The Future of Canvas in FlightGear]]So at the moment, I am not too thrilled to add too many new features to Canvas, until this is solved - because we're seeing so much Nasal/Canvas code that is simply a dead-end due to the way it is structured, i.e. it won't be able to benefit from future optimiations short of a major rewrite or tons of 1:1 support by people familiar with the Canvas system. Which is why I am convinced that we need to stop implementing useful functionality using the existing approach, and instead adopt one that is CanvasElement-centric, where useful instruments, widgets, MFDs would be registered as custom elements implemented in Nasal space (via cppbind sub-classing).If we don't do that, we will continue to see cool Canvas features implemented as spaghetti code monsters that reflect badly upon Nasal and Canvas due to lack of of design, and performance.|2= {{cite web | url = {{forum link|p=260810}} | title = <nowiki>Re: WINDOW IN WINDOW</nowiki> | author = <nowiki>Hooray</nowiki> | date = Oct 17th, 2015 }}}} | ||
Yet, many Canvas early-adopters were/are working on conceptually-similar, and often even identical, features and functionality so that a lot of time is being wasted by people not knowing how to provide, and reuse, functionality in a "library"-fashion that is agnostic to the original use-case/aircraft (think [[MapStructure]]). | Yet, many Canvas early-adopters were/are working on conceptually-similar, and often even identical, features and functionality so that a lot of time is being wasted by people not knowing how to provide, and reuse, functionality in a "library"-fashion that is agnostic to the original use-case/aircraft (think [[MapStructure]]). | ||
| Line 2,552: | Line 2,552: | ||
[[Avidyne Entegra R9]] | [[Avidyne Entegra R9]] | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=275365}} | ||
| title = <nowiki>Re: Garmin gns530</nowiki> | | title = <nowiki>Re: Garmin gns530</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 2,593: | Line 2,593: | ||
{{FGCquote | {{FGCquote | ||
|the main motivation is that we want to provide some more "structure" for people creating canvas-based features like the pfd, nd, efb, HUD, cdu etc - but also MapStructure/Avidyne stuff. As long as new displays/instruments can be registered as higher-level canvas elements, we would ensure that some form of encapsulation is enforced, i.e. so that multiple instances can be trivially supported, and I/O really just takes places via the property tree. People would need to declare properties that they read/write through custom attributes, which would make it straightforward to support distributed setups for any canvas-based textures, including multiplayer, but also multi-instance setups like those at FSWeekend. | |the main motivation is that we want to provide some more "structure" for people creating canvas-based features like the pfd, nd, efb, HUD, cdu etc - but also MapStructure/Avidyne stuff. As long as new displays/instruments can be registered as higher-level canvas elements, we would ensure that some form of encapsulation is enforced, i.e. so that multiple instances can be trivially supported, and I/O really just takes places via the property tree. People would need to declare properties that they read/write through custom attributes, which would make it straightforward to support distributed setups for any canvas-based textures, including multiplayer, but also multi-instance setups like those at FSWeekend. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211510}} | ||
|title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,602: | Line 2,602: | ||
{{FGCquote | {{FGCquote | ||
|The long-term idea is to establish sufficient encapsulation, so that we can also support recursion, and use the whole thing in stand-alone mode, e.g. something like FGCanvas, without being extremely specific to a single aircraft/instrument. I think this could be a worthwhile direction to explore in the long-term | |The long-term idea is to establish sufficient encapsulation, so that we can also support recursion, and use the whole thing in stand-alone mode, e.g. something like FGCanvas, without being extremely specific to a single aircraft/instrument. I think this could be a worthwhile direction to explore in the long-term | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211510}} | ||
|title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,632: | Line 2,632: | ||
|what is the recommended way to register new elements at runtime ?I can see that sc::Element is already exposed to Nasal via NasalCanvas.cxx - I have added another _newCanvasElement() member to the canvas namespace, and looking to add a method to expose the std::map with group elements so that new groups can be added. | |what is the recommended way to register new elements at runtime ?I can see that sc::Element is already exposed to Nasal via NasalCanvas.cxx - I have added another _newCanvasElement() member to the canvas namespace, and looking to add a method to expose the std::map with group elements so that new groups can be added. | ||
The main idea here is that I want to be able to extend the core canvas system by allowing custom elements to be prototyped & registered via Nasal (analogous to addcommand() ). According to CanvasMgr this seems to be supported already to some extent ? | The main idea here is that I want to be able to extend the core canvas system by allowing custom elements to be prototyped & registered via Nasal (analogous to addcommand() ). According to CanvasMgr this seems to be supported already to some extent ? | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=209136}} | ||
|title=<nowiki>NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,667: | Line 2,667: | ||
Then one player can be the captain, another one the first officier, and the third one is the flight engineer. Maybe another second officier | Then one player can be the captain, another one the first officier, and the third one is the flight engineer. Maybe another second officier | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270482}} | ||
| title = <nowiki>Global Feature Suggestion for FlightGear: Cockpit Sharing</nowiki> | | title = <nowiki>Global Feature Suggestion for FlightGear: Cockpit Sharing</nowiki> | ||
| author = <nowiki>CaptainTech</nowiki> | | author = <nowiki>CaptainTech</nowiki> | ||
| Line 2,680: | Line 2,680: | ||
The main thing that aircraft developers would still have to do is to create a corresponding "flightrecorder" configuration for their aircraft/cockpit to encode the transmission/update semantics accordingly. | The main thing that aircraft developers would still have to do is to create a corresponding "flightrecorder" configuration for their aircraft/cockpit to encode the transmission/update semantics accordingly. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270498}} | ||
| title = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki> | | title = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 2,694: | Line 2,694: | ||
But under the hood, it is mainly about formaliing state management - which is overlapping with the way the flight recorder has to work, but also the MP protocol. | But under the hood, it is mainly about formaliing state management - which is overlapping with the way the flight recorder has to work, but also the MP protocol. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270526}} | ||
| title = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki> | | title = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 2,714: | Line 2,714: | ||
So we would need both 1) an updated transport/IPC mechanism, and 2) a better way to encapsulate Canvas-based features in a way that properties are the primary I/O means, which is ironically how hard-coded instruments are working already - we are just violating the whole design concept via Nasal currently, which is also making it more difficult to augment/replace Nasal-based components that turn out to be performance-critical. | So we would need both 1) an updated transport/IPC mechanism, and 2) a better way to encapsulate Canvas-based features in a way that properties are the primary I/O means, which is ironically how hard-coded instruments are working already - we are just violating the whole design concept via Nasal currently, which is also making it more difficult to augment/replace Nasal-based components that turn out to be performance-critical. | ||
|2= {{cite web | |2= {{cite web | ||
| url = | | url = {{forum url|p=270526}} | ||
| title = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki> | | title = <nowiki>Re: Global Feature Suggestion for FlightGear: Cockpit Sharin</nowiki> | ||
| author = <nowiki>Hooray</nowiki> | | author = <nowiki>Hooray</nowiki> | ||
| Line 2,818: | Line 2,818: | ||
{{FGCquote | {{FGCquote | ||
|If it's really the amount of property accesses that contribute to the performance issue, it'd be a classical case where a conventional GUI fires a worker thread to remain responsive until all the background work has been proceseed. | |If it's really the amount of property accesses that contribute to the performance issue, it'd be a classical case where a conventional GUI fires a worker thread to remain responsive until all the background work has been proceseed. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=166939}} | ||
|title=<nowiki>Re: Using a </nowiki> | |title=<nowiki>Re: Using a </nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,827: | Line 2,827: | ||
{{FGCquote | {{FGCquote | ||
|This would seem to suggest that, with some changes to the C++ code, we could assemble a canvas tree asynchronously (in the background) and afterwards make it available in the global tree. In that case, it would probably make sense to add a hook to the canvas system to disable its listeners for a certain branch, so that the copy operation doesn't invoke any listeners for any of the added children - and just set a "finished" signal after the copy operation has completed, so that the canvas can "parse" and process the new tree. | |This would seem to suggest that, with some changes to the C++ code, we could assemble a canvas tree asynchronously (in the background) and afterwards make it available in the global tree. In that case, it would probably make sense to add a hook to the canvas system to disable its listeners for a certain branch, so that the copy operation doesn't invoke any listeners for any of the added children - and just set a "finished" signal after the copy operation has completed, so that the canvas can "parse" and process the new tree. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=166939}} | ||
|title=<nowiki>Re: Using a </nowiki> | |title=<nowiki>Re: Using a </nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,854: | Line 2,854: | ||
| I don't think that we need many Nasal-driven elements - the motivation is really just to provide a mechanism so that new building blocks can be directly registered as new elements, which may initially be prototyped in scripting space, i.e. by the MapStructure/ND folks. I am primarily thinking in terms of things like our SymbolCache for now, which would seem like a sure candidate for being re-implemented in C++ at some point. | | I don't think that we need many Nasal-driven elements - the motivation is really just to provide a mechanism so that new building blocks can be directly registered as new elements, which may initially be prototyped in scripting space, i.e. by the MapStructure/ND folks. I am primarily thinking in terms of things like our SymbolCache for now, which would seem like a sure candidate for being re-implemented in C++ at some point. | ||
This would mean that we can prototype new element types, and if/when those are optimized through C++ additions, any back-end code will automatically benefit from such optimizations, without having to be ported, because it already was a proper CanvasElement previously. | This would mean that we can prototype new element types, and if/when those are optimized through C++ additions, any back-end code will automatically benefit from such optimizations, without having to be ported, because it already was a proper CanvasElement previously. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=209136}} | ||
|title=<nowiki>NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,864: | Line 2,864: | ||
|Likewise, our current "SymbolCache" could be registered as a custom NasalCanvasElement, and easily re-implemented in C++ at some point.<br/> | |Likewise, our current "SymbolCache" could be registered as a custom NasalCanvasElement, and easily re-implemented in C++ at some point.<br/> | ||
MFDs are another good example, because page/mode management is one of the most common requirements here, which is explicitly implemented using fairly ugly Nasal code at the moment, but can be trivially expressed through supporting a custom "MFD" element with "page" children (basically groups). | MFDs are another good example, because page/mode management is one of the most common requirements here, which is explicitly implemented using fairly ugly Nasal code at the moment, but can be trivially expressed through supporting a custom "MFD" element with "page" children (basically groups). | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211510}} | ||
|title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,875: | Line 2,875: | ||
The idea is to establish boundaries and interfacing mechanisms, so that things can be easily optimized/re-implemented or replaced once the need arises, without us having to touch a ton of places. | The idea is to establish boundaries and interfacing mechanisms, so that things can be easily optimized/re-implemented or replaced once the need arises, without us having to touch a ton of places. | ||
For example, a simple "animation" element would accept a handful of property events and internally manage timers and listeners - if that shows up as a bottleneck at some point, it can be optimized or re-implemented through native C++ code, without having to change the front-end code. | For example, a simple "animation" element would accept a handful of property events and internally manage timers and listeners - if that shows up as a bottleneck at some point, it can be optimized or re-implemented through native C++ code, without having to change the front-end code. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=211510}} | ||
|title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>Re: NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||
| Line 2,886: | Line 2,886: | ||
Currently, we are implementing animations by using timers and listeners - in the long run, we may want to use SGCondition/SGStateMachine or even some of the AP/PID components to reduce Nasal overhead - thus, exposing a dedicated wrapper means encapsulating things, so that we only have to update a single place then. | Currently, we are implementing animations by using timers and listeners - in the long run, we may want to use SGCondition/SGStateMachine or even some of the AP/PID components to reduce Nasal overhead - thus, exposing a dedicated wrapper means encapsulating things, so that we only have to update a single place then. | ||
We could prototype such things in Nasal and if we find things being too slow, we can trivially update stuff. | We could prototype such things in Nasal and if we find things being too slow, we can trivially update stuff. | ||
|{{cite web |url= | |{{cite web |url={{forum url|p=209136}} | ||
|title=<nowiki>NasalElement vs. CanvasMgr::elementCreated</nowiki> | |title=<nowiki>NasalElement vs. CanvasMgr::elementCreated</nowiki> | ||
|author=<nowiki>Hooray</nowiki> | |author=<nowiki>Hooray</nowiki> | ||