I have one quick comment. Open-source projects tend to be "merit" based
rather than authoritative. One could read Thorsten's message not as
appealing to his authority, but simply trying to establish some "merit"
points by referencing another situation outside the FlightGear project.
Thorsten did not emphasize his work with sky and could shaders -- I assume
not wanting to take his message over the top, and leaving it to the
developers and contributors to connect the dots. Let me connect just a bit
...
If you follow the forums, you will notice that Thorsten has been one of the
few people that has really dived into trying to understand the subtle
effects of lighting and shading and illumination and all of that as it
relates to human perception -- with the end goal to make FlightGear sky,
clouds, fog, haze, sunrises, sunsets, etc. far more realistic than they are
now. He is way down into the subtleties that most of us would never think
about except when he posts his screenshots we say WOW!
I also say WOW! when I look at the water effects -- those have been a great
addition too -- especially at a personal level because I do some marine
aviation work for my day job and have been able to show some really nice
results in the simulator that parallel reality quite closely.
So I think Thorsten has way more than established his credibility within
the FlightGear project. And also so has Emelian.
One of the original flightgear contributors used to use a marine saying to
describe what I think is going on here. "Every man has his own way to tie
up his boat."
The great tradition of the FlightGear project is to try to find a way to
offer both methods when faced with strong opinions about how the boat
should be tied up. I don't know if that would be easy or hard in this case
-- but could the changes be presented in a way where an average person
could easily switch back and forth between them and look for rendering
differences and performance differences?
Thanks,
Curt.
On Apr 22, 2012 7:48 AM, "Bertrand Coconnier" <bcoco...@gmail.com> wrote:
>
> 2012/4/22 Renk Thorsten <thorsten.i.r...@jyu.fi>:
> >
> > After the last related discussion, I've really been thinking a while if
I should bring this up again or not. I don't want to annoy people just for
the sake of it, I know open source development is often a thankless task in
which one frequently gets to hear more complaints about things not working
than thanks for things working, and all in all I perfer a pleasant
atmosphere on the mailing list, and critique of someone's code tends to
lead to the opposite.
> >
> > But then, we had a performance discussion, and I had my share of
criticism about my use of Nasal slowing things down, and in the end it's
information which is better transmitted than not.
> >
> > Let me nevertheless start off by thanking all the people who worked on
the shader codes I've been looking at - I learned a lot about how this is
done and what can be done by just taking things apart and putting it back
together again, I have often enjoyed the effects before starting to mess
with shaders myself, and I guess many others also do.
> >
> > I've been over the water sine wave shader again, seeing if I could make
run it faster. What I found reminded me of something I (mean-spirited as I
am) did to a PhD student starting to work for me. I asked him to write a
code evaluating a quantum mechanical scattering process. He did so using
an established general-purpose Monte Carlo integral solver. I wrote a code
for the same problem, we compared the results and they were the same, so we
did solve the same problem and had the same solution - just my code was 100
times faster. Afterwards, he was ready to accept that he can learn from me
how to code physics properly.
> >
> > That miracle was accomplished by me telling the integral solver where
performance is needed and where not (technically, this involves using an a
priori suitably biased sampling distribution, which after the fact gets
corrected by conditional probability calculus - which can be proven to
work, but looks like black magic). To give a very simple simple example, if
we want to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't
really a good strategy to spend an hour to calculate a billion digits of
pi. It requires to understand the problem and not use all-purpose, but
specially designed problem-solving strategies.
> >
> > The same accuracy statement is true of the shaders by the way - so far
all I have seen use the Blinn–Phong shading model, so it's completely
useless to aim for an accuracy beyond what that can deliver, because
Blinn-Phong is already an approximation which limits the precision that can
be achieved.
> >
> > Now, it struck me that the water shader computes wave patterns and foam
on a meter-scale. It does so even for a pixel which is 120 km distant (and
which probably represents an area of 100x400 m or so). We first calculate a
very detailed wave pattern and foam for that pixel, then let the renderer
average everything out again to give the pixel a color. That didn't strike
me as a particularly efficient way to do things.
> >
> > I replaced the wave pattern in the distance by something that averages
to the same thing. That's not the average wave pattern (=a flat surface)
because reflected light intensity is a non-linear function of the surface
distortion, but noise with the right amplitude, leading to the same
standard deviation and the same average, gets the job done. I also asked
not to compute any foam beyond some other distance. As a result, the shader
performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at
30.000 ft looking at the horizon, 120 km visibility range).
> >
> > 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. So in terms of performance, simplifying the rendering
of distant objects counts a lot.
> >
> > I have spent 30 minutes testing the visual impression of my changes in
different winds, in different light and from different altitudes, and I
could not spot any problem - the shader just ran faster. Despite this, it's
possible that there is a problematic situation somewhere. But the answer to
this should not be to revert the changes, the proper answer should be to
code an exception dealing with the particular problem.
> >
> > I did not get the impression that there was so far any attempt made to
optimize the performance of the water sine shader. It's difficult to
compare directly since I added the whole terrain haze and lightfield
rendering, but I suspect that if all I did (remove redundant operations,
throw per-frame constant computations out of the shader, do not use
textures to sample constant colors, do not interpolate the normal of water,
do simplified rendering for large distances,...) would be applied to the
original water shader, it could run twice as fast in many situations
without any loss of visual detail.
> >
> > I know that it's tempting to ignore me, because at the end of the day I
still don't really know a lot about how the technical aspects of 3d
rendering work. But on the other hand, once we're inside the shader, it's
just an algorithm to compute a physics problem. And this I know in all
likelihood much better than most people on this list. So do with the
information what you like.
> >
> > Have a nice Sunday!
> >
> > Cheers,
> >
> > * Thorsten
>
> Thorsten,
>
> 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.
> 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.
>
> 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.
>
> 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.
>
> Once egos are involved, a discussion can no longer take place at the
> technical level. No matter how good your technical arguments are.
> People will resist your proposal because, in their minds, it would
> mean otherwise that they acknowledge you are an expert while they are
> not.
>
> 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.
>
> 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 ?
>
> Good luck.
>
> Bertrand.
>
>
------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
