Board index FlightGear Development Canvas

Gear view in cockpit computer

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: Gear view in cockpit computer

Postby Hooray » Sat Aug 26, 2017 11:30 pm

Well, this is going to be very offoptic, so please bear with me, anyway:

I don't disagree that, in a perfect world, things would be the way you say - in reality however, it's not such a "black and white" thing unfortunately.
Equally, like I recently said in another topic, there would be no need for unfinished, outdated and especially quote-based wiki "articles" if people implementing new features would also write the corresponding documentation (think the Nasal flightplan APIs).

That being said, I have contributed to the wiki long before it was "official", and long before it was used by "the team", i.e. back when it was actually used primarily by other contributors interested in helping document things, and that included adding, and often also writing, documentation that simply existed nowhere else, or "documentation" and "advice" that was only provided in the form of discussions on the devel/users mailing lists.

None of this is to say that I disagree with any of what you said, but I don't see it as a clear-cut thing unfortunately - which would be hugely different if the people implementing features would also automatically document them, even if just in the form of corresponding "*.README" files in $FG_ROOT/Docs (which was the predominant practice in the early days of the project).

However, that is no longer the case, and it took basically the better part of a decade for the project (well, some of the team) to actually "adopt" an issue tracking system and a modern SCM - with this context in mind, it does make sense to use the wiki in this way, because it simply works. Without doubt it would be better to organize the wiki accordingly, but that is not a difficult thing to do, and it can even be done by people not interested in helping write/maintain the wiki. So, feel free to "be the change you want to see". Categories, and even portals, are "cheap" to do after all.

But again, this discussion is very much offtopic, and we've had this discussion more than once, "cleaning up" the wiki to move unfinished articles to a different category is not exactly rocket science either. it's just not something that I am currently prioritzing, and certainly it also isn't something that I am going to prioritize as long as I find myself having to add information to the wiki that would otherwise be lost in the depths of the archives, because the people implementing new functionality don't have the time, or the inclination, to add dedicated docs.

Thus, this is more of a chicken/egg issue than most people realize: The wiki could certainly be in a much better shape if people were documenting their efforts, especially finished features, much better - no matter if that means using the wiki or not. Using its state as a mere excuse for not getting involved in documenting new, or recent, additions is very much pathetic at best, especially in the light of the project's tradition to commit dedicated feature.README files to $FG_ROOT/Docs pretty much since the beginning of the project.

And to be honest, I'd rather not have this discussion here and now, because there's nothing that I fundamentally disagree with, I am well aware of the general standpoint, but as long as there is such an enormous disparity between documented and undocumented features/contributions, without anybody willing to do something about this, I am seeing a need for a workaround, even if it's a poor substitute for proper documentation.

Ultimately, it all boils down to trying to be a part of the solution rather than the problem - as someone who's literally spent hundreds of hours adding relevant contents to the wiki to cover features that would otherwise not be documented anywhere, I feel that my perspective is more than justified. Nevertheless, I am certainly not going to write proper articles for each and every undocumented/updated feature that I am aware of. What I am doing, and how I am doing it, is a feasible compromise without causing tons of work, and that includes adding contents that cover discussions or work-in-progress features. Not because I think it's such a great idea, or experience, to do so - but because I actually saw, and am seeing, it work out reasonably well, given a sane time frame.

Obviously, YMMV - but this whole project being a community driven project, it is obviously up to you (and everybody else) to disagree with developments, features and also documentation/articles and provide a compelling alternative, i.e. something that just turns out to be much "better". At that point, what will usually happen subsequently is that your contribution is superior, and going to help deprecate/phase out the legacy contribution.

As a matter of fact, many of the most compelling features, including some aircraft/cockpits, came to be due to a certain degree of "disagreement" with the way someone else handled something, I think we're all aware of the history of the shuttle effort, and the irritation that caused at some point - yet, we're once again seeing "survival of the fittest".

In other words, if you -or anybody else- should come up with something "better", please be my guest, and I'll actually applaud any efforts to remove quote-based articles and/or articles merely covering proposals. But for the time being, I ain't see that happening (unfortunately).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby Alant » Sat Aug 26, 2017 11:43 pm

All is OK with me. It seems that we have no ideological (sorry - long word) disagreements.

I will add some notes to the wiki about this development.

If I am sufficiently self-organised, I will update ( or delete) my wiki notes when anything changes.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Gear view in cockpit computer

Postby Hooray » Sat Aug 26, 2017 11:56 pm

Well, trying to get back on topic, what would actually be helpful is if you could try customizing a cockpit panel to show several independent instances of the same instrument using different views - maybe even using a separate panel with just the "camera-display" gauges. The point being that this would tell us if multiple/independent instances actually work or not (which is a requirement for anything involving the Canvas system), and having one or two screenshots showing a custom panel with 3-4 "camera-displays" displaying different views would also show the potential of the approach, as well as make it much more obvious what this is about.

My suggestion would be to add this to an aircraft with an actual tail-cam or something like that -even though a simple/subset panel may make things easier to recognize.

