Re: [Flightgear-devel] Atmospheric Light Scattering
Hi Henri, However your approach is questionable. I can understand you are working on an other FlightGear variant for yourself. (...) It is not the Atmospheric Light Scattering, we want. Who is the 'we' you're claiming to represent? I look at the FGUK weekly flight screenshots in the forum, and pretty much everyone there is using ALS. I look at some recent scenery projects (Russia, New Zealand) - and I see people playing with the procedural texturing of ALS. So *you* may not want it, but you're not representing 'the community', you're representing yourself here. And you know what? You can simply never switch it on if you don't like it, and that solves it all. It's a bit beyond me how you could possibly be bothered by a feature you currently actively have to switch on. (And even if I were the only person interested in using it, it would still be perfectly legitimate for me to work on what interests me rather than the rest of the users - this is my spare time we're talking about.) You call it Atmospheric Light Scattering, you could call it Renk ALS I could at that, but it's handed out to the community under GPL, so it doesn't belong to me, it belongs to whoever adheres to GPL. We want, so far, a consistent flightgear system, any features should be compatible each other, and not breaking each other. First, you haven't read what I wrote: There is nothing 'broken' by ALS - everything you're using when ALS is off works just the same as if you would remove the whole framework (if you disagree, name me a single Rembrandt feature that doesn't work any more because ALS blocks it). The only implementation which actually prefers Basic Weather consistently over Advanced Weather (and hence in a sense breaks things, although one can to some extend hack around it) is the environment interface of the default (and Rembrandt) rendering framework - which is designed by the very person who brought up the idea that I would break things. Second, you're applying double standards here. Rembrandt (which you like) is massively incompatible with the default rendering framework at a much deeper level. It requires to modify aircraft to even see through cockpits, it requires likewise to re-write every effect and shader. You seem to have zero issue with this, but taking your argument seriously, you would have to be against Rembrandt. Of course you personally like Rembrandt but not ALS, so it's okay if Rembrandt is incompatible with the default, but not ALS - I don't have a particularly high opinion of such types of arguments. What about Rembrandt ? To reproduce the reality, isn't it the main tool which gives the best effect ? Won't the effort should done on that side ? What you're asking is really 'I like Rembrandt better, so why don't you work on it?' Let me ask you back - I like ALS better, so why don't you ask FredB to work on ALS instead? Makes just as much sense. As for Rembrandt being superior, Rembrandt is a different engine, not a set of different effects. As such, it has more potential, because it can potentially do the same things ALS can do and still add multiple light sources and shadows. As has been mentioned a few times, ALS can be ported to Rembrandt by re-writing the effects, but this isn't something I am personally so interested in that I would do it completely on my own, and unless a volunteer appears to do it with me, that's all there is to say. Currently I would claim that ALS delivers more realistic outside scenes at daytime and at sunrise/sunset, whereas Rembrandt wins for aircraft interior, close to the ground when shadows are important and at night where multiple light sources are important. I hope that the next Flightgear version will offer a consistent system and not several independents systems ( including your Flightgear) which won't be compatible each other. I hope you have the fairness to ask FredB to remove Rembrandt then as well, because we need to ship the default rendering scheme such that users without good graphics cards (the integrated intels for instance) can use FG at all, and neither Rembrandt not ALS are compatible with default. I mean, what is this really about? You're seriously bothered by a framework you especially have to activate, which doesn't break any of the features you like to the degree that you blatantly ignore the significant group of users who uses ALS and claim to represent 'the community' and invent 'broken things' for which you can't give a single example'? And you expect me to... do what? Code what you like instead of what I like? Please... can we keep some basic fairness and decency here? * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app,
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 01:34:12 henri orange wrote: It is not the Atmospheric Light Scattering, we want. Referring to your explanation, and some other talks you had with Emilian ( who unfortunately gave up ), you are ignoring the flightgear users community interest. It is not the Atmospheric Light Scattering, we want. Please do not pretend to speak for all FlightGear users. You may certainly speak for yourself, you may even represent some part of the users, but you do not speak for all of us. I am a user and let me make this clear: I love Atmospheric Light Scattering. I love that it makes the view in the simulation match almost perfectly what I see outside the window. For me as a VFR pilot, visibility is one of the most important parts of a simulation and ALS doesn't only get it right, it also looks stunningly beautiful at that. We want, so far, a consistent flightgear system, any features should be compatible each other, and not breaking each other. If you ask me, the way to achieve that is to just drop the default rendering scheme. It's clearly inferior and makes FG look quite unprofessional. But even though the free radeon drivers are nowadays good enough to allow me to use ALS, some people simply have not the hardware necessary for good performance. And for them the default rendering scheme may still have use. What about Rembrandt ? To reproduce the reality, isn't it the main tool which gives the best effect ? Won't the effort should done on that side ? Like for some people's machines ALS might be too much, Rembrandt certainly is too much for mine. Last time I tried, I still get graphics corruption and poor rendering performance, so it's not an option for me. And as I said, there are people with less powerful hardware than me. So if FG would only use Rembrandt, it would leave plenty of users behind. I hope that the next Flightgear version will offer a consistent system and not several independents systems ( including your Flightgear) which won't be compatible each other. What about Thorsten' arguments? Why is it so important for _some_ users that the different rendering schemes support exactly the same features. Or in other words: why should ALS users have to forgo very nice features, just because the default rendering scheme does not support them? And why do you think Thorsten is responsible for implementing all features in all rendering schemes? If certain features are so important for you, why don't _you_ contribute? This is free software after all. Regards, Stefan -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thu, 25 Apr 2013 06:24:41 +, Renk wrote in message e495a106ff5f31448739e79d34138c192a740...@mbs4.ad.jyu.fi: Hi Henri, However your approach is questionable. ..Stefan addressed this properly. ;o) Please... can we keep some basic fairness and decency here? ..yes, but we also need some patience with non-native English writers who _should_ include their French etc original so we don't get people wound up on questionable translations of things that may warrant discussion. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
..yes, but we also need some patience with non-native English writers who _should_ include their French etc original so we don't get people wound up on questionable translations of things that may warrant discussion For the record, there is a repeating pattern here on and off list and I don't think I'm overreacting. I don't think you are ignoring the flightgear users community interest, features should be compatible each other, and not breaking each other or You call it Atmospheric Light Scattering, you could call it Renk ALS are particularly prone to mistranslation or are intended to mean something else. I'm not wound up about wording here. I'm wound up about 1) Repeated insinuations that I would 'break' things. Somehow, nobody can seem to come up with an example of what I have actually broken. So I think I'm not out of line in asking that people either say what they think I broke (and give me a chance to fix it) or shut up. 2) A complete lack of explanation why simply not switching on a completely optional framework which they don't like is not an acceptable solution to some people. 3) The inherent double standard in arguments that if other people do the same thing it's completely okay, but if I do it it's very bad. Could somebody who disagrees with me just spell out what I'm supposedly doing wrong, what I should rather be doing and explain to me why? Rather than insinuating, making vague statements, expressing unspecified concerns, hinting at some unspecified group which would be of the same opinion but never committing to any statement which can actually be investigated? Because I'd really really like to see that case reasoned. Thanks, * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Le jeudi 25 avril 2013 06:24:41 Renk Thorsten a écrit : Hello, Renk I hope you have the fairness to ask FredB to remove Rembrandt then as well, because we need to ship the default rendering scheme such that users without good graphics cards (the integrated intels for instance) can use FG at all, and neither Rembrandt not ALS are compatible with default. So, your long answer to explain you don't like Rembrandt and you prefer to work on your own system, as just been underlined there by you. Your conclusion is REMOVE REMBRANDT and keep up my own development This clarify to everybody your approach. You want a flightgear without Rembrandt. You claim we have to modify models to get it working with rembrandt, the same kind of work ( more difficult) had to be done when the shaders came up. And what about the FDM improvements? where the updates introduce more time and more difficulty ( talking about JSBSIM, since YASIM seems to be frozen ). Your claim is not receivable, since models must get the best improvements due to the last flightgear version. You claim Rembrandt wants high level Hardware my 9600 GT 512 mb can process it. With An average of 20 fps ( disabling rembrandt and without ALS i never get more than 30 fps). Your ALS systems wants (when it is not crashing my system) a higher level capacity Hardware ( mostly GPU ) to work correctly, with every features. Only the first ALS version tried out 2 years ago was good to me ( and some others later on, but not today) You told us you had the most perfect equipment , you can't evaluate what is good or wrong with low level equipments. I mean, what is this really about? You're seriously bothered by a framework you especially have to activate, which doesn't break any of the features you like to the degree that you blatantly ignore the significant group of users who uses ALS and claim to represent 'the community' and invent 'broken things' for which you can't give a single example'? And you expect me to... do what? Code what you like instead of what I like? I don't mean i don't like ALS, i mean i don't like your approach , instead of working on consistency with the existing valuable features which were implemented within FlighGear, ( and by including Rembrandt), you ARE WORKING on a other FlightGear. You are working on a flightgear VARIANT, your work is not OPTIONS to flightgear. Others , better than me, tried before me to tell you, you (are) were on the wrong way. Unfortunately we are missing the Emilian's know how, he gave up because of that approach ( because of you). Hello Arnt, Yes English is not my native language, and wrong to me, mostly when i had not talked for a long time ( better with Arabic and partly French ). Ahmad, (Henri) -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 14:45:05 henri orange wrote: So, your long answer to explain you don't like Rembrandt and you prefer to work on your own system, as just been underlined there by you. Your conclusion is REMOVE REMBRANDT and keep up my own development This clarify to everybody your approach. You want a flightgear without Rembrandt. Thorsten did not even remotly say anything like that. Your accusation is completely uncalled for. If this is what you read in his last email, please try to find someone who reads Thorsten's English the way he meant it and have him explain to you. It would be a shame if a solution would fail due to a language barrier. You claim Rembrandt wants high level Hardware my 9600 GT 512 mb can process it. With An average of 20 fps ( disabling rembrandt and without ALS i never get more than 30 fps). On a Radeon HD 5670 I get 3 (in words: three) FPS with Rembrandt using the free radeon drivers with lots of graphics problems and very ugly shadows. On the other hand I get solid 15-20 FPS using ALS and pretty maxed out quality. Your ALS systems wants (when it is not crashing my system) a higher level capacity Hardware ( mostly GPU ) to work correctly, with every features. Maybe. On some systems it ALS might be a problem, on others it's Rembrandt. You told us you had the most perfect equipment , you can't evaluate what is good or wrong with low level equipments. And you have only your own system for comparison. Just like I only got mine. And yours and mine certainly don't match. So while maybe Thorsten cannot give general adivse on FG's performance on low level equipment, neither can you and neither can I. I don't mean i don't like ALS, i mean i don't like your approach , instead of working on consistency with the existing valuable features which were implemented within FlighGear, ( and by including Rembrandt), you ARE WORKING on a other FlightGear. You are working on a flightgear VARIANT, your work is not OPTIONS to flightgear. I can start FG, go to the rendering _options_ and turn ALS on and off, at runtime, as often as I like. How is this not an option? Others , better than me, tried before me to tell you, you (are) were on the wrong way. And Thorsten time and again explained on solid technical grounds why he implemented it the way he did, why he had to and what the consequences of other approaches would have been. I have to date not seen anyone even acknowledge these reasons, much less provide real arguments against them. Why Thorsten has not given up on this yet is just beyond me. This is not a discussion, it's just handwaving and accusations. I'm just very glad, that he didn't give up. So instead, I can enjoy as much of the great flying experience as I can get during the long winter months. And just to be clear: I'd love to have all the goodies combined. Very nice shadows provided by the Rembrandt defered renderer combined with stunning ALS visuals and correctness and the performance of the default renderer with all effects turned off. But that's simply not possible, so instead I enjoy what _is_ possible. Regards, Stefan signature.asc Description: This is a digitally signed message part. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Thorsten ..yes, but we also need some patience with non-native English writers who _should_ include their French etc original so we don't get people wound up on questionable translations of things that may warrant discussion For the record, there is a repeating pattern here on and off list and I don't think I'm overreacting. I don't think you are ignoring the flightgear users community interest, features should be compatible each other, and not breaking each other or You call it Atmospheric Light Scattering, you could call it Renk ALS are particularly prone to mistranslation or are intended to mean something else. I'm not wound up about wording here. I'm wound up about 1) Repeated insinuations that I would 'break' things. Somehow, nobody can seem to come up with an example of what I have actually broken. So I think I'm not out of line in asking that people either say what they think I broke (and give me a chance to fix it) or shut up. 2) A complete lack of explanation why simply not switching on a completely optional framework which they don't like is not an acceptable solution to some people. 3) The inherent double standard in arguments that if other people do the same thing it's completely okay, but if I do it it's very bad. Could somebody who disagrees with me just spell out what I'm supposedly doing wrong, what I should rather be doing and explain to me why? Rather than insinuating, making vague statements, expressing unspecified concerns, hinting at some unspecified group which would be of the same opinion but never committing to any statement which can actually be investigated? Because I'd really really like to see that case reasoned. ALS is very impressive work, but things broken? Have you forgotten the flag shader (now fixed), wake effect and rainbow effect? I don't have a particular problem with these and hope that they will be fixed eventually, although I note that do you seem to have raced on to other things while leaving the wake effect unfixed for some time. I rather fear that that's just going to get lost in the noise and general excitement over the latest bit of eye-candy. I think a more general concern would be that we seem to be developing 3 or 4 different Flightgears, in which different things work or not as the case might be: Rembrandt Basic weather/Advanced Weather Atmospheric Light Scattering (ALS) As a developer I have only just finished making my models Rembrandt compatible, and I don't know if I will ever be able to actually make use Rembrandt facilities in all of them. I'm sure that there are models in our inventory which haven't even got that far. As I understand it, ALS will include modelling facilities which will not work in the other flavours of FG. How is this meant to be used? Personally, I seem to be forever fixing things in my models that others have broken, to the extent that I'm not actually able to move my own work forward. That's how it feels anyway. In an ideal world everything would work and be compatible with everything else. I realise that might involve a number of intermediate steps to reach the final goal, but right now we seem to be moving our flavours further apart rather than converging them. What are aircraft developers and/or users meant to make of this ? As to Emilian's concerns, I don't really understand the technical details, but I do know that he felt that his advice and expertise was being ignored with the result that FG was headed in the wrong direction, so he folded his tent and left the project. Perhaps you received contrary advice, or considered that his advice wasn't of value, but we never had that debate IIRC. We could have done with not ending up like that. Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - but from where I'm standing we all seem to be a doing a fair representation of a headless chicken, rushing about in all directions without really finishing anything. I'm having difficulty keeping up with it, but I know that all this work has exciting potential. Oh - and btw the ALS still shows up a tear in the skydome that we have had right from the beginning. I thought perhaps it would be helpful if a native English speaker tried to put things in perspective, Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Re: [Flightgear-devel] Atmospheric Light Scattering
Hi, Stefen On Thursday 25 April 2013 14:45:05 henri orange wrote: So, your long answer to explain you don't like Rembrandt and you prefer to work on your own system, as just been underlined there by you. Your conclusion is REMOVE REMBRANDT and keep up my own development This clarify to everybody your approach. You want a flightgear without Rembrandt. Thorsten did not even remotly say anything like that. Your accusation is completely uncalled for. If this is what you read in his last email, please try to find someone who reads Thorsten's English the way he meant it and have him explain to you. It would be a shame if a solution would fail due to a language barrier. Here is quoted Renk sentence himself: I hope you have the fairness to ask FredB to remove Rembrandt then as well, because we need to ship the default rendering scheme such that users without good graphics cards... You claim Rembrandt wants high level Hardware my 9600 GT 512 mb can process it. With An average of 20 fps ( disabling rembrandt and without ALS i never get more than 30 fps). On a Radeon HD 5670 I get 3 (in words: three) FPS with Rembrandt using the free radeon drivers with lots of graphics problems and very ugly shadows. On the other hand I get solid 15-20 FPS using ALS and pretty maxed out quality. Does'nt ATI known to be the wrong choice to play FG ? Your ALS systems wants (when it is not crashing my system) a higher level capacity Hardware ( mostly GPU ) to work correctly, with every features. Maybe. On some systems it ALS might be a problem, on others it's Rembrandt. You told us you had the most perfect equipment , you can't evaluate what is good or wrong with low level equipments. And you have only your own system for comparison. Just like I only got mine. And yours and mine certainly don't match. So while maybe Thorsten cannot give general adivse on FG's performance on low level equipment, neither can you and neither can I. Said before you are in difficulty because of ATI. At least i evaluate with an NVIDIA equipment. If i can do with a medium/low system, it can be done with a better (NVIDIA based) equipment. Don't try to trap me in an inconsistency logical mind :) These differences of performances versus one Factory system to an other ( NVIDIA, ATI, INTEL ) is due to OpenGL more or less correctly implemented within these GPU. Nothing else. And, but, change of policy within FlighGear, OpenGL remains. I don't mean i don't like ALS, i mean i don't like your approach , instead of working on consistency with the existing valuable features which were implemented within FlighGear, ( and by including Rembrandt), you ARE WORKING on a other FlightGear. You are working on a flightgear VARIANT, your work is not OPTIONS to flightgear. I can start FG, go to the rendering _options_ and turn ALS on and off, at runtime, as often as I like. How is this not an option? I know my english is wrong, however, i know the difference between VARIANT and OPTION. Right know there is options with shaders , clouds weathers etc. Variants with Rembrandt and ALS. Others , better than me, tried before me to tell you, you (are) were on the wrong way. And Thorsten time and again explained on solid technical grounds why he implemented it the way he did, why he had to and what the consequences of other approaches would have been. I have to date not seen anyone even acknowledge these reasons, much less provide real arguments against them. Why Thorsten has not given up on this yet is just beyond me. This is not a discussion, it's just handwaving and accusations. I'm just very glad, that he didn't give up. So instead, I can enjoy as much of the great flying experience as I can get during the long winter months. And just to be clear: I'd love to have all the goodies combined. Very nice shadows provided by the Rembrandt defered renderer combined with stunning ALS visuals and correctness and the performance of the default renderer with all effects turned off. But that's simply not possible, so instead I enjoy what _is_ possible. Regards, Stefan -- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 15:41:54 henri orange wrote: Here is quoted Renk sentence himself: I hope you have the fairness to ask FredB to remove Rembrandt then as well, because we need to ship the default rendering scheme such that users without good graphics cards... I know, you cited it the first time as well. But it simply does not mean what you obviously think it means. That's why I kindly asked you, to have someone explain it to you in your native language. Thorsten only said, that _if_ you ask him to remove ALS because of concern for users without good graphics cards, you should aks FredB as well to remove Rembrandt, because the same argument would apply. Not doing it just shows that different standards are applied which is simply unfair. Does'nt ATI known to be the wrong choice to play FG ? No it doesn't. To cite http://wiki.flightgear.org/Supported_Video_Cards you should be fine with any Nvidia or AMD/ATI products having 512-1024MB of *dedicated* video memory. Said before you are in difficulty because of ATI. Ok, so I'm in difficulty because of ATI (which do not even exist anymore, it's been AMD for 7 years now) and therefore Rembrandt is ok. But if you have problems with ALS, it's not your NVIDIA hardware that's the problem, but ALS. Because clearly, your hardware is more important than mine and FG developers should develop for your system only. Right? I know my english is wrong, however, i know the difference between VARIANT and OPTION. Right know there is options with shaders , clouds weathers etc. Variants with Rembrandt and ALS. So please enlighten me and tell me what in your eyes is the difference between a variant and an option and why the distinction is important. As a user, I can simply decide at runtime if I want ALS or not by clicking a checkbox in an options panel. So why is ALS a problem for a user who doesn't want to use it? Regards, Stefan signature.asc Description: This is a digitally signed message part. -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Hi Vivian, I'm not going to address the high level debate, but I have some specific comments. On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: I think a more general concern would be that we seem to be developing 3 or 4 different Flightgears, in which different things work or not as the case might be: Rembrandt Basic weather/Advanced Weather Atmospheric Light Scattering (ALS) I've just put in some effort recently to ensure that Basic Weather can take advantage of ALS properly. So while we retain two weather models, there's no longer a dependency of ALS on Advanced Weather. So we're moving in the right direction here. I've also taken a bit of a look at merging Rembrandt and ALS, and I think I understand the Rembrandt pipeline enough that I could add ALS to it. I'm very keen to promote a more consistent experience so that new users don't encounter confusing differences between alternative rendering schemes, and I'm prepared to put time into making that happen. I'll take a look at the wake shader if you want, but I supect you'd prefer me to fix some of the other issues you raised below first :). Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've not had any time to look at the screenshot/terrasync directory issue. I strongly suspect that I could fix it, but I only have so many hours in the day, and as mentioned before am spread pretty thin. Personally I think most of the active FG devs are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On 25 Apr 2013, at 15:28, Stuart Buchanan stuar...@gmail.com wrote: I've not had any time to look at the screenshot/terrasync directory issue. I strongly suspect that I could fix it, but I only have so many hours in the day, and as mentioned before am spread pretty thin. I suspect both of these are my 'fault', but equally I was only made aware of the TerraSync one a few weeks ago, and the screenshot one, this is the first I've heard of it. In both cases a defect in bug tracker, CC-ed to me, with some detailed information, would greatly help, since these are not features I use, so I need to know what behaviour is considered 'right'. In particular saying it should work 'as it always did' is not helpful. In the particular case of the Terrasync path I am especially confused because it's not possible to change the terrasync path once fgfs is running, as never has been as far as I know; since we can't adjust scenery paths with restarting the sim. So, to re-iterate, the defect really needs to explain what the intended use-case was here, since I am clueless. BTW, concerning the larger issue of different rendering pipelines / approaches, my opinion is, and remains, that the long-term solution is separate viewer codebases - while a plethora would be bad, we would already benefit from a 'fixed-function, no shaders' renderer codebase distinct from a Rembrandt renderer and modern, forward-rendering OpenGL 3.x pipeline. This needs the viewer to be cleanly split out from the simulation backend, via HLA, which is exactly what Mathias (and soon, myself) are working towards, but slowly. Regards, James-- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Stuart -Original Message- From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 25 April 2013 15:28 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric Light Scattering Hi Vivian, I'm not going to address the high level debate, but I have some specific comments. On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: I think a more general concern would be that we seem to be developing 3 or 4 different Flightgears, in which different things work or not as the case might be: Rembrandt Basic weather/Advanced Weather Atmospheric Light Scattering (ALS) I've just put in some effort recently to ensure that Basic Weather can take advantage of ALS properly. So while we retain two weather models, there's no longer a dependency of ALS on Advanced Weather. So we're moving in the right direction here. I've also taken a bit of a look at merging Rembrandt and ALS, and I think I understand the Rembrandt pipeline enough that I could add ALS to it. I'm very keen to promote a more consistent experience so that new users don't encounter confusing differences between alternative rendering schemes, and I'm prepared to put time into making that happen. I'll take a look at the wake shader if you want, but I supect you'd prefer me to fix some of the other issues you raised below first :). Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've not had any time to look at the screenshot/terrasync directory issue. I strongly suspect that I could fix it, but I only have so many hours in the day, and as mentioned before am spread pretty thin. Personally I think most of the active FG devs are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs. Couldn't we just! All the more reason not to bite off more than we can chew. And I know I owe you a more detailed response on the tree stuff - later today perhaps. While I'm on a roll we have had this one in terrasync at KSFO for I can't remember how many years: Could not find at least one of the following objects for animation: 'terminal_2' when using Terrasync data at KSFO, And this one seems to be new: Failed to create alias at /controls[0]/refuelling[0]/refuelling-drogues-pos-norm [0]. Source /sim[0]/multiplay[0]/generic[0]/float[2] is already aliasing another property. Failed to set alias to /controls/refuelling/refuelling-drogues-pos-norm With that I'll get back to some more useless eye-candy of passing sub-models over mp which I left as a TODO more years ago than I care to mention. I promise not to break anything though :-). Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thursday 25 April 2013 15:41:54 henri orange wrote: Here is quoted Renk sentence himself: I hope you have the fairness to ask FredB to remove Rembrandt then as well, because we need to ship the default rendering scheme such that users without good graphics cards... I know, you cited it the first time as well. But it simply does not mean what you obviously think it means. That's why I kindly asked you, to have someone explain it to you in your native language. Thorsten only said, that _if_ you ask him to remove ALS because of concern for users without good graphics cards, you should aks FredB as well to remove Rembrandt, because the same argument would apply. Not doing it just shows that different standards are applied which is simply unfair. First , it is not because i am unable to write English correctly, i can't understand it written. Suggesting to ask for removing Rembrandt gives enough to conclude. On the other side i did not asked to remove ALS only to develop in the good direction. Which is a huge difference. (though , just reading the last Stuart Buchanan Mail which can close the debate ) Does'nt ATI known to be the wrong choice to play FG ? No it doesn't. To cite http://wiki.flightgear.org/Supported_Video_Cards you should be fine with any Nvidia or AMD/ATI products having 512-1024MB of *dedicated* video memory. Which is the problem, giving a list of GPU supposed to be compliant, is the most difficult. First look at OpenGL compliance. Don't be confident in such list. The best would be to refer to the experience from others, when we can. I had first before using FG an ATI card, at that time i had a lot of difficulties to get a driver working with Linux. When i had to update my equipment 3 years ago i did not refer to any list but followed the suggestions ( from FG users) to choose an NVIDIA GPU. I can notice the permanent work in progress with the OpenGL drivers there: ftp://download.nvidia.com/XFree86/Linux-x86_64/ that was enough to secure the choice. When i get enough money my next equipment will be also with NVIDIA, for the same reason. Spare time and money. Said before you are in difficulty because of ATI. Ok, so I'm in difficulty because of ATI (which do not even exist anymore, it's been AMD for 7 years now) and therefore Rembrandt is ok. But if you have problems with ALS, it's not your NVIDIA hardware that's the problem, but ALS. Because clearly, your hardware is more important than mine and FG developers should develop for your system only. Right? I know my english is wrong, however, i know the difference between VARIANT and OPTION. Right know there is options with shaders , clouds weathers etc. Variants with Rembrandt and ALS. So please enlighten me and tell me what in your eyes is the difference between a variant and an option and why the distinction is important. As a user, I can simply decide at runtime if I want ALS or not by clicking a checkbox in an options panel. If you don't like the words option versus variants ( direction ) Let me give an example. If sitting at Zeralda, if i have some time for visiting my country one variant is visit Constantine, the other is to visit Bou Saada both are not the same direction. To travel i have several options: i can choose on the map: paths or roads or highway, i can choose at my home: mule (the best friend of my children) or motorcycle (a collector one ) or a Mercedes ( an old one ). So why is ALS a problem for a user who doesn't want to use it? Regards, Stefan BTW: after the points by Vivian, i am just reading the last Stuart Buchanan's Mail which can close the debat. Though it does not modify my feeling ALS development related. -- -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Stuart, This could be the best news I heard today! :) In addition to core developers, just a thought that just came to me while reading today's mail: IMHO I realize that the project lacks a Project Manager or at least a meeting where priorities would be set for the Devs to fix/implement BEFORE proceeding to extra feature. I know we all love to start pursuing our ideas at the time they are conceived due to excitement, but this should occur after the previous goals have been met, that is if the already existent, yet experimental shaders/models/whatever have reached a predetermined Release state where they work seamlessly with everything preceeding them. Think of it as a CHECK LIST! Branching and testing/experimenting is good, of course, but we need here something/someone that will make sure by providing the resources/info gathering/moderation for the Devs to bring the individual subprojects up to a e.g. Release state for merging them to function together! Thank you! -Klearchos SE-MUA Sent from my Gentoo-phone On 25 apr 2013, at 16:29, Stuart Buchanan stuar...@gmail.com wrote: Hi Vivian, I'm not going to address the high level debate, but I have some specific comments. On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: I think a more general concern would be that we seem to be developing 3 or 4 different Flightgears, in which different things work or not as the case might be: Rembrandt Basic weather/Advanced Weather Atmospheric Light Scattering (ALS) I've just put in some effort recently to ensure that Basic Weather can take advantage of ALS properly. So while we retain two weather models, there's no longer a dependency of ALS on Advanced Weather. So we're moving in the right direction here. I've also taken a bit of a look at merging Rembrandt and ALS, and I think I understand the Rembrandt pipeline enough that I could add ALS to it. I'm very keen to promote a more consistent experience so that new users don't encounter confusing differences between alternative rendering schemes, and I'm prepared to put time into making that happen. I'll take a look at the wake shader if you want, but I supect you'd prefer me to fix some of the other issues you raised below first :). Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've not had any time to look at the screenshot/terrasync directory issue. I strongly suspect that I could fix it, but I only have so many hours in the day, and as mentioned before am spread pretty thin. Personally I think most of the active FG devs are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Henri, Thorsten only said, that _if_ you ask him to remove ALS because of concern for users without good graphics cards, you should aks FredB as well to remove Rembrandt, because the same argument would apply. Not doing it just shows that different standards are applied which is simply unfair. First , it is not because i am unable to write English correctly, i can't understand it written. Suggesting to ask for removing Rembrandt gives enough to conclude. You clearly don't get this right, and therefore draw the wrong conclusions. As Stefan said, have someone who understands English better explain this to you in your language. @Thorsten: I love ALS. @FredB: I love Rembrandt. And of course I'd love to see both combined. I'm pretty sure that at some point in the future they will be. Why Thorsten has not given up on this yet is just beyond me. This is not a discussion, it's just handwaving and accusations. I'm just very glad, that he didn't give up. So instead, I can enjoy as much of the great flying experience as I can get during the long winter months. +1 Tom -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
When I've seen the bits of pixels on the very edges of the transparent tree areas it has sure looked like a texture wrapping issue to me. This is a flag you can turn on/off at least at the low level of opengl and I'm sure OSG would expose this. Basically the bits at the very top of the tree probably line up nicely with the bits at the bottom. You want this when you are tiling textures and mipmapping together to avoid seeing the seams, but with billboard textures you probably want to turn this off, and it especially stands out with transparent textures. Regards, Curt. On Thu, Apr 25, 2013 at 3:29 PM, Stuart Buchanan stuar...@gmail.com wrote: On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Hi Curt, On Thu, Apr 25, 2013 at 9:42 PM, Curtis Olson wrote: When I've seen the bits of pixels on the very edges of the transparent tree areas it has sure looked like a texture wrapping issue to me. This is a flag you can turn on/off at least at the low level of opengl and I'm sure OSG would expose this. I think you might be thinking of the UV clamping function? Unfortunately the UV coordinates are something like (0,0), (0.128, 0.0), (0.128, 0.25), (0.0, 0.25) and it's that top edge at y=0.25 which is the problem. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thu, Apr 25, 2013 at 3:28 PM, Stuart Buchanan wrote: On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've just pushed a fix for the weather issue. I found two bugs in it which I've fixed, but there may be more as it's quite a complex dialog. FYI I'm also planning to move some of the buttons around a bit. I think the changes you (vivian) made are an improvement in terms of making the configuration options more understandable, but I can improve the layout slightly I think. AFAICT the screenshot directory entry in the GUI does work. At least on my system I can change the screenshot directory via the GUI and record screenshots to the new directory. On Thu, Apr 25, 2013 at 4:08 PM, James Turner wrote: I suspect both of these are my 'fault', but equally I was only made aware of the TerraSync one a few weeks ago, and the screenshot one, this is the first I've heard of it. Well, the Terrasync was caused by adding an additional nasalopen block at the top of the file, so the one at the bottom was ignored :) snip In the particular case of the Terrasync path I am especially confused because it's not possible to change the terrasync path once fgfs is running, as never has been as far as I know; since we can't adjust scenery paths with restarting the sim. So, to re-iterate, the defect really needs to explain what the intended use-case was here, since I am clueless. I've restored the previous behaviour which did allow one to set the directory. However, on testing, you are absolutely correct - changing has no effect within the current session. I'll add a warning message to that effect to the dialog. I think it's still useful to be able to set the directory within the sim, even if you have to restart. I think I must have added this function under the mistaken impression that it had some effect. Whoops! -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Stuart Sent: 25 April 2013 22:24 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric Light Scattering On Thu, Apr 25, 2013 at 3:28 PM, Stuart Buchanan wrote: On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've just pushed a fix for the weather issue. I found two bugs in it which I've fixed, but there may be more as it's quite a complex dialog. FYI I'm also planning to move some of the buttons around a bit. I think the changes you (vivian) made are an improvement in terms of making the configuration options more understandable, but I can improve the layout slightly I think. AFAICT the screenshot directory entry in the GUI does work. At least on my system I can change the screenshot directory via the GUI and record screenshots to the new directory. Not here. It seems to be stuck at this weird default value: C:/Program Files/FlightGear-nightly-2010/osgPlugins-3.0.1 Why there - decidedly odd? Win 7 will not permit a program to write to Program Files, so it fails. I can't enter any different value, or navigate above Program Files using the gui. I have tried deleting the value in AppData\Roaming\flightgear.org\autosave_2_11.xml (which I wouldn't expect a user to do - or even find), but neither doing that nor anything else I can think of has fixed it. On Thu, Apr 25, 2013 at 4:08 PM, James Turner wrote: I suspect both of these are my 'fault', but equally I was only made aware of the TerraSync one a few weeks ago, and the screenshot one, this is the first I've heard of it. Well, the Terrasync was caused by adding an additional nasalopen block at the top of the file, so the one at the bottom was ignored :) snip In the particular case of the Terrasync path I am especially confused because it's not possible to change the terrasync path once fgfs is running, as never has been as far as I know; since we can't adjust scenery paths with restarting the sim. So, to re-iterate, the defect really needs to explain what the intended use-case was here, since I am clueless. I've restored the previous behaviour which did allow one to set the directory. However, on testing, you are absolutely correct - changing has no effect within the current session. I'll add a warning message to that effect to the dialog. I think it's still useful to be able to set the directory within the sim, even if you have to restart. I think I must have added this function under the mistaken impression that it had some effect. Whoops! It would be nice to be able to direct the output of Terragear at run time without restarting, (we can do that with Scenarios - thanks James), but if that is not possible then after a restart will do. I don't remember if we used to need a restart - I suppose we must have done. What was the pull-down in the menu item for? Nearly back to square one - well done. Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I would give you some screenshots - but that's broken here. Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Vivian, Your description makes sense in conjunction with a mipmapping issue. Think about how mipmapping works. The default mipmap generation algorithm creates the 1/2 size image by averaging each 2x2 block of pixels in the higher level down to 1 pixel in the next level. Then repeat, generating the 1/4 size image from the 1/2 size image. You can see that at smaller image sizes, each pixel will draw information from a wide block of pixels out of the original so there can be a lot of bleeding across. This also impacts alpha levels so transparency is another one that doesn't usually mipmap as you'd expect/wish. Note to people who hadn't noticed this before -- the requirement that texture sizes be powers of two allows the mipmapping level creating scheme to be well defined, and if your texture dimensions aren't an even power of two, they are probably getting scaled to the next size down under the hood when they are loaded by OSG. I'm not sure what to do about the tree problem though -- it might help to divide up the internal image into power of 2 chunks, go 4 trees across the texture rather than 5 (just for example.) That might split down further before producing artifacts if we aren't already doing that. (?) I've heard graphics guru's speak of using other algorithms to generate the mip map levels, or even manually creating them. In some cases I think you need to consider this sort of thing even though it's a pain and blows up the size of the distributed texture if we need to also include the pregenerated mipmap levels. Curt. On Thu, Apr 25, 2013 at 5:50 PM, Vivian Meazza vivian.mea...@lineone.netwrote: Stuart On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I would give you some screenshots - but that's broken here. Vivian -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt!
