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 punkepanda » Sat Oct 18, 2014 7:49 pm

wlbragg wrote in Sat Oct 18, 2014 6:48 pm:
punkepanda wrote in Sat Oct 18, 2014 6:48 pm:Thorsten is Hi-Jacking the project!

punkepanda wrote in Sat Oct 18, 2014 6:48 pm:...............Hi-Jacking....... in lack of better words :D


First of all; Read what I am saying. Then take some time to think it trough before throwing quick responses..I was slightly refering to an old statement with the "high-jacking". Its not like its something criminal going on here!! lol
wlbragg wrote in Sat Oct 18, 2014 6:48 pm:ALS is the only rendering progress in all of the FlightGear project.

I've never stated he does not contribute to the project, which would be unfair to say. I just dont agree in every way he does it! FlightGear will still move on one way or another and he is a big contributor to that.. In my opinion it would just be more productive and less confusing to make progress on the default scheme than making he's own "fuzzy world" around it.

wlbragg wrote in Sat Oct 18, 2014 6:48 pm: It isn't touching the default rendering scheme.


Yes and that is what i think is wrong!! In my opinion he should continue to improve the default rendering scheme, rather than making a new one overlapping the old, making things dependent on hes layer of code. This is what I mean by hi-jacking..

Because he could maintain the old scheme instead of making an new hype about ALS. (which turns out to be compatible with the default if he wanted it to be). Why the fuzz if it can be activated at runtime.. Which means it mostly compatible with the defaults!!

Its like building a railroad over the old one instead of maintaining it or even removing the rusty ones and start from scratch!! The railroad design is still the same, just a little more shiny, but underneath its a mess!!

Rembrandt is a whole other story. And I dont even think that should be part of the FG at all as it is not compatible with the default. Atleast the whole community should agree to switch rendering engine so aircraft and scenery developers knew what standard to follow on.

In my opinion it should be all about finding a standard and do progress together than splitting it up in layers of confusing rendering standards, making it a nightmare for the community to follow and hard to work with.. Why aircraft developers have to make 3 versions when just keeping it simple for them..
This is probably FG weakest part!!
punkepanda
 
Posts: 234
Joined: Mon Nov 04, 2013 10:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Orbital Makes the Sky Black

Postby Hooray » Sat Oct 18, 2014 9:04 pm

it's software evolution in progress - simple as that. You are witnessing "survival of the fittest" - given Thorsten's track record, his contributions and the time he is dedicating to FG each month, his contributions are undeniably "fit" in contrast to many others that must be considered unmaintained for the time being - no matter what a few people are stating here, especially those without a background in related core development (rendering).

There are a lot of people here making statements that don't have the corresponding background in rendering, but which are still trying to affect the way rendering related development is happening - and all these statements are kinda ridiculous to read unfortunately. There are a few other contributors, including core developers, that don't quite agree with the way Thorsten is developing things - but for completely unrelated reasons, i.e. technical ones. The bottom line is that people want to tell Thorsten how to spend his time contributing to the project, without having a credible background to back up their statements, which is obviously straightforward for Thorsten to tell given his background.
Thus, please don't expect to be taken seriously - you guys are trying to tell someone how to sail a boat who's "circumnavigated the FG world" a couple of times already, and you are lacking any credibility in your statements.

FG has many other "weak" parts - and areas where development is very much alive and kicking, frankly don't qualify as such - you are just stating your own priorities and preferences here, without demonstrating a background that would back up your statements, and this also includes F-JJTH unfortunately.

Many of the issues pointed out by a few users here are beyond user/fgdata space, i.e. need to be tackled at the c++ level first, i.e. involves stuff that Thorsten doesn't touch normally (well, until recently).

Frankly, all this is kinda annoying and makes the forum a very unpleasant place - as many of you will know, I don't tend to automatically agree with everything Thorsten says/does - but in this instance, he's obviously the guy who's shouldering the main load of recent rendering related developments, so people should be prepared to either make a compelling case or be willing to listen and do some reading to actually understand the underlying issue before ridiculing themselves and their reputation around here.

