Done. Could do with some more refinement, but it works. If you input
speed-kt, then position updates are ignored and positions are calculated
from input speed and pitch. Here are the patches:
http://dl.dropbox.com/u/57645542/0001-SG%20Make-Models-move-with-heading-and
-speed.patch
But ... there is no visible structure in textures folder yet for regional
textures, is it ? Want a zurich_kreis_6_neighbourhood_grass.png as a
30mb .dds for my next merge request ? ;-)
I think that's because we don't know yet how a reasonable structure should look
like. What I'm discovering
Okay, given yesterday's discussion, I don't know if there is still need to
discuss further or not or if this should be merged or not, but I'm putting this
up now as I'll be travelling next week and won't have any decent internet
connection to rebase my local branch properly, so anyone can have
Sorry for my impatience, but I think before one start to have tousands of
custom scenery textures in fgdata we should discuss if such limited
custom scenery changes makes sense to be in the (already heavy) fgdata
repository.
Okay, what would your answer to the following question be:
'We
Using the default random building density, the tiles that are loaded
initially when sitting on the runway generates ~ 340k random
buildings.
We might be generating too many buildings then?
The greater Los Angeles area has between 13 and 16 million inhabitants
(dependent on what you count).
Besides being totally off topic, you can't do that direct comparison.
First off, our default scenery lacks a lot of detail in the urban area
boundaries in
that area thus marking a far larger area as being urban - a far larger
area on which to generate buildings
That'd makes my point
No, I think you're extrapolating from a particularly bad case of mismatch
between reality and simulation. I wasn't talking about regionalized
building
placement, I was talking about bad landclass representation in that
particular
area, representation from which come the figures you used
I have tested using only the test tile so far. The time spent in events
is dramatically reduced to around 70ms vice 210ms. There remains some odd
cyclical frames coming in, but the results are broadly in line with Basic
Weather.
Okay, that's good news. I'll continue working along these
Not that we're there yet
Heiko and Vivian, please try the following version and let me know if this
improves anything. If possible, do all tests with the weather tile type 'Test'
(that has no randomness in the cloud configuration selection, so it delivers a
fairly reproducable situation in
(Even if this works fine, please do not commit yet, I am not 100% sure
that I didn't create an instability somewhere).
Turns out I broke at least the visibility interpolation - to restore it,
uncomment line 726 in Nasal/local_weather/local_weather.nas
if (vis 0.0)
88 declared but unused variables
47 declarations of the same or similar variables
427 instances of else if instead of elsif
100 instances of I = I + 1 instead of i+=1
Numerous examples of variables declared inside for loops, and some of those
are inside other for loops
Variables declared
just a quick note to this interesting thread ...
its elsif in nasal , not elseif ... no e
Thanks. That would explain it ;-)
I hope you're not suggesting that C++ is always slower than Nasal? :-)
Pascal summarized it nicely - we already have ported the important stuff to
C++, so what remains
With your scientific background you should know better than
cherry-picking that statistic. Those on the forum are a self-selected
minority of our users.
(...)
No I'm most definitely not. What I'm saying is that by optimising for a
subset of users, you run the risk of sub-optimising for the
After sleeping it over...
Now set
all Advanced Weather settime() to 0.0 and retest with METAR. Wow!!!
Improvement, not as good as Basic Weather , but much better. Worst fps is
stable at 24, av. is still unstable.
You had a worst of 27 in your list
The facts are:
-it isn't that much important if you have 20fps or 60fps. But it is more
important that the framerates are stable !!!
It is for Vivian. We seem to agree that a stable 20 fps is possible (I get it
and Vivian gets it if he throttles down), but he aims at more. Which is okay
Conclusion: don't try to optimise, particularly for a poor system - you
might make it better for that system, but more likely you will make it
worse for everyone else.
Judging by framerate comparisons with people in the forum, my system is still
somewhere in the upper third - many people
Yes. You have produced a very nice piece of work which gives variable
results in different systems. We need to at least understand the cause
and try to fix it
GC according to what I can test.
Pity you didn't use standard scenery. I don't think custom scenery and
the ufo will produce
Concorde has of the order of 6000 lines of active code, and yes, it
displays exactly the same discontinuities as Advanced Weather (approx. 10,000
lines of code). So far, I have not found any other examples.
Just to idly continue my list - the A380 has in excess of 8000 lines of Nasal,
Quick question to Stuart:
Currently the conditionals for texture selection are done using
/position/longitude-deg,... i.e. aircraft position. The actual tile position
however is different from that by the visibility and an direction, which makes
for some uncertainty.
So, it'd be more
I did a bit of testing of my own yesterday, and I have made a few other
observations as well.
User feedback:
I've largely come to ignore that (with few exceptions such as Vivian's
performance table), because trying to make sense of it is a path into madness.
Just a few examples: On my own
Is it just me or has the model-combined shader stopped reflecting ?
Moving the model slider seems to have no effect now .
Skydome shader on by any chance? (That would probably de-activate it).
* Thorsten
--
Live
Tested extensively today, and the short answer is no. There is some
improvement as the flags are successively set to 0, but Advanced Weather
never becomes as smooth as Basic Weather (and that's not without
staggers of
its own).
(...)
I suppose the bottom line is that this just might
It is the largest expanse of intertidal mudflats and sand in the United
Kingdom! Neither of these locations could be remotely described as deep
ocean, and yes, we should certainly be investigating how to best model
such areas of sea.
Okay, if you're specifically after deep ocean (i.e.
Does the problem go away if you set local-weather/dynamics-loop-flag=1
from the property browser *after* Advanced Weather is started?
Does the problem go away if you set local-weather/timing-loop-flag=1
from the property browser *after* Advanced Weather is started?
Does the problem go
Hmm I've got something wrong here then - if I understand that right I
select
Advanced Weather, and skydome and the sea colour stuff should run? I get
this:
http://dl.dropbox.com/u/57645542/fgfs-screen-190.png
It doesn't seem to have any interpolation.
The color seems about right to me
There are good sources for sea colour out there - here is one:
http://oceancolor.gsfc.nasa.gov/FEATURE/IMAGES/A2008129125500.Scotland.png
The Northern North Sea, away from the turbidity and major river outfalls
of the Southern North Sea, is indistinguishable from the Atlantic, the other
This scheme introduces yet another for loop in Nasal, of undetermined
size. This potentially introduces yet another source of stagger to FG, or it
would if it worked, but as far as I can see it never runs here. Is it meant?
Well, anticipating your reaction, yes, at this point it's meant
In a fresh pull of everything as of this morning, I lost the ability to
re-locate by choosing an airport from the list. Trying to do so results in
command 'presets-commit' failed with exception
message:invalid leg index (from FlightPlan::setCurrentIndex)
written to the console and the
For the purpose of making the tests more comparable, would not it be
better to use a standard setting/script/options which would set FG to
some defined state?
In this case clearly no. I'm interested in the relative change matrix of
framerates for two features being on or off, not in the
At the moment it seems to me that FG requirements are increasing faster
than the performance of affordable computers.
I can't confirm that. The 'bare' current binary (= all shaders off) runs even a
bit faster for me than previous releases.
I think one clearly needs to distinguish between
Since the random buildings are now in the effect system, I've run a few tests
with the lightfield shaders yesterday.
The good news is: It works just fine.
The bad news is: It eats performance like mad.
For comparison: Without lightfield shading, I had a test case involving a large
urban area
The runway effect parameters override any parameters it has in common
with the terrain-default effect (since it inherits from it), it is not a bug,
that's how the system is supposed to work.
I don't know, it doesn't strike me as consistent.
There are two control structures here:
No, you got the system wrong.
When an effect inherits from another it rewrites those parts that are
common
between the two xml files, keeping the parts that are different.
Yes, but what's wrong with making that conditional based on technique number?
What functionality would this destroy?
So far we had: start with skydome shader on and landmass set to 4:
- models appear black and are not shaded properly
Click on landmass slider without changing the value:
- modelss jump to proper shading
I've made one more observation: Do the above at noon. Then change to dawn
- models remain
Using tied properties as uniforms?
I don't think so, because the same parameters do get updated per frame just
fine when shading the terrain.
* Thorsten
--
Live Security Virtual Conference
Exclusive live event will
Hmm, that would be really strange, and a legitimate bug then.
Worth a try with the property filter to see if that fixes them.
That's actually how terminator-relative-position-m (the sun position for shader
purposes) is done - see
Environment/local-weather-rules.xml
* Thorsten
Sorry, was looking at the wrong shader. You don't assign the terminator
to an
uniform in the technique n=5 in the model-default.eff.
I'll be buggered... you're right. How embarrassing...
* Thorsten
--
Live Security
Hi Heiko,
Okay, so cloud and terrain shaders on both detail levels perform okay, but the
skydome shader doesn't come on - one can see the mismatch between terrain and
sky in the distance, and there's no scattering effect at all in the sky. Which
means we need to find the reason why, and
I would like to ask a few opinions on the following points:
I've been experimenting with regional textures after Stuart's re-organization
of materials.xml, and I have a few nice adaptions which I would like to suggest.
For instance, one can use 18th_century_city.png to texture cities in
I did try that- after some more tryings with different settings I found
out that I didn't know yet that it only works with advanced weather AND
at high altitudes (above 10.000ft!!)
Agreeing somewhat with Fred, the screenshots don't make it easy to see what is
going on, as there is neither
I've just checked in a change so the buildings now use the Effects
system properly, which includes a global cache of the textures. This
might help.
Nice - have to try this.
Btw - could you take a look at the ambient value of the material declaration? I
have the feeling it is very low, I'm
I tested last night with win7 and xp using ATI cards (winXP - hd3850,
win7
64bit hd5870 tested with all ATI drivers since 11.4 beside the latest)
and
the skydome shader is crashing fgfs. The crash looks like the crash that
occours if i enable the generic shader. No console output.
Well,
From memory, I've set it to 0.3. It is configurable in the
data/Effects/buidling.eff file under parameters/material/ambient if
you want to have a look yourself. I'm happy to accept a change to the
value - I haven't spent any time tuning it.
Okay, that explains it.
I think it should be in
The direct link to the merge request is usually handy.
Will do next time.
Effects/terrain-default.eff has two techniques number 4. They seem
similar
Could you check ?
Aarg... GIT strikes again. The two blocks with technique 4 are identical copies
- one of them can go. Must be my screwup
It also seems that some model are not lighted anymore :
http://frbouvi.free.fr/flightsim/fgfs-haze-1.3.gif
The only place models get the effect is if they go via
Effects/model-default.eff if they're using their own effect file they are not
in the scheme.
In addition, neither the random
That problem goes away if landmass shader is disabled. The strange thing
is that when set to some value, the problem appears but as soon as you
click on the landmass slider, without changing the value, the problem
goes away too.
Is this anything I could have caused? Because I have no idea
I have no idea too. It looks like an uninitialized value that get one
when we click on the slider. Do you reproduce the problem I see ?
For some (yet to be determined) reason the shader settings are not archived on
Flightgear exit in my local devel branch since my next-to-last update three
Do you reproduce the problem I see ?
Okay, found the problem with userarchive and eliminated it Now I see the
same thing you describe, the model shader doesn't start up correctly, but all
goes well once one just clicks the slider. The model shader doesn't seem to be
doing anything at all,
This doesn't happen when you click on another slider or when we start
at 1. Should be something specific to landmass.
Tenuous, but:
Terrain and models are sent to the same shader code (terrain-haze.*) by the
effect file technique 5. To switch the detailed terrain rendering on, I used
the
So, maybe we could find a better method of switching between the weather
systems - though this isn't the main issue here. Using radio buttons or
a drop-down list would be a more standard way to toggle between
alternatives. Otherwise, just updating (and maybe moving) the button
descriptions
I've just created a merge request containing the recent work I've done for the
haze shaders (haze in water shader, dust effect, Mie scattering on clouds, ...).
The procedure described in the wiki to create a merge request did not work for
me, I could not push a local branch containing my
What about the mentioned problems? Better? Worse?
A quick 3 minute test flight with the ufo looks very promising - I didn't see
any obvious issues with the version pulled 10 minutes ago. I will do longer
tests later toady.
* Thorsten
Hm... I'm getting good performance, but the rendering of the random buildings
do not seem to go via model-default.eff - they respond to the normal
visibility, but not to the terrain haze layer, so they remain visible when I
turn on heavy ground fog. Is there a conceptual problem, or can this be
Hooray alerted me to that one, and I would like to ask a few opinions on what
to do and offer my own thoughts.
*What steps will reproduce the problem?*
1.F10-Environment-Weather-Advanced Weather
2.Select METAR
3.Return to Basic weather
*What is the expected output? What do you see
I've just pulled and compiled simgear and flightgear and pulled a fresh FGData
to start package the next lightfield shader version, but it turns out the
resulting binary is unstable.
I get segfaults about 10 seconds after startup with the master branch, no other
errors written to the console,
I had similar problem this weekend, and a full rebuild (simgear +
flightgear) solved the issue. I have the sentiment that changes
to SGReferenced (in simgear) could have created this instability
I pulled everything fresh and compiled both simgear and flightgear new, so
things shouldn't be out
Can you get a backtrace?
Okay, following your instructions I did make clean in any of my build folders,
ran cmake with -DCMAKE_BUILD_TYPE=Debug added, recompiled simgear and
flightgear, and did
gdb ./fgfs
run --log-level=info --airport=KSFO --disable-real-weather-fetch
--disable-fullscreen
Oops, missed that part of the instructions *blush*
Here's the output:
(gdb) bt
#0 0x5e3d9a08 in ?? ()
#1 0x088dd542 in hashForAirport (c=0x13bedd28, apt=0xdcd3988)
at /home/fgfs/CMake/flightgear/src/Scripting/NasalPositioned.cxx:113
#2 0x088ddc29 in f_airportinfo (c=0x13bedd28, me=
Okay, this is my fault, but I don't know why / how it's crashing for
you. Presumably you have some aircraft or nasal that makes additional
airportinfo() calls, and you've managed to find a test-case that my
testing has not encountered. Unfortunately we need to find out the
relevant
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
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
And a more simple second question, what do the developers accept as
proper performance (value) in regards of frames per second. Perhaps i
demand/expect too much, but 20 - 30 fps i find rather disappointing,
flight is far from smooth at such numbers, but others might find that
(more
What do people think about dynamically scaling the eye candy to meet a
target framerate?
Define 'the eye candy' and you'll spot the problem.
In general, the performance-driving factors are (not an exhaustive list)
1) visibility range, i.e. number of terrain vertices in the scene
2) cloud
Before and after screenshots:
Before - http://www.nanjika.co.uk/flightgear/buildings-old.jpg
After - http://www.nanjika.co.uk/flightgear/buildings.jpg
Wow, this looks pretty good! Why are there buildings on the street though -
isn't that a different landclass?
Does this have to an US-style
However, one of the issues I'm hitting right now is that I have to
avoid overlapping
buildings by binning buildings that are too close to other buildings.
As density
increases you get more overlapping, and spend more time binning
points, so scenery loading starts taking longer.
Create a
What *is* the baseline hardware fg ought to be aiming at?
I guess in practice every developer works such that stuff runs well on his own
system. What else can we do? I'm not buying a second computer just to test how
it would run on a Mac.
Advances in quality always requires more resources.
I've implemented the snow shader effect into lightfield rendering yesterday -
this looks quite promising already:
http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=165#p155463
but I have a few questions I've come across?
I've tried to use /environment/snow-level-m to control the
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
I have the same bug when the skydome scattering shader is enable.
Are you sure you have disable skydome scattering shader ?
Look, I literally wrote the part of the effect file that controls what shaders
run when the skydome shader is enabled and what shaders don't, I did a fair
share of the
I've made a case study converting the high quality water shader (my favourite
shader effect :-) ) to lightfield rendering in the last two days (see some pics
in the forum here
http://www.flightgear.org/forums/viewtopic.php?f=47t=14755start=150#p155110
sunrises with water reflection look
(*)No it's not bad design, it's a conscious hack around the state that
the environment interface was in when the shader was developed.
Something like a property rule or a Nasal script outside the shader would have
done the trick as well... But I'm not arguing why it's done the way it is, and
Emilian proposes the weather system to be agnostic about the shaders,
not the shaders to be agnostic about weather.
Advanced Weather works based on abstraction layers. The high levels are unaware
of any technical issues ('we have a tile with 6/8 Nimbostratus coverage and
light rain'), as the
To be safe you need to limit yourself to 32 float varyings.
Note: a vec3 counts as 3 float varyings, a vec4 as 4 etc.
Okay thanks, then I am safe. Btw (spotted this while checking) - is there any
particular reason to compute a normal from gl_Normal in the vertex shader, use
a full varying
Apart that the earth is a sphere and ocean tiles are large pieces
of terrain where the curvature is quite apparent, how whould you
define flat ?
'flat' = 'For any visibility we can actually render, the normal (before wave
noise) is (0,0,1) in model space to such a good approximation that you
'flat' = 'For any visibility we can actually render, the normal (before
wave
noise) is (0,0,1) in model space to such a good approximation that you
won't spot the difference to the actual normal including earth
curvature if
I show you a picture.'
Cheers,
* Thorsten
That will give
If it looks right in one limited test case, doesn't mean it's right, or
the proper way to deal with it (so it won't backfire later on)
Look, basic ray optics says that the error in ray propagation I make by
neglecting the curvature is linear proportional to the error in normal angle
which I
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
I think that is what we have for now. You can do better by increasing
your shadow map size to 8192 or 16384, but at the 16384 resolution my
performance goes into the tank, and at 8192, there are still many shadow
artifacts due to lack of resolution. (clearly blocky/xelated/aliasing
edges,
The disappearing shadow was caused by the sun camera and range animation
and was fixed a while back - can you confirm that you are using the very
latest fg/sg/fgdata? And it's probably worth checking that you have the very
latest nVidia drivers.
FG, SG and FGData are pulled and
The first line says it all.
Okay... so what does it mean?
I'd first try to reduce the size of the shadow map :
--prop:/sim/rendering/shadows/map-size=1024
No success, problem persists.
or reduce the window size : --geometry=800x600
to reduce the memory footprint.
Same as above, problem
Be sure I value your feedback, but we are exploring new lands here.
There is not so much OSG deferred rendering example or real
application around, so please be forgiving.
And I don't think Flightgear is unusable for anybody. The Rembrandt
renderer is optional and the classical/2.6 renderer
Just freshly pulled and compiled GIT, fresh FGData master, trying to start with
--enable-rembrandt results in garbage on the screen and an impressive list of
errors - (I've omitted messages with meaning known to me in the following as
well as repetitions). Running without Rembrandt looks fine
No moon shadows? I see a long discussion coming up about how unrealistic
this all is ;-)
Did we not have a discussion a while back about our nights being too
dark? I
think moonlight would be great, but we would need to take into account
the
phases of the moon. Something to do as a
Hi Mathias,
thanks for the detailed answer. That indeed helps a lot. May I ask a follow-up
question?
I typically prepare a lot of things that are usually sensible and helpful
for its own but with such a final goal in mind. Once all is set up in place
I just need to grab into the black hat
Independent of using Earthview or not, I've found that the following series of
code modifications makes Flightgear support flights into low orbits (without
Earthview, you can enjoy a fogged sphere, but without the changes, JSBSim
models never reach high enough and rendering artefacts (grey
I guess most people are aware of the rendering artefact in the skydome shader.
I've made an observation which might shed some light into what it happening.
Under most angles, the artefact appears as a thin light grey line with subtly
mismatched colors to both sides of it. However, under some
For anyone who wants to have a look at Earthview in action, I've made the first
version available for download here:
http://www.flightgear.org/forums/viewtopic.php?f=6t=15754#p153257
(I have the next higher resolution level textures as well, but they're too
large to host for me). Anyway, this
Before going into more detail, you might want to check with Mathias'
recent work to integrate space-view into FlightGear. Otherwise you'll
probably be doing duplicate work.
Well, if Mathias could simply comment on the issue? What can we expect
at
what timescale? (And how do you know
Once you understand how the scattering integrals work it's natural to
compute them also from the outside of the atmosphere.
Okay, now I am *really* confused. Are we trying to solve the same problem?
Light scattering in the atmosphere is not part of what Earthview does at all.
That is
You haven't really looked at any of my designs so far, have you?
Nice trick - didn't work
Martin,
I have no clue what the point of this is. I'm in the habit of trying to say
what I think as clearly as possible, rather than trying to play tricks (I've
been hanging around in international
You ought to be able to initialize any vehicle at any altitude (up to and
even beyond 3000 km). At this time, only the Vostok has control jets, as
far as I know.
Actually I can not do that. Trying to initialize the ufo at 1.000.000 ft works
fine, and so does flying the ufo to the altitude.
When balancing different arguments I'd recommend to consider this one
as well: Backing out a kludge after it's been adopted by the users,
detangling additional hacks which start building on top of the
mentioned kludge is highly ungrateful work most of the time.
You haven't really looked at
Before going into more detail, you might want to check with Mathias'
recent work to integrate space-view into FlightGear. Otherwise you'll
probably be doing duplicate work.
Well, if Mathias could simply comment on the issue? What can we expect at what
timescale? (And how do you know these
the hardcoded value of 1000.0m is now settable at runtime with
/sim/rendering/minimum-sky-visibility
and defaults to 1000m, so the default behaviour is unchanged.
For the precipitation effect, I'm currently working on exposing most of
the effect's properties to the property tree and
Now that lightfields are in GIT, it occurred to me that we could have moonlight
with this bit of technology relatively easy (before anyone mentions Project
Rembrandt, I was thinking of rendering cloud layers in the moonlight, or
snow-covered mountain ranges, i.e. for any distance from high
I have a request to aircraft developers.
I was trying the DR400 yesterday, and I liked the plane as such quite well -
but the canopy glass effect spoiled all my fun. The reflection effects are just
way too strong. I have a similar problem with the cockpit windows of the CRJ700
which also dull
Ok I haven't entirely given up on the idea of removing the
auto-coordination from the code.
Why?
Wouldn't it be more appropriate to add
that rudder control to controls.nas?
Nasal runs per graphical frame, FDMs may need to run faster at low framerates.
Nasal AP systems tend to become
I've just tested the runtime-switchable lightfield with GIT as of 30 minutes
ago, and it seems to run just fine. If anyone would care to pick it up, here is
the link:
http://users.jyu.fi/~trenk/files/terrain-haze-v1.2.tgz
In fact, choosing a technique index of 7 has the pleasant side effect
I could add a check every time autopilot is engaged to disable it
while autopilot is active , but my real question is ,
can it be removed from the code ? It consists of three lines in
flightgear/src/Aircraft/controls.cxx , but it seems
that this should be handled by the autopilot system.
301 - 400 of 401 matches
Mail list logo