> So no reason the get polemic or arrogant: > >> I wrote 'scenery and models', I did not write 'trees'. > ... >> Which of these two statements did you find hard to understand?
Heiko, that didn't come out of the blue. That came after I took the time to explain something, then explained it in different words, then explained the same thing in yet different words. This turns frustrating eventually. Basically, here you are throwing me something into my face which I have explained myself previously as if I were not aware of it. There can be three basic reasons for this: a) You deliberately misunderstand me and want to provoke me. I don't actually think so. b) You do not read carefully what I write. That'd be disrespectful in a discussion, since it takes me much more time to write something than you do read. c) You have genuine trouble understanding what I write. In this case, I would think (since we're both German native speakers) that you'd contact me offline for explanations. Since you didn't do that, my working hypothesis was b). So, for the record, I am willing to discuss and to explain my position, even a few times, but I require that whoever discusses with me makes an effort to read and understand what I say. That is not arrogant, elitist or anything like that, because otherwise the discussion is a waste of my time. > However, I simply I had the feeling that I somewhere read that there has > been a more simple way proposed to have your shader working together > along with the other shaders. Yes, Emilian sketched a way to include the fog function from a different file. Unfortunately, that's not really straightforward since I also change the light and fog lighting, and it's not clear to me after thinking about it for quite a while how to do it technically without doubling or even tripling a lot of computations. Maybe that's just my lack of insight into Effect file structure and GLSL coding. I listed a detailed discussion of issues I saw when working on the water shader in a post on this list a while ago (which you probably missed), some of it was discussed, some was not. The original plan had been that Emilian and Vivian pick up the Atmospheric Scattering framework and incorporate that into their pile of shaders which they processed (that was like 7 months ago). Since this didn't move forward, I decided at some point to work on the problem myself and start converting shaders the way I would do it. After a (somewhat heated) water shader discussion I offered my help to Emilian if he wanted to follow up his original idea (since he seems to have a clearer picture of the technicalities) something like 2 months ago. Nothing has come out of it so far, so even if I wanted to try something different (which I'm not really sure of), at this point I am stuck with my way of doing things. So, just saying that there's a more simple way doesn't really change anything. Let me state again, whoever wants help/explanations/whatnot to make shader X work in the framework will get it from me as much as I'm able to. But I'm not a GLSL wizard, I can design an algorithm which does what I want, but I can't code elegant designs. In many situations, I felt pretty much left alone with any questions I posted (to date, I still have no clear idea what the format of 3d noise textures in the shaders actually is for instance), so I had to come up with my own solutions based on trial and error. That's okay, but to say after the fact 'Oh, but you should have done it like that...' is very cheap. > ... could have written in one short sentence: >"Sorry, some things goes behind my knowledge, that's why it isn't there. > If anyone interested to help, you are welcome!" or anything like that. Yes, it could. But you started the argument with 'users want' and the relevance of my text was that the existence of people wanting something doesn't make me do it, the same way as just me wanting things doesn't get them done. > And at > the end we wonder we have it again, that people come up and say "Uh, > there is now way to contribute....; there are all feeling like > elites..; the don't listen to users; ... etc, etc. I strongly disagree. There is a world of difference between cheap user response and meaningful user response. Cheap user response starts from the assumption that the developer is basically unable to notice or know even the simplest things, and then the response is based on the wishes of the user with no regard for what is possible. 'We need better framerate.' or 'Clouds should not turn when seen from above' are such statements. I'd basically only say that if I were of the mind that developers are too dumb to note that all shaders to max cause low framerates and that they would have coded 3d clouds without noting that they turn when seen from above. Thoughful user response tries to understand what is happening right now, why things are the way they are and ideally comes up with an idea how to improve things. My position in general is to deal with cheap user response cheaply or not at all, so that I have time to deal in length with thoughtful user response. The latter category has lead to many useful additional features coded into weather and shaders, and I value it highly. Conversation always goes two ways - it's not my task to give long and polite explanations to every cheap comment made, but if the other person tries hard, so do I. > I hope you understand, then at least that's exactly the feeling I got > here with your replies, and I hope that wasn't that what you wanted. My intention was to give you an explanation, my feeling through the whole discussion was that you did not read what I wrote, at least initially I assumed that was my fault in giving a bad explanation so I tried again, then, well, see above... > Sorry, that's the goal of every flight simulator: realistic as > possible, perfomance friendly as possible. Only knowledge and hardware > is the limit here, and this limit is pushed further every year. Yes it is, precisely my point - so a user asking for it implies that the developers are unaware of the goal and don't actually try for realism or framerate. It's a cheap point to make, and it's really annoying when you took two weeks benchmarking and optimizing a bit of code and have no idea how to get even 5% more to hear 'Oh, but this needs to be faster'. > But that doesn't mean that we should forget users- Because the users > from today are the developers from tomorrow and NO, in this context I > don't mean problems with framerates here. Users and heir contributions > are our gain, not money. See above (and also remember how you told me off in the forum quite a while ago when I was a rather annoying user dabbling in development! - it was the right thing to do then, and it still is now). > But you also wouldn't have made such a statement if you wouldn't have > forget that FGFS is used in some research and even commercial projects, > and that's even one goal of our project. The essence remains valid - also a research project doesn't get things just because people want it if my time is the limiting factor. But I have yet to see cheap user response from a research project. Usually that comes as a thoughtful response and gets a thoughtful answer. > And that's exactly what I have wished: that you see such complains more > as a feature request and not as a personal attack on your work. Heiko, I did not at any point see an attack of my work from your side. The problem here was that explanation after explanation was seemingly lost into the void with you bringing up points as if I had never explained anything. > Just to remember what you wrote: "For information, my priority list is > very much focused on looking out of the cockpit and seeing the scenery" Yes, I wrote that. It happens to be true. I work on things which I enjoy. Anyone here who frequently works on features he doesn't enjoy? > But I can't deny, I think no one can, that it is simply dissapointing, > if you work pretty hard on something and at the end you have to see that > it only works for some configurations, though you would have expected > something different. No, we depend on others here. So, the solution is - we get in touch with the people who can help, we make our case why it's important, everyone thinks over it, sometimes things get done, sometimes not and if not we have to live with the decision of the others. You might have asked 'What needs to be done to make shader XXX work together with the sky?', received the answer and then asked if someone could convert the shader because it's important for YYY. Insisting that unsupproted shaders are a bug and are as problematic as rendering artefacts didn't exactly help making your case. > I don't take offence because someone doesn't enjoy the same things as > me, but I expect from this person that he respects that I have another > favour, and when I come up with this, that he doesn't see it as a > personal attack and it ends all in a big strong discussion. Ah, but that's not what you did. You insisted that there's a bug, that there's inconsistent development, that incompatibility is a huge problem, that things were okay before, and you disregarded any argument to the contrary. For instance, I would still like to see your assessment of the 3000 m visibility screenshot with skydome shader on. I haven't heard a clear message from your side that this situation is actually not okay or even acceptable. Despite my problems with your responses, this ends in a big discussion rather than being ignored because I respect you much and I want to give you a proper explanation even if it costs a lot of my time and nerves. > And I had discussions off-list with others about he whole topic, and we > agree that the current design is a mess, sorry to say that. > > I can't tell if there is really 20-30% better perfomance with your > solution, but I do see maintenance friendly at such complex things like > shaders as a gain equal to 20-30% better perfomance. See above, it's not that Emilian didn't have his shot at the problem or as if I would deliberately withhold information or prevent Emilian from following his idea. > But I do more want at the end to have a GOOD solution, a good SYSTEM, as > friendly to use as possible. In a nutshell, it's framerate against ease of maintenance in many cases. Simple example - I can use approximate analytical solutions to combine fogging expressions, the result is twice as fast as the naive thing, but you can't easily see where it comes from without knowing a bit of math. Expansions around Earth curvature usually give a factor 3-5 performance gain of code fragments, but you have to be able to understand Taylor series to see what is happening. So it has to be good for whom and friendly to use for whom? The end user favours framerate, the developer ease of maintenance. Some problems do not have a unique solution, there are just different opinions what is important and what not. In this case, arguments have been exchanged, but to point fingers at me for not following Emilian's opinion after I explained where I have a different opinion isn't really helpful. Cheers, * Thorsten ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