I am not involved in Rembrandt and/or ALS, but I would also only listen to feedback that makes sense, or that is coming from people who have some kind of track record/interest and compelling case - so far, I am failing to see that unfortunately. There's a lot of silly rubbish being spread here - and most of you guys spreading this FUD, wouldn't be taken seriously in a face to face conversation with a developer even just for a single minute. Honestly, you guys are just wasting time and preventing other features from materializing by doing what you are doing here.

And this is frankly one of the weaker points of the project: the pathetic signal-to-noise frequently caused by end-users and even contributors, and obviously also a few core developers/committers. It's this very behavior that is distracting people from creating a better FG. Thorsten is a relatively recent contributor, many others won't even visit the forum, let alone get involved in discussions like these because of all the time wasted here.
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: Orbital Makes the Sky Black

Postby F-JJTH » Sat Oct 18, 2014 11:57 pm

Yeah, you are right... I don't understand anything about how rendering works and I have no clue what is a shader...
Well, that's why I have been able to implement the Skydome for the default rendering scheme, and Rembrandt without destroying ALS:
https://gitorious.org/fg/f-jjths-fgdata ... 0d456d3928

Now that you have the proof that I'm not a total newbie, can I open my mouth ?! Seriously guys... stop to believe that you are the king of the world and that only you are enough smart to understand rendering stuff.
I never claim that I'm an expert, but at least when I read a piece of code I can understand it (yeah it certainly require much more time for me than you, for sure, but NO I'm not silly !)

Can we admit that I demonstrated this "background that would back up my statements" ? Or should I create another rendering scheme named ALS-bis to proove that I understand at least what I am talking about ?
If you ask everybody to have as much knowledge than you before being able to talk with you, for sure the "entry" level is far high.


Regards,
Clément
User avatar
F-JJTH
 
Posts: 696
Joined: Fri Sep 09, 2011 12:02 pm

Re: Orbital Makes the Sky Black

Postby Hooray » Sun Oct 19, 2014 12:23 am

I didn't look at your patch - and to be honest, I feel that I wouldn't be sufficiently qualified to review any shader/effects additions, but based on your statements - you were indeed being silly - as has been previously pointed out. The whole ALS/Rembrandt situation like you have presented it here is just FUD and a huge misinformation campaign in my eyes - and I am afraid that many new users might listen to you and give your comments some weight due to your track record, your forum reputation - and due to the fact that you are meanwhile a core committer.

But please keep in mind that just because we may have implemented a few features in FG, that doesn't necessarily make us experts in all domains of FG/SG - just recall the time when your own patches were critically discussed by other contributors.

I don't consider myself a rendering expert - but I am a little familiar with the way Rembrandt is integrated, and with the way how Thorsten has added ALS - those are two very different approaches with hugely different requirements, and asking Thorsten to handle all the workload required to make features like Rembrandt<->ALS inter-operate properly is simply not feasible - and suggesting something like that isn't just unreasonable it is plain ridiculous: you are claiming that Rembrandt is being maintained by people like you, yet you are referring to a fgdata patch - completely disregarding the fact that Rembrandt is having issues that are completely outside of fgdata space, i.e. in C++ space - especially WRT performance and portability, which are Rembrandt's primary issue - not some arbitrary enumeration of fancy effects.

Again, I am not at all opposed to Rembrandt (or even ALS, or osgEarth) - but certain requests are simply ridiculous - people are constantly attacking power contributors like Thorsten because of their track record and because they are getting feedback from them - without noticing the degree of misinformation they're spreading here to get a little attention by yelling at the wrong guy...

FlightGear is a huge code base and there's not a single guy around who's familiar with all components/code - so it takes different skills and interests to do certain things.

Like I said, I am far from being a rendering expert, but I do know how SG and FG are structured, and I can look at most code to see how it hangs together - your statements (and especially requests) about Rembrandt vs. ALS are plain wrong, if not even ridiculous.

