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
On Monday 23 April 2012 07:05:58 Renk Thorsten wrote:
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.
Please don't. Framerate is
On Sunday 22 April 2012 14:46:09 Bertrand Coconnier wrote:
And if, at the end of the day, your
change is not included in FG, will it be that terrible ?
As a user, I would answer this with yes. Water looks fantastic in FG but it's
also taking quite some toll in performance. Since performance
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
Thorsten wrote:
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
There's the problem Thorsten. I didn't have the info or the knowledge to
do the second bit.
Neither you nor Emilian honestly could have come up with something like this?
=
var setBasicWeatherScattering = func {
# establish the minimum cloud cover
var max_cover = 5;
for
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
On Sunday 22 April 2012 11:02:46 Renk Thorsten wrote:
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
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
On Sun, 2012-04-22 at 11:02 +, Renk Thorsten wrote:
After the last related discussion, I've really been thinking a while if I
should bring this up again or not.
Let me just add to the discussion that 'technically perfect' always will
look a tad odd to humans since the world around us is
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
Thorsten wrote
-Original Message-
From: Renk mailto:thorsten.i.r...@jyu.fi]
Sent: 22 April 2012 12:03
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] Water shader issues
After the last related discussion, I've really been thinking a while if I
should
bring
I don't think your analysis can be correct;
I don't particulary care. In my version of the shader, the problem is fixed for
good and performance is improved, I've posted the code which does it, if you
prefer your version of the code for whatever reason, be my guest. Likewise, if
you and
Plus, if you neglect the curvature effect in every relevant vector, the
rendering artefacts at the tile boundaries must go away, because the
differences in rendering geometry between tiles go away, and they're the
only thing which can introduce the artefacts in the first place.
Turns
Thorsten wrote:
Plus, if you neglect the curvature effect in every relevant vector,
the rendering artefacts at the tile boundaries must go away, because
the differences in rendering geometry between tiles go away, and
they're the only thing which can introduce the artefacts in the first
15 matches
Mail list logo
