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 F-JJTH » Fri Oct 17, 2014 6:42 pm

I never claimed that "ALS (or Rembrandt) has to go".
As I said I prefer that existing stuff are improved.
Concretely, instead of creating another rendering scheme (ALS) I would largely prefer that all your stuff are going in the default rendering scheme in an optional way.

Finally instead of choosing between default vs ALS vs Rembrandt, our users just need to move a slider who fit his hardware capabilities.
But instead of adding an optional feature to the default rendering scheme you chosen to create another rendering scheme. That's where I disagree with the way you contribute to the project.

I want to be clear: I like the beautiful sky available in ALS, I like the nice fog effect in ALS, I like the improved scenery contrast in ALS, I like the trees moving depend on wind. All your addition are cool and nice to have. But I also like the nice SSAO of Rembrandt, the great shadows and all these dynamics lights who reflect on the water, the bloom effect in illuminated cockpit.

Unfortunately I have to choose between all these eye-candy because some are not compatible together.

Taking a famous sentence: I Have A Dream ! Where a slider give me the possibility to have the default rendering scheme when I set it to 0, and all Rembrandt+ALS eye-candy when I set it to 10.
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: Orbital Makes the Sky Black

Postby wlbragg » Fri Oct 17, 2014 7:15 pm

There needs to be a point of clarity here.

First we need to drop the terms Rembrandt and ALS. These are terms the developers chose to give their projects. It is "deferred rendering vs "direct rendering". Both project are using the same hardware and software. They are using the same math. They are both manipulating simulated light. They are both using OpenGL/GLSL. They are completely compatible with each other.
They are the same thing done using different buffers at different points in rendering pipeline time and with different amounts of stages, for lack of a better term.
We're talking green apples vs red apples, not apples vs oranges.

You could in fact take lots of the procedural texturing code and it would run


There is no such thing as 'exposing' things to a different renderer. You have to copy a few blocks of code over and integrate them


Everything Thorsten is doing can be implemented into Rembrandt, it would be nice for the "deferred rendering" users if he did. But the time taken for him to do that would take away from the techniques he is developing and introducing us to. ANYONE can put it into the deferred rendering stage. Right now only Thorsten is creating these techniques. Both of these methods, documented or not, are standard ways of manipulating rendered data and are well documented elswhere. It's the math routines that is the real genius to what is being done in both methods, The rest is just OpenGL/GLSL methods.
There should be no argument here. Just developers trying to put it all together or not. Right now not, because "deferred rendering" doesn't work for a lot of users in this case.

Side note: I quit using the deferred rendering pipeline because the tower light beams didn't work. That was enough for me. I remember at the time when I asked the question about it that it was one of those answers that left me less than hopeful that it was anything that was going to be addressed anytime soon.

So there are many reasons one chooses which way they want to go. Same thing for tg win vs linux.
I know one thing, more choices are better. Now that I understand how things get done on this project it's no skin off of one shoulder if they aren't the ones supporting something and they are free at anytime to choose not to support something. There is never a good reason for eliminating someones choice.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4685
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 » Fri Oct 17, 2014 8:43 pm

@F-JJTH: You are still misunderstanding what the main problem here is: it is lack of integration, i.e. different development paths not being sufficiently, let alone properly/fully, integrated - so this has nothing to do with GLSL/effects or Rembrandt in particular. Doing proper integration/development does take a lot of time and energy, and obviously skills and expertise. What we are seeing is people less-familiar with a certain part of the code (e.g. rendering) asking those few doing the actual coding, to make things work together - despite those other features being de-facto inactive for the time being, and for the last couple of years. Which obviously begs the question if, and how/why, someone interested in a particular feature should be forced to pick up some unmaintained, and scarcely-documented- piece of code and continue its maintenance/development.

Also, please keep in mind that FlightGear development pace is generally very slow - so what we are seeing is software evolution at work - i.e. "survival of the fittest". And for a feature to qualify as "fit", it must obviously be sufficiently fast and documented, as well as either sufficiently mature/complete, or have some manpower associated with it, so that it can be improved over time.

Features can be stalled from a development standpoint and still survive, and even continue to be widely adopted by others - but for that to happen, its original developers must document it really well and make it sufficientl extensible, just look at the XML/property tree code, the Nasal engine or even the windows/effects code - this very code hasn't been touched by any of its original developers in years, but still, those are the very same pillars of the FlightGear architecture that people are using every day - and even Canvas development is currently not as active as it used to be a few months ago - yet, people are adopting, and using, it every day.

