Emilian, just up-front to keep this discussion focused on what it actually is
about:
Do you, or do you not agree that 20 (or 16) km terrain loaded regardless of
the visibility is a sane value? Somehow, you still haven't really answered the
question, you're just expressing unspecified
Buildings/trees are generated at tile load time currently, and remain
resident
in memory, for as long as the tile is loaded. If you don't se them on
screen
doens't mean they're not there.
Yes, but strangely enough, this part of the discussion happened to be about LOD
systems and
Let's please be honest here.
I'll repeat it once more, I don't have a personal problem with you, I
have a problem with your methods, and AFAIK I'm not the only one, but
(un)fortunately, the other ones chose to stay silent...
If you refer to my methods of coding, I don't think we've had
While I think that sometimes Thorsten may give
people more benefit of the doubt...
After sleeping over it, I have to admit that Stefan is right.
I was angry about the way the discussion was turning away from being
productive, and that colored my response to Lorenzo, which is not how
Have you ever read the getstart.pdf? apparently not.
I've read it once, a long while ago. But I don't feel bound by what it says, in
my view the logic is that we implement what's reasonable, then change the
documentation accordingly, not that we first have a documentation as god-given
and
..a point I forgot to make: you (or your MUA?) don't attribute
properly what I wrote below, which may be part of the thread
breaking problem.
Arnt, you do know that 'you' in the English language doesn't necessarily refer
to you personally, but that it doubles as an unspecified 'one'?
If I
Straw man ?!?!?
http://en.wikipedia.org/wiki/Straw_man [See :: structure point 2.5] and
you will understand that simplifying my point of view trying to
invalidate it is ... a straw man technique.
Are you so sure that it is not what you have done concluding rushy that
I do not had read the
- Assumes that we want to set the limits by equipment (radar) rather
than visuals, although we've just said we don't want to do this because
of memory issues, and I've listed several points besides radar why I'd
like to do it.
On re-reading, this sounds pretty hilarious...
What I mean
I was not referring to a frame rate issue, but FG running out of memory.
http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p177392
It is rare to see that happening using the current scenery, but here if I
select random buildings and objects with a high value for trees, I can
Why should those users be forced to give up on those goodies just
because one
part of the rendering scheme doesn't want to play by the rules? Even
more so when there's no indication that happens...
The default max visibility value is a pretty sane default, and simply
increasing that to
I was talking about the 16km value (sorry for not being more clear about
that) and see below for the huge value.
Let me get this straight. You state that the 16 km are a pretty sane value. The
proposal being discussed is to load terrain to 20 km no matter what the
visibility is. Vivian has
Another option would be to move the visibility control to a dialog, with
a slider / spin box, and explicitly disable it when advanced weather is
selection. Then we could lose the keybinding completely, which is
something I want to move towards for options that are infrequently used,
..a pointer to your previous message would help here, this thread
is broken (in at least my MUA) and getting hard to follow.
Maybe we just have some cultural misunderstandings?
The way I see it - if you want to make a statement in a discussion, you have to
read what has been said before. No
Vivian wrote a while ago:
I've only tested Atmospheric Light Scattering for about 10 mins - and so
far I've discovered that the Cat III scenario looks decidedly odd with a
clear circle around my aircraft on the ground and black skies.
I've taken a few hours to look into low visibility
Vivian:
There seem to be significant issues with the loading of terrain. If we
load too much, the frame rate drops, if we load too little it looks poor, and
AG radar doesn't work. Actually. We don't load enough for AG radar to work
realistically in any case. We probably need something
Hey guys, I have been trying to work on some textures for NZ, but I
cannot
find the land-class via cntrl.alt.click.
I have tried multiple aircraft, can anyone help?
It's an ufo feature...
* Thorsten
--
Everyone
I'm not sure this is necessary. I think an opt-in checkbox would
suffice. After all FlightGear has been around for personal experiments
for a very long time. So why not this option.
I don't mind leaving it - the rational for deleting it is that the texture
sheets take up space and download
Did you test your airfield grass with some of the newer generated terrain
(LOWI in my case)?
No, I didn't. Shouldn't make a difference for rendering purposes how you
created it, at this stage it's all vertices and pixels and the shaders don't
care where they come from or how they connect.
It seems we have some cases where the ufo trick ctrl-alt-click does not report
the correct landclass - I would assume that the underlying call is geodinfo()
going wrong.
http://www.flightgear.org/forums/viewtopic.php?f=5t=19113
The theme seems to be that if I have two different materials
Okay, after sleeping over this and going over all the feedback on this list:
My original idea was that the whole concept of a continuous season model in
combination with a user-customizable environment by pixel processing is a big
thing - I doubt many other simulators have something like this
In general, giving users choice is bad. What developers should do, is
figure out what the user *wanted*, and then do it. Excessive choices /
options / preferences are a failure to be sufficiently smart, about what
the user actually wants.
I disagree with this on a very general basis.
Just what is it you want to customize?
Consider a simple 'snow in the mountains'. You can have
* early snow up north, the leaves have just started turning and the snow is on
slightly yellowish trees up the slopes, no snow on green trees down
* one day later - a bit of snow is still on the
What I expected was that having selected Regional scenery, then the
slider would give me reasonable results for my region. Perhaps that's simply
too
difficult, or the region is defined too widely. I also see that the
regional scenery for the area is wrong as well, but I'm working on
..the obvious way to control all this, is use e.g. FG time
and METAR history to set up a credible scenery appearance.
Right, so we somehow get the METARs for the last month for a location, have the
environment model run the consequences and use that. Sounds not so easy to me.
But... I never
OK, now I understand. Here's a screenshot:
https://dl.dropbox.com/u/57645542/fgfs-screen-099.png
It's not good for UK - but I guess we can fix that eventually.
Do you have any reference material how autumn/winter colors in the UK should
look like?
..desert? Severe drought?
-20
..maybe in the old days, nowadays, some grass is green, most
of it, say 4/5 is a pale dull yellow when the snow comes.
Climate change, grass grows about 3 months longer now, than
in the 1960-ies when grass was cut once, nowadays farmers get
3 harvests.
The whole discussion brings again a
I think I must have something wrong here: much of the textures which were
green turn a horrid brown colour, it looks like nothing I have ever seen
on the ground in the UK. Is that what is intended?
That'd depend on the slider position and the landclass I guess - no way to tell
without a
I've just pushed the current state of the autumn color model where the amount
of coloring is encoded in the texture alpha channel. I've tried to be very
conservative and pushed alternative textures (marked with *-autumn.png) where
this is done - I could not see any negative effects in the
Something along these lines:
$ git branch my-2.10.0 origin/release/2.10.0
$ git checkout my-2.10.0
Find the commit ids of the bug fix commits on the master branch
$ git log master
Cherry pick these to your local release branch
$ git cherry-pick id
Okay, as usualy this is not so
If you want all of them you should be able to cherry-pick the commits _in
order_ or, alternatively, you could just checkout the final state of the
files from master as you suggested above.
I can't cherry-pick them no matter what order I try. Basically I want
commit
Could anyone perhaps instruct me how to push onto the release branch? I have
committed a couple of shader bugfixes to the master branch which should go to
release as well, but I don't have a local release branch by default, so I'm
unsure what to do. Or is the idea that only a subset of
I've received two bugreports in the forum for which I would like to ask some
advice here:
1) The ultra terrain shader makes runway designation signs go away:
http://www.flightgear.org/forums/viewtopic.php?f=47t=18999
It would appear that all the sign boards in airports are driven to grey
Should we think about some kind of tool to find flightgear lint like
this? What would the tool have to do?
Renk, What steps did
you take to find candidates for deletion and to verify the
weather is not used?
Well, I introduced these textures and models in the first place, I also have a
Cannot reproduce here on today's GIT.
Given the intermitent nature of it, I have a possible culprit (but
you're not
going to like it):
-try with the texture fetches outside of the conditionals, see if you
(or the reporter) can still reproduce it.
I think I told you a while ago that I
I think the foam texture is still read in a conditional, based on
distance.
(water-lightfield.frag/water-lightfield_lr.frag lines 422-434)
You got me there :-) But it turned out not to be the problem... the problem was
that
if (condition) {do_stuff();}
(...)
if (condition)
If so, we should definitely remove the experimental label from the
rendering dialog, and possibly change this to the default renderer and
have a discussion about whether to retire the previous scheme.
I've only tested Atmospheric Light Scattering for about 10 mins - and so
far I've
Here's a list of objects which I have tested to be safe to remove from
/Models/Weather/ - all in all ~19MB. If no one else has objections, as far as
I'm concerned they can go.
* Thorsten
altocumulus_textures.dds
altocumulus_textures.rgb
cumulonimbus1.ac
cumulonimbus1.xml
cumulonimbus2.ac
4. Models/Weather - 76 MB - As asked are BOTH duplicate
dds and rgb files needed, or could a release work with only
one or the other?
5. And now I find in both Textures and Textures.high
the same duplication of dds and png files. Again
are BOTH really required for a release?
6. Are there
Are the Winter textures still needed?
In a sense they were never really needed... for instance I have never used them.
Just to summarize the options we have to generate snow:
1) Winter textures
They are base texture sheets with snow painted on, which means they have a
fixed snowcover and no
I'm not sure if I'm doing something wrong here: we now have so many
different options, but getting snow by method 2 or 3 results in deciduous
trees in full leaf with snow coverage on the ground. Not an impossible
scenario, but bare trees are more likely. Is this a bug?
It's actually... pretty
I've just pushed the first version of the model shader for Atmospheric Light
Scattering. It should do random buildings with reflections and all aircraft
using the model-combined.eff without normal mapping. The shader still has some
quirks, but they're hard to spot if you don't look for them ;-)
Following a forum bug report
http://www.flightgear.org/forums/viewtopic.php?f=68t=18924
I had a look at random buildings in Atmosperhic Light Scattering (which I
normally don't use).
I just pushed a fix
* ensuring that the Mie angle gets correctly to the fragment shader
* and simplifying the
It does run on my Win 7 laptop with nvidia graphics hardware (and nvidia
graphics drivers installed.) I will get it uploading ... 740Mb! So much
for the CD distribution. :-) Didn't Bill Gates famously say 640Mb should
be enough for anyone?
Um... which reminds me - I had on my old computer
Dear Mathias,
But what I saw lately - especially from this finish guy - is noting close
there.
I continue to have a name (which is Thorsten), that name doesn't actually sound
very Finnish, and that would be because I am actually German (I do live in
Finland). There's no need to pretend you
No, I think what he meant is that (without me ever even seeing shader
code)
something like:
if (enable_light_scattering) {
a = b + c;
}
compromises performance, even if light_scattering is disabled because the
compiler would assign registers to this code (the a = b + c), even
Ah, now I understand what Mathias is after:
That would be ok if this would be optional in the sense that it does not
impact what is there performance wise. But since this is all runtime
configured
by an uebershader with a lot of uniforms this is not the case. Any
additional
feature
After some discussion / observation, I am going to change the default
shader level for 2.10 (and probably next) to '1' instead of '3'
(...)
Comments / objections?
Complete agreement, after looking at the Intel and Mac problems in the forum, I
was about to suggest the same thing.
* Thorsten
You may be right that I did not pick the exactly right person for every
line of code.
But I also did not get the completely wrong one as you never cared for
the state of the art even if being pointed to.
Quoting myself:
You did no such thing, Mathias. You gave a completely
I've managed to adapt the model ubershader for Atmospheric Light Scattering in
the last few days. The results look pretty nice (performance consumption is
probably not so nice though):
http://users.jyu.fi/~trenk/pics/IAR80-sunrise.jpg
So now we can have atmospheric light scattering skydome,
I see applications that care for stable 60 hz. If you get for one frame
59 hz they have too much jitter and look for an other renderer.
What I really do not like is that people purely push in the direction
they just like more.
Beats me when this has ever been a problem. My first
I'd like to ask for a few opinions.
The problem: Vertex shader coordinates are continuous only within a terrain
tile, so the noise distributions we use show discontinuities across terrain
tiles - seen most prominently in snow or fog patches.
The solution: Emilian and Fred have figured out a
Yes. Any uniform needs to be handled by the driver. And any of them
takes cpu
cycles to load. I think having lots of them is one factor that accounts
for
the long draw times I see here. Looking at profiles the function
collecting
them and putting it into a buffer for use in the gpu is
Well, if you ask in that way, then the question is:
Do we need 10 different flavours of rock?
If we want to look a scene roughly as it would in the location, the answer is
yes - volcanic rock on Hawaii looks very different from Alpine rock in France.
Rock in Iran looks very different again.
I've recently come across the idea of using one generic sand or rock texture
and selecting the particular hue desired by multiplying every pixel value with
an (rgb) vector - so rather than two different-colored sands, we'd just store
one texture and three numbers on disk (and potentially in
For example here on an nvidia 8800GT with 313.09 linux driver I have:
MAX_VERTEX_UNIFORM_COMPONENTS 4096
MAX_FRAGMENT_UNIFORM_COMPONENTS 2048
Nevertheless, that would make 50 seem a rather harmless number. Especially when
I'm going to assume that no one with a much older card will be able to
BTW: I've been discussing with the terragear guys something similar,
with a
texture encoding material info accompanying the btg, and being generated
at scenery build time.
This texture would use a secondary set of texture coordinates, relative
to in-tile position, and would be read in
I was wondering if anyone has experience with the stereoscopic view modes of
FG. Coming with my new laptop were very fancy NVidia IR synchronized LCD
shutter glasses for 3D vision, and I've used them to have a look at some 3D
movie clips, which was sort of impressive. Unfortunately, they
By the way, do you know this book ?
http://books.google.fr/books/about/Texturing_and_Modeling.html?id=bDlSJd8GfMcCredir_esc=y
No, I don't. I have never read much about scenery texturing. (I mostly make it
up as I go - my greatest wish would anyway be an artist and a decent database
to
Agreed, this stuff is all about plausible heuristics, but I think this
one fails the 'plausible in enough areas' test. Hopefully we'll (soon)
be able to suggest land cover updates to fix any areas with these kind
of data issues, once the world scenery rebuild completes.
Somewhat
Hi Stuart,
That sounds like an excellent plan. Let me know how I can help.
yes, I could definitely need a hand... Now since the holiday period is over, my
coding time just decreased dramatically... So, if you like, I could give you
what I have in terms of autumn colors and hires terrain
Geometry shader can also process adjacency information if provided by the
CPU through special primitives (GL_TRIANGLES_ADJACENCY and
GL_TRIANGLE_STRIP_ADJACENCY)
Oh, right - a geometry shader can probably receive a triangle as input, compute
its center of gravity, shift all vertices outward
We have to accept some inconsistencies if we want even vaguely tolerable
performance, and pretty much everything you said convinces me we should
switch to the 'b' approach, or family of them (see below), as the
default option after 2.10, to get as much test and feedback as possible
The landmass shader looks like you fixed something :)
Great to hear - so presumably it was the things Emilian identified (?!)- I
haven't fixed anything else.
Flickering is gone in all settings and i have only some small artifacts
visible in the distance while having snow cover and fog.
What's the a / b performance impact?
All to be taken with some caution, since it seems to be very hardware dependent
how expensive certain options are. For my new GTX 670M, I can't measure
performance without external tools because any terrain is always rendered with
vsync of 60 fps, and only
Stuart, one thing that caught me out earlier today with using 2D cloud
layers - while using a 2D layer and modifying visibility inside the
layer is working quite well, the edge (moving vertically) is very sharp.
I wonder if there's some technique to perturb the top and bottom of the
Perhaps we could use something similar for the trees? I.e. pass in a
uniform indicating which fraction of the texture sheet on the x-axis
should be color-rotated. The uniform can be taken from a property on
the material definition.
Ah, that's clever - I think that would do just fine.
It has emerged from forum discussions that gathering the goals for developers
so that people can synchronize efforts better and users know what to expect
would be a good idea. I've sort of been trying to do that previously, so I
might as well continue, even if it's a bit early and 2.10 isn't
There are many issues and tradeoffs with mesh simplification. There are
many algorithms and approaches, each with their own unique strengths and
weaknesses. Challenges include finding a strategy to hide the cracks
between adjacent tiles draw with different levels of details (and
possibly
Well, we did have
alpha-test
comparisongreater/comparison
reference type=float0.01/reference
/alpha-test
everywhere in the cloud effect files. So it's not clear to me how transparent
fragments should even make it to the shader (?). Maybe I'm still confused about
Apparently that's ok now, another issue cropped up in the
urban-lightfield
shader, something wrong with an #if:
FRAGMENT glCompileShader
/home/chris/FlightGear/Shaders/urban-lightfield.frag
FAILED
FRAGMENT Shader /home/chris/FlightGear/Shaders/urban-lightfield.frag
infolog:
Those are fixed, but you still have some implicit casts/coversions in
there,
those are tolerated by the nvidia compiler but not by other drivers:
http://dpaste.com/845842/
Aw, a forgotten decimal point - that's picky. Okay, how about now?
* Thorsten
- no errors on the console
- latest drivers for the ati card (tested with all ati drivers from 2012
for win7 64bit)
- the artifacts show up if the landmass shader is over 3 (counting from
left / starting with 0)
- the artefacts show up if the transition shader is over 1 / at 2 only
the
Forum:
by zakalawe on Wed Dec 12, 2012 4:46 pm
I've pushed a fix (to SG) for the sound issue. Better to report such issues
via the developer list in the future, I don't check topics here.
Jenkins FlightGear-Win64-CMake build history:
#220 (pending - All nodes of label 'x64' are offline
In some cases, the used algorithm is plain wrong as we
know by definition (ICAO rules) the propagation of the radio signal.
Um... I would like to understand this statement. The algorithm has a physics
model in. I am no expert in radio propagation, but after doing a bit of
reading, by usual FG
If anyone likes flying in Iceland - the current state of Iceland regional
texturing is now on GIT with the region-specific materials file - use with
Atmospheric Light Scattering, Transition Effects to max. for best effect -
otherwise the endless lava fields and glaciers have very strong
With an ati 5870 on win7 64bit the transition effect is not working as
expected.
I get what is best described as fast flickering artifacts... but have a
look at the screen shoots yourself.
I corrected it some minutes ago and hope everything is fine
again.
Huh, that was fast, thanks. Airport green is looking good here.
* Thorsten
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
My suggestion is to include this feature, leave it off, and let anyone
interested turn it on.
+1
There may be many reasons to reject code, but they roughly fall into two
categories: 1) the idea itself which is coded is not acceptable or 2) the
actual implementation is not acceptable
During the last weeks, someone added the 'Grass' landclass to the 'grass_raw'
materials declaration and the 'Dirt' landclass to the 'dirt_rwy' declaration
in/ Materials/regions/materials.xml.
I would like to undo the changes, or discuss other solutions to fix the
problems caused by them - my
Please let me be very clear about a few things.
This is not about lack of praise or thanks - I'm doing weather and light mainly
because I like doing it, because I like to see if I can capture the essence of
a scene I see in real life in shader code. I am passionate and excited about
that,
I've created a merge request
https://www.gitorious.org/fg/fgdata/merge_requests/183
containing lots of my recent shader work(...)
Um... what should I do with this? I've gotten one comment pointing to a problem
with the urban shader, but I can reproduce the same problem on a pristine
master
That was caused by your previous merge request, which was resolved
without
proper testing I guess.
There's a bugreport about that
http://code.google.com/p/flightgear-bugs/issues/detail?id=836
Which was marked as fixed, but obviously it isn't.
Thanks for letting me know. Commenting out
Personally I find a collection of independent requests much easier to
deal with than one 'all my recent work' submission. Eg I'm interested in
your work to early-Z-fill the trees, but the rest of the request, I'm
not 'qualified' to make any judgement about.
Difficult to do in this case
Me asking a genuine question:
Why do I need to make a song and dance to get the last stable under
Linux when it works no fuss under Windows? Are we genuinely unable to
provide a working generic 32 and a 64bit set of binaryies for Linux? I
know that lib paths and versions are different
No it doesn't. There's nothing preventing us from providing packages for
older
distribution versions.
This sounds very neat, and if this works in practice, then I take my comment
back - being able to get an rpm for any major Linux distribution would be
equivalent to the Windows installer
I have no idea
though about Nasal terrain sampling performance.
Pretty good these days - whenever a convective weather system is set up, we use
about O(1000-2000) terrain elevation sampling points to generate the
cloud-terrain interaction, they're done at a rate of 20 per frame. On my old
So, I finally broke down over the weekend, getting so frustrated with a the GPU
not powering up under Linux that I installed FG on Windows.
If I want to get FG last stable under Fedora 17, I have to compile it myself,
only 2.6 is on the repo. The process is probably similar to compiling
So, some of my impressions of how FG runs on the GeForce 670M (Windows).
* in default terrain (I did Nevada, going with the F-16 from KNID to KLSV), all
procedural effects in atmospheric light scattering on, some snow on the Sierra
Nevada, 120 km max. visibility range, some Cirrus cloud
* strange bug - all generated clouds (on Linux and Wndows) used only one
texture of a multi-texture sheet, which gives some odd repetitions. This
may be something trivial (my binary and FGData snapshots are a few days
apart) so if there's been work on clouds in the mean time it could
Binary releases on Linux are /possible/ but a pain - working with each
distro's packaging system is definitely the way to go, in my opinion.
That basically seems to require that everyone who wants most recent FG needs to
update to most recent Linux. Which is something which according to my
I'm not sure if the settings suggested there still work with current
drivers, but it's a start.
Nope - the available options for the newer driver are quite different. Also,
the problem is not that the PowerMizer defaults to adaptive - it doesn't, I can
change its setting. It just never
I'm just trying to get a working devel environment on my new machine, and I've
succeeded in compiling simgear, but flightgear refuses the cmake configuration.
Basically I want to have the simgear libs inside a user directory and not
system-wide. So what I did is cloning the repositories,
If you *have* set SIMGEAR_DIR or other settings, I'd recommend erasing your
build
directory and running cmake from clean - it 'remembers' previous values in
the build dir's cache.
Ah, that's how it's supposed to be... I've now hacked my way through by adding
the path explicitly to
I guess I need some help here... I've finally managed to compile FG on the new
computer, then copy my FGData here, and... it works. But the framerate is
abysmally bad.
It doesn't seem to be Flightgear though... When I open the NVIDIA X Server
Settings while FG is running, I can see the
Stuart wrote:
Personally I'd really like to see the rendering systems unified, even
though I don't have enough GPU to run them both together (or indeed
Rembrandt with shadows). It's just make for a more consistent
experience. (...)
I had a look at this a couple of weeks ago but
didn't
I've created a merge request
https://www.gitorious.org/fg/fgdata/merge_requests/183
containing lots of my recent shader work, including
* ambient and cloud shadow correction to blue-grey hue
* more pre-dawn illumination
* procedural snow
* a hires grass texture overlay effect for airport grass
I've pushed a change to the effect files that makes sure that shaders are
disabled when /sim/rendering/shaders/quality-level is 0 or non existant.
Previously this relied on gui.nas to set the individual shader levels to
0, and fgviewer had no easy way to disable them.
I don't know how you
How should we call our new baby? Is it 3.0.0 or is it 2.10.0? This is a
carry-over from our last release and gets answered along with: Is
Rembrandt production ready?
Hm, I had a list of items for a 3.0 half a year ago, so some progress chack
along these lines:
* Scanery-related
'Publish 3.0
Hmm . that's an underwhelming list, and I can't come up with anything
that's
really any better. Does that encapsulate the problem?
Well well, it would seem our shader-based treatment of light and the
environment is quite competitive against what FSX has to offer:
I don't know if anyone is interested in what precisely I've been up to of late,
but I do know that I get frequently asked why the reflection (bump, you name
it) effect isn't yet working in atmospheric light scattering, so this is sort
of an answer to that. Well, I also sort of wanted to write
101 - 200 of 401 matches
Mail list logo