My thinking here being that having such screenshots would help us getting more people involved, especially those interested in tail-cam like functionality, i.e. those who previously asked about this feature here on the forum.

For starters however, modifying the ufo/ogeL should do to show different cam views without causing tons of work.

Let me know if you're getting stuck or need any help to see if this works
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby Alant » Sun Aug 27, 2017 12:08 am

The changes on the aircraft side are quite trivial. I will try to document them.

At the moment sticking to a single camera view is probaly best. Multiple cameras can come later.

Alan
Alant
 
Posts: 1219
Joined: Wed Jun 23, 2010 6:58 am
Location: Portugal
Callsign: Tarnish99
Version: latest Git
OS: Windows 10/11

Re: Gear view in cockpit computer

Postby Hooray » Sun Aug 27, 2017 12:19 am

I realize that the -set.xml/cockpit panel changes are indeed trivial, it's really just instantiating the class.
Like I said, I looked at the code - /instrumentation/cockpit-display should show additional numbered nodes, and each should support:

- enabled
- name
- number
- view-number


Documenting the required XML to add this to a cockpit panel seems like a good idea to lower the barrier to entry for those wanting to tinker with this - what may look trivial to you, may seem very complicated to others, including possibly people able to write C++ code. For instance, I have never done a single cockpit panel, let alone an FDM or 3D model - so while I do know how to make this show up, it's only because I know how to read the code, and because I originally helped add the instructions to the wiki - other than that, I am not very familiar with the steps required for cockpit building, let alone aircraft development as a whole.

Bottom line being that different people bring different skills and expertise to the table, and under perfect circumstances, people realize that they can mutually augment their capabilities by sharing their knowledge in a public way that can be easily replicated and eventually also edited/maintained by others.

Anyway, the point of my request was that I am currently not in a good position to patch/rebuild fgfs and actually test the patch, despite knowing how to add the instrument to a panel ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby Hooray » Sun Aug 27, 2017 12:30 am

I have updated the wiki to add the XML markup required to make the instrument show up, feel free to review/improve: http://wiki.flightgear.org/Canvas_News# ... ve_Cameras

At the moment sticking to a single camera view is probaly best. Multiple cameras can come later.


In general, I do agree - at least we should wait until the flickering/jumping is fixed.
However, it does help to know if multiple cams work already or not, as the two problems may be related.
Equally, it would be good to know if there is less flickering/jumping if the same view is being shown as in the main view.
This helps us troubleshooting the problem and excluding certain factors

EDIT: I have documented the required code changes to add a new Canvas element inheriting from Canvas::Image to illustrate what is necessary to integrate Clement's groundwork with the Canvas system, I also sent out a few PMs to people who previously stated that they'd be interested in this kind of functionality, so let's see what happens next :D
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby icecode » Mon Aug 28, 2017 10:40 pm

Image

Quick and dirty integration into Canvas. The image is mirrored because of different coordinate systems. Apparently the missing piece was to use FG's view manager. Maybe the view manager could be moved to SimGear so all the infrastructure could be accessed better by Canvas. Who knows, with cleaner code and some tweaks we could have a deferred renderer and RTT capabilities in Canvas space, as long as the effect framework can access these RTT contexts, as Hooray proposed multiple times. I'm still skeptical about it, since rendering as a whole is delicate and Canvas may introduce several inconsistencies.
icecode
 
Posts: 708
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Gear view in cockpit computer

Postby Hooray » Tue Aug 29, 2017 4:28 pm

Hi, just briefly - you don't need to move the view manager to SimGear to accomplish this - like I mentioned previously, the correct way to access FG-level subsystems via the Canvas system is to review/extend the FGCanvasSystemAdapter to expose the corresponding APIs.

I actually posted code snippets that illustrate how to do this, for example in the 3D model loader, specifically look for the FGCanvasSystemAdapter changes in both $FG_SRC and $SG_SRC

There is step by step instructions which can be found here: http://wiki.flightgear.org/Howto:Extend ... temAdapter

In other words: Any API that you need to access from the Canvas system would need a correspondinger "getter" added to retrieve the handle from the FG host application.
And that should be reflected in the header file

But the implementation would reside in $FG_SRC/Canvas/FGCanvasSystemAdapter.cxx - the SimGear code would only have a copy of the corresponding header file.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Postby Hooray » Thu Aug 31, 2017 6:12 pm

This is just to provide a little update for those not following our wiki updates: We've been talking behind the scenes about integrating F-JJTH's groundwork with the Canvas system to come up with a dedicated "View" element that would render arbitrary viewMgr views to an offscreen texture - and Icecode_GL actually prototyped the whole thing. As can be seen, it's basically working - there are really only two minor issues remaining (e.g. the skydome isn't currently added, probably due to us using the wrong root node or missing some effect/shader).

For now this is pretty compelling actually - using Clement's approach, the code boils down to roughly 20 lines of C++ code added to the ~100 LOC of boilerplate code needed for any new Canvas element, and the Nasal code to set up such a view is basically 10 lines of code only.

