Talk:Hackathon Proposal: Shaderbased ND features

Hi, the idea is great (and has in fact been previously discussed on the forum and devel list) - but I would suggest to consider postponing working on this, simply because there is so much related work going on at the moment. Like you said, this would be ideally done by using the Compositor. Since you mention the ND (NavDisplay) specifically, you will probably agree that such a feature would be developed with the Canvas in mind, because that's what non-legacy avionics in FlightGear are using to create such instrumentation. So, this would be best done by extending the Canvas system (as in creating a dedicated canvas element). Namely, by rendering a scenery sub-camera to a texture. Fernando, who has developed the Compositor, also came up with patches to render such a sub-camera to a texture. And he also made quite a bit of progress at the time. However, since then, many things have changed/progressed quite a bit - on the one hand, there's Fernando's Compositor work, and on the other hand there is Jules' CompositeViewer Support effort. Thus, if you are serious about developing this, it would ideally be done in tandem with the Compositor/CompositeViewer efforts, because having those two features in place, will greatly simplify your job. Also, even if you have a working build environment, and even if you have years of professional background in C++/OSG, this isn't something that is prototyped during a single weekend. You only need to look at the time frames involved in the prototyping of the Compositor/CompositeViewer efforts, to see for yourself that such projects aren't delivered in just a few days. If in doubt, it would be best to check back with the developers mailing list, and ask specifically Fernando, Jules and James for their opinions. In the meantime, if you are specifically interested in bringing effects/shader functionality to current and future NDs, the lowest hanging fruit is indeed adding effects support to the Canvas system - which is something that has been previously prototyped, and something that's even be suggested by the creator of the canvas system a while ago: Canvas Development#Effects / Shaders

Realistically, this kind of change is strictly opt-in, and touches less than 50 lines of code - and we've done this previously:

unmodified airport selection canvas with fragment shader applied

All that being said, your idea is indeed good and a long-standing one, too - in fact, even prior to the Compositor framework, people have been wanting to create support for orthographic terrain views, for some pointers to related discussions see the following wiki article (inspired by ideas that TorstenD posted on the forum, which favors an atlas-based approach, because it predates the Compositor by many years): Canvas_Tile_Element

And even aside from the Compositor/Terrain overlay, having effect/shader support per canvas could come in very handy - and it could also speed up rendering, e.g. some senior core devs have been toying with the idea to implement symbol instancing via effects/shaders, i.e. for those maps/charts where hundreds of symbols are drawn - which is currently expensive to do via Canvas, and could become much cheaper if shaders were used instead. Check the archives for comments posted by James or ThorstenR to learn more.

--Hooray (talk) 09:50, 10 October 2020 (EDT)

Well... personally, I was more interrested into the rendering aspect of it as the hackathlon isn't intended to creat fully working features.

If we'd got the effects and shaders done at the weekend, that would be great... even if it just renders it to screen, instead of a canvas.

Obviously, to accomplish this, I certainly need help from someone with experience in shader creation.

At the same time I'm already in the dilema of being really interested in two proposals...

--merspieler (talk) 14:58, 10 October 2020 (UTC)

Again, I don't meant to discourage you at all - but being pretty familiar with the ND/MapStructure and Canvas side of things, I think you'd be well-advised to reach out to Jules and Fernando, because the code that they've recently been sharing with the community makes it really straightforward to "have our cake and eat it". At this point, the main thing we're lacking is an integration between those key components (CompositeViewer, Compositor, Canvas) - once that is in place, you can definitely render a custom camera view to a (sub) texture and use that as a terrain or weather layer. And in fact, psadro_gm (core developer involved in TerraGear) and Stuart have previously toyed with the idea on the forum. For instance, see the following postings/discussions: https://forum.flightgear.org/viewtopic.php?f=71&t=27985&p=264172&#p264175

Note that Pete's original idea is now basically implemented thanks to Fernando's work. What's still missing is integrating Jules' CompositeViewer work, and maybe hooking up the compositor and the canvas again, to create a new Canvas element that accepts an arbitrary compositor to render a sub-scene graph using custom effects/shaders (again, the original idea here was to support custom exterior camera passes to render mirror textures, gear views, tail cams, night vision etc)

If you are primarily interested in working on the rendering side of this, and given what else is already "in the pipeline", the lowest hanging fruit would be adding support for effects per canvas - there are existing code snippets/patches here: Canvas_Development#Effects_.2F_Shaders

Also, since you also mentioned "WXR" overlays, you might want to look up Thorsten's responses in the context of Advanced weather and WXR:

* https://forum.flightgear.org/viewtopic.php?f=30&t=15355

* https://forum.flightgear.org/viewtopic.php?f=14&t=32056&p=313756&#p313756

--Hooray (talk) 11:14, 10 October 2020 (EDT)

Indeed, the timing for this can be a little tricky. Not having CompositeViewer Support is the main showstopper regarding terrain views in cockpit elements. Jules is working on this so we should be seeing progress in this area quite soon. If you don't mind using Jules' fork, then I guess it should be possible to start work on this, although he has mentioned that he doesn't deem the effort production-ready just yet. I'd recommend to postpone this until every "ingredient" is ready.

Icecode (talk) 15:34, 11 October 2020 (EDT)

Well, just today, Jules has posted an update to the devel list: https://sourceforge.net/p/flightgear/mailman/message/37126783/

The summary is that he's made a lot of progress over the last couple of weeks, and that he's basing his work off Compositor support - however, he ran also into issues related to OSG 3.4, issues that are solved when using OSG 3.6 - that, however, brings with it other issues - namely regressions in the osgtext department. James stated quite clearly that there are some MacOS/Compositor and osgText issues that needs to be fixed first for the Compositor/CompositeViewer work to land in next. In other words, it seems unlikely that working on this particular idea is going to be particularly fruitful - at least not for the time being. --Hooray (talk) 16:00, 11 October 2020 (EDT)