From: Renk T. <tho...@jy...> - 2013-04-25 06:25:27
|
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 |
From: Renk T. <tho...@jy...> - 2013-04-25 09:37:30
|
> ..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 |
From: Vivian M. <viv...@li...> - 2013-04-25 13:33:44
|
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 |
From: Stuart B. <stu...@gm...> - 2013-04-25 14:28:16
|
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 |
From: Vivian M. <viv...@li...> - 2013-04-25 15:08:57
|
Stuart > -----Original Message----- > From: Stuart Buchanan [mailto:stu...@gm...] > 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 |
From: Kleo G. <mua...@ho...> - 2013-04-25 15:51:21
|
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" <stu...@gm...> 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Stuart B. <stu...@gm...> - 2013-04-25 21:24:04
|
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 <nasal><open> 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 |
From: Vivian M. <viv...@li...> - 2013-04-25 22:09:52
|
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 <nasal><open> 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 |
From: James T. <zak...@ma...> - 2013-04-26 07:49:46
|
On 25 Apr 2013, at 22:23, Stuart Buchanan <stu...@gm...> wrote: Thanks for investigating Stuart! > 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. Okay, that's interesting indeed. Keep in mind I've not made an explicit changes to the screenshot directory code, but I have changed the file picker logic recently, which I assumed would be the likely cause. However Windows and Linux use the same code paths for the file-picker. Based on Vivian's report that the path is bad, something else must be going on for him (and other Windows users?) > > Well, the Terrasync was caused by adding an additional <nasal><open> block > at the top of the file, so the one at the bottom was ignored :) Whoops, that is entirely my fault. Many apologies. > 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! Okay, I did always wonder why the option was added :) Personally I am pushing people to always use the default TerraSync location unless they are doing 'something special' in which case an entry in fgfsrc seems a better solution to me. I.e keep the GUI simple for the common case, and ensure the advanced case is possible via config files. Changing the code to allow run-time switching of the terrasync dir, and the scenery paths, is not impossible but it would be a fairly large amount of effort, not a worthwhile use of time from my point of view. Regards, James |
From: Vivian M. <viv...@li...> - 2013-04-26 09:23:32
|
James, Terrasync now works entirely as expected here - but not quite as you describe. I can enter a path at the gui, and then stop and restart Terrasync from the gui and it will download to the new directory. Of course, the scenery directories remain as they were defined at startup. We can reload scenery at runtime, so perhaps it would be nice to change the Terrasync scenery as well - not quite sure about that because I can envisage situations when it would be advantageous to download to one directory while using another. Vivian From: James Turner [mailto:zak...@ma...] Sent: 26 April 2013 08:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric Light Scattering On 25 Apr 2013, at 22:23, Stuart Buchanan <stu...@gm...> wrote: Thanks for investigating Stuart! 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. Okay, that's interesting indeed. Keep in mind I've not made an explicit changes to the screenshot directory code, but I have changed the file picker logic recently, which I assumed would be the likely cause. However Windows and Linux use the same code paths for the file-picker. Based on Vivian's report that the path is bad, something else must be going on for him (and other Windows users?) Well, the Terrasync was caused by adding an additional <nasal><open> block at the top of the file, so the one at the bottom was ignored :) Whoops, that is entirely my fault. Many apologies. 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! Okay, I did always wonder why the option was added :) Personally I am pushing people to always use the default TerraSync location unless they are doing 'something special' in which case an entry in fgfsrc seems a better solution to me. I.e keep the GUI simple for the common case, and ensure the advanced case is possible via config files. Changing the code to allow run-time switching of the terrasync dir, and the scenery paths, is not impossible but it would be a fairly large amount of effort, not a worthwhile use of time from my point of view. Regards, James |
From: James T. <zak...@ma...> - 2013-04-25 15:08:54
|
On 25 Apr 2013, at 15:28, Stuart Buchanan <stu...@gm...> 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 |
From: Thomas A. <ra...@we...> - 2013-04-25 16:16:50
|
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 |
From: Renk T. <tho...@jy...> - 2013-04-26 06:22:04
|
Hi Vivian, > 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. That is what I tried to explain in length. My definition of broken is 'used to work, there was a change, now doesn't work'. What is yours? The wake effect used to work in default, and now still does. The wake effect never worked in ALS and now still doesn't. There's nothing broken here, you are talking about non-existing features and a feature request to implement them. Which is very different from breaking existing things. To give you the reverse example - procedural texturing works in ALS but not in Rembrandt - so does this imply it's broken in Rembrandt? Cloud shadows don't work in either Rembrandt or ALS - does that imply we've broken them? Nope - they never existed, and you can make a feature request to implement them. In the event, your feature request for the wake effect is noted, but not my top priority - I prefer to race on to the next bit of eye candy (as you put it) because the wake effect is a very localized effect, whereas I want to address some world-wide stuff which affects a few billion pixels more first. You're welcome to implement it yourself, and I'll be happy to assist you if that is needed. To call a non-existing feature with a feature request attached 'broken' generates a completely wrong impression and a sense of urgency which really isn't there. > 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) This may be a question of philosophy, but I don't think OpenSource fares badly with this approach in general. As a Linux user I get a choice between Gnome, KDE and a host of other desktop environments - and I rather like that, I can pick what suits me best. As an aircraft developer, I can pick JSBSim or YaSim, whatever suits me best. So why should we not offer different rendering approaches dependent on what the user wants to burn the framerate for? I don't see this at all as a problem, I rather see it as a huge opportunity. We can ship one rendering approach for the low end graphics cards and are then not restricted in what we offer for the high end. How exactly is that a bad thing? > 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. You'll have noticed that the ALS ubershader (short of inserting the tangent, normal and binormal attribute for normal maps which I understand really _must_ be airplane-side) works out of the box without any action required in ALS. So there is no need to make your models ALS compatible, this is not a real problem, but a hypothetical one. The worst case by the way is not that the aircraft can't be flown as in Rembrandt, because you can't see out of the cockpit, the worst case is that your normal map doesn't work. > 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? Optionally. *sigh* When you and Emilian wrote the default ubershader, it provided new features. These were offered to the airplane developers as options - it was their choice to make use of them or not. Now ALS offers an ubershader which might get additional features. There are offered to airplane modellers as options. Just why is it okay if you do it, but problematic if I do it? Yes, they may not work in Rembrandt - and Rembrandt has AO, and bloom, and real internal light sources which do not work in other frameworks. So not every framework has the same visuals. Why is this a problem? > In an ideal world everything would work and be > compatible with everything else. I don't see how any progress could be made that way. I don't see how Rembrandt could have been made requiring that it must be completely compatible with existing technology and aircraft definitions. We used to characterize the atmosphere by a fog density and a fog color. It's beyond me how one could make ALS by requiring the same thing. JSBSIm has updates, they break some aircraft, developers fix it - somehow I miss all the complaints about this (and JSBSim updates actually have the potential to break aircraft in the sense of rendering them non-functional, not in the sense of bumpmapping not working). Just imagine computers were required to be able to run DOS nowadays... Just imagine modern Windows software were required to be able to run on DOS... > What are aircraft developers and/or users meant to make of this ? As I said above, that's a hypothetical issue. In reality, the aircraft and models rendered with the ubershader just work with ALS because the shader uses exactly the same configuration, so there's that. Aircraft not using the ubershader do not get nice effects, but then again, Emilian when he still was active in the forum was busy telling people that older effects are deprecated and they should be using the ubershader - so when exactly did this recommendation become bad? > 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 Well, there it goes again. The 'wrong direction' - what is that? Who gets to decide it? How can an optional feature push something into the wrong direction? What is the concrete problem we're talking about? You don't understand exactly... But somehow, there must be something to it, right? And so, a vague impression remains and we're back to rumormongering. > Perhaps you received contrary advice, or > considered that his advice wasn't of value, but we never had that debate > IIRC. The concrete advice I received from Emilian I usually followed up - either by following it and implementing it, or by doing some background reading, implementation testing and discarding it when I made up my mind that he wasn't right. The objections in the end seemed to be rather unspecified and general though - the 'wrong way' as you put it. > Oh - and btw the ALS still shows up a tear in the skydome that we have > had right from the beginning. Yes - it's not in the shader as far as I can test, which means I can't fix it. I suspect it's in the geometry, which is generated god knows where, I've posted two analyses here and in the forum, people know about it - so that's the limit of my expertise, sorry. I recognize that a fix is needed, but I'm unable to do it. > I thought perhaps it would be helpful if a native English speaker tried > to put things in perspective Yes - as I suspected, it's about (from my view) unrealistic expectations. You're somehow fine with the fact that we have JSBSim and YaSim (and possibly UIUC - does this still work?) to drive FDMs - so it's okay that FG is open here. So why are openness and choice suddenly bad when we come to rendering? Why do you expect that ALS must support the effects which default supports, but not that Rembrandt must support what ALS does? I don't see you arguing with Fred that Rembrandt broke procedural texturing - why's that? I didn't see you arguing with Fred that you had to make aircraft Rembrandt-compatible - now you're arguing with me that you might have to make aircraft ALS compatible despite the fact that you actually don't have to? I'm not getting this, it's not a consistent position. * Thorsten |
From: Vivian M. <viv...@li...> - 2013-04-26 22:57:23
|
Thorsten > > 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. > > That is what I tried to explain in length. My definition of broken is 'used to > work, there was a change, now doesn't work'. What is yours? > > The wake effect used to work in default, and now still does. The wake effect > never worked in ALS and now still doesn't. There's nothing broken here, you > are talking about non-existing features and a feature request to implement > them. Which is very different from breaking existing things. > > To give you the reverse example - procedural texturing works in ALS but not > in Rembrandt - so does this imply it's broken in Rembrandt? Cloud shadows > don't work in either Rembrandt or ALS - does that imply we've broken them? > Nope - they never existed, and you can make a feature request to > implement them. > > In the event, your feature request for the wake effect is noted, but not my > top priority - I prefer to race on to the next bit of eye candy (as you put it) > because the wake effect is a very localized effect, whereas I want to address > some world-wide stuff which affects a few billion pixels more first. You're > welcome to implement it yourself, and I'll be happy to assist you if that is > needed. > > To call a non-existing feature with a feature request attached 'broken' > generates a completely wrong impression and a sense of urgency which > really isn't there. > > > 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) > > This may be a question of philosophy, but I don't think OpenSource fares > badly with this approach in general. As a Linux user I get a choice between > Gnome, KDE and a host of other desktop environments - and I rather like > that, I can pick what suits me best. As an aircraft developer, I can pick JSBSim > or YaSim, whatever suits me best. So why should we not offer different > rendering approaches dependent on what the user wants to burn the > framerate for? I don't see this at all as a problem, I rather see it as a huge > opportunity. We can ship one rendering approach for the low end graphics > cards and are then not restricted in what we offer for the high end. How > exactly is that a bad thing? > > > 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. > > You'll have noticed that the ALS ubershader (short of inserting the tangent, > normal and binormal attribute for normal maps which I understand really > _must_ be airplane-side) works out of the box without any action required in > ALS. So there is no need to make your models ALS compatible, this is not a > real problem, but a hypothetical one. The worst case by the way is not that > the aircraft can't be flown as in Rembrandt, because you can't see out of the > cockpit, the worst case is that your normal map doesn't work. > > > 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? > > Optionally. > > *sigh* When you and Emilian wrote the default ubershader, it provided new > features. These were offered to the airplane developers as options - it was > their choice to make use of them or not. Now ALS offers an ubershader > which might get additional features. There are offered to airplane modellers > as options. Just why is it okay if you do it, but problematic if I do it? > > Yes, they may not work in Rembrandt - and Rembrandt has AO, and bloom, > and real internal light sources which do not work in other frameworks. So not > every framework has the same visuals. Why is this a problem? > > > In an ideal world everything would work and be compatible with > > everything else. > > I don't see how any progress could be made that way. I don't see how > Rembrandt could have been made requiring that it must be completely > compatible with existing technology and aircraft definitions. We used to > characterize the atmosphere by a fog density and a fog color. It's beyond me > how one could make ALS by requiring the same thing. JSBSIm has updates, > they break some aircraft, developers fix it - somehow I miss all the > complaints about this (and JSBSim updates actually have the potential to > break aircraft in the sense of rendering them non-functional, not in the > sense of bumpmapping not working). > > Just imagine computers were required to be able to run DOS nowadays... > Just imagine modern Windows software were required to be able to run on > DOS... > > > > What are aircraft developers and/or users meant to make of this ? > > As I said above, that's a hypothetical issue. In reality, the aircraft and models > rendered with the ubershader just work with ALS because the shader uses > exactly the same configuration, so there's that. Aircraft not using the > ubershader do not get nice effects, but then again, Emilian when he still was > active in the forum was busy telling people that older effects are deprecated > and they should be using the ubershader - so when exactly did this > recommendation become bad? > > > 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 > > Well, there it goes again. The 'wrong direction' - what is that? Who gets to > decide it? How can an optional feature push something into the wrong > direction? What is the concrete problem we're talking about? You don't > understand exactly... But somehow, there must be something to it, right? > And so, a vague impression remains and we're back to rumormongering. > > > Perhaps you received contrary advice, or considered that his advice > > wasn't of value, but we never had that debate IIRC. > > The concrete advice I received from Emilian I usually followed up - either by > following it and implementing it, or by doing some background reading, > implementation testing and discarding it when I made up my mind that he > wasn't right. The objections in the end seemed to be rather unspecified and > general though - the 'wrong way' as you put it. > > > Oh - and btw the ALS still shows up a tear in the skydome that we have > > had right from the beginning. > > Yes - it's not in the shader as far as I can test, which means I can't fix it. I > suspect it's in the geometry, which is generated god knows where, I've > posted two analyses here and in the forum, people know about it - so that's > the limit of my expertise, sorry. I recognize that a fix is needed, but I'm > unable to do it. > > > I thought perhaps it would be helpful if a native English speaker > > tried to put things in perspective > > Yes - as I suspected, it's about (from my view) unrealistic expectations. > You're somehow fine with the fact that we have JSBSim and YaSim (and > possibly UIUC - does this still work?) to drive FDMs - so it's okay that FG is > open here. So why are openness and choice suddenly bad when we come to > rendering? Why do you expect that ALS must support the effects which > default supports, but not that Rembrandt must support what ALS does? I > don't see you arguing with Fred that Rembrandt broke procedural texturing - > why's that? I didn't see you arguing with Fred that you had to make aircraft > Rembrandt-compatible - now you're arguing with me that you might have to > make aircraft ALS compatible despite the fact that you actually don't have to? > I'm not getting this, it's not a consistent position. > The gentleman doth protest too much, methinks. (And at too great a length). If something exists and works in the default scheme, but is missing or does not work in a child scheme then that child scheme is broken or we might say that there is a regression. That might or might not matter in the short term, but longer term it needs fixing. In addition, if we add something in the child scheme which proves to be useful, then it should be our ambition to back-port that to the parent. If there is any call for it, I think the grain stuff could be back-ported without too much difficulty. That said - I don't see why an Atmospheric Light Scattering scheme should have embedded in it some ac modelling stuff. That serves to diverge the schemes. And it makes it look like ALS is your private sandbox. I know that isn't the case, but you can see why there are those like Henri who fear it is: "Grain effect - good idea. Oh, that means I have to chuck out something - Rainbow effect will do. I'll put that back later somehow. Oh look - that's a good new interesting idea - I'll do that instead." OK, I exaggerate - but you can see how it might be interpreted. There is no doubt in my mind that ALS breaks the bow-wave and rainbow effects. Well, I hope so - because I just pushed a fix for the latter. Emilian pointed me at http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_G uide_G80.pdf para 3.5.3. The solution was obvious - combine the Fresnel and Rainbow look-up textures into 1 texture. A few trivial changes - job done. Of more interest, we could, and probably should, do something similar for almost any complex math function. Blender has suitable tools to generate such textures - but I won't pretend that I understand that in any depth. There are some other tips and suggestions for efficient shader programming: well worth some study I would say. I haven't looked at the bow-wave - but I suspect it's more than a few minutes' work. Don't compare the FDMs: JSBSim, Yasim, and UIUC with the rendering schemes - they are intended to fulfil different roles. While there is some overlap, they are not alternatives in the same way the ALS and Rembrandt are (and shouldn't be) - we do want to see ALS and Rembrandt converging long term. We don't want nice atmospheric effects and no shadows/lights and vice versa. Judging from Tim Moore's recent post this might be doable. "Wrong direction" - don't know: if Emilian were still around you could ask him. Many of the problems here are caused by a poor command of English and consequential mutual misunderstandings. It is much to everyone's credit that they even try to contribute to the discussion. For example, I can see Henri's concerns, I suspect they are based on a misunderstanding, and they are badly expressed leading to more misunderstanding: a little more consideration would not come amiss. Enough, too long already Vivian |
From: geneb <ge...@de...> - 2013-04-26 23:22:02
|
On Fri, 26 Apr 2013, Vivian Meazza wrote: > > Enough, too long already > It would have been a LOT shorter had you trimmed his original message down instead of just tacking on to the bottom. :D g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! |
From: Vivian M. <viv...@li...> - 2013-04-26 23:29:23
|
Gene > > > > > Enough, too long already > > > It would have been a LOT shorter had you trimmed his original message > down instead of just tacking on to the bottom. :D > What and spoil the point? :-) Vivian |
From: geneb <ge...@de...> - 2013-04-27 01:40:46
|
On Sat, 27 Apr 2013, Vivian Meazza wrote: > Gene > >> >>> >>> Enough, too long already >>> >> It would have been a LOT shorter had you trimmed his original message >> down instead of just tacking on to the bottom. :D >> > > What and spoil the point? :-) > By the time I reached where your text started, I'd forgotten what was going on. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! |
From: Renk T. <tho...@jy...> - 2013-04-26 06:39:57
|
> 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. Just to provide some expectation management: Rembrandt (as deferred rendering) is very heavy on the fragment shader. ALS at low quality is currently rather balanced between vertex and fragment shader and at high quality adds all additional load to the fragment shader. An ALS implementation in Rembrandt will require that basically all light computations which are currently in the vertex pipeline move to the fragment shader as well. That's not a small workload, sunlight is about 100 times heavier to compute in ALS than in default or Rembrandt (that's what ALS burns framerate for). I'm currently running ALS at highest quality on a GeForce 670M which is a GPU on the top-end of the performance scale. With all settings maxed out, this pretty much guarantees me a framerate of above 20 fps, no matter the weather or the scenery (with very few pathological exceptions where it drops to 15). Rembrandt + ALS will be slower than any of them, because of all that additional stuff which needs to go into the fragment pipeline which will completely choke. My strong expectation is that even on a top-notch GPU, maxing out all settings will not work fast enough, so something will be lost if you actually hope to fly. The GPU to run that framework isn't sold yet... and I can picture the crowd of usual suspects shouting 'This is too slow! This is badly implemented!' once it's actually running. And I a so looking forward to that experience. (*irony*) * Thorsten |
From: Tim M. <tim...@gm...> - 2013-04-26 08:56:52
|
On Fri, Apr 26, 2013 at 8:39 AM, Renk Thorsten <tho...@jy...>wrote: > > 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. > > Just to provide some expectation management: > > Rembrandt (as deferred rendering) is very heavy on the fragment shader. > ALS at low quality is currently rather balanced between vertex and fragment > shader and at high quality adds all additional load to the fragment shader. > An ALS implementation in Rembrandt will require that basically all light > computations which are currently in the vertex pipeline move to the > fragment shader as well. That's not a small workload, sunlight is about 100 > times heavier to compute in ALS than in default or Rembrandt (that's what > ALS burns framerate for). > > I don't think it's quite that bad. In a deferred shader like Rembrandt, the ALS would run in the deferred lighting pass. While it's true that the heavy work is done in a fragment shader, it only runs for each pixel on the screen, not for every rendered fragment. Also, in many cases the sky would take up a large portion of the out-the-window scene; is computing ALS for the blue sky as expensive as for an object in the scene? Not to mention that you don't need to run ALS in the cockpit... Tim |
From: Renk T. <tho...@jy...> - 2013-04-26 09:26:04
|
> I don't think it's quite that bad. In a deferred shader like Rembrandt, > the ALS would run in the deferred lighting pass. While it's true that the > heavy work is done in a fragment shader, it only runs for each pixel on > the screen, not for every rendered fragment. Yes - but you need to execute ~ 200 additional lines per screen pixel just to get the light at every point right in the scene. Then come ~150 additional lines to compute fog. As for the graphical goodies of terrain texturing, that's all in the fragment shader and contributes another 300 lines or so in total, and now that's only done per screen pixel, because I always use a trivial first pass to fill the z-buffer and render terrain only when actually seen. So the fragment shader will get ~650 additional lines to execute for every screen terrain pixel. Have you looked at terrain-haze-ultra.frag ? That has 720 lines of code in total, part of it subroutines which are called a few times. It is true that we currently render terrain obscured by the panel due to the near/far camera issue - but I have a crude panel masking code and a good feeling of how much this saves you. > Also, in many cases the sky > would take up a large portion of the out-the-window scene; is computing ALS for > the blue sky as expensive as for an object in the scene? Not to mention > that you don't need to run ALS in the cockpit... Yes, it does now as well. But you want the sim well-behaved not only in level flight, but also when you descend or do aerobatics. So you have to design for a clouded sky (which reverses the argument, looking at the sky then becomes very bad) or a steep descent when only terrain is visible - it doesn't do to have a framework which only runs when half the screen is sky :-) And you do have to use ALS light computations for the cockpit to get consistent light (you don't need fog or pixel postprocessing). In the end, I guess we'll see how bad it is... * Thorsten |
From: Renk T. <tho...@jy...> - 2013-04-26 12:02:24
|
I've thought about if I really should comment on Henri or not, and I won't dignify most with a reply, but just this: > 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. Please get your facts right. The first appearance of the skydome shader in the forum dates to Mar 07, 2011. The first appearance of Rembrandt in the forum seems to be Jan 04, 2012. Assuming that they roughly correlate with the time at which these features were first presented elsewhere as well, this means that the beginning of ALS _predated_ Rembrandt by almost 10 month (!). Thus, it is very clear what the 'existing' feature is, and who did not contribute to the existing technology - it's FredB and Rembrandt, not Lauri, me and ALS. Let me make it very clear that I have no issue whatsoever with that. I did not expect FredB to incorporate the skydome shader or anything that follows out of this. It is also very clear to me that FredB has no issue with Rembrandt and ALS co-existing, because he showed me how to implement the terrain shading in the effect framework and committed it himself after I had finished it. But your whole argument about not contributing to existing features simply applies to the wrong person. That's embarrassing, isn't it? Have a nice weekend, * Thorsten |
From: Renk T. <tho...@jy...> - 2013-04-27 07:11:34
|
> That said - I don't see why an Atmospheric > Light Scattering scheme should have embedded in it some ac modelling > stuff. > That serves to diverge the schemes. And it makes it look like ALS is your > private sandbox. Offering new and different options is the whole point of having a different scheme. What would be the point of having Rembrandt if it were to look just as the default scheme and would not offer novel options? You think these options should be limited to the sky (and terrain?) - fine, I don't, I think they may well affect models, trees, all the visuals. Since Emilian accused me of wanting to rule FG anyway - just what would happen if I would start editing some new effects also into Rembrandt or default? Or if I would decide myself how Basic Weather needs to interact with ALS? Let me give you the answer: I would get the same accusations 10 times over - and (at least partially) rightfully so. It's not my call to make - it's up to the maintainers of Basic Weather (Rembrandt,...) to decide what to include and how. There's simply no pleasing some people - if I introduce new effect in my framework, you complain about diverging schemes, if I would do it everywhere you would be complaining that I can't simply make such decisions on my own. So in your book, I just shouldn't introduce any novel effects at all unless you approve? (You didn't say this, but it pretty much follows.) You can't be serious. Last time I checked, I designed or ported something like 95% of the code of ALS. Stuart did some work on the trees, Lauri did the original skydome shader before haze, Emilian contributed insights, corrections and tests to the ported model ubershader - and that's basically it. So I guess that makes me the current maintainer of the scheme. What you (and Henri) are really saying here that you guys should really have a vote on where the scheme is going without investing work into it (and ironically enough, you're both not even users of the scheme), and you should even be able to overrule my own judgement on what is important and how things get implemented and be able to tell me what I should be working on first. Just since when did we start doing things that way in FG? I fully accept that decisions which affect other subsystems, potentially disable them or require substantial action by others must be discussed and voted on, and that coding e.g. an explicit preference for one weather system over the other is a bad thing. So if the choice were that we can have either Rembrandt or ALS, we'd need to have a discussion and a vote. But that's not the case. Thus, you don't get to overrule me if I consider implementing wind effects more useful than the wake effect. You can bring up your case, you can ask nicely, we can have a discussion, but as long as you expect me to do the work, you'll have to live with my decisions and wait till your request reaches the top of my to-do list (in the case of the wake, I have already stated that it's on the to-do list - same with the rainbow). You can do it yourself if it has a higher priority for you (in which case I offered help and expect the customary amount of coordination with what I'm doing, same as if I would start working on one of your aircraft), you can convince anyone else to do it (in which case I'll also help), and that's how it works everywhere else in FG. If I want a particular feature for an aircraft, I ask nicely and try to be convincing, I don't go around claiming the aircraft is broken every time. Why is this mode not acceptable to you? You know, I don't want any special treatment here - I just want that the same standards are applied to me which apply to other people (specifically also you and Emilian). And I can't see that in what you say - I'm always held to much stricter standards. Vivian, for all your eloquence, I don't get the impression that all this is the real sticking point - what is _really_ bugging you here? You're not a user of ALS, I haven't seen it on in any of your screenshots. You're not affected personally by anything I do. I told you I will put the rainbow back and I will implement the wave, and we're in the middle between release periods, just when it's officially time to introduce new features with the idea to consolidate towards the release. So there can't be any serious concern at this point that users might not get to see and appreciate your work sufficiently. You argue against the hypothetical case that you might potentially have to adjust your aircraft for ALS even when this is not factually the case. At every opportunity, you speak up against the way Advanced Weather is done. You implemented, together with Emilian, an environment for the water shader which explicitly favours Basic Weather over Advanced Weather, in spite of the fact that I documented the lighting model of Advanced Weather in the readme, outlined it to you on this list, again in a mail to you and Emilian and coded a shader which explicitly demonstrates my control property approach which avoids this. When I handed over the code of ALS to you and Emilian, you did nothing with it for half a year, and afterwards criticized forever that I implemented it the wrong way. I'm trying very hard to come up with a charitable explanation not involving that you do it just to put stumbling blocks to whatever I do, but I am running out of those. You accept that it's perfectly fine if Fred introduces new features in Rembrandt and modify your aircraft according to novel standards, but you have concerns all over the place when ALS (which is much less of a radical change) is concerned. Pretty much every novel feature by ALS has been criticized by you or Emilian as unwanted, badly implemented, breaking things ... In several cases, it was pretty apparent you (or Emilian) hadn't even looked in any detail through the shader you were opposed to and argued just based on assumptions. You frequently argue on behalf of users - but I hang out in the forum and have all the discussion with users (much more than you do), and I think I get a pretty clear picture of what the average user is about. I don't get it. What is the real problem? I'm not asking you to like what I do. I'm just asking for some basic mutual respect and peaceful co-existence. Can't you be content with me not taking away any of what you like in FG? Do you have to oppose features nobody asks you to use? Can't you stand the idea that there is an option which works different from what you like? We can take this off-list if you like, but I'm really at a point where I can no longer treat this as a misunderstanding and lack of information flow, I have explained too much to believe in this any more. Finally, I acknowledge gratefully that you have always been very polite and civilized in discussing with me, which can't be said for some hate-mails I've received from others off-list. * Thorsten |
From: grtuxhangar t. <hoh...@gm...> - 2013-04-27 12:04:01
|
> > What you (and Henri) are really saying here that you guys should really have > a vote on where the scheme is going without investing work into it (and > ironically enough, you're both not even users of the scheme), and you > should even be able to overrule my own judgement on what is important and > how things get implemented and be able to tell me what I should be working > on first. Just since when did we start doing things that way in FG? I thought the debate closed. The very good description of the situation by Vivian ( and best of the best with a Shakespeare introduction :) ). He was expressing in detail how to do and what to do. I worry there won't be a pilot in the "Flighgear" plane, though Vivian could be the one. Renk, How could you say "you're both not even users of the scheme" ? Yes i had at the beginning done some screenshots with the Dome project, the period when i could use it without breaking others features. I was, even, able to combine the Effects with the dome by unlocking the conditions. To me the project was promising , until you engage to develop deeply. Yes, right now, i do use Rembrandt for screenshots the effect/results are the best we may get with Flighgear. light and shadow are amazing. Renk, You pretend to be experienced and worry we don't use your know how, Emilian is experienced and you rejected his know how. Would you say everybody but you is stupid. Renk, How could you say the Shadows system has come after ALS ? Looking at the history of Flightgear, i can notice the Shadows system was a feature in the old time, i have got from GRTUX's database ( inherited) some old snapshot with Shadows. With the OSG arrival that old feature did not longer worked. So, Rembrandt is only coming to follow the original features content, it could have been offered as default within flightgear as soon it was considered right. It is right since months ago. It is said "Rembrandt cannot be run on some GPU", yes it depends on the OpenGL compliance, and a minimum of memory is necessary ( for better information refer to fredb instructions ). The modification to the aircraft to get it working is minor, i had to update our hangar it took only 1 hour to update our hangar (21 officials models + 12 non official ). Only the object with transparencies are involved, easy to find. Since it offer a nice real Light , i implemented it , in cockpit/ instrument and outside with landing light , it took time to understand the process, one day ( slow brain ) , and only 5 hours to update the Hangar. The time required was minor compared to the time spent when i had to introduce the shader effect ( one week and more). All the best Ahmad (Henri) On 27 April 2013 09:10, Renk Thorsten <tho...@jy...> wrote: > > That said - I don't see why an Atmospheric > > Light Scattering scheme should have embedded in it some ac modelling > > stuff. > > That serves to diverge the schemes. And it makes it look like ALS is your > > private sandbox. > > Offering new and different options is the whole point of having a > different scheme. What would be the point of having Rembrandt if it were to > look just as the default scheme and would not offer novel options? You > think these options should be limited to the sky (and terrain?) - fine, I > don't, I think they may well affect models, trees, all the visuals. > > Since Emilian accused me of wanting to rule FG anyway - just what would > happen if I would start editing some new effects also into Rembrandt or > default? Or if I would decide myself how Basic Weather needs to interact > with ALS? Let me give you the answer: I would get the same accusations 10 > times over - and (at least partially) rightfully so. It's not my call to > make - it's up to the maintainers of Basic Weather (Rembrandt,...) to > decide what to include and how. There's simply no pleasing some people - > if I introduce new effect in my framework, you complain about diverging > schemes, if I would do it everywhere you would be complaining that I can't > simply make such decisions on my own. So in your book, I just shouldn't > introduce any novel effects at all unless you approve? (You didn't say > this, but it pretty much follows.) You can't be serious. > > Last time I checked, I designed or ported something like 95% of the code > of ALS. Stuart did some work on the trees, Lauri did the original skydome > shader before haze, Emilian contributed insights, corrections and tests to > the ported model ubershader - and that's basically it. So I guess that > makes me the current maintainer of the scheme. > > What you (and Henri) are really saying here that you guys should really > have a vote on where the scheme is going without investing work into it > (and ironically enough, you're both not even users of the scheme), and you > should even be able to overrule my own judgement on what is important and > how things get implemented and be able to tell me what I should be working > on first. Just since when did we start doing things that way in FG? > > I fully accept that decisions which affect other subsystems, potentially > disable them or require substantial action by others must be discussed and > voted on, and that coding e.g. an explicit preference for one weather > system over the other is a bad thing. So if the choice were that we can > have either Rembrandt or ALS, we'd need to have a discussion and a vote. > But that's not the case. > > Thus, you don't get to overrule me if I consider implementing wind > effects more useful than the wake effect. You can bring up your case, you > can ask nicely, we can have a discussion, but as long as you expect me to > do the work, you'll have to live with my decisions and wait till your > request reaches the top of my to-do list (in the case of the wake, I have > already stated that it's on the to-do list - same with the rainbow). You > can do it yourself if it has a higher priority for you (in which case I > offered help and expect the customary amount of coordination with what I'm > doing, same as if I would start working on one of your aircraft), you can > convince anyone else to do it (in which case I'll also help), and that's > how it works everywhere else in FG. If I want a particular feature for an > aircraft, I ask nicely and try to be convincing, I don't go around claiming > the aircraft is broken every time. Why is this mode not acceptable to you? > > You know, I don't want any special treatment here - I just want that the > same standards are applied to me which apply to other people (specifically > also you and Emilian). And I can't see that in what you say - I'm always > held to much stricter standards. > > Vivian, for all your eloquence, I don't get the impression that all this > is the real sticking point - what is _really_ bugging you here? > > You're not a user of ALS, I haven't seen it on in any of your screenshots. > You're not affected personally by anything I do. I told you I will put the > rainbow back and I will implement the wave, and we're in the middle between > release periods, just when it's officially time to introduce new features > with the idea to consolidate towards the release. So there can't be any > serious concern at this point that users might not get to see and > appreciate your work sufficiently. You argue against the hypothetical case > that you might potentially have to adjust your aircraft for ALS even when > this is not factually the case. > > At every opportunity, you speak up against the way Advanced Weather is > done. You implemented, together with Emilian, an environment for the water > shader which explicitly favours Basic Weather over Advanced Weather, in > spite of the fact that I documented the lighting model of Advanced Weather > in the readme, outlined it to you on this list, again in a mail to you and > Emilian and coded a shader which explicitly demonstrates my control > property approach which avoids this. When I handed over the code of ALS to > you and Emilian, you did nothing with it for half a year, and afterwards > criticized forever that I implemented it the wrong way. > > I'm trying very hard to come up with a charitable explanation not > involving that you do it just to put stumbling blocks to whatever I do, but > I am running out of those. > > You accept that it's perfectly fine if Fred introduces new features in > Rembrandt and modify your aircraft according to novel standards, but you > have concerns all over the place when ALS (which is much less of a radical > change) is concerned. Pretty much every novel feature by ALS has been > criticized by you or Emilian as unwanted, badly implemented, breaking > things ... In several cases, it was pretty apparent you (or Emilian) hadn't > even looked in any detail through the shader you were opposed to and argued > just based on assumptions. You frequently argue on behalf of users - but I > hang out in the forum and have all the discussion with users (much more > than you do), and I think I get a pretty clear picture of what the average > user is about. > > I don't get it. What is the real problem? > > I'm not asking you to like what I do. I'm just asking for some basic > mutual respect and peaceful co-existence. Can't you be content with me not > taking away any of what you like in FG? Do you have to oppose features > nobody asks you to use? Can't you stand the idea that there is an option > which works different from what you like? We can take this off-list if you > like, but I'm really at a point where I can no longer treat this as a > misunderstanding and lack of information flow, I have explained too much to > believe in this any more. > > Finally, I acknowledge gratefully that you have always been very polite > and civilized in discussing with me, which can't be said for some > hate-mails I've received from others off-list. > > * 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 > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Best regards, Henri, aka Alva Official grtux hangar maintainer |
From: Vivian M. <viv...@li...> - 2013-04-27 12:31:46
|
Thorsten > Sent: 27 April 2013 08:11 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Atmospheric Light Scattering > > > That said - I don't see why an Atmospheric Light Scattering scheme > > should have embedded in it some ac modelling stuff. > > That serves to diverge the schemes. And it makes it look like ALS is > > your private sandbox. > > Offering new and different options is the whole point of having a different > scheme. What would be the point of having Rembrandt if it were to look just > as the default scheme and would not offer novel options? You think these > options should be limited to the sky (and terrain?) - fine, I don't, I think they > may well affect models, trees, all the visuals. > > Since Emilian accused me of wanting to rule FG anyway - just what would > happen if I would start editing some new effects also into Rembrandt or > default? Or if I would decide myself how Basic Weather needs to interact > with ALS? Let me give you the answer: I would get the same accusations 10 > times over - and (at least partially) rightfully so. It's not my call to make - it's > up to the maintainers of Basic Weather (Rembrandt,...) to decide what to > include and how. There's simply no pleasing some people - if I introduce new > effect in my framework, you complain about diverging schemes, if I would do > it everywhere you would be complaining that I can't simply make such > decisions on my own. So in your book, I just shouldn't introduce any novel > effects at all unless you approve? (You didn't say this, but it pretty much > follows.) You can't be serious. > > Last time I checked, I designed or ported something like 95% of the code of > ALS. Stuart did some work on the trees, Lauri did the original skydome shader > before haze, Emilian contributed insights, corrections and tests to the ported > model ubershader - and that's basically it. So I guess that makes me the > current maintainer of the scheme. > > What you (and Henri) are really saying here that you guys should really have > a vote on where the scheme is going without investing work into it (and > ironically enough, you're both not even users of the scheme), and you > should even be able to overrule my own judgement on what is important > and how things get implemented and be able to tell me what I should be > working on first. Just since when did we start doing things that way in FG? > > I fully accept that decisions which affect other subsystems, potentially > disable them or require substantial action by others must be discussed and > voted on, and that coding e.g. an explicit preference for one weather system > over the other is a bad thing. So if the choice were that we can have either > Rembrandt or ALS, we'd need to have a discussion and a vote. But that's not > the case. > > Thus, you don't get to overrule me if I consider implementing wind effects > more useful than the wake effect. You can bring up your case, you can ask > nicely, we can have a discussion, but as long as you expect me to do the > work, you'll have to live with my decisions and wait till your request reaches > the top of my to-do list (in the case of the wake, I have already stated that > it's on the to-do list - same with the rainbow). You can do it yourself if it has a > higher priority for you (in which case I offered help and expect the customary > amount of coordination with what I'm doing, same as if I would start working > on one of your aircraft), you can convince anyone else to do it (in which case > I'll also help), and that's how it works everywhere else in FG. If I want a > particular feature for an aircraft, I ask nicely and try to be convincing, I don't > go around claiming the aircraft is broken every time. Why is this mode not > acceptable to you? > > You know, I don't want any special treatment here - I just want that the same > standards are applied to me which apply to other people (specifically also you > and Emilian). And I can't see that in what you say - I'm always held to much > stricter standards. > > Vivian, for all your eloquence, I don't get the impression that all this is the > real sticking point - what is _really_ bugging you here? > > You're not a user of ALS, I haven't seen it on in any of your screenshots. > You're not affected personally by anything I do. I told you I will put the > rainbow back and I will implement the wave, and we're in the middle > between release periods, just when it's officially time to introduce new > features with the idea to consolidate towards the release. So there can't be > any serious concern at this point that users might not get to see and > appreciate your work sufficiently. You argue against the hypothetical case > that you might potentially have to adjust your aircraft for ALS even when this > is not factually the case. > > At every opportunity, you speak up against the way Advanced Weather is > done. You implemented, together with Emilian, an environment for the > water shader which explicitly favours Basic Weather over Advanced > Weather, in spite of the fact that I documented the lighting model of > Advanced Weather in the readme, outlined it to you on this list, again in a > mail to you and Emilian and coded a shader which explicitly demonstrates my > control property approach which avoids this. When I handed over the code > of ALS to you and Emilian, you did nothing with it for half a year, and > afterwards criticized forever that I implemented it the wrong way. > > I'm trying very hard to come up with a charitable explanation not involving > that you do it just to put stumbling blocks to whatever I do, but I am running > out of those. > > You accept that it's perfectly fine if Fred introduces new features in > Rembrandt and modify your aircraft according to novel standards, but you > have concerns all over the place when ALS (which is much less of a radical > change) is concerned. Pretty much every novel feature by ALS has been > criticized by you or Emilian as unwanted, badly implemented, breaking things > ... In several cases, it was pretty apparent you (or Emilian) hadn't even > looked in any detail through the shader you were opposed to and argued > just based on assumptions. You frequently argue on behalf of users - but I > hang out in the forum and have all the discussion with users (much more > than you do), and I think I get a pretty clear picture of what the average user > is about. > > I don't get it. What is the real problem? > > I'm not asking you to like what I do. I'm just asking for some basic mutual > respect and peaceful co-existence. Can't you be content with me not taking > away any of what you like in FG? Do you have to oppose features nobody > asks you to use? Can't you stand the idea that there is an option which works > different from what you like? We can take this off-list if you like, but I'm > really at a point where I can no longer treat this as a misunderstanding and > lack of information flow, I have explained too much to believe in this any > more. > > Finally, I acknowledge gratefully that you have always been very polite and > civilized in discussing with me, which can't be said for some hate-mails I've > received from others off-list. > What is the real problem? I've got a little list: I don't want to open the Devel List to find yet another storm with Thorsten at the centre of it. I don't want to download fgdata/fg/sg to find that I have to spend hours fixing up my work. I'd rather get on with my own stuff. I don't want to download fg/sg to find that it won't build. I don't want to download fgdata to find things which "used to work". I don't want to force users to choose between a nice atmospheric effects or shadows, or anything else. I don't want to force developers to develop ac for one scheme/framework rather than another. I don't want to have frame-rates of less than 40 and/or jittery. And finally - I feel really strongly about this one: I don't want anyone to feel that they have to leave the project because of acrimonious discussions on this list or anywhere else. It has happened only rarely, but I regret each and every one. I know this is unrealistic, but we should all be striving along these lines. I'm horrified that you have received hate-mail. This is only a flight sim for goodness sake. We have a long tradition here of friendly and orderly debate. I would caution you against the forum: it is a self-selected cut of our users. Some seem decidedly odd. If you can identify any of the perpetrators, then I'm sure that we can take steps to ban them from this list and the forum. Vivian |
From: Stefan S. <ni...@de...> - 2013-04-27 12:56:55
|
On Saturday 27 April 2013 13:31:33 Vivian Meazza wrote: > What is the real problem? I've got a little list: > > I don't want to download fgdata/fg/sg to find that I have to spend > hours fixing up my work. I'd rather get on with my own stuff. > > I don't want to download fg/sg to find that it won't build. > > I don't want to download fgdata to find things which "used to work". > > I don't want to have frame-rates of less than 40 and/or jittery. Well then the problem cannot be as large as it looks like since ALS does not cause any of those. > I don't want to force users to choose between a nice atmospheric > effects or shadows, or anything else. > > I don't want to force developers to develop ac for one > scheme/framework rather than another. Then why have I not read a single email about how Rembrandt diverges from the default rendering scheme and forces users to choose or that aricraft developers have to make adjustments? I only read about ALS which is much less of a problem, since I can use any airplane with it and can turn it on or off at runtime without a problem, so as a user I don't have to decide up front. > I don't want to open the Devel List to find yet another storm with > Thorsten at the centre of it. > > And finally - I feel really strongly about this one: > > I don't want anyone to feel that they have to leave the project > because of acrimonious discussions on this list or anywhere else. It has > happened only rarely, but I regret each and every one. So why are you with those who are driving Thorsten away if you feel so strongly about this point? If you don't want a shit storm why are you happily contributing to it and siding with people who call others racist just for refusing a huge feature commit during a feature freeze? > I know this is unrealistic, but we should all be striving along these lines. > > I'm horrified that you have received hate-mail. This is only a flight sim > for goodness sake. We have a long tradition here of friendly and orderly > debate. These are probably the most reasonable sentences within this whole debate. Regards, Stefan |