And Canvas is another excellent example for the dilemma that Rembrandt is facing: we've been wanting to support dedicated camera/sub-cameras passes for years, and it was thanks to Zan's work that this became possible a while ago, but all of the main rendering guys back then (Mathias, Tim and Fred) were completely unaware of this work, despite agreeing that they wanted to see this integrated - so Rembrandt pre-dated Zan's work. And equally, some of the features implemented in other areas of FG would be better implemented by adapting Zan's code, which is something that Zan, Fred and Mathias agreed on back then. Yet, so the problem is not lacking an agreement, it is having someone to do the integration work.

Likewise, Canvas got implemented despite making a number of similar efforts entirely obsolete (ND/Map, wxradar etc).
So whenever someone complains that things do not interoperate well, it is because software development is a dynamic process - this is just very visible/annoying in the FlightGear context because of FlightGear's slow development pace overall.

The thing to keep in mind here is that fgdata development has always been more vivid than core development, and it isn't unlikely that this will remain the case in the years to come - thus, it is important to recognize and appreciate this circumstance, which people like the previously mentioned core developers did (XML/property tree, Nasal, effects) by ensuring that all the fgdata momentum can be leveraged. In the case of Rembrandt this didn't happen as much (yet) - thus, it is only natural, that getting involved in Rembrandt development is more difficult than coming up with features like ALS - because ALS can be optionally implemented without touching any C++ code, "just" by adding code/XML files to the base package.

For the time being, the "eye candy" development manpower is not in deferred rendering/Rembrandt - it is whereever Thorsten decides to contribute to - which still could very well be Rembrandt if some issues were to be solved first. But for now, most of us with pretty powerful hardware are locked out by the existing Rembrandt implementation, despite not being new to FG. And honestly, the issue is not requiring configuration advice, the issue remains portability and performance. FlightGear does have a couple of fairly serious resource/performance issues, one of those got fixed recently by Stuart - but a number of others remain, and I am afraid that Rembrandt is currently adding to that list, simple as that.

Given all the recent development, the most natural development to take place would be modularizing it by splitting it up and re-implementing it on top of Zan's newcamera work - at that point, the integration layer would be much more modular, and could even be integrated with Canvas, which is another natural development step, simply because all the stuff that people cannot currently do, would become possible, without being tied to a particular rendering framework or even scenery engine.

If you want to see Rembrandt improved, the one thing that is missing is documentation for contributors wanting to get involved, it seems that contributors like i4dnf could help with that to some degree - but otherwise, even newcomers can do that - even if just involves the underlying building blocks, such as the rendering pipeline in general and the integration of the effects system - once those articles exist as stubs, we can grow them over time and fill in any gaps/findings.

Absent that, we have to wait for some kind of miracle/power contributor to do all the development, without requiring any docs - analogous to the work done by Mathias (OSG port), Tim (effects), Fred (Rembrandt), TheTom (Canvas) or poweroftwo (osgEarth) - all of them contributed to major components/C++ code in FG that lacked any real docs.

Otherwise, integration is going to be a boring and slow process taking many years - it will happen, but it will be dead-slow any annoying more often than not.

Obviously, we cannot expect people to adjust their priorities according to our own ideas and expectations - but what we can, and should do, is to prioritize support accordingly, i.e. by documenting things we're interested in and by helping/mentoring newcomers. This does work perfectly well, and those "mentoring" do not necessarily have a lot of work, they just need a lot of patience, because the process will inevitably be slower than implementing something directly - but it can still be gratifying, just look at the interaction between Thorsten and wlbragg. And we have numerous other examples, where mentoring worked exceptionally well - just don't expect contributors to adjust their own priorities immediately.

I think Thorsten will agree with me that coming up with a new system from scratch (like LW/AW or ALS) is hugely different from adapting an existing system or even making it work with new features. Collaboration and coordination needs a conscious effort from all parties involved - with Rembrandt's main developer not being actively involved in FG, Rembrandt expertise/manpower is scarce obviously - but that would just as well apply to other components in FG, which includes the whole JSBSim/YAsim debate, as well as scenery engines, TerraGear platform support or Nasal VM issues.
n
If you want to see a certain change, the safest way is being the change - and if that's not possible, just allow others to become the change by lowering the barrier to entry.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Orbital Makes the Sky Black

Postby Thorsten » Sat Oct 18, 2014 7:18 am

Finally instead of choosing between default vs ALS vs Rembrandt, our users just need to move a slider who fit his hardware capabilities.

But instead of adding an optional feature to the default rendering scheme you chosen to create another rendering scheme. That's where I disagree with the way you contribute to the project.


Um... do you know actually how the effect framework and its quality control works? Because ALS is written in such a way as to support what you suggest out of the box, whereas Rembrandt is not. Rembrandt actually requires a completely different architecture - which is why it can't be switched runtime.

For all I care, the GUI could be rewritten (as has been proposed by Stuart and James at some point) to activate ALS at higher quality settings rather than with its own checkbox, that's a question of GUI design. ALS would still have to have its own set of effects and shaders (just as the different quality levels in default have) because that's how GLSL works. You can't selectively 'switch ALS light on' or 'do ALS fog' without using a different shader. But the GUI can be changed. Doing that has just met vocal opposition from... Rembrandt enthusiasts, which is why the GUI is how it is. And... I didn't actually design that GUI either... I just contributed to the existing one.

You see, you also got the history wrong. I didn't choose anything in how ALS appears to the user. ALS was actually started with the skydome code by Lauri, not by my own work and it predates Rembrandt by a few months - I just worked out consistent terrain shaders for that inside the already existing structure and went on from there - with advice on how to assign effects to the shaders from... FredB. That'd be the same FredB who actually committed my first ALS contributions, and there was just zero concern on the way this was done.

where a slider give me the possibility to have the default rendering scheme when I set it to 0, and all Rembrandt+ALS eye-candy when I set it to 10.


Well, it's the Rembrandt maintainers which prevent your dream from coming true, not me. Rembrandt can't be switched runtime, so it can't be controlled by quality slider even in theory like ALS could (easily - just rewrite the GUI and you're done - ALS shader quality assignment even leaves space for default rendering quality levels...), and the Rembrandt maintainers haven't been (and aren't) interested in porting any of the ALS additions you like or my help in doing it.

It's like someone creates a 747 for FG, someone else makes a 777 and creates a great glass cockpit with hundreds of options and even offers to help porting the instruments to another aircraft, but the 747 enthusiasts all clamor that his work is bad because it's not done for the 747 which is a much better aircraft anyway and he should really not try to do his own thing with the 777 work and contribute to the 747, it'd be so much better for flightgear and not divide the community.

That's how you and your fellow Rembrandt users are behaving.

I think you have it very much upside down where the responsibility for the current state of affairs is - the things you criticize chiefly apply to Rembrandt and its proponents.
Thorsten
 
Posts: 10639
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby F-JJTH » Sat Oct 18, 2014 8:28 am

Well maybe I don't communicate correctly, let me explain again my point of view in a different way:

Thorsten, your work looks good to me on the final visual side. I don't have enough GLSL skill to criticize (in good or bad way) your code.
I'm happy that you work on shader. (Well I think I can't be more explicit)

But I disagree with the "form" of your contribution, i.e: create another rendering scheme. (well don't play with words here, I know that's not another "rendering scheme" because it's still a forward technique like the default rendering. That's not the point here)

Let me give some example of why I disagree with the way you implement your code:
* default sky:
We all know that the default sky is broken and looks bad, and my opinion is that the fix for this bug is the nice skydome available when ALS is ON.
But instead of saying "hey we have a fix for the default sky who is broken ! It's the "skydome", you (or whoever) said "hey the default sky is broken, I will leave this broken sky and commit a better sky named skydome". I really don't understand why the skydome is an optional feature instead of the fix of our broken default sky.

* trees moving in wind:
Why this feature is not simply available in the default rendering scheme ? Even if you like to have everything optionally we could have a checkbox for that "Trees moving in wind". Why it is an ALS-specific feature ? I don't see the point to make this feature available only in ALS, it should works as fine in the default rendering scheme. I really don't understand why this feature is not a standard feature available in default rendering scheme.

* improved contrast on slope:
again, you added a nice eye candy here, but it's again an ALS-specific feature, why ? why it isn't a simple checkbox "Improve contrast on slope" ? why this feature require to be implemented in a separate rendering scheme and leave the default scheme looking bad ? (and here we are falling back to my first words: I would prefer that the existing stuff is improved instead of creating a separate stuff)

Well there is already 3 reasons who make me think: why ALS has been created ? instead of creating ALS why didn't you commited your work in the default rendering scheme ?
I can continue like that with almost all your work: I really don't see the point to commit your work in a separate rendering scheme, why your work need to be separated ? why your work is not commited as improvement/bugfix of the default rendering scheme ?


Finally, yes it's just a matter of GUI re-work, but behind the scene it's finally a totally separated rendering scheme, and that's where I disagree, your work shouldn't be a separate stuff, it should be the improvement/bugfix of the default rendering.
We get the possibility to have a nice default rendering and Rembrandt, instead we have a bad default rendering, a nice ALS and Rembrandt.
There is 1 unnecessary rendering scheme in my opinion...


Well I hope that now my opinion is very clear. I don't criticize your work, I criticize the way you integrate it in FG. You consider that your work need to be implemented in a separate scheme named ALS while I think your work should be considered like all the bugfix and improvement that default rendering scheme need.



(Sorry I have to go to fly IRL, I will answer about "Rembrandt" later ;) )

regards,
Clément
User avatar
F-JJTH
 
Posts: 697
Joined: Fri Sep 09, 2011 11:02 am

Re: Orbital Makes the Sky Black

Postby wlbragg » Sat Oct 18, 2014 9:20 am

* trees moving in wind:
Why this feature is not simply available in the default rendering scheme ?


Clement, did you know you can comment out one line of code in effects and you will have tree movement in the default rendering scheme.

Line 99 in tree.eff
<!--property>/sim/rendering/shaders/skydome</property-->

It's that way with virtually all this shader code.

Thorsten, correct me if I am wrong.

I think the fear is that if it is not an option that there are going to be a bunch of pissed off people who's graphics cards don't support the shader code. Just like there would be a bunch of pissed off people if you couldn't turn off Rembrandt.
These are choices not punishments.
I think for now it need to be a choice.

I just read you post closer and you go on to say.

* improved contrast on slope:
again, you added a nice eye candy here, but it's again an ALS-specific feature, why ? why it isn't a simple checkbox "Improve contrast on slope" ?


I never really thought about it until just now when I went in and turned off the check for skydome and sure enough the tree shader code worked in the default rendering scheme. So for most of this stuff I guess you could do what your asking and relatively easy at that.
But in a way that is already being done by just choosing ALS?

Is there any advantage in to having it as a check box in the default scheme? You still have to turn it on or check the box. I guess I don't see the difference. In fact, selecting ALS check box IS turning on the "eye candy" in the default rendering scheme. It is adding the shader code. I think were talking semantics now.

Look at it this way.

OK, your in the default rendering scheme.

Now you want realistic sky,
Choice one check box ALS.
Choice two check box Realistic Sky.

Same thing.

Now you want tree movement.
Choice one, check box ALS, then slide tree movement slider.
Choice two, check box tree movement.

Same thing

About the only difference would be you could have tree movement without having realistic sky.
Right now you have to check ALS and get the realistic sky before you can get the tree movement.

Maybe there is something to changing the GUI selections and in what order they allow shader use. But really all your asking for is to allow all the shader code other than "realistic sky" to be selected independently of "realistic sky". I guess it could be done. But then you will start getting into certain techniques that require prior techniques to work because that is how it was setup. Some of this stuff is built upon its predecessors, some not. Tree movement could be independent. But now you are talking about reinventing the wheel. Now your talking about rewriting the GUI. I'm not sure I see enough advantage to reorganizing the shader code. Because really that's all your talking about.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4685
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 Thorsten » Sat Oct 18, 2014 10:02 am

We all know that the default sky is broken and looks bad, and my opinion is that the fix for this bug is the nice skydome available when ALS is ON.
But instead of saying "hey we have a fix for the default sky who is broken ! It's the "skydome", you (or whoever) said "hey the default sky is broken, I will leave this broken sky and commit a better sky named skydome". I really don't understand why the skydome is an optional feature instead of the fix of our broken default sky.


I think we're going through that one periodically... Since I haven't done it for a year or so, let's explain it again :-) The answer in short is that ALS at lowest quality level in fact is the fix of the default sky.

Skydome and terrain aren't unrelated. The reason is that fog isn't an object associated with a 'fog' model loaded into the scene, it's always something rendered onto a background. So, to avoid jarring visual discontinuities, you need to render the same fog model onto both terrain and skydome. If you don't, you get this

Image

(that's from Lauri's first implementation - skydome uses its native Mie+Rayleigh model, terrain uses the default rendering scheme diffuse haze mode, they ain't matching anywhere - bad)

Assuming we want no visual discontinuities (at least I don't want any, because that prompts just a bazillion of bug reports), in order to use the skydome shader it was therefore necessary to 1) add a layer of diffuse fog to the skydome rendering and 2) modify the default rendering scheme to use the same layer.

You can read up on the whole history here and see the subsequent layers of 'fixes' being applied by yours truly. It's not like I didn't try what you suggest - it just didn't work.

That immediately led to the next problem, which is that the skydome shader shows very rich lighting at dusk and dawn (because it knows all about Mie and Rayleigh scattering) - so in low light, it never ever matched even semi-plausibly with a simple fog layer as the default scheme used. The solution was again to bite the bullet and do a complete position differential light calculation in both skydome and terrain shader to match.

So, ALS at low shader quality level is the minimal alteration you have to make to the default rendering scheme to use the skydome shader without creating visual discontinuities. It is impossible to make the skydome shader work with the default renderer's lighting or fogging scheme.

Since that minimal light and fog computation is substantially more GPU-demanding than the default sky with default light and fog, the decision to make it optional seems sort of reasonable.

And since light and fog in ALS need to be position-differential, you can't simply call a different fog function to get the effect, you need to do lots of extra geometry work in the vertex shader stage already. Which means you can't simply graft the light and fog model of ALS onto an existing shader effect, you have to re-implement the existing shader effect inside the ALS light and fog workflow.

You imagine there'd be a choice anywhere along the path, but I never saw one, and I don't see it now.

Why this feature is not simply available in the default rendering scheme ? Even if you like to have everything optionally we could have a checkbox for that "Trees moving in wind". Why it is an ALS-specific feature ? I don't see the point to make this feature available only in ALS, it should works as fine in the default rendering scheme. I really don't understand why this feature is not a standard feature available in default rendering scheme.


Because Stuart, who wrote both the tree rendering code for the default scheme and the trees move in the wind code decided to not include it. He's the maintainer of that effect, it's his decision, whereas I am the maintainer of ALS and made a different decision.

This is a question like 'Why are the sidewinder missiles of the F-14b not implemented for the F-16?' Because the person who maintains the airplane didn't do it. I don't know what your idea of FG development is - but as a rule, we just don't go changing things in areas maintained by other people without their approval. So it's not my call to make.

again, you added a nice eye candy here, but it's again an ALS-specific feature, why ? why it isn't a simple checkbox "Improve contrast on slope" ? why this feature require to be implemented in a separate rendering scheme and leave the default scheme looking bad ? (and here we are falling back to my first words: I would prefer that the existing stuff is improved instead of creating a separate stuff)


Because, again, there is no simple switch in GLSL 'render this effect using ALS' - the slope line code exists in some context and is matched to a particular fragment shader file. So, if you want it in Rembrandt or default as well, you have to write a corresponding effect and shader code from scratch, or adapt an existing effect. I could theoretically do that, but I am maintainer of all the Advanced Weather code as well as all of the ALS shader code, that's a lot of work already, and I'm not interested in adding yet more to my plate.

As stated above, ALS has to use quite different vertex and fragment shaders from default - we don't have any choice here. So in essence, you're asking me why don't I develop for default fog, sky and light rather than ALS fog, sky and light or why don't I double my workload. I think the answer to that one should be fairly obvious. Like everyone else in development, I have to focus my efforts.

Finally, yes it's just a matter of GUI re-work, but behind the scene it's finally a totally separated rendering scheme, and that's where I disagree, your work shouldn't be a separate stuff, it should be the improvement/bugfix of the default rendering.


Well, I'll let you in on a secret. If you use the default renderer, it reads terrain-default.eff and executes terrain-default.vert and terrain-default.frag. If you use the water effect in the default renderer, it reads water.eff and executes water_sine.vert and water_sine.frag - totally different files. Which is to say, for every different effect and many different quality levels, the default rendering scheme refers to separate files.

Whereas if you use the basic ALS terrain rendering, it reads terrain-default.eff and executes terrain-ALS-base.vert and terrain-ALS-base.frag. It also refers to separate files. It's internally no different from they way the default renderer manages different terrain types and quality levels.

So behind the scenes there is actually no technical difference between ALS and default - the defining difference is in the way they handle light, sky and fog, and these are not interchangeable (see above). You have to group matching shaders, otherwise you get graphical discontinuities. Which is what the GUI has to do in some way.
Thorsten
 
Posts: 10639
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby Thorsten » Sat Oct 18, 2014 10:07 am

I never really thought about it until just now when I went in and turned off the check for skydome and sure enough the tree shader code worked in the default rendering scheme.


Well, it works - it just has the wrong lighting and fogging. Try watching it in low light or heavy fog to see that... Subtle, but a problem.
Thorsten
 
Posts: 10639
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby AndersG » Sat Oct 18, 2014 10:09 am

F-JJTH wrote in Sat Oct 18, 2014 8:28 am:Well there is already 3 reasons who make me think: why ALS has been created ? instead of creating ALS why didn't you commited your work in the default rendering scheme ?
I can continue like that with almost all your work: I really don't see the point to commit your work in a separate rendering scheme, why your work need to be separated ? why your work is not commited as improvement/bugfix of the default rendering scheme ?


F-JJTH,

I think you are being silly. IIRC, ALS went in as an alternative to the default rendering scheme because there were opinions expressed among the FG developers that opposed the new (at that stage experimental) work going into the shaders of the default rendering scheme. Though, as it has matured well (very well, indeed) I would certainly not mind it replacing the higher levels of the default rendering scheme, but I'm sure there are still some with reservations. Hence, having it as an optional alternative is good middle way.

For my visual preferences and on my system ALS is a much better use of what rendering resources there are than Rembrandt and the view out the windows is superior to that of the default scheme.

/Anders
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2433
Joined: Wed Nov 29, 2006 9:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: Orbital Makes the Sky Black

Postby Thorsten » Sat Oct 18, 2014 5:06 pm

I've debated with myself for a while how to say this nicely, but I think in the interest of fairness, I have to say this in some form:

Clement, from your comments, it's fairly clear now that by the beginning of this thread, you didn't know important conceptual rendering background, like the way we have to treat sky, fog, light and terrain absolutely consistent. It's clear that you didn't know basic technical aspects of how we do schemes in FG, like the way switching quality levels in default or switching default to ALS is technically identical.

And yet, you felt you need to lecture people here how bad GLSL 1.20 is and how bad it is that we don't modernize, and how deferred rendering is superior.

Equally well, your comments have made it quite clear that you haven't known the history of how ALS was developed and the discussions about the GUI and ALS integration that have been done on the mailing list.

And yet, you felt it absolutely okay to blame me personally for doing things the way they were decided after discussing on the list.

You mentioned things like the maintenance problem for aircraft developers, that they have to care for different frameworks. However, the only framework which in reality requires action (declaring transparent surfaces, light volumes,...) is Rembrandt - whatever default renders, ALS renders as well without the need for substantial extra action.

And yet, you felt you could bring this as an argument that I shouldn't do what I do.

I've spent a lot of time in this thread explaining how things actually work, and why they work this way. But next time, I would much prefer if you'd just ask me to explain it if you're not sure, rather than criticizing me in public and waiting for me to clear things up. I would really appreciate that. Thanks.
Thorsten
 
Posts: 10639
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby punkepanda » Sat Oct 18, 2014 5:28 pm

F-JJTH wrote in Sat Oct 18, 2014 8:28 am:Let me give some example of why I disagree with the way you implement your code:
* default sky:
We all know that the default sky is broken and looks bad, and my opinion is that the fix for this bug is the nice skydome available when ALS is ON.
But instead of saying "hey we have a fix for the default sky who is broken ! It's the "skydome", you (or whoever) said "hey the default sky is broken, I will leave this broken sky and commit a better sky named skydome". I really don't understand why the skydome is an optional feature instead of the fix of our broken default sky.

* trees moving in wind:
Why this feature is not simply available in the default rendering scheme ? Even if you like to have everything optionally we could have a checkbox for that "Trees moving in wind". Why it is an ALS-specific feature ? I don't see the point to make this feature available only in ALS, it should works as fine in the default rendering scheme. I really don't understand why this feature is not a standard feature available in default rendering scheme.

* improved contrast on slope:
again, you added a nice eye candy here, but it's again an ALS-specific feature, why ? why it isn't a simple checkbox "Improve contrast on slope" ? why this feature require to be implemented in a separate rendering scheme and leave the default scheme looking bad ? (and here we are falling back to my first words: I would prefer that the existing stuff is improved instead of creating a separate stuff)

Well there is already 3 reasons who make me think: why ALS has been created ? instead of creating ALS why didn't you commited your work in the default rendering scheme ?
I can continue like that with almost all your work: I really don't see the point to commit your work in a separate rendering scheme, why your work need to be separated ? why your work is not commited as improvement/bugfix of the default rendering scheme ?


Right on spot!!!
Thats excactly the reason(s) I earlier in forum threads have stated that Thorsten is Hi-Jacking the project!! In lack of better words!! :D
Even if he always hide behind the tricky words of "Its Optional".. Which is not the end user impression of it if they want to put on more eye candy!
He could rather take with him his followers and start a new FlightGear under a different name.. "ALS Gear" or something.. It would be less confusing!
Last edited by punkepanda on Sat Oct 18, 2014 5:56 pm, edited 2 times in total.
punkepanda
 
Posts: 237
Joined: Mon Nov 04, 2013 9:11 pm
Callsign: LostFlight
Version: 2.12
OS: Arch Linux

Re: Orbital Makes the Sky Black

Postby wlbragg » Sat Oct 18, 2014 5:43 pm

Thorsten,

The technical part of this discussion is fascinating and eye opening for me personally. I had no idea of the conflicts between the two sets of shaders. From the little I knew about the subject I assumed it should be easily interchangeable.

I took a couple low light level, (not any fog), screen shots of the tree.shader in effect (with and without ALS) (technique 4). It even included the secondary lights in both. For anyone else following this thread, yes they also work in default scheme, because they are included in technique 4, which is where I disabled the predicate requiring skydome to be on.

I didn't see the "subtle" problem. But then again I don't know what I am looking for.

I would love to post these shots sometime and continue this line of investigation/conversation.
But I guess this isn't the time or place to do this.
So for now, here is the URLS to them if anyone is interested.
tree.eff and secondary light with ALS
tree.eff and secondary light with Default
If you ever feel like participating in a teaching/project history thread, just let me know..
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4685
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 wlbragg » Sat Oct 18, 2014 5:48 pm

Thorsten is Hi-Jacking the project!


Are you kidding me? That's real productive.
ALS is the only rendering progress in all of the FlightGear project. It isn't touching the default rendering scheme.

At least Clement is asking questions like "WHY?", which was explained effectively.

You really don't have a clue, even after reading the explanations above..
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4685
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 psadro_gm » Sat Oct 18, 2014 6:26 pm

As far as I understood (I may be wrong), the reason we still havent moved to opengl 3.x+ has been due to supporting OSX. If we wish to support OSX, we need to completely abandon the fixed function pipeline. Some of our dependencies (plib) are no longer maintained , so must be replaced with something that supports shaders (canvas, etc).

Apple has made app developers to move on or stay in fixed fn. We aren't there yet.

Almost every feature in fg needs a maintainer. Maybe someone who especially loves deferred rendering will step up, and begin migrating Thorsten's als shaders to rembrandt.
8.50 airport parser, textured roads and streams...
psadro_gm
 
Posts: 750
Joined: Thu Aug 25, 2011 2:23 am
Location: Atlanta, GA USA
IRC name: psadro_*
Version: git
OS: Fedora 21

Re: Orbital Makes the Sky Black

Postby Hooray » Sat Oct 18, 2014 6:45 pm

the other issue is that there's still legacy GL code running in the main/rendering loop that prevents us from using a more recent OpenGL version, such as the panel/HUD and GUI code - those things are in the process of being unified, and re-implemented, on top of modern OSG code using a shared back-end via Canvas.
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: 11317
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Graphics

Who is online

Users browsing this forum: No registered users and 0 guests