While the water shader is a visual effect, is there any way to translate
that in to a "physical" wave that would interact with water craft?
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 peo
> 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
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 wit
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, wh
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
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
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 on
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 real
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
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 n
2012/4/22 Renk Thorsten :
>
> 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 mor
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 freq
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 worki
> 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 Emil
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 t
> 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
16 matches
Mail list logo
