Board index FlightGear Development Effects and shaders

getting started with RTT  Topic is solved

An exciting "new" option in FlightGear, that includes reflections, lightmaps, the particle system etc.. A lot is yet to be discovered/implemented!

getting started with RTT

Postby cyrfer » Thu Oct 05, 2017 6:23 am

Hi! I am wondering how to get started implementing some ideas I have for ways to render the scene. I am competent with C++/OSG/GLSL but I am new to FG.

Some things I know I will need to understand are:

1. how to filter the scene elements to prevent some objects from being rendered? For example, I want to remove all of the ground and sky, rendering only aircraft.
2. how to change the shader used to render aircraft? At program start, but dynamically would be ok too.
3. how to render the scene to a texture?
4. how to create and dynamically update a custom texture's memory?
5. how to run a composite pass sampling from the scene texture and the custom texture?

Do I need XML, Nasal, C++, or some combination of these? I plan to develop on Windows, Linux, and Mac.

Thank you for any advice!
Posts: 4
Joined: Thu Oct 05, 2017 6:02 am

Re: getting started with RTT

Postby Thorsten » Thu Oct 05, 2017 7:10 am

May I suggest to start small, read what the wiki has to say on effects and shaders and look into how a particular aircraft implements it? And then go from there?
Posts: 12000
Joined: Mon Nov 02, 2009 8:33 am

Re: getting started with RTT

Postby cyrfer » Thu Oct 05, 2017 7:19 am

I've been digging, and starting small is exactly what I want to do.

It really helps to have someone point in the right direction when reading tons of documentation.

What I THINK is the closest thing I've found to the most basic way to customize the rendering is a git diff pasted into in the wiki, which is not ideal. Can you confirm or point to something more useful?
`diff --git a/simgear/canvas/elements/CanvasView.hxx b/simgear/canvas/elements/CanvasView.hxx` ... ra_Element
Posts: 4
Joined: Thu Oct 05, 2017 6:02 am

Re: getting started with RTT  

Postby Thorsten » Thu Oct 05, 2017 7:25 am

Look, the problem here is - you're making your first post along the lines of 'I'd like to rewrite the FG rendering framework - can you tell me how to do that?'

The correct answer to that one is - read any existing documentation on effects and shaders and then go through the rendering code. Since you didn't tell us what exactly you have in mind, you can't be expected to be pointed into the right direction - you're asking for basically a broad overview over everything.

There's specific documentation on the wiki how to apply effects to aircraft, on how the effect framework works and these things and if I enter 'Flightgear wiki effect' into google, I'm immediately getting relevant links in the first three spots for instance - this might be a valid starting point.
Posts: 12000
Joined: Mon Nov 02, 2009 8:33 am

Re: getting started with RTT

Postby stuart » Thu Oct 05, 2017 9:35 am

Hi cryfer,

What might not have been obvious from Thorsten's post is that "Effects" are the name of the FlightGear component that provides shader definition and integration with models and the scenegraph.

Using Canvas is one approach for customizing the rendering, but may not be quite what you're looking for. I'd suggest reading the wiki as Thorsten suggested, and then looking at the simgear/scene/ source code to see how Effects are integrated and how the scenegraph is built.

User avatar
Posts: 1588
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: getting started with RTT

Postby erik » Thu Oct 05, 2017 10:41 am

There is the fgviewer utility (which can be found in flightgear/utils/fgviewer) which does basically what you want but without calling the FDM and such. That may be a decent start.

Posts: 1791
Joined: Thu Nov 01, 2007 1:41 pm

Re: getting started with RTT

Postby Icecode GL » Thu Oct 05, 2017 2:55 pm

I've been quite interested in this subject lately. I've exchanged several PMs with Hooray on the matter, who has been proven to be very helpful when it comes to Canvas.

Rewriting the FG rendering framework is not an easy task but it can be done. In fact I think it can be done much more easily than the Canvas implementation a few years ago.

Hooray initially wanted to base the entire rendering framework on Canvas. If you dig deep enough and are familiar with OpenGL/3D rendering as you say, you'll quickly find that Canvas doesn't provide enough flexibility to do that. Instead, we can base the rendering framework on the property system via PropertyBasedElement. It would feature a fully configurable pipeline based on RTT, of course allowing direct forward rendering without any RTT if you so desire. I've been calling it the "Compositor". It'd be node based, heavily inspired by Blender, Ogre3D and other modern game engines. For shader support it'd use the current effects framework, and to display stuff on the screen it'd either use Canvas or a OSG window directly.

