Re: [Flightgear-devel] Random vegetation and Atmospheric light scattering (was Re: Shader menu structure)
Hi Stuart, Question for Thorsten: I've only integrated the terrain-haze.[vert|frag], not terrain-haze-detailed.[vert|frag]. How much additonal quality does that add, and is it appropriate for trees? I'm in the middle of my holiday right now and will basically be mostly offline for another week - so I can't actually pull current GIT and test anything at the moment. The detailed version of the shader offers in addition the snow cover, the dust cover and the structured fog option (in addition some things are planned which only exist in my mind at the moment...). Snow is a bit of an open issue - both trees without snow sticking out of snow cover and snow-covered trees can occur, but in any case trees should never make use of the default snow texture. Trees can be dusty. For the structured fog, I don't think it makes any difference. My impression is that using the default shaders is just fine, the problems created when anyone runs the detailed version for the terrain and default version for trees are very minor, very low priority, need special attention and should be bumped way down the priority list. In short, I think it's very reasonable how you've done it. Cheers, * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader menu structure
I get to see a seamless and plausible match between sky and terrain from ground level to low Earth orbit, at all times of the day and under any weather condition. Scenery and models are now rendered correctly with the sky at all locations and all times. Really? Look at the trees- Does they blend correct here? http://www.hoerbird.net/Treeblend.jpg Heiko, you really walked into this... I wrote 'scenery and models', I did not write 'trees'. I explained earlier: quote myself: http://www.hoerbird.net/fgfs-screen-764.jpg illustrates that the random vegetation shader isn't converted - trees are fogged too weakly as compared with the rest of the scene. Which of these two statements did you find hard to understand? We have shaders. We decided once ago to haven them. And when a user is also able to have them, as his computer allows them to have, he wants to have them all of course. And what's the relevance of this? I want plenty of things... Someone with GLSL knowledge to explain things to me so that I can get rid of trial and error based development for starters. Someone who learned digital image processing to help me with cloud texture extraction. Someone who flies his own plane to take GPL compatible semi-ortho-images to create textures and to take aerial images of some rare cloud types. I want people to pick up some of the space capabilities of Flightgear, create orbiting AI model code and some more spacecraft so that we could fly to ISS. Do I get any of these things? No, I don't, and I'm guessing there is a reason every no. I know pretty well what what users want - you can get a good impression here for instance: http://www.flightgear.org/forums/viewtopic.php?f=68t=16800 Everything should be as realistic as possible, but under no circumstances should it lead to a loss of framerate, and every idea needs to be implemented yesterday. So, yes, users may want to use all shaders at the same time, but as I (and Emilian) have said a few times by now, it is not simple to do and takes development time, and time is a rare commodity. So people may wish for it all they want, but that doesn't give me the time to do it, and as long as my time is the limiting factor, it gets done when I have time, end of story. You can pick it up and do it if you want it done faster. Besides, I'll take a 50 Euro bet that once all shaders are working together, we get frequent complaints that the framerates are very low from users which max out all quality sliders. So then the users simply want different things. Anyone wants to take that bet? The user doesn't want to check everytime which of the shaders is compatible with others. That's one BIG secret behind the success of some flightsimulators and even a requirement there. If a shader can be deselected, than just for perfomance reasons, but not due to being not compatible with other shaders. Well, he doesn't have to check anything - incompatible shaders are de-selected automatically. In essence, your suggestion is to 'dumb down' flightgear and not to offer any features which are not completely integrated with everything else because the user may not be willing to accept that not everything works with everything else. Sounds like a bad idea to me. We are not a commercial enterprise, and we play by different rules. Trying to adopt commercial development strategies will only make us fail. And that's exactly the problem here. We had no consistently way in developing and adding shaders. I beg to differ - you are not in shader development. I am, and I have talked on and off-list with Emilian, Fred and Vivian who also are (sometimes a lot), and I would say that we have a pretty clear picture of what the issues are and a general agreement what the development goals are (we also have some disagreements over details how to solve particular problems). Nobody disputes that eventually aircraft shaders should work with Rembrandt and atmospheric scattering. 1.)Zan's shader was known that it gave artifacts on the horizon. But it wasn't plain wrong. Show me the screenshot from 2.6 with visibility set to 3000 m, skydome shader on and repeat your claim (I'll also take the sunrise picture from cruise altitude). It was included in the hope that this issue can be solved. Now you introduced a shader which doesn't have problems with the horizon, but other shaders doesn't work. If you don't like the solution, then show me a better one. Anyone who understands shader development agrees on how to solve the horizon problem. There is no known solution which does not require to re-write all other shaders to some degree, which means that other shaders don't work till this is done. It is not really an improvement- unless you just look at the horizon and nothing else. Common sentiment seems to be that atmospheric scattering does quite spectacular things, but I take note of your different opinion. Personally, I
Re: [Flightgear-devel] Shader menu structure
Thorsten, What I really, really hate in FlightGear's last years developement, is how the ego of some people involved (yes, I think that's include me as well) seems to make things and discussions more and more difficult. And this discussion shows it again. But maybe it is only the translation from german to english and from english to german we both have to do make things here difficult. But well, the whole discussion was more or less my fault- I have been warned off-list that I will open a can of worms with my posting*sigh* Again: I criticed NOT YOU as person, simply the way what happend with the shaders, and especially the atmospheric shader. As you was the main developer behind the atmospheric shader, you was being adressed. So no reason the get polemic or arrogant: I wrote 'scenery and models', I did not write 'trees'. ... Which of these two statements did you find hard to understand? However, I simply I had the feeling that I somewhere read that there has been a more simple way proposed to have your shader working together along with the other shaders. Don't worry - I really, really understand, that you have a different view on it, and my proposal to get a middle thing isn't a good solution. That's why I asked, and that's why I got clear and understandable answers here- unfortunately just not from you. You have to know that beeing involved myself since 2006, (more than as a simple stupid user) I think I'm allowed to say what I think what is mabye not right. That doesn't mean of course I'm right at the end. That doesn't mean that really everyone thinks so. But different to a closed project, in FGFS different views, even from outside, are sometimes wished and accepted. But something like that...: And what's the relevance of this? I want plenty of things... Someone with GLSL knowledge to explain things to me so that I can get rid of trial and error based development for starters. Someone who learned digital image processing to help me with cloud texture extraction. Someone who flies his own plane to take GPL compatible semi-ortho-images to create textures and to take aerial images of some rare cloud types. I want people to pick up some of the space capabilities of Flightgear, create orbiting AI model code and some more spacecraft so that we could fly to ISS. Do I get any of these things? No, I don't, and I'm guessing there is a reason every no. ... could have written in one short sentence: Sorry, some things goes behind my knowledge, that's why it isn't there. If anyone interested to help, you are welcome! or anything like that. or There is currently no technical way in the moment to do so. Accetable by everyone, even by me ;-). But flooding with texts, especially in a manner that others make looks like a dumbhead makes you look like being ignorant and shows some strange attitude to some. And at the end we wonder we have it again, that people come up and say Uh, there is now way to contribute; there are all feeling like elites..; the don't listen to users; ... etc, etc. I hope you understand, then at least that's exactly the feeling I got here with your replies, and I hope that wasn't that what you wanted. Everything should be as realistic as possible, but under no circumstances should it lead to a loss of framerate, ... Sorry, that's the goal of every flight simulator: realistic as possible, perfomance friendly as possible. Only knowledge and hardware is the limit here, and this limit is pushed further every year. In essence, your suggestion is to 'dumb down' flightgear and not to offer any features which are not completely integrated with everything else because the user may not be willing to accept that not everything works with everything else. Sounds like a bad idea to me. We are not a commercial enterprise, and we play by different rules. Trying to adopt commercial development strategies will only make us fail. Again: my whole statements was from users point of view. FlightGear was based on the idea to be an alternative to MSFS for many reasons. Since then, up to this day we are being measured with MSFS and other flight simulations, commercial or free. The good thing is, and there I agree, that we aren't bound on earning money, so we can make things without the risque beeing not that successful with. That makes us indeed strong! But that doesn't mean that we should forget users- Because the users from today are the developers from tomorrow and NO, in this context I don't mean problems with framerates here. Users and heir contributions are our gain, not money. But you also wouldn't have made such a statement if you wouldn't have forget that FGFS is used in some research and even commercial projects, and that's even one goal of our project. I hope you are aware that under Users are not only meant pimpled teenagers with a bag of crisps sitting in front of their computers. While our big
Re: [Flightgear-devel] Default materials.xml file (was Re: Hawaii regional textures merge request)
On Tue, Jul 3, 2012 at 11:25 AM, Stuart Buchanan wrote: On Sat, Jun 9, 2012 at 8:27 PM, Stuart Buchanan wrote: I wonder whether we should set the regions/materials.xml as the default in preferences.xml? They represent a significant improvement to texturing in the regions that are defined. Hi All, I don't think I saw any response to this either for or against. I realize it's a bit late, but I'd still like to do this for the 2.8.0 release. Any objections? As you may have noticed (if you fly in Europe or Hawaii!), I've changed the default in preferences.xml After the release I may also see if we can have the materials.xml file selectable from a dialog and re-loadable from in-sim. FYI, I already have this working and will commit it after the release. This should make creating new regional material definitions much easier, as you'll be able to edit the materials.xml file and simply reload it rather than having to restart FG. I'm also working on some regional improvements for the Caribbean, which I'll also commit after the release. -Stuart -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autosave question
Hello, I have a problem with autosave when using the same property in a variant/livery file and with the aircraft-data-mechanism. Let's assume that in the livery.xml-File the properties A=3 and B=5 are set. During flight I manipulate property B to B=10. Property B is autosaved with the aircraft-data-mechanism in myaircraft-set.xml. After restart I get B=5 instead of B=10. I found out that in the aircraft-autosave-file ~/.fgfs/aircraft-data/myaircraft.xml property B AND the variant name are stored. I assume that at restart first the aircraft-data properties are read (B=10) and subsequent the variant name, which overwrites B with the value in the variant.xml-File. Question 1: Is there a possibility to define the order properties are read from the autosave-file at restart? I think in my case first read the variant name and then the properties would do the job. Question2: Alternatively I could live without storing the variant name in the autosave-file. Unfortunately I'm not able to do this with the archive/userarchive-method ( I set the following in all my variant-files: sim model livery name type=string archive=nDefault/name /livery myaircraft name type=string archive=nDefault/name ). What's wrong with this? Do I have to do something else? Question 3: Maybe there is an other solution to my problem? Thanks in advance! Best regards D-NXKT -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
