Board index FlightGear Support Graphics

Orbital Makes the Sky Black

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Re: Orbital Makes the Sky Black

Postby Hooray » Sun Oct 19, 2014 5:21 pm

it is like Thorsten said already - the situation isn't unlike any other subsystem lacking dedicated reinit support - Rembrandt pre-dates the whole reset/re-init effort by several years, and while SGSubsystem does provide the corresponding interfaces to be implemented by each subsystem to handle simulator resets, our rendering system isn't a conventional SGSubsystem - equally, all the CameraGroup stuff has become fairly massive meanwhile.

It is definitely possible to implement dynamic reset/re-init even for the renderer, including all buffers and windows/views - Zan's work still is the most promising effort in this department.

But that, too, predates the whole Canvas effort.

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.


Internally, FG doesn't usually use the C/C++ APIs for GLSL directly, but uses the OSG abstraction layers instead (which are fairly well documented, even for people new to shaders).

The "obscure" parts of Rembrandt are not necessarily its effects or shaders, but the underlying C++ code which sets up all the buffers and sequencing. Once that is either documented or exposed, it is foreseeable that deferred rendering will be resurrected again, even if FredB should still not be around - such an effort would not need to involve Zan's work or Canvas, but it would be the most logical step for the time being, absent some other overlapping development effort.

But as has been said by a number of people already, doing all the integration work can be really tedious and frustrating.
Last edited by Hooray on Sun Oct 19, 2014 6:37 pm, edited 1 time in total.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: Orbital Makes the Sky Black

Postby wlbragg » Sun Oct 19, 2014 5:51 pm

So Rembrandt is in FG C space?
Most other GLSL routines including those passed through "effects" are being passed to the OSG abstract layers?
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4808
Joined: Sat Aug 25, 2012 11:31 pm
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Debain/nVGT640

Re: Orbital Makes the Sky Black

Postby Hooray » Sun Oct 19, 2014 6:33 pm

It basically works like this:

  • FlightGear contains an effects subsystem that integrates shaders + properties and materials (=textures)
  • the effects subsystem is using the OSG abstraction layer for GLSL like you say
  • FlightGear itself has all the viewer/renderer logic in $FG_SRC/Viewer
  • Rembrandt needs buffers set up, initialized and updated beyond what's possible via fgdata-space additions, such as Nasal, effects, shaders
  • this is why FredB took the existing "fixed pipeline" code and adapted it to set up a bunch of buffers for all deferred rendering stages
  • and then, a few hard-coded shaders are/were associated with some buffers
  • incrementally, Fred then started to adopt the effects subsystem to move hard-coded shaders out of C++ into $FG_ROOT (fgdata)
  • thus, Rembrandt does indeed uses effects and shaders primarily now - but all the setup/init and update logic still resides in C++
  • many of the performance implications associated with Rembrandt were linked to its C++ code
  • people primarily doing fgdata-level effects/shader development are thus in an exceptionally bad situation to help improve/maintain Rembrandt, because the whole integration is not sufficiently documented, and it can really only be changed via C++ additions.
  • we've seen other C++ patches rejected, despite the corresponding subsystems having active/involved maintainers
  • several core developers have repeatedly stated that they won't target/support Rembrandt due to its known performance implications
  • in its current form, the setup/init logic isn't designed to be dynamically adjusted, i.e. many attributes are not yet exposed to properties/listeners, or only read during startup
  • this is a common trait of C++ code that didn't quite progress beyond "prototyping" - it took Zakalawe almost 2 years to implement reset/re-init support in its current form

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.

For a WIP-intro, refer to: http://wiki.flightgear.org/The_FlightGe ... g_Pipeline
(contributions/feedback appreciated !)

Now, regarding Canvas and effects/shaders - we do have patches prototyping this to some degree - the main thing missing is integration obviously. For a summary, see: http://wiki.flightgear.org/Canvas_Devel ... 2F_Shaders
To render fully-independent scenery/camera views to a FBO/texture (Canvas), we'd need to use OSG's CompositeViewer: http://wiki.flightgear.org/CompositeViewer_Support

For a summary of the whole cameras vs. canvas discussion, see: http://wiki.flightgear.org/Canvas_Devel ... ng_Cameras

wlbragg wrote in Sun Oct 19, 2014 10:06 am:
it's all the init/setup code that is hard-coded, and which used to contain a few hard-coded shaders - those are basically different rendering buffers that are chained together to set up a deferred rendering pipeline

I have experience with GLSL in this fashion. I know what goes into setting up the rendering pipeline in the C source. That is why I was surprised and impressed when I saw that FG developers set it up to allow for XML configuration. I have yet to look at the C code to see how they tied it all together. But I am impressed without even seeing it. It really is a ingenious way to handle it. I'm would be willing to bet you could design and load the deferred rendering pipeline in a similar fashion


This is why I gave certain pointers already - that is exactly what Zan's code is doing:

https://www.mail-archive.com/flightgear ... 36480.html

Both, Fred and Mathias, seemed pretty eager to adopt Zan's work back then:
https://www.mail-archive.com/flightgear ... 36481.html
https://www.mail-archive.com/flightgear ... 36486.html

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.

I am not talking about Rembrandt and/or ALS in particular here - I am just seeing the main challenge being the lack of accessibility when it comes to required structural changes to the C++ code - regardless of the concrete renderer - the lack of Rembrandt maintenance, and the slow response whenever ALS requires C++ level changes, is primarily because the corresponding renderer code is not being maintained actively - moving this into fgdata space via effects and shaders is a logical thing to do, and will allow people like Thorsten (or yourself) to make corresponding modifications without facing a core development bottleneck when it comes to Rembrandt/FGRenderer or any other $FG_SRC/Viewer modifications.

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).
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Graphics

Who is online

Users browsing this forum: No registered users and 1 guest