If you are interested feel free to contact me so I can share with you some code and pointers/ideas that I've been collecting along the way. I guess that'd be better than starting from zero. :)
Icecode GL
Posts: 640
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Fedora

Re: getting started with RTT

Postby Hooray » Sat Oct 07, 2017 6:12 pm

Hi & welcome,

regarding your questions (actually, only #3 and #4) - the patch you have found is experimental, it will basically look up a view and dynamically add a slave camera to the renderer that renders the whole thing to a Canvas, a Canvas is a fancy word for a RTT/FBO context in FlightGear that can be updated by using a property-based API built on top of the property tree in the form of events/signals that are represented via listeners.

Which is to say each Canvas has a handful of well-defined property names (and types) that it is watching to handle "events" - think stuff like changing the size/view port etc. And then there is a single top-level root group, which serves as the top-level element to keep other Canvas elements.

A Canvas element is nothing more than a rendering primitive that the Canvas system can handle - e.g. stuff like a raster image can be added to a Canvas group, a text string/font, and 2D drawing primitives in the form of OpenVG instrutions mapped to ShivaVG. And that's basically about it (with a few exceptions that handle use-case specific stuff like 2D mapping/charts).

Apart from that, the main thing to keep in mind is that a Canvas is really just a FBO - i.e. an invisible RTT context - to become actually visible, you need to add a so called "placement" - this tells the rendering engine to look up a certain canvas and add it to the scene/cockpit or the GUI (dialogs/windows).

So far, all of this is handled using native code that watches the global /canvas tree in the property tree - there is a canvas manager that handles events and passes them onto the corresponding canvas instance and its child elements.

Realistically, all Canvas textures are however instantiated/updated using scripting space hooks that end up writing to the corresponding properties in the global property tree, this makes it much easier to manipulate a canvas/element, because you don't need to do any low-level getprop/setprop stuff, but can directly use an element specific API.

Like Stuart said, by default (without any patches applied), the Canvas pointers you have found are unlikely to be relevant "as is".

What is most relevant are the pointers to effects and shaders. An effect in FlightGear is basically a set of XML files using the PropertyList format that is processed by the FlightGear/SimGear effects system to map effects to shaders using an inheritance mechanism, conditions and of course properties.

Someone with your background, i.e. familiarity with C++, OSG and GLSL would undoubtedly benefit from the pointers that Stuart posted, in addition I would strongly suggest to get in touch with Icecode_GL, but also read up on Zan's newcameras effort - which was basically pre-dating Canvas/Rembrandt (deferred rendering), but Zan created an XML-configurable rendering pipeline by extending Tim's original CameraGroup/effects groundwork.

And that's probably the other most relevant pointer in the context of modifying the hard-coded rendering pipeline: CameraGroup and $FG_SRC/Viewer - to make heads and tails of it, you will want to look up README.multiscreen and look at $FG_SRC/Viewer

And maybe read up on how Rembrandt (deferred renderer) relates to all of this (or not). ... ultiscreen ... aGroup.cxx ... rc/Viewer/ ... ameraGroup

The Canvas system however is currently constrained to being 2D specific, i.e. to be useful for any of the "3d scene" stuff you're interested in, you'd need to read up on adding new/custom elements - e.g. those useful for 3d stuff, and effects/shaders specifically.

As Icecode GL mentioned, this is something that he's been tinkering with lately. Like he also mentioned, based on Zan's groundwork (newcameras), we are looking at exposing a similar degree of flexibility via the Canvas system by introducing new elements and/or additional "modes".

For starters, this will probably only involve a new view-manager based Canvas view to render a slave scenery view to a Canvas texture. The next incarnation may include effects/shader support to customize such a slave view.

Besides, it would also be possible to render a totally independent scene/osg::Node - which is something that we once prototyped to load 3D models from disk and rotate/transform those using an osg::PositionAttitudeTransformMatrix ... _3D_models

The wiki also contains experimental patches demonstrating how effects/shaders could be enabled: ... 2F_Shaders
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,
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Posts: 12167
Joined: Tue Mar 25, 2008 8:40 am

Return to Effects and shaders

Who is online

Users browsing this forum: No registered users and 3 guests