That being said, it would obviously be great if we could get more people involved to help with testing/debugging this - ideally people able to patch/rebuild FG from source.

The interesting thing to note is that the colors don't seem to be wrong (unlike the screenshots using Clement's original prototype, whereas his code gets the skydome right):

http://wiki.flightgear.org/Howto:Canvas ... nt#Gallery
Image

Image

So, for the time being, this is merely to post an update and hopefully get more people interested in helping with this, in one way or another - otherwise, these patches may linger around on our hard disk for another couple of years, so it's all up to those interested in tail-cam like functionality, which is why it'd probably be a good idea to review the number of aircraft missing this feature currently, and reach out to the corresponding aircraft developers to see what they can bring to the table in terms of skills.

As a matter of fact, too bad that the IAR80 is unlikely to have a tail-cam, or we could be consulting back with i4dnf for the skydome/effects stuff ;-)

In the meantime people may want to spread the word to make sure that this won't take another 12 months before we re-discover these patches.

Finally, using this new Canvas::View element, it would also be possible to implement a fully runtime configurable view manager front-end that would allow people to create/maintain and manage arbitrary "views" using a GUI dialog featuring a preview. If someone able to patch/rebuild from source would be interested in exploring this, I would be more than happy to provide code snippets and pointers to get this going, because I think this could be a great asset, and a good non-aircraft use-case for this work.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby www2 » Thu Aug 31, 2017 9:18 pm

i have a question can you an option to add for using an custom shader/materials, disable objects?
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: Gear view in cockpit computer

Postby icecode » Thu Aug 31, 2017 9:59 pm

About disabling objects, choosing which objects of the scene graph get rendered is a contemplated feature.
And about custom effects/shaders, what do you exactly mean by that?
icecode
 
Posts: 708
Joined: Thu Aug 12, 2010 1:17 pm
Location: Spain
Version: next
OS: Fedora

Re: Gear view in cockpit computer

Postby Hooray » Thu Aug 31, 2017 10:21 pm

As far as I am concerned, I think we should prioritize getting the viewMgr-based CanvasView element finished "as is", without any additional features other than what Clement prototyped last year. Once that is working sufficiently well, we can certainly revisit extending either CanvasView element, or providing a more flexible/better customizable version of it.

For instance, another long-standing feature request related to, and even blocked by, this would be "synthetic terrain" view, which is more and more commonly found on modern PFDs/avionics:

Synthetic terrain
Image

As can be seen, there is a certain number of features, and aircraft that are likely to benefit from this development.

In this particular case, we'd need to be able to register osg::Switch nodes to disable optional stuff like clouds/weather, and apply custom texturing.

In my opinion, it would actually be great to reach out to the developers/maintainers of such aircraft to get them involved in testing, debugging and refining/extending this feature, so that it better matches actual requirements.

That being said, there are certain features that would be more complex, such as implementing mirror-textures, i.e. flipping the image - and I think that even just getting the CanvasView element fininshed, debugged and reviewed/committed would be a huge improvement.

Then again, if you care about this development, or if you know someone who cares about this, please do make sure to get in touch so that we can incorporate such feedback, and ideally even get more people involved in this - like I mentioned over the course of the last 5 years: the code base clearly has all the pieces available, it's primarily an integration thing - and for something like this to take basically the 5+ years is not necessary at all.

You only need to look at the wiki, that this is a long-standign feature request, even pre-dating the Canvas system in its ccurrent form.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby stuart » Fri Sep 01, 2017 7:38 am

Hi,

I'm happy to review any patches and get them committed. Please ping me when you think the code is worth checking in. It doesn't have to be perfect - Particularly once the current release is out.

-Stuart
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1629
Joined: Wed Nov 29, 2006 10:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: Gear view in cockpit computer

Postby Hooray » Sat Sep 02, 2017 11:36 am

Stuart, thanks for offering to help with getting this reviewed.
As far as I know, the only remaining issue is that we explicitly need to .update() the element, even though the element's update() method in C++ should be updating the texture accordingly. Apart from that, it's working as expected - it's probably a minor thing that we're missing, to be honest I don't recall having that problem with any of the other elements we came up with (e.g. the 3D model viewer or the PDF viewer)

Besides, I do think that this work would nicely fit into the bigger picture of supporting G1000-style avionics built in Canvas space, as more and more PFDs do render some kind of synthetic terrain view - for example:
Image

Image

As has been mentioned previously, once this new element is added, we will need to revisit the whole idea to also support custom shaders/effects to customize the appearance of the display, as well as support draw-masks (osg::Switch nodes) for things like the skydome, AI objects, 3D models, random buildings etc - so that these can be specifically excluded in such "views", while a proper tailcam would obviously still want to render those - so we need to make this configurable per view element
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: Gear view in cockpit computer

Postby www2 » Sat Sep 02, 2017 6:02 pm

I have current problems adding the patch to FGROOT (api.nas)
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests