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 » Wed Oct 15, 2014 7:19 pm

MasteroftheSKIES wrote in Wed Oct 15, 2014 11:30 am:I assumed it was an incorrect setting or a problem with my graphics card. I assure you, I did not assume it was a bug; and I did not report it as such either.

Don't fall into the trap of arguing with Thorsten..It has been tried before many times by many people. He knows what you thinking so no need to thare your toughts! And if you do, you think wrong anyway!! U better leave it if you wanna stay on the forum ;)
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 MasteroftheSKIES » Wed Oct 15, 2014 8:26 pm

OK lol I'll stop.
I would use FSX but I use FlightGear because it's a project with goals.

Windows 7; Processor: 8 core 4 GHz; 8GB RAM; Graphics: NVIDIA GeForce GTX 770 (a pretty good graphics card if you're wondering)
MasteroftheSKIES
 
Posts: 216
Joined: Tue Oct 22, 2013 11:10 am
Version: 3.2
OS: Windows 7

Re: Orbital Makes the Sky Black

Postby wlbragg » Wed Oct 15, 2014 11:07 pm

Cool, this one is right up my alley!
I should be banned from the forums for asking stupid questions!

But I will say this, I hope nobody is sent away with hard feelings for asking a "questionably" dumb question or making a "questionably" dumb statement. It took me two years of time consuming investigation to even be close to being on the same page as people that have been doing this for much longer.

At the same time I think I would be even more devastated to loose a major contributor over hard feelings caused by a forum argument.

It, isn't obvious, nothing about this project is obvious to anyone but those intimately involved or inherently genius.

To one person that know exactly what Orbital Rendering is, it's a huge gift from the contributor.
To the person seeing this VAST collection of simulated systems for the first time, well, not so much. It is something that didn't do what they expected for whatever that reason was.

Yes, the answer is there if your wiling to put some time and energy into looking. But I'd be willing to bet that even if MasteroftheSKIES did he might still have asked. "Is it supposed to act this way?". I know I would have.

People, let's not perpetuate stereotypical online behavior.
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4890
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 » Thu Oct 16, 2014 6:37 am

But I will say this, I hope nobody is sent away with hard feelings for asking a "questionably" dumb question or making a "questionably" dumb statement


Look - that's not the issue.

It's often said that there are no dumb questions. I don't think that's true - there are. If you ask something that you could have figured out in 3 seconds yourself, that's wasting time and falls into that category. As I type this, I have a pink box with requirements what info to supply for a bug report on screen right above the box into which I am typing. To disregard that and assume that people can figure a bug from a vague description like 'FG sometimes crashes' would be an example.

Not the issue here.

The issue here is twofold: Equal effort, and politeness.

Let's start with the second. If I know something, I make a statement of fact. If I am not sure, I say 'I believe X is like this'. If I don't really know, I ask a question 'Could it be that X is like that?' This is to let the person I am talking to know the level of certainty in the information I give - if I state my assumptions as facts, you can imagine how they're quoted down the line as truths and how everyone gets royally confused. And if I stated something as fact which turned out to be wrong, I apologize for having spread wrong information (I feel actually ashamed if I do that, in case someone is wondering).

So, where does politeness come in? It's in assuming that people who have developed an aircraft (autopilot, subsystem,...) know a lot about it. Say I have a problem with the autopilot of the Y-55 plane. My default assumption is that the person who developed that can operate the autopilot or is in the process of working on it, because we usually don't commit broken stuff just for the sake of it, we commit what we can use ourselves. So it's unlikely that the AP is completely broken (it can happen if it depends on other systems which have changed though) - it's far more likely that there's an issue on my side - either specific for my computer, or something in the way I operate the thing. In fact, observing my own case history, at least 8 of 10 cases the problem did turn out to be on my side when I reported such things - about half and half specific configs and my mistakes in using a system. More often than we think, the problem sits right in front of the screen :-)

How do I now report this AP problem? Here's some variants with the implied message:

* The AP of the Y-55 is broken
(What kind of a stupid person are you to need me to tell you that - shouldn't you have realized that yourself and now you need me to tell you?)

* The AP of the Y-55 doesn't work on my system
(There may be something specific in my config which makes this not work which you might not have considered)

* I can't seem to be able to operate the AP of the Y-55
(There may be something in my config or my way of handling it which doesn't agree with what you assumed)

* I can't seem to be able to operate the AP of the Y-55 - this is what I am doing, this is what I expect, this is what I get and I have consulted this reference
(I've exhausted all avenues of information to address this myself, and I still find a problem)

Which of these questions would you prefer to deal with? I like best to be asked politely.

Which brings me to the second point - equal effort. We have two parties which want to exchange information. A knows stuff, B has a question. What B wants is a comprehensive answer and discussion, in non-technical terms, with the ability to ask questions and ideally a ready-made patch which fixes the problem.

But A has a time limit - he can explain, or develop, or document, but not all of these, but A sees the need to provide answers. So what A wants is to keep the answer as least time consuming as possible, i.e. he wants to give a pointer 'Look up on covariant metric transformations' and then let B do the information gathering and structuring.

So, if we want a meaningful exchange, A has to make an effort in structuring the information he has such that it is comprehensible. B has to make an effort to structure the information he gets such that he comprehends it. And the efforts of A and B should be on average equal (modulo the fact that A may address questions of different users simultaneously). If you take 30 seconds to type a question because you didn't want to do a wiki search, you can feel entitled to a 30 second reply 'read wiki page XY' by this principle.

I go out of my way to help people who are actually interested in working on something or analyzing a bug such that it can be fixed, i.e. actually try to read some beforehand and look into the resources I point out, look into files I point out and try different settings, etc. I turn my back on questions which want a ready-made solution, have obviously not done even a cursory search of the forum or the wiki and signal no intention to put some effort into understanding/debugging - these are, from my experience, lost causes which take my time and accomplish nothing because I can't magically guess problems on other systems, and my time is better invested in helping people who put effort of their own in.

The issue here is not about asking stupid questions, the issue is about managing information flow. You may want to get someone's exclusive attention and help, but that ain't working if that person has other things to do, so you need to structure the exchange in such a way that it benefits both sides, not only yourself because that is working. Politeness and equal effort are keys to do that. As simple as that.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby wlbragg » Thu Oct 16, 2014 8:08 am

Politeness and equal effort are keys to do that


Yes, after going back to start and re-reading it again with a different context in mind the comment/question wasn't phrased in the most polite manner.
The second response, after getting the hint as to what the feature was all about and the 2nd reply with a little more of a complete answer, was even more combative.

I also see a
Thanks for all the help.

and a
Sorry,

negated by a self defense move of
Do you have to know exactly what a feature does before using it? I don't think so.


Maybe I am naive, but I can see both sides of it. I think it was an honest mistake, hopefully not meant in the context that it was perceived.

I think what we should all get out of this is,
if there was a small button with a question mark

Try to look at questions from a total novices point of view and use this type of question to help us predict what that point of view is going to be. Then try to make changes and improvements accordingly, "when we can".
I don't think a novice can ever look at it from an experienced contributors point of view, until they've been there.

Oh, and Thorsten, get back to work and quit wasting your time on this stuff, let someone else deal with it. Unless of course it's your entertainment for the day. :)
Kansas(2-27-15)/Ohio/Midwest scenery development.
KEQA (2-27-15), 3AU, KRCP Airport Layout
User avatar
wlbragg
 
Posts: 4890
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 punkepanda » Thu Oct 16, 2014 10:52 pm

wlbragg wrote in Thu Oct 16, 2014 8:08 am:Oh, and Thorsten, get back to work and quit wasting your time on this stuff, let someone else deal with it. Unless of course it's your entertainment for the day. :)

Me and Thorsten agreed to that some months ago, because of discussions like this. So we stayed away from the forum, instead focusing on developlemt(Thorsten), testing(thorsten/Me) and having fun with FlightGear(Atleast me :)

Thorsten.. Please go back coding and finish the new ALS lights you just made. Forum is taking to much of your time which probably delays implementing new stuff.

Just a short question(little of topic), Is it possible for the new search light feature to be connected to the sun to cast sunlight rays and shadows, or will it melt the GPU?
Rembrandt is dead so we should have a alternative.. Dont you think?

BTW... Testing Orbital Rendering I never got beyond 300.000 feet without computer freezing and hardisk work like hell, proably running out of memory.. And I have 8 Gb! :(
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 F-JJTH » Fri Oct 17, 2014 12:43 am

punkepanda wrote in Thu Oct 16, 2014 10:52 pm:Just a short question(little of topic), Is it possible for the new search light feature to be connected to the sun to cast sunlight rays and shadows, or will it melt the GPU?
Rembrandt is dead so we should have a alternative.. Dont you think?


Wow Rembrandt is dead ! Where did you read it ? Is it announced somewhere ?
IMO, the "ALS search light" is just a "re inventing the wheel" case, Rembrandt does it and even much more for long time.
Instead of spending their time to reinvent the wheel I would prefer that people spend their time on improving the existing stuff.

Deferred rendering is definitely the way to go instead of the old scheme (implemented in 2006) , do I have to remember that we are in 2014 and OpenGL 4.5 is here ?
It would be good if FlightGear move forward instead of still using old-school rendering scheme. You can be sure that since 2006 your GPU has evolved and the old-school scheme does not fit the the capabilities of your last driver/hardware couple anymore.

If deferred rendering was "dead" (as you say) I wonder why a large number of recent commercial game are using it these days.
Are you suggesting that all these professional graphic developper are stupid by implementing deferred rendering technique ?

The line
Code: Select all
#version 120
at top of most of our GLSL files make me cry when we know that our GPU have much more capabilities today.


Rembrandt is definitely not dead, and is the way to go in future.

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

Re: Orbital Makes the Sky Black

Postby Thorsten » Fri Oct 17, 2014 6:00 am

IMO, the "ALS search light" is just a "re inventing the wheel" case, Rembrandt does it and even much more for long time.
Instead of spending their time to reinvent the wheel I would prefer that people spend their time on improving the existing stuff.


Well, Clement, if the issue were just as simple.

For many of us, Rembrandt works with <15 fps (does so for me, on a GeForce GTX 670M (!) ) - at rather low visual quality apart from secondary lights and shadows. Whereas I can run ALS with 75 km visibility at 36.000 ft and get 30 fps, increasing to 60 fps at all details maxed out close to the ground. And, I get all the shadows which are actually important from high altitude - the terrain shading itself and cloud shadows. So, to put it bluntly, that's a problem for Rembrandt, and I personally want my GPU performance to go into haze, lights, non-tiling terrain texturing and so on rather than detailed aircraft shadows and secondary lights. That's my personal choice, and people who like it different can use Rembrandt, it's what it's for. If you like Rembrandt, fine, but don't make that the rule for the rest of us please.

Deferred rendering is conceptually a very neat thing for some applications, not so much for others, but the FG implementation as Rembrandt has issues. We can't go forward on a scheme which works well for an estimated 20% of people and not for the rest - someone needs to sit down, investigate why Rembrandt shows such odd behavior on rather high-powered GPUs and see what can be done. And unless that happens, deferred rendering is a nice buzzword.

Personally, I don't care about fashion trends, and what is an old-school scheme and what is not - I get a bunch of vertices, and I care to render them such that the outcome looks appealing and that the computations are done as fast as possible. The math is the math, whether you do it deferred or forward, it needs to be solved. You can do things like HDR just as well in a forward scheme if you understand the equations.

The ALS secondary light is not 're-inventing the wheel', it's a computationally very neat trick to render lights close to the eye perspective and hence an easy improvement to an existing scheme to make (you did want me to improve existing stuff, right?). I mean, sorry that some folks happen to like the fact that they don't need to accept the <15 fps of Rembrandt to see a landing light :-)

Are you suggesting that all these professional graphic developper are stupid by implementing deferred rendering technique ?


It's a technique - you deploy it where you see an advantage, you don't if you don't. Deferred rendering was invented to solve a particular class of problems, forward rendering was invented to solve a different class of problems. There's not one 'better' than the other before you talk about what exactly you're trying to render.

And yes, I think in many cases, professional developers use techniques because a reference manual says so, not because they understand all the underlying math and re-structure the equations to solve fastest.

I mean, at the end of the day, 'I'm using X because lots of other people are doing it' isn't exactly the best of arguments :-)
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby F-JJTH » Fri Oct 17, 2014 10:07 am

Thorsten wrote in Fri Oct 17, 2014 6:00 am:For many of us, Rembrandt works with <15 fps (does so for me, on a GeForce GTX 670M (!) )


This looks like a bad argument to me. Here I have a low-end laptop with the bad Windows 7 OS and AMD hardware.
- memory: 4Go
- GPU: HD7310 m
- CPU: AMD Dual-Core E1-1200 (1.4GHz)

So this computer is definitely the worst to use Rembrandt, BUT:
Playing with Rembrandt options give me the same visual result than the default rendering with 22fps.
Yes you read it correctly: 22 fps ! with my very bad computer largely worst than your GTX 670M.

So your 15fps are there because you want it. If you spend some minutes to configure Rembrandt to fit your hardware capabilities you would have much better FPS.

Another example with my "production" computer:
- memory: 12Go
- GPU: GTX 460SE (yeah the cheap version)
- CPU: Intel Core I5 (3.4GHz)

With all fancy eye-candy ON (Shader slider at 5/5, 8192 shadow texture, SSAO, Bloom effect...) I have ~40fps and sometimes 55fps (even some peak at 60fps over ocean)
Yes, again you read it correctly: 40/55fps with my hardware which is worst than your hardware.


I think you just have some configuration problem on your side. If you need help to configure your computer I'm ready to help you, just ask for help ;-)
Feel you free to open a new thread, and don't be shame, a problem can touch everybody even the best people ;-)


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

Re: Orbital Makes the Sky Black

Postby Thorsten » Fri Oct 17, 2014 10:48 am

Clement, I had FredB's advice to configure Rembrandt, back when Emilian was still talking to me I had his, and I've played for an hour on my own, James has the same graphics card I do and reports the same thing, we have had a discussion on the mailing list a while ago with yet more people confirming the observations. There's a lot of people 'not getting it' apparently.

For some unexplained reason, some people are 'lucky' with Rembrandt and get good framerates. You're one of them. The rest does not, even with high-powered hardware. I don't think it's understood. It's not a bad argument, it's an observation repeatedly made and you can see people report it all across the forum and in mailing list discussions if you care to look.

But I'm not even interested in having this argument again and convincing you that I really get low framerates for the nth time. I would however like to point out the slight asymmetry that I have never ever said to anyone that I think he should abandon development for Rembrandt for whatever reason. Yet when I continue to do ALS, everyone in the Rembrandt community feels entitled to tell me how stupid I am, what a waste of times this is, that it's re-inventing the wheel, - by people who can't explain to me why actually, other than using buzzwords like 'deferred rendering is the future'. Think of the why - what GLSL 4.x functionality do you want to use? What do you need deferred rendering for? That's how the discussions should go.

And I am getting tired of the Rembrandt user community even lacking the basic decency to accept that one can do some very interesting things with better performance without Rembrandt.

I accept that you (just like a few others) are interested in Rembrandt, and I know you'd therefore prefer me to code for Rembrandt, but I don't, I have my reasons (which I have stated more than a few times by now). I can understand that it alarms the Rembrandt community that lots of development happens outside of Rembrandt (where development seems to have largely stalled), but I think that's a problem which needs to be addressed inside the Rembrandt community, and the solution is not to stall all other development as well - I am not responsible for the Rembrandt development pace, I have never influenced it.


Instead of spending their time to reinvent the wheel I would prefer that people spend their time on improving the existing stuff.


The basic flaw here is that ALS is existing stuff - but for some weird reason, for you it doesn't count - ask yourself why. It's just a tad silly to ask me not to add 60 lines to ALS to make a light work and instead add 3000+ lines of ALS functionality to Rembrandt to make haze and procedural texturing work there in the vague hope that somehow the fragment pipeline will crunch it fast enough.

I've known you as a decent person otherwise - may I kindly ask you to accept that ALS has just as much right to exist in FG as Rembrandt?
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby punkepanda » Fri Oct 17, 2014 12:35 pm

F-JJTH wrote in Fri Oct 17, 2014 12:43 am:Wow Rembrandt is dead ! Where did you read it ? Is it announced somewhere ?

I sayd that Rembrandt development is probably dead and nobody want ever touch that code again to improve it (whch uffcourse is a sad story)

I never been a big fan of putting ALS on top pf the old rendering framework myself.. As you say, its 2014!!
But I have to agree to Thorstein also that when nobody seem to find interest in maintaining the Rembrandt code, ALS is probably the best alternative we have at the moment.
ALS is not a waste of time, but it is neither the future. Unless i see a very good alternative to sunlight and shadows in ALS uffcourse (if it is even possible to compare it. I donno!)

Earlier on this forum I told Thorsten he did hi-jack FG with his implementation of ALS.. And there is some truth to that since every new eye candy is only combatible in ALS mode.

But Thorsten is the only comunity member on the rendering side that make any progress at the moment!!

So untill someone comes up with something better I guess we will stick to that..

BTW.. ALS can be really slow at times too. Especially with the "Transition Option" set to max.. It even look worse than no transition at all many places in the scenery. So Rembrandt gives me better framerate many places in the scenery than ALS.
So telling that ALS is giving a lot of eye candy without loosing FPS is bull!! If someone made the sky look better in Rembrandt I would never touch ALS. But untill then....FG community need more expert skills on the rendering side!!
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 F-JJTH » Fri Oct 17, 2014 5:23 pm

Don't worry, there is still people around here to maintain Rembrandt code.
But what need to be maintained ? We have dynamic lights, shadow, bloom, all default shaders (ubershader), SSAO, and even night vision, color shift, color fringe, film wear.
And all of this works fine :-) so where do we need improvement ?

About the sky:
Well open the property browser, navigate to /sim/rendering/shaders then switch "skydome" to true, now you have the beautiful sky like in ALS ! Wonderful isn't it ? :-)
Unfortunately other part of the scene looks weird, but it means one important things: the skydome from ALS is totally compatible with Rembrandt, it just require some good faith to expose this feature to Rembrandt.

Also if you are close to trees you will see that trees are moving dependant on the wind, yeah that's another "only-ALS" feature which works out-of-the box with Rembrandt ! But not exposed for some misterious reason.

I don't have a list of all "only-ALS" feature but I'm pretty sure we have other example of those feature who works absolutely fine with Rembrandt but intenionaly not exposed to Rembrandt.
Finally I wonder if we are here to improve FlightGear or improve ALS, if it's the second case I would suggest to fork FlightGear instead of creating a "parralel world" named ALS.


In my opinion, having 3 rendering scheme make the community divided and create conflict (because you have to choose your "gang").
It also increase the required maintainance (we have to maintain 3 rendering scheme !) and make the code more complex than necessary
Code: Select all
if(rembrandt_is_active){
do_that();
}elseif(als_is_active){
do_this();
}else{
do_blabla();
}



But i know that everybody here contribute to an open source project, it means that contributor are free to contribute on what they love.
I'm not here to force someone to contribute in the way I would contribute.


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

Re: Orbital Makes the Sky Black

Postby Hooray » Fri Oct 17, 2014 6:01 pm

I also wouldn't say that Rembrandt is dead - but it does have performance issues, and is not a viable platform for many potential contributors. The main issue here is the lack of manpower on the C++ side familiar with Rembrandt internals, beyond just people who claim to be familiar with it on some wiki discussion page, versus people who actually can contribute in a meaningful way.

A few months ago, I actually started investigating a little and Thorsten joined the effort for a few days. I still do think that supporting deferred rendering/rembrandt is technically the right thing to do, but the FG implementation and integration layer needs to be better understood first.

I do still believe that 2-3 contributors familiar with C++ and GLSL could make Rembrandt perform faster - even without being very familiar with GLSL or the FG rendering side, I did identify several bottlenecks using just profilers.

However, there are issues that are not sufficiently well understood yet - and frankly, I found other things more interesting, and more promising - which also seems to apply to Thorsten. But I have no doubt that we could put together a team of people to help document, profile and incrementally improve Rembrandt.

The main issue here is the barrier to entry involved, which basically means that FredB is the main guy who could help address this particular problem, while other experienced C++ developers familiar with the rendering pipeline (Mathias/Tim) might be able to make working changes, the lack of integration docs is the main showstopper preventing Rembrandt from being more widely adopted - for now, C++ changes related to Rembrandt were primarily contributed by FredB - and while comments made by i4dnf sound promising, we have yet to see anything concrete materializing in the Rembrandt department,

Things like ALS are being developed by people for the same reason that Nasal and XML effects are used (vs C++/GLSL): accessibility. And when/if Thorsten should decide to abandon FlightGear for a while, some of his own work may suffer from the same problem - except for those things that he thoroughly documented already.

So this is not a Rembrandt specific issue - we need to accept that some features are inherently "complicated" and require a lot of background knowledge/expertise that may not be obvious, which raises the barrier to entry significantly.

But exactly like Rembrandt, ALS is optional - so no need to "convert" people into contributing in some specific way.

F-JJTH wrote in Fri Oct 17, 2014 5:23 pm:Don't worry, there is still people around here to maintain Rembrandt code.
But what need to be maintained ? We have dynamic lights, shadow, bloom, all default shaders (ubershader), SSAO, and even night vision, color shift, color fringe, film wear.
And all of this works fine :-) so where do we need improvement ?


You are bringing up individual effects/shaders, whereas the main issue with the existing Rembrandt implementation is beyond individual features and much more about portability/compatibility and performance in general, and obviously developer documentation. The Nasal engine suffered from the same problem, some people recognized this, and Nasal internals were documented, so that things like cppbind became possible. So it is a chicken/egg problem obviously, but that doesn't make Rembrandt, ALS or Nasal a bad feature/choice or system - we need to accept that manpower is in a constant flux.

And just as well, this also applies to osgEarth - which also lacks integration with Rembrandt/ALS etc (or vice versa).
Understand that, and you'll see this is not about Rembrandt or ALS: It is about the way FG development "happens", simple as that. And more often than not, contributions that may appear redundant/unnecessary to some people, are helping to lower the barrier to entry.

We are also seeing a lot of redundant development in Nasal/Canvas space, especially in avionics - but people are generally unable to contribute in the most meaningful way directly unless they're enormously experienced and have sufficient spare time. And several commits made to the SG&FG repositories by core developers were also not sufficiently generic/direct, but that's the way it goes - you cannot tell people what to work on....
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

Re: Orbital Makes the Sky Black

Postby Thorsten » Fri Oct 17, 2014 6:02 pm

Unfortunately other part of the scene looks weird, but it means one important things: the skydome from ALS is totally compatible with Rembrandt, it just require some good faith to expose this feature to Rembrandt.

Also if you are close to trees you will see that trees are moving dependant on the wind, yeah that's another "only-ALS" feature which works out-of-the box with Rembrandt ! But not exposed for some misterious reason.


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 - basically how I integrated the depth map for the water shader. Stuart wrote the tree moving in the winds code, but didn't want to implement it. I thought it's cool and asked him to send it and inserted the 4 lines into the ALS tree shader, which is why we have it, but if someone would bother to insert it into Rembrandt, it would run.

You could in fact take lots of the procedural texturing code and it would run - it's even easy, since I factored the noise functions into libraries which can be included. As to why Rembrandt doesn't do that, it's a question for the Rembrandt maintainers, not for me. I have offered 3 or 4 times to assist if anyone wants to port these code blocks on the devel list.

So, the mysterious reason is: the Rembrandt maintainers are not interested. That's all.

Finally I wonder if we are here to improve FlightGear or improve ALS, if it's the second case I would suggest to fork FlightGear instead of creating a "parralel world" named ALS.


See, you're still not getting the point. Rembrandt isn't more or less FG than ALS. So by the same argument, you might suggest to create a parallel world named Rembrandt. The fact of the matter is that ALS is far less invasive than Rembrandt as far as almost any architectural aspect is concerned, which is why you can e.g. switch it on and off runtime, which isn't possible for Rembrandt.

But in your world, Rembrandt has a right to be in FG because you like it better, ALS has not. And that's the attitude I oppose here.

It also increase the required maintainance (we have to maintain 3 rendering scheme !) and make the code more complex than necessary


Again, if you want to avoid complexity that'd be an argument to give up Rembrandt because it requires architectural changes to the core and to a lot of models, not to give up ALS.

And I don't really see the 'we' - >95% of the ALS code is written by yours truly, and I maintain it just fine. It's not like I would have ensnared lots of 3d rendering experts to leave Rembrandt and join the ALS effort.

In my opinion, having 3 rendering scheme make the community divided and create conflict (because you have to choose your "gang").


Sorry, that's just plain silly. We're talking about a checkbox - you can switch between two schemes runtime, i.e. you don't even have to start your flight in the scheme you finish it, and whether you want to use Rembrandt you can still decide from one flight to the next. We're not talking about lifetime commitments here. This is like saying you have to choose whether you want to fly the c172p or the 777-200ER and join one of the gangs - you have to specify that at startup as well.

It's a bit of a weird attitude to construe the presence of options as making the community divided.

But if you worry about division, you're free to convince people that we should abandon Rembrandt. Because if you insist that in order to avoid being divided, ALS has to go, I'd be forced to doubt that your worries are real and conclude that the argument is just a straw man to further your real agenda.

I'm not here to force someone to contribute in the way I would contribute.


Well - but then simply accept that what we find interesting is not aligned and stop making snide remarks. It's snide remarks like yours which divide the community, not the presence of a checkbox in the GUI.
Thorsten
 
Posts: 10986
Joined: Mon Nov 02, 2009 8:33 am

Re: Orbital Makes the Sky Black

Postby Hooray » Fri Oct 17, 2014 6:11 pm

FWIW, I tend to use/support what works for me well enough (including performance), as well as features that are either sufficiently generic and extensible or at least well-documented with some manpower - for the time being, none of this applies to Rembrandt unfortunately. I consider myself fairly familiar with FG, including its internals - and I am generally able to make FG work well enough on most systems - in fact, I am the one who started the corresponding wiki articles to document such tips - I have yet to see sufficient "configuration advice" from Rembrandt evangelists.
I would also very much like to see Rembrandt development to continue, and I might even contribute to such an effort - but for that to happen, a few other things need to happen first, including more/better developer docs - Rembrandt is covering a lot of uncharted waters, i.e. areas in FG to which only long-time contributors like Fred, Tim or Mathias have contributed.
Given Thorsten's recent C++ patches to the rendering pipeline, he seems to be well on his way to actually understand/document such code paths than any other active contributor.
Personally, I am frankly easily distracted by stuff that I find more interesting than investigating Rembrandt's performance issues, and I don't consider shadows essential either - but Rembrandt development will either need to be picked up by Fred himself, or we'll inevitably have to do a lot of research, trial & error and documenting to make heads and tails of the code.
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: 11329
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Graphics

Who is online

Users browsing this forum: No registered users and 1 guest