And you are even proving this with the nature of your own fgdata patch, which also doesn't involve any of the $FG_SRC/Viewer logic that contains the meat of the whole Rembrandt challenge - shaders and effects are obviously relevant, too - but those can be easily maintained without dedicated C++ support - like you're proving. Thus, what you are saying is basically this "Thorsten, stop doing what you are doing in fgdata - and do what I tell you to do in Rembrandt/C++ space - and by the way, to back up my statements, see my own fgdata patch - and by the way, don't be bothered by Rembrandt not working well for you... "

Honestly, this is just another "attention junkie" thread where people are trying to yell at some power contributor trying to make someone contribute in a certain way, without rolling up their own sleeves first.

Many of the things that Thorsten is being asked to do here are beyond what he'd usually work with - i.e. in terms of source code and modules. Thorsten has been working with components A, B and C while you guys are expecting him to work with X, Y, Z that may seem related to new users, but that have completely different requirements. While Thorsten obviously has the mental capacity to deal with those things, his comfort zone is clearly elsewhere - just like all of us have our own interests. Please don't just expect Thorsten to maintian all of FG for you, and don't complain that he's "hijacking" FG by adding optional features, that are -by nature- much more optional than any C++ level patch can possibly be.

It is threads like these that make FG a terribly frustrating experience - Sorry, but the 3-4 people around here hijacking the thread (you know who you are) would not be taken seriously on the devel list... and rightly so.
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: Orbital Makes the Sky Black

Postby F-JJTH » Sun Oct 19, 2014 1:13 am

Hooray wrote in Sun Oct 19, 2014 12:23 am:Thus, what you are saying is basically this "Thorsten, stop doing what you are doing in fgdata - and do what I tell you to do in Rembrandt/C++ space"

No I'm not saying that at all.

Similarly, I never talked about
You mentioned things like the maintenance problem for aircraft developers

please use the "find" feature of your internet browser and you will see that I never wrote "aircraft" in any of my post.

So you two make me say what I'm not saying, I know I'm not a native english person but I think I writting fine enough to be understood. So please make an effort and only attribute me what I write here instead of inventing what I never wrote.


And I re write it here again: ALS work is nice, Thorsten is doing nice stuff, there is no doubt on this side and I'm happy with that. But as a "FlightGear contributor" (vs an ALS-only contributor) I would have expected that feature like Skydome is simply replacing the crappy default sky instead of living aside. So in this case there would have never been default + ALS to maintain but only default (being the reflect of Thorsten work which is named ALS as of today).

If tomorrow another rendering contributor come to the community with another idea we will have a fourth framework, and next year another contributor will come with again another idea we will have a fifth framework. Well where are we going if the project goes in this way !? my answer: in the wall.

