Bertrand, apparently I am really doing a bad job expressing myself.
> After having read this long post, I had mixed feelings. Posts that > start by something like "First of all, I find that you are all doing a > great job" are, in most cases, intended to tell the exact opposite. This is not one of the cases. I honestly and genuinely have a lot of respect for the shader work done by Stuart, Emilian, Vivian, Frederic and others. In many cases, I could not have come up with the code myself due to my lack of technical skills, but seeing how it is done, I can learn it and improve. I am more than a bit distressed that you interpret my intention as trying to do the opposite. > And indeed, at first, it looks like you are trying to prove you are > more skilled and experienced than most people of the ML are. As far as > I am concerned I am no expert in quantum physics so you are most > certainly more skilled and smarter than I am and ever will be. No, you can not infer that. I am quite certainly more skilled in calculating quantum physics, but to deduce from that that I am more skilled in other matters is wrong - there is no transfer of knowledge. As for smart, that's secondary if you lack the skill and knowledge in some area. If I am smart or not is completely irrelevant if the problem is fixing my car for instance, because simply I can't do it. > After some further thoughts and knowing the contributions you made to > FG, it seems that there is another message behind your post. It looks > like you are trying to submit some changes to the code of FG, changes > that are technically sound but that some people are resisting. You > probably hit the human factor. *sigh* I try never ever to do hidden second meanings in what I write anywhere in the internet. I come from a particular cultural context, I deal with people all over the world who can't even see my face while I write this - I can't reasonably expect anyone to deduce my hidden meaning correctly. So if you look for any hidden meaning, you are probably seeing random noise. My motivation is precisely as stated: I would like to share information - theoretical arguments, results of practical experiments and bits of code - because I think it is relevant and can improve performance. I would like to do it in a polite way, but I would also like to do it in such a way that it isn't ignored offhand and that I don't feel talked down to. > According to this post, the strategy you chose is to exhibit your > professional skills and your immense experience on similar subjects. > You are thus relying on the authoritative argument. Unfortunately, > this strategy is generally doomed to failure. In most cases, the > reason is that the authoritative argument is hurting egos : it > implicitly claims you are an expert while (some?) others are not. What you call authoritative argument is simply my attempt to establish some credibility. After past experience, this seems necessary. Just to give some examples of how this went: Me: 'For any visibility we can actually render, the normal (before wave noise) is (0,0,1) in model space to such a good approximation that you won't spot the difference to the actual normal including earth curvature if I show you a picture.' This is a statement based on a calculation which I later posted here. It is also a reasonably precise, technical statement. Emilian's response: Emilian: "That will give you even worse lighting difference between tiles, and will shurely give you ugly artefacts and wrong speculars in relation with the sun." My calculation indicated that no such thing will happen, and as I tried it later in the shader, it did in fact not happen. I might be a bit touchy here, but it seems to me that Emilian dismissed my statement offhand without bothering to do either the calculation or the actual test, just based on his belief that I am wrong. After I did the actual test and reported that the results agree with my findings, the response was: Emilian: "If it looks right in one limited test case, doesn't mean it's right, or the proper way to deal with it (so it won't backfire later on)" In other words, Emilian still did not believe me. In actual fact, after a week of testing, the rendering artefacts predicted by Emilian never showed up on my system. *** After I posted what causes the tile boundary bug and what code needs to be replaced to fix it, Vivian's reaction was Vivian: "I don't think your analysis can be correct (...) Something wrong with the texture? I don't think so.(...) " (followed by a claim that my modification would not adjust sea color based on the sky, which is manifestly wrong...) I think that sums it up. I wasn't to learn why Vivian thinks that my analysis cannot be correct, or why nothing can possibly be wrong with th texture while the problem disappears when I use a different texture. *** We might happily continue with recent reactions: I wrote (making a very general statament not specific to water): Me: "In general, how much performance one spends on distant stuff doesn't influence the visuals drastically, because these pixels are more and more fogged and more and more details are averaged out. But more than 80% of the vertices in the scene are farther than half the visibility range, and a fair share of pixels is, and that's the stuff you see from a typical cockpit perspective." (note that I explicitly make a distinction between distant vertices and distant pixels) Emilian: "All the sine stuff happens in the fragment shader, so performance is directly related to the amount of screen pixels covered by water, not on the amount of vertices. Maybe just testing the pixel depth against the fog distance might bring some performance in fogged scenarios, where you won't compute the sine waves beyond visible range, for the few pixels that fall into that category." He doesn't at all acknowledge that my statement was not water-specific, nor that I am well aware of the difference between vertices and pixels. Despite the fact that I already tested in a clearly non-fogged scenario (120 km visibility range) that not computing the sine waves beyond some distance gives a dramatic improvement of performance (I quoted 30 fps vs. 42 fps), Emilian believes that this 'might bring some performance in fogged scenarios'. Okay. *** Vivian: "I'm sure this is all very well and good - but what are we meant to be testing/doing/patching? Your last patch was all very good - except it only worked with advanced weather, so I was forced to abandon it." Needless to say, the last patch did not 'only work with advanced weather', it just used a single property to summarize cloud coverage instead of computing the cloud coverage inside the shader as I had explained all along. It is a few line Nasal computation to set the property for Basic Weather if needed, a property rule can do the same job I guess, it is a change of one number to make the patch run with the 'cover' parameter in the current version of the shader instead... What 'you' (i.e. all people dealing with shaders) are supposed to do is think about what the principle is that I try to apply to improve performance, consider their merit and apply them to your own work when they're found to be working so that ultimately we end up with faster rendering. I'm not really after fixing one particular problem here. *** All in all, in this conversation I feel generally talked down to as if I would be a schoolboy intruding into a discussion of the engineers whose every statement can be dismissed without giving any good cause for it and who is just considered making a lot of noise. As I said, I have great respect for Vivian and Emilian, but I find the style of this conversation inacceptable nevertheless. > Once egos are involved, a discussion can no longer take place at the > technical level. No matter how good your technical arguments are. I am sorry, we're past the technical level since the moment where I posted the code to fix a problem and got the response 'I don't believe you.' It was at this point that I changed to the 'authoritative strategy' as you call it to indicate that I am in fact not a schoolboy to be talked down to, but that there is some cause to take me seriously and at least give me decent counter-arguments if I am to be wrong. > People will resist your proposal because, in their minds, it would > mean otherwise that they acknowledge you are an expert while they are > not. Look, I honestly don't really care much beyond a point, because I'm currently writing my own set of shaders, I can structure them the way I like, I can improve their performance by any means I like. I am happy to share that work, or commit it to GIT for everyone else to have. But my main motivation is that I can make the atmosphere rendering look like what has always fascinated me in flight, and I would continue the work even if I would leave the project tomorrow over disagreements. The only reason I am posting here and trying to be calm while technical arguments are dismissed on the basis of belief is that at this point I feel responsible for the project as a whole, and if there is some general strategy to make shaders run faster, then I would like to make that strategy known to as many people as possible. I talk to a lot of people in the forum, per email or per PM who are concerned about framerate issues. In fact, I am as well. So there is an issue, and I think 'You need a better computer' is not the best possible response. > Furthermore, asking the whole ML to act as witnesses of your > authoritative argument will lead nowhere. For the simple reason that > most people are indeed no expert in the field of quantum physics, sine > waves, shaders and whatnot. So they cannot approve or disapprove your > claims. As I said, if giving a theoretical calculation why X shouldn't matter doesn't do the trick, if doing the test in practice that X doesn't matter doesn't do the trick, then what does? Stating my experience is by no means intended as a claim that I am right. But it is intended as a reason to actuall read through what I have to say and think over it, because at the end of the day it is likely that a theoretical physicist knows things about light scattering. The reason why this goes to the whole list is that I want to share my findings with all people, not form an exclusive ring exchanging secret knowledge. Now the information is on the list and publicly available and can be references by everyone. > All I can suggest you is to drop the authoritative argument and try to > stick to the technical facts. And if, at the end of the day, your > change is not included in FG, will it be that terrible ? See above. All I can say is that I am really, genuinely frustrated with the way this is going, and so I will simply put the matter to rest, restrict myself to making my own set of shaders faster and just shut up. Cheers, * Thorsten ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
