Could this weather properties be shared trough network somehow
?
No idea, I'm not into MP at all, so I know next to nothing about how easy or
difficult it is to transmit anything more.
Sorry this dumb questions, I just had the intention to show flightgear
weather on a external map/radar
But if this thunderstorm looks exactly the same from different angles is
not that important in case there IS a thunderstorm probably. Sharing the
center position, pressure, movement, winds and probably cloud density
over network is sufficient, in case this data could be shared in
metar-like
I think that's just a side-effect of having so many pixels covered by
(multiple) quads with alpha. I'm not sure there's much we can do
about that, unless we somehow start dropping sprites. I'll have a
think - 3D cloud perf has always been a big challenge.
Based on my own experiments, I
I suspect the difference in light intensity
(dynamic range) doesn't fit in an 8-bit 3-component color.
It sure doesn't, but I think you're thinking way too complex. We don't want to
render physical light intensity, we want to render perceived light intensity,
and there the Weber Fechner law
You need to do High Dynamic Range rendering to accurately capture these
differences and the eye's ability to adapt to them. Basically, you do all
the rendering in floating point and at the end convert the values to RGB
colors with a mapping operator. We don't do that yet.
I'm currently
Flightgear has a nice (local and global) weather implementation AFAIK.
Are there some ideas (or solutions) how to map custom or shared weather
values in a (internal or external) weather radar ?
Someone was working on that, and we got to the point that Advanced Weather
writes thunderstorm info
If you need any information about the moon's position and/or phase, just
let me know. It should be trivial to extract these values from the
ephemeris code.
Thanks, that was what I was hoping for :-)
It depends a bit on if Fred wants to do anything with the moon - my scheme
would be fine
I was toying with this for a while, but now I have a reasonably cheap solution
to render moonlight effects:
http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=195#p170250
Now, all I need is the info about the current moon phase and if the moon is
above the horizon which is
Interesting, looks good. So effectively it glows...
Not really - unlike glowing stuff, it is actually obscured by cloud cover for
instance.
* Thorsten
--
Everyone hates slow websites. So do we.
Make your web apps
Thanks for the responses, I think I understand the issue much better.
The eye catcher is not the gem, but things you see, and notice, from a
distance,
like a huge flag with free writen on it.
I guess it'd just be a matter of setting things up. Sure, on a laptop things
tend to get lost. But
Hi Durk,
Please note that I never said that we didn't *have* any major new
features. The major difference between previous years and this year was
that we didn't have *obvious* eye catchers. Every feature you mention is
really a great improvement, but they are not sufficiently salient
presenting something drastically new every year. But this year the new
essence seemed to be missing somewhat. I didn't really feel that we had
any major innovations to show (with the notable exception of project
rembrandt, which ran well on Alexis' machine). With our multiscreen
So I know clouds write a z-buffer, and I know terrain reads a z-buffer -
they just don't seem to use the same z-buffer. In which case the whole
scheme doesn't work as advertized. Does that make any sense? Is there
anything special about clouds?
Seems I can't figure that one out on my
I've managed to get a test implementation for the idea of filling the depth
buffer early by clouds by inserting tracers into some of the cloud calls. The
tracers are in essence just opaque white sheets marked with a top shade factor
of 0.0 (black - no real cloud can ever have that low a
I see no reason to include multiple options of the same texture if one
could do just fine. It's just a matter of removing them from the xml
file (or comment hem out).
I take the lack of other responses as silent agreement and will proceed as I
see fit then.
I also noticed you effectively
I haven't really been following this thread closely... are the
tracers basically occludes? Are they completely opaque?
Yes, they're completely opaque. That's tracer.frag - if it gets a white
gl_Color from the vertex shader, it's a real cloud and the fragment is dropped,
if it gets any other
I realize that I'm confused about whether you are working on Stuart's
clouds in C++ or clouds in Nasal.
They're the same now - there's an interface to generate a cloud from Nasal
which is what I'm using, whereas Basic Weather uses and xml format for layer
declaration, but for rendering
If I understand correctly, you have only one model of the cloud, which
has a bunch of sprites and a few tracer polygons. I don't know if this
is practical in the current system, but I'm saying that it would be
better to draw only the tracers in the tracer pass and the sprites in
the real pass
I have two questions to which I'd like to gather a few opinions:
1) Emilian pointed out here
http://www.flightgear.org/forums/viewtopic.php?f=68t=17114hilit=procedural+texturingstart=30#p165312
that terrain textures are a fair share of memory consumption and concluded that
we shouldn't use
Speaking of which - it'd be nice to have local north as well defined
direction as well - that would allow for things like the snowline
being higher on south slopes ...
In the Northern hemisphere ;-)
Quite so - but once you have a north-pointing vector, the rest is trivial
because you can
Btw, in terrasync terrain you can safely use gl_Vertex.z as altitude.
There are some issues with that one, but only in custom terrain generated
after 2009, which you're not interested in supporting anyway.
FYI, I fixed the snowline problem for custom terrain half a year ago by passing
camera
Hint... I already knew that
In which case I'm puzzled by your remark that I wouldn't be interested in
supporting custom scenery anyway when you know that I've cooked up a scheme
which does just that. But maybe I'm simply too tired.
* Thorsten
Maybe it would be better next time to ping some more people and notify
them
about problems in the scenery toolchain.
Emilian did it
(http://code.google.com/p/flightgear-bugs/issues/detail?id=888)
and we fixed the bug, which means that your additional calculations are
unnecessary now for
And the matrix transform is for free...?
Oh, I forgot, a useless matrix transform is ok to be run on milions of
vertices, but one that actualy has a use, and runs on tens or maybe
hundreds at most, is killing performance
A uniform float doesn't have a matrix transform. I thought you'd
I'm talking about the ep ... which is done for each vertex, everytime
... and the relevance of that observation to the ongoing discussion is...?
It's needed among other things to construct a sun/horizon coordinate system for
the lighting computations, so the ep has to be computed
Even the oldest hardware that
supports OpenGL programmable shaders implements vector operations, and
a vector multiply-add has, as far as I know, the same cost as a scalar
operation. On the other hand, the shader compiler might be able to
combine multiple scalar interpolations into vector
One can assume that
a vec4 varying is no more expensive than a vec3.
(...)
I'm not sure it's useful to think of each component of a varying
vector as a varying i.e., three vec3 varying values use up three
varying slots, and so do 3 float varying values
I dunno...
Just counting the number
I thought it might be a good idea to write up a few things I've tried recently
and not seen in widespread use - so that either others know about them as well
or I can find out what the pitfalls are.
Basically this is about reducing the number of varyings, which is desirable for
at least two
and it works particularly well with some of the
angle-dependent rock shaders.
Indeed it does - Yosemite valley from above (not bad for default scenery...):
http://users.jyu.fi/~trenk/pics/tree_slopes.jpg
* Thorsten
Do you have some other local modifications (materials / texture set) in
this screenshot? But it's not a part of the world I have explored, maybe
I'm simply ignorant of our textures in such places.
I think this is all classified as EvergreenForest (or at least some forest...),
and the
The reason I didn't just label it material definitions was that I
don't think that
a new user is going to understand what that means, while the concept of
different textures should be familiar to people who have some background
in graphics, or gaming.
I'd go for something like 'terrain
Hi Stuart,
played around with this a bit yesterday... *very* nice feature!
The default values look about right to me from a typical
temperate latitudes viewpoint, and using
much smaller values gives a quite nice effect possibly suitable for
more northerly latitudes.
I agree that the
Hi Emilian,
Understood...
I will refrain from any further tests/opinions on this topic then. Please
accept my apologies, and disregard any of the issues I've raised.
Everything's working smooth, and looks better than IRL... it's just my
imagination playing tricks, better get my eyes checked
I've had a look at this in Scotland, where it is a bit too bright based
on my own experience, so I'd like to leave this change so it only applies to
South America. Obviously I could do the opposite and make some
specific materials for Scotland (hmmm, good idea :)
I wanted to have a look at
First I get this when opening the shader settings dialog:
Nasal runtime error: non-objects have no members
at $FG_ROOT/Nasal/props.nas, line 181
called from: __dlg:shaders-lightfield, line 32
and the slider is off to the right, and can't be of much use.
Assuming that this is the shader
I'm taking a look at this merge request. One thing I don't quite
understand from doing a code read is the chance to the overall
Grasscover to use the tundra-hawaii-green texture, on line 1909 of
regions/materials.xml.
Can I check this is intentional?
This is intentional - I'm trying to
Nice - looking forward to it!
(and before anyone asks, I'm not planning to reduce tree density on
shaded slopes...)
We wouldn't really want that - shaded slopes in my experience do not grow less
trees, they just grow different tree species... :-) I wonder if we could trick
the shader into
I've sometimes wondered if we could have much greater variety of
'trees', to place scrub (cactus in Central America, bramble in Scotland)
in areas where full trees don't make sense. I guess wi the regional
materials that ought to be much easier?
Yes, it's quite straightforward -
I wonder how we deal with this with the next release- I'm sure a whole
lot more users will complain about the stuck while launching FGFS.
By printing a message like 'Building database during first startup' on the
screen? By including the binary nav data with the release? Doesn't look like a
You know that rendering a transparent object twice alter its
transparency.
Of course, you can avoid to render it in the color buffer using write
mask in one pass.
What I do with the trees is render just the opaque bits early on as white with
essentially no light and fog computations to
I am pretty confident (and hope to test, but it sounds like you might
beat me to it) that for either the classical (non-Rembrandt) render,
doing a depth-write *only* pass of the entire scene will be a net win.
(Again assuming the fragment shader is the bottleneck). Since this will
To summarize, all objects having a pass of render bin -1 are rendered
before any object having a render bin 1. If an object have two passes,
it is rendered twice, once with the objects of the same render bin than
the first pass, once with the objects of the same render bin than the
second
It seems some change during the last weeks broke parts of Advanced Weather in
at least two places (I had no problems under any conditions until my update
yesterday, now I can reproduce both issues consistently on both master and my
devel branch).
The more serious problem is that under some
I'm trying to catch up with recent developments, and I've pulled and compiled
an up-to-date snapshot today. One thing I stumbled across by accident is that
we seem to have lost the ability to do software rendering as a fallback. If I
start today's Flightgear binary without access to the GPU
I'm trying to understand why clouds can obscure hills and hills can obscure
clouds properly.
My individual bits of knowledge are:
* clouds are drawn from outside in, because they are in a depth sorted bin, and
this is why clouds obscure other clouds properly.
* hills are not drawn from
So you are calling for git monkeys that take care of the tedious
process of getting changes into the tree?
If it is as critical to do this right as you say, everyone might be better off
if only people who know what they're doing handle commits and every other
commit goes through them,
Hi All,
unfortunately, due to personal reasons, I won't have much coding time for the
rest of the year, which means that I probably won't have a chance to do some
things I sort of promised to do (make more shaders work in the atmospheric
light scattering framework, help making atmospheric
There remains this strange discrepancy between what people are outraged about
and what could potentially stand in court.
Wah. They're immoral scammers by any examination. They're suckering
people into not only buying free software, but public domain materials as
well!
I think the truth
Hence I would use the same license to keep off scammers.
(...)
Anything but code should be possible to license similar to GPL, but not
allowing any commmercial use.
My two cents:
First of all, define your use of 'scammer' here. From Wikipedia, I get A
confidence trick is also known as a con
FlightProSim does not defraud its customers as far as I am aware.
According to reports on this very list (hint) and elsewhere they don't
comply with the money-back guarantee they advertize.
Well, since there's always small-print (which I don't know) I would leave that
to the courts to
We haven't
been able to pin them down on a specific technical violation of the gpl,
but that doesn't mean they are legitimate, honorable, and ethical.
They're immoral scammers, plain and simple.
It galls me to speak up for FlightProSim, but such statements are, as far as I
am concerned, not
Computing constant values at runtime is bad design and we should not do
that. No matter if we notice a significant increase in load time now or
not. The ground elevation at a specific point is well known at scenery
generation time and that is where the vertical position of an object has
to be
I know, some people on the forum would like to eventually replace
fgfs(.exe) with nasal(.exe), because apparently everything is just
better (tm) when implemented in Nasal (core = bad, nasal = good). But I
really think this is a completely wrong direction - and harming the
project.
Could we
I still haven't given up on the idea of 'masking' the terrain pixel shading by
the cockpit, since even a very simple mask easily makes the system 50% faster
for me. Lauri has kindly given me some instructions on how to use the stencil
buffer - so the idea was to start by filling the stencil
The typical fix is to edit the conflicting files and git add them the run
git rebase --continue.
But these files don't exist so I can't edit them, git add fails, git rm also
fails since they don't exist.
If the files no longer exist, I think one solution is to tell the system to
skip the
Of late, I have increasingly been running into some segfaults which seem to
have to do with peak memory usage (I don't think memory leaks are a major issue
for what I've been seeing, since some segfauls happened quite early on, and
especially when I try pushing my limits of graphical goodies).
Do I want atmospheric scattering on or off? That affects which are the
top two sliders.
You want atmospheric scattering on. Then the top sliders are 'Landmass' and
'Transition'. These you want at 5.
What did it take to make the correct dialog appear? Are you sure you have the
updated
Some variants of this have been going on for some time - currently my console
ends up swamped with messages (I suspect the AI traffic) like this:
Checking for end of cruise stage for :
Descent rate : 7.62
Descent speed : 154.333
VerticalDistance : -483.402. Altitude : 3584.04.
Are you sure about the syntax of the --prop=/sim/... command line
option? I thought it should be something like: --prop:/sim/... If I'm
right, you might still have the traffic manager running.
For all I know and can test, they're equivalent. Changing to --prop:/sim/...
doesn't change the
are there any screenshots available which compares before/after?
Not as such... A collection of work in progress is in the forum
http://www.flightgear.org/forums/viewtopic.php?f=47t=16884
but this is with my private not-necessarily-GPL development environment.
The comparison is otherwise
Is this work something that is active by default or does it need to be
turned on? Or is it only availble in a particular area? Do I need to do
anything special to look at the results beyond just take off and fly
around
anywhere?
Forgot: Works currently only with
Is this work something that is active by default or does it need to be
turned on? Or is it only availble in a particular area? Do I need to do
anything special to look at the results beyond just take off and fly
around
anywhere?
* atmospheric light scattering: on
* shader micromanagement
Hmmm, my shader micromanagement dialog box is only showing two options
right now. Category General: landmass and water.
I don't have the bandwidth at the moment to pull back master, but I've checked
the local branch from which I merged and I checked the log for FGData master on
GIT - among
I'm on the master/next branch here for these tests. But I haven't kept
close enough tabs on the lightfield/regional gui options dialog box to
quite know exactly what I should be seeing or where to start for hunting
what's going on. Shouldn't I be seeing quite a few detailed shader
Hi Fred,
I have created a merge request containing part of my recent experiments with
procedural terrain texturing - please have a look (I hope I haven't messed up
the request again...).
https://www.gitorious.org/fg/fgdata/merge_requests/175
Thanks,
* Thorsten
Are you sure you're using/looking at the correct fgdata? Looking at the
files here they use the proper uniform to determine if the normalmap is dds,
and reverse the normals only in that case:
I was looking at my devel branch rebased against master. Seems like one of my
'GIT strikes again'
I've just pushed a change that allows a material definition in
materials.xml
to include a parameters section, which is merged with the parameters
section of the effect. So you can now define parameters in the
materials.xml
file that can be used as uniforms in the effects file, and
Just stumbled across this one:
Effects/water.eff now declares png textures for reflection and nose to avoid
dds. The relevant commit changed the effect file and water_sine.frag but didn't
change the corresponding lines in water_lightfield.frag which has pretty
identical normal-generating
I'm very keen on the placement maps myself, but they are fundamentally
incompatible with the crop shader, as the placement information is
required well above the shader layer.
I like the idea of the placement masks, and one could use them to do LOD by
passing the mask itself to the shader
Since we usually don't have roadmaps and things, I thought I might try to put
this up for discussion early on.
I've been experimenting with a partially procedural texturing approach, and I
think this is the way to go forward, the outcome looks very convincing. My
experiments are coded within
Actually, the code that creates the texture is in
scene/util/StateAttributeFactory.cxx, but you would have to do
something similar to the noise texture code in TextureBuilder to
access your texture from a texture. It would be nice if the Effects
framework had a way to load arbitrary textures
First of all, a big thanks to Tim - Akenine-Moller Co. is indeed quite an
interesting read, and in addition to gaining a better understanding, I've so
far experimented successfully with a heightfield for parallax and normal
mapping and a simple irrandiance map instead of the ambient term in
The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing.
Most of the discussion is drifting a bit over my head now, but I'm pretty sure
that's not what I am talking about.
I am talking about a situation
This is an optimization to avoid running really expensive shaders on
geometry that will be hidden from view. The GPU has an early Z
capability and won't run a fragment shader if it knows the result will
be discarded.
But that can't be all that is going on. In this case I'd expect that if I
Which is very unfortunate, since in the common case it would allow a
huge amount of tile/terrain pixels to be dumped. Could we use a buffer
copying to trick to initialise a stencil plane on the far camera based
on the near-camera Z-buffer?
I've no idea what the penalty of a z-buffer
May I ask yet another dumb question?
In the first rendering pass of default terrain rendering, we use default.vert
and terrain-nocolor.frag as shaders. I have so far mindlessly copied the first
pass since I had no real clue as to what it is for. Its purpose seems to be to
establish that
The main reason to render textures at this stage is that textures with
transparency do change the fragments that are rendered. Calculating
the fog color seems wrong, but I don't have the sources in front of me
and gitorious is acting up.
So since we're not using transparent textures for
A number of effects files use .dds textures, leading to error messages
on the console.
IIRC in the last release, we suppressed these error messages for the
release, and I think we need
to do something for for 2.8.0 as well.
Of particular concern is terrain-default.eff which uses
Hi Tim,
If I could give some gentle advice, perhaps based on out-of-date
observations: you could really benefit from a serious study of
computer graphics. I highly recommend the book Real Time Rendering
by Akenine-Moller et al.
Thanks, that's actually not a bad idea. I think I'll get myself
Believe it or not, computer graphics researchers (not me) think about
shader work in those terms too. It comes off as a bit pompous to
assume that no one here would understand what you are talking about or
be able to come up to speed on the math if necessary.
I'm assuming here that the
..this kinda blending looks so good it should IMHO go into the
current release, even if it means delaying the release.
Just in case: The effect is quite tricky to get right, because the parameters
and overlay texture need to be somewhat carefully tuned for each landclass,
untuned it looks
Action plan for recovery :
1. Go straight to the point (actionee: Thorsten R.)
2. Write much shorter e-mails (actionee: Thorsten R.)
3. Read Thorsten's e-mails (actionee: rest of the world)
Bertrand.
(My) Life insurance : This is a miserable attempt of humour to try to
remind everyone
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
Hi Stuart,
Question for Thorsten: I've only integrated the
terrain-haze.[vert|frag], not terrain-haze-detailed.[vert|frag]. How
much additonal quality does that add, and is it appropriate for trees?
I'm in the middle of my holiday right now and will basically be mostly offline
for another
I get to see a seamless
and plausible match between sky and terrain from ground level to low
Earth orbit, at all times of the day and under any weather condition.
Scenery and models are now rendered correctly with the sky at all locations
and
all times.
Really? Look at the trees- Does
Heiko: Thanks, that's now an answer I was looking for.
Though I'm sure we will get bug reports as well by users complaining
where the shader from 2.6.0 went, or why shaders won't work.
Some of this confusion was already visible in the forum.
I don't want to bitch, but the thread started
My (completely biased) opinion:
*2.6.0
In 2.6.0 we had only the choice between default sky or Zan's sky shader.
In both variants shaders on aircraft and on terrain worked, but there
was the problem with horizon.
It gave us pretty cool looking skies, as you can see on the 2.6.0
gallery.
Is there a way we can have all three possibilities (default, skydome
shader, Thorstens atmospheric light scattering) selectable?
Atmospheric light scattering should not be thought as different from skydome
shader - it is the terrain/model/whatnot shader combination consistent with the
Anyway, just reporting what I see, but I am sure other
users must get VERY confused by such strange - it works,
then it does not work - behavior... but I suppose when
it is all documented the sun will shine, and shadows
cast...
Indeed. Forum reports suggest that users do get confused. So
So.if.someone.could.setup.a list of effect(combination)s that don't
work, I can try to construct something.
From my side:
Lightfields currently support
- of the detailed shader config dialog: water reflection (water slider) and
snow/dust (currently on landmass slider), all other sliders
There is a simple solution to that. Move the work in the fragment
shader. You
won't be scene complexity bound, and you'll also have the correct depth
available as (...)
Right... but I need the projection of the vertex position into the sun
direction in the horizon plane to compute light -
I would like to point the attention of people who can commit on flightgear and
simgear to two merge requests put in by Vivian recently:
https://www.gitorious.org/fg/simgear/merge_requests/26
https://www.gitorious.org/fg/flightgear/merge_requests/1564
This contains functionality which is
I'd appreciate it if someone could take a look at the
aircraft as well to check that everything is OK or if there is anything
to fix.
Hi Vik,
I rather liked the plane - some impressions in the Forum:
http://www.flightgear.org/forums/viewtopic.php?f=19t=9446p=159456#p159456
No obvious
I'd add to this list
* lightfields integrating well with other shaders.
For example, I know that the random vegetation doesn't work with
lightfield shaders, and the fix that Emilian put together to allow the
random buildings to work was a workaround rather than a full fix. I
think this
I'd like to propose having random buildings enabled in
preferences.xml, so they are switched on by default. I think they
improve the realism of our Urban, Suburban and Town sceneries
significantly.
I would suggest to have them on as default (so that people are aware that they
are there)
Torsten's question about what the release number should be got me thinking a
bit what I would expect from a 3.0 version, and I thought maybe I can put my
outcome for a discussion:
I think what makes the difference isn't so much new cool feature, but really a
good and intuitive integration of
1) What's the version number of the new release?
a) 2.8.0
b) 3.0.0
My impression is that it would be best to advertize Rembrandt as a new,
exciting, but optional and stil experimental development. The reason is similar
to what others have said - it seems to do really impressive things
Okay, I didn't get a message that this was merged, and despite the argument
that there's need for a discussion of the regional texturing scheme there
wasn't any discussion, so can I assume the subject isn't interesting at the
moment, discontinue to try to come up with GPL compatible solutions
Issue #1:
We finally found the reason why Heiko didn't get the lightfield scheme
properly:
/sim/rendering/shader-effects
is required to be true in skydome.eff but apparently not set any more by recent
GIT, it was however leftover in my autosave, so I didn't notice anything. I can
simply
The /sim/rendering/shader-effects property has been removed since before
2.6.0, and IIRC it was properly announced on this list.
I believe each of those properties was documented on the
wiki by Fred, and the major changes were announced on this list.
I don't mean to blame anyone for lack of
201 - 300 of 401 matches
Mail list logo