So again (yes I didn't change my first assumption): instead of dividing FlightGear we would unify it and work all together in order to have 1 good framework instead of multiple piece of framework doing things on their side like a battle. That's really how I see it today and I'm not happy with that.


About C++ side, don't worry about that, in fact I'm far better at playing with OSG on C++ than with GLSL. I have a long standing feature that I'm working on for example:

Image

Image

How many proof have I to bring before having the chance that my opinion is listened ? Do you realize that now it's YOU who are making the entry really high ? some hours ago you was just spotting this point and now you are the one who say "hey boy, shut up, you know nothing about rendering so please go back playing with your toys". That's definitely not how I like to be considered, even regarding my contribution to the project: release process (yeah that's something behind the scene that nobody know but I'm mostly the one who maintain Jenkins job) , fgcom, aircraft, fgrun (even if I'm not a Windows user I'm maintaining the Windows stuff), d&c... well I think I deserve better than your, kind of hidden "shut up and move away, your are not welcome here" message.


So please, stop to believe that I'm ignorant, it's really painful.

Regards,
Clément
User avatar
F-JJTH
 
Posts: 696
Joined: Fri Sep 09, 2011 12:02 pm

Re: Orbital Makes the Sky Black

Postby wlbragg » Sun Oct 19, 2014 4:25 am

Everyone can go on busting each others eggs. But I'm going to try to actually learn something here.

Clément,
I have a long standing feature that I'm working on for example:

Way cool!
Is that something your doing for yourself only or are you planning on sharing it with the community when it's ready?
Is that using GLSL in C space or in fgdata effects space?


Thorsten,
If one was to comment out the predicate
<technique n="8">
<predicate>
<and>
<!--property>/sim/rendering/shaders/skydome</property-->

in skydome.eff
Is that effectively adding the skydome shader to the default rendering scheme or is it just eliminating choosing ALS in the GUI and choosing it before hand?
Is the difference between ALS and !ALS just the ALS switch and the predicate?
If the above is true and you take that a few steps farther and comment out basically every predicate requiring skydome including skydome.eff, have you just moved all of ALS over to the default rendering scheme?

Rembrandt can't be switched runtime

Is that because the GLSL is hard coded into C space VS ALS using the effects framework outside of C space?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Orbital Makes the Sky Black

Postby Thorsten » Sun Oct 19, 2014 7:34 am

Is that effectively adding the skydome shader to the default rendering scheme or is it just eliminating choosing ALS in the GUI and choosing it before hand?


What Clement's shotgun marriage between ALS and default/Rembrandt light and fog model does is the following:

Sunrise scene from 36.000 ft:

Image

After nightfall scene from 36.000 ft:

Image

It gets correspondingly more awful if you reduce visibility and/or LOD range...

How many proof have I to bring before having the chance that my opinion is listened ?


I think your patch about did it for me, thanks... I see now how well you understood my explanations about the need to match light and fog models - see above.
Last edited by Thorsten on Sun Oct 19, 2014 7:49 am, edited 1 time in total.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Orbital Makes the Sky Black

Postby Thorsten » Sun Oct 19, 2014 7:48 am

And while we're at it, here's ALS-rendered trees in default rendered scene, turning some fog on - fog color ain't matching, this is bad - you can see trees in arbitrary distance by virtue of not being drawn in the same fog color:

Image

More subtle, but still sticking out in contrast with the buildings, light colors aren't matching up, default has red specular channel where ALS is dark and diffuse already:

Image

It's kinda easy to make everything match on a clear day at noon, because then ALS and default illuminate everything with white light and the fog is largely gone. Far less so in low light and/or fog where they really differ.


Bottomline: You can't mix different light and fog models. They have to be consistent across the whole scene, at all times, at all altitudes, in all weather. A lesson that was learned the hard way.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Orbital Makes the Sky Black

Postby wlbragg » Sun Oct 19, 2014 8:47 am

Thorsten,
I never doubted anything you have said. I believed you all along. I understand it isn't doing it correctly, I just wanted to know if it was indeed using the ALS shaders in the default rendering mode in those instances. And it obviously is, but it looks like crap.

And so, if you move the ALS shader code and correct it to match skydome and terrain, then you have effectively ELIMINATED the default rendering mode and turned it into ALS. Same difference except in that case you would no longer have the default rendering mode. You would only have ALS. I think I get it.

If I want to to use the tree movement shader code, (or any other for that matter), in default rendering, then I do the pixel math inside the "default rendering" shader using its fog, haze and lighting routines. That would be the correct way to implement it.

I'm just trying to use this as an opportunity to learn more about the subject.

I would still like to know if I have this other question correct.
Rembrandt can't be switched at runtime

Is that because the GLSL is hard coded into C space VS ALS is using the effects framework outside of C space?
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Orbital Makes the Sky Black

Postby Thorsten » Sun Oct 19, 2014 9:42 am

Is that because the GLSL is hard coded into C space VS ALS is using the effects framework outside of C space?


Not quite. Rembrandt has GLSL components (all the *-gbuffer shaders are Rembrandt GLSL code), but Rembrandt needs some additional 'infrastructure' set up - the buffers it renders into being the most important, and a special definition of the sequence of rendering. Such buffers don't feature in a fixed pipeline rendering or in forward rendering. I believe they could theoretically all be set up runtime as well. I don't understand this too well, but I think it's a bit akin to the reset problem in Flightgear - seems easy, but there's a lot of smallprint to consider. It's much easier to create the infrastructure at startup time.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Orbital Makes the Sky Black

Postby wlbragg » Sun Oct 19, 2014 10:30 am

Thank You!
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Orbital Makes the Sky Black

Postby Hooray » Sun Oct 19, 2014 10:44 am

What Thorsten said is correct - 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 - this isn't done in a "plug & play" fashion currently - exposing this to XML/property tree space would be a huge undertaking probably - Zan's "newcamera" work really is the best match here - and RTT/buffer management is exactly what Canvas is already doing under the hood.
Thus, each RTT buffer could simply be a Canvas texture internally - so that all the hard-coded Rembrandt logic could be maintained more easily at some point.

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.
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: Orbital Makes the Sky Black

Postby wlbragg » Sun Oct 19, 2014 11: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
Kansas and Ohio/Midwest scenery development.
KEQA, 3AU, KRCP Airport Layout
Intel i7/GeForce RTX 2070/Max-Q
User avatar
wlbragg
 
Posts: 7586
Joined: Sun Aug 26, 2012 12:31 am
Location: Kansas (Tornado Alley), USA
Callsign: WC2020
Version: next
OS: Win10/Linux/RTX 2070

Re: Orbital Makes the Sky Black

Postby F-JJTH » Sun Oct 19, 2014 12:18 pm

The deferred rendering can't be switched on/off at runtime, but we can switch all buffer on/off at runtime.
It means that you can simply stop to render the shadow buffer, the SSAO buffer, the bloom buffer, the light buffer ... at runtime.

Finally when all these buffer are OFF you have no more no less than the default rendering visual result, but it's done in a deferred scheme.
Ideally Rembrandt should be come out-of-the-box with all these optional buffer OFF (at least that's how I would like it), here all these buffer OFF give me the same visual result than default rendering and the same framerate too.

regards,
Clément
User avatar
F-JJTH
 
Posts: 696
Joined: Fri Sep 09, 2011 12:02 pm

Re: Orbital Makes the Sky Black

Postby Thorsten » Sun Oct 19, 2014 6:16 pm

Finally when all these buffer are OFF you have no more no less than the default rendering visual result, but it's done in a deferred scheme.


Deferred = rendering a geometry pass into the geometry (g-)buffer which holds positions, normals, materials, then doing all operations (texel, light, ...) in fragment passes on that buffer (or any others).

Forward = (usually) rendering part of the shading (typically ambient and diffuse light) per vertex, extrapolate all quantities which are declared as varying across triangles and hand them via rasterizer to the fragment shader which does the rest

The figure of merit is very roughly the ratio of vertices per pixels and the ratio of the vertex pipeline computational power of your GPU over the fragment pipeline. Basically, in a few vertex scene on a large screen forward rendering wins out, in a many vertices scene on a small screen deferred rendering wins out. Thus, getting the same framerate is completely accidential and specific to a particular scene and GPU, the schemes work internally rather different. On my new GPU, I get 60 fps with basic forward rendering because that's vsync and 30 for Rembrandt without any perks, on my old GPU I got 60 fps for simple forward and 10 fps for deferred with all special buffers off - which tells you the new card has better fragment to vertex capabilities.

The decisive thing is interpolation across triangles - if you have a triangle spanning 1000 pixels, you have to compute 3 vertices and get 1000 pixels by very simple interpolation which makes forward rendering appealing. If you have 100 vertices inside a single pixel, you come to the opposite conclusion.

Thus, despite Clement's implied suggestion that they'd appear the same, you never actually transit from a deferred to a forward scheme, which is why you don't have the same baseline internally, which is why you need to structure operations you do very differently and can in general expect a very different performance footprint.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

PreviousNext

Return to Graphics

Who is online

Users browsing this forum: No registered users and 3 guests