Hi All,
since Stuart brought up the question of merging my local weather packages
better into the C++ structures in a response to me in the forum, I'd like
to propose a structure I would consider useful here.
The problem: Currently, it is a bit difficult to set weather conditions
from Nasal. If
Since I'm quite new on the list, I have pondered a few days if this is
meant to be a joke.
Ohhh look.
A chunk of work required that is not screamingly time-sensitive, could
be tightly defined and has potential mentors.
I smell a potential project for Google Summer of Code next year
Hi,
I don't really know what to make of it...but hope solution
can be found as I've started to grow tired of real-weather-fetch and
would like to be able to set up more realistic (and less annoying)
weather conditions, for longer distance cross country trips
especially.
Somewhat loosely
For RL flight planning charts are available for levels (pressure levels)
FL50(850mb), FL100(700mb), FL180(500mb), FL240(400mb), FL300(300mb),
FL390(200mb) and FL450(150mb). This should be sufficient for aloft data.
So, how would you imagine the GUI for this to be? I have never seen such
However, reverting those changes didn't seem to have any
effect.
Has anyone managed to find a solution to this?
-Stuart
Just a guess- could it be that changes made for the alternative clouds
system introduced it?
Which changes?
Back when the effect was reported here for the first time,
A few comments to your math:
I haven't done anything (yet) with Hal's exhaust thrust function. I was
waiting for someone else to work out the math...
The exhaust thrust function should return a force. Newton tells us:
F=ma
Indeed, but not very helpful here... force as a time-derivative
Don't we need to keep R, the universal gas constant, to make the equation
work?
v ~ sqrt(TR/M) ?
Not when you write it like this, because it's just a constant, so you can
pull it out and the result is still proportional to the rest if you drop
it, like
v ~ sqrt(R) * sqrt(T/M) ~ sqrt(T/M)
I've recently come across some interesting phenomenon with regard to the
range animation.
In the second generation of my cloud rendering system, every cloud in the
system was rotated towards the viewer, and then shaded to invisible if it
was more than 31 km away by the vertex shader.
Since I
Hi Curt,
Are you placing your range animation node above each tile or
above each object in each tile?
One has to work with the tools available - or write one's owns... with
range animation I literally mean the xml-tag in the wrapper of a model:
animation
typerange/type
min-m0/min-m
Sure - would you like a guess where my shader code largely comes from? :-)
But there are limits:
I asked before doing any work if the existing system can be used to get me
a cloud to a predefined location - Stuart's answer was a clear 'no', and
since I wanted to have precisely that capability, I
I've tested some large visibility range bad weather cloud configurations
yesterday, and I've noticed something:
The light in the scenery, especially for sunrise and sunset, is
beautifully tuned for fair weather conditions. However, underneath a thick
layer, having rosy-hued golden morning light
The main problem is that it's actually the code that generates the
values and setting. If you are adjusting the corresponding properties
from NASAL (they are in the property tree already) they will be
overwritten the next frame. I think it would be way easier to implement
this in the C++
We seem to disagree quite a bit here, Nasal is nice for supporting
aircraft functions but scenery coloring is part of the simulator core
and should be kept in the C++ code. In fact the same applies to the new
cloud code if you'd ask me but for proof of concept and ease of
development by the
There is now support for a /rendering/scene/saturation property in git
which if set to 1.0 (default) sets the colors as before and when set to
0.0 turns everything dark.
Thanks, much appreciated!
* Thorsten
--
Start
I get the same message on start.
Yes, there's a script that checks if a hard-coded vector elevation
sampling works or if you have to do repeated goedinfo calls. If the system
is to be compatible with 2.0.0 and to make use of GIT features to speed it
up, it has to have some way of knowing if the
I run last sources and data and I also see this message. Is it expecting
a not yet written feature ?
No, I have a GIT binary from a while ago supplied by Hooray which does not
produce the message but detects support available. So there exist versions
of code in which the patch is supplied, but
I'd be interested to run such a comparison myself. Could you translate
the described conditions into a set of command line parameters against
'default' FlightGear/GIT startup so I/we can make sure not to interfere
with local customizations ?
I don't think it can be done from the command line
I've just spent a session optimizing performance of the weather dynamics
routines, and I have largely done so by analyzing the performance of
elementary Nasal function calls and making use of my findings (and also by
dispensing with the pretense of elegant coding).
I was rather gratified to see
You just discovered that Nasal is 10x slower than C++
code! This is exactly why I prefer core code to end up in C++ in the end.
I don't think that's a valid interpretation of my results. Consider the
two cases where I achieved a significant performance gain by replacing
hard-coded structures
The distance_to() method is a pretty standard great circle calculation,
and that's exactly its purpose. Are you sure your faster version does
the same? Does it yield the same (numeric) results? And besides, in the
visual range direct_distance_to() should be good enough, and it's
certainly
The way I did the comparison [...]
Your rather elaborate pleadings make me feel that you've been
implementing a rather 'autonomous' (or 'uncontrollable') system for
setting weather effects, which - obviously - is destined to drive
people into a comparing apples and pears situation. Simply
Hi, in yesterday's GIT version somehow the menu
local_weather_config.xml
(which contains settings for view ranges of clouds and the amount of
resources given to moving clouds) seems to have vanished from the menu
bar, although it still is under /gui/dialogs/. I'd be obliged if anyone
could
I was experimenting with the new water shader and local weather, and I
could not help myself thinking how sad it is, that the more perfect the
simulation gets, the more noticeable the remaining weak points become.
Well, it would turn into a useful philosophical observation once you could
tell
Hmmm - looking through the commit log of menubar.xml, I can't find any
reference to local_weather_config.xml since local weather was first
commited at Apr, 12th. Looks like it has never been in GIT's menubar!?
I wouldn't know... It's part of the package though and should be
accessible
Hello,
with significant help, I've recently succeeded to compile my own GIT
binary. Initially this was very slow, in the mean time I've been told some
flags for the compiler which I've been using to recompile OpenSceneGraph,
Simgear and Flightgear which improved the available framerate by a
That seems like the shader not running - I can get this appearance of the
clouds when I start Flightgear from a shell as a different user - then I
don't get 3d acceleration from the graphics card (and lots of errors that
shaders did not compile) and the clouds look exactly like that. They seem
to
Thorsten asked me to switch off xxx-loop-flags in /local-weather/ to
rule out Nasal.
Set to zero:
buffer-loop-flag = '0' (double)
convective-loop-flag = '0' (double)
dynamics-loop-flag = '0' (double)
effect-loop-flag = '0' (double)
housekeeping-loop-flag = '0' (double)
With regard to the speed of loading models from Nasal into the scenery I
was writing about a while ago, I have made some discovery yesterday.
I was testing a setup in 2.0.0 with some heavy numerics running on the
second CPU, and this pushed the behaviour of the framerate into the
behaviour I was
Not sure, maybe it is connected with an other issue we recently
discovered. There are indeed some OSG operations which don't scale
well.
For example, OSG keeps a simple list of references at each shared
model - so each shared model knows all nodes it is shared to. Adding a
new member to the
However, the (so far to me unknown) C++ subrouting actually bringing
clouds into the visibly rendered scenery is even way slower - I can read
the message that the property writing is over after the expected 2.5
seconds, but continue to see clouds appear in the scenery for 30 seconds
and more.
I've just completed a sweep through all available aircraft in GIT, and I
thought a list of the non-functional ones might be useful for some people.
I have not taken care to make sure the problem persists in more recent
pulls, and I have not tried to find out if a quirk in my system us
responsible
I've just completed a sweep through all available aircraft in GIT, and I
thought a list of the non-functional ones might be useful for some
people.
[]
c182rg
I just picked this one as a random item from your list and I'm happy to
state that it runs and flies properly for me (real weather,
Lightning works fine here.
Here it does not. Pulled flightgear, simgear and fgdata today, compiled
simgear and flightgear.
Error logs attached.
I was entertaining the theory that something is wrong in the way I update
fgdata, but while git status lists a couple of files as having
fgdata, but while git status lists a couple of files as having
differences, that are files I know should be different because I changed
them. No aircraft is listed as being different.
The inter-dependencies in the Base Package between seemlingly unrelated
pieces have grown _that_ much, that
I've had just occasion to compare performance of a GIT binary compiled on
Nov 24th with a GIT binary compiled Nov 13th in one of my standard
benchmark tests (which I described a while ago), and the test confirmed an
impression I had yesterday in just test-flying - I've lost almost 1/3 of
available
Can you compare the OSG statistics between the two binaries? Choose
cycle onscreen statistics three times.
I sure can, but I have no idea what I am looking at when I do that - I
basically get a table with numbers which change when I move or change view
direction. I'd make screenshots
2. Clouds rotate in an unrealistic way when doing loops and other
maneuvers
that involve going to/from inverted (loops, half Cuban eights, split S's
...)
but it does not happen when doing rolls. The clouds will flip over 180
degrees
at the top and bottom of loops for example.
(...)
The
One more observation. Yesterday I was doing tweaks to the spin related
functions in my model and during spin tests I noticed that I get the same
affect when I am in a spin only the clouds are rotating about a vertical
axis
rather than a horizontal axis. Again it only appears to happen in
I'd like to let everyone know that I just finished a project assigning
each aircraft model/cockpit a number between 0 and 10 indicating the
visual level of quality of the cockpit. The results can be found in the
forum here:
http://www.flightgear.org/forums/viewtopic.php?f=4t=10080
Why did I do
Martin wrote:
I think the risk of doing harm by rating aircraft and their cockpits
after just a quick test is rather high compared to the potential
benefit - especially when you're too unfamiliar with some of the
respective real-life references. To put in into different words: By
assigning
I'm afraid that your grading is no more than a beauty contest. It does
matter if the gauges are all in the right place or if the cockpit is
complete down to the last detail. Under your grading a cockpit could be
a complete figment of the imagination, but by looking pretty or having a
wow
So, if you claim that your rating is _not_ a beauty contest, then I'd
ask you: After taking the above mentioned thoughts into account, what's
left as a criteria for your rating ?
Martin, I see no need to repeat myself over and over. Please read the
explanations I have given so far, if you feel
One example that strikes me is the c172p, though I'm biased as one of the
maintainers of the aircraft, and it is rated accurately according to
your criteria :)
Compared with, say, the A-10, the F-14b or the Tu-154b (which is not in
the GIT repository) - how would you rate the c172p cockpit?
Henri wrote:
Please don't fall in the MSFS policy, when the eye candy is the main
approach.
I don't see 'accuracy' and 'visual detail' as mutually exclusive - you can
have both. I for once am interested in 'realism' in a simulator. An
important part is that the aircraft behaves like an
My point is your rating was based on an assumption that was totally
incorrect: that the developer had made a reasonable effort to put the
right
gauges and levers in the right place. Do you make a similar assumption
about
the FDM? That it is approximately right? Is there much value in such a
Nevertheless, I am not persuaded. Your rating is based on: Four legs
good, two legs bad!. While that may be generally true, it will throw up
many anomalies, and the problem is you neither know which these are,
nor how many, because you haven't and can't properly test your hypothesis.
First of
Yup, if you are in a AAR-capable aircraft, click on AI-AITanker. Click
Request in the window displayed, and a tanker will be instantiated
nearby.
The controller will tell you where it is relative to your current
position.
Hope it still works! I haven't tested it for several years.
It
Hi All,
After a period of having been extremely busy at work, following a switch
of jobs and moving to a different country, I'm slowly coming back to
life. December is already well on it's way, and it would be great if we
could manage another major release this year.
I realize that
I suggest the following:
18 or higher = advanced production (minimum 4 in each rating)
16 to 17 = production (minimum 4 in each rating)
For production perhaps at most 1 category with a 3 rating all others 4
and
above to get a little bit of a sliding scale between production and
advanced
Since I have the technology lying around - here's how fog banks could look
in a 3d approach (I created this in 5 minutes by adding 5 lines of Nasal
to a tile setup call - could be even better with some more tuning):
http://www.flightgear.org/forums/viewtopic.php?f=5t=7358p=106546#p106546
(If
I have to admit that looks very good. Good volumetric fog is kind of the
holy grail in simulation (well one of them.) Would it be possible to
post
some quick instructions somewhere for how to configure your local weather
system to do this?
Sure... technically it's just effect volumes with
Hi Martin,
I also find it rather interesting to read something about the 'invisible'
work behind the scenery - thank you for letting us know. It's sometimes
difficult to appreciate the work that is not directly seen, and it helps a
lot if you tell us.
Thanks for the hard work.
However, there is
Martin:
This is a rather incomplete and therefore, at least to my opinion,
pretty unfortunate and unsuitable representation of a certain status
quo.
It wasn't meant to be a representation of any status quo - it is what you
(among others) have been communicating (at least to me, given private
of Scenery development is substantially different from craving for
aaah's and oooh's on The Forum after you successfully managed to
follow
an elaborate and nicely illustrated recipe on how to build FlightGear
Terrain.
Hehe, I'm glad that I managed to catch at least one reader by putting
After some more grey hair, I believe I talked the Local Weather package
into working with live METAR data such that it is competitive with the
default system. In some areas it performs worse (especially getting denser
coverage of convective clouds right is a bit of a problem, it doesn't do
time
The metar realwx controller checks every 60 seconds for a station
reporting
metar and loads that data if the station id has changed since the last
check.
It also rechecks the metar every 15 minutes for the unchanged station.
Okay, so every 60 seconds, the controller
* determines what the
I would have guessed that loading these images would be an infrequent
hit making file size a relatively small factor, but if the system is
continually swapping them out and reloading them for some reason, that
might not be so.
*shrugs* It's reasonable to set things up in such a way that a
I've found the time yesterday to update my December GIT to an up to date
version, and I'd like to fire off two remarks.
First, I had the impression that some nice work has been done on the
default clouds. If anyone wants to add more texture variety here, I have,
in addition to my extracted cloud
It seems more and more that people prefer using the forum instead the
devel-list.
vs.
Forum activity is winding down too- all the informal aircraft/scenery
developers have either left or are inactive.
What a nice example of perceptional relativism! We have the same set of
data (= the
A while ago I posed the question:
What I have been wondering is the following: Currently I am using *.rgb
textures. I have noticed that the filesize can be reduced by a factor 2 or
so by going to *.png textures. However, what is the format which would
most efficiently into the scenery? If *.png
Maybe you already did this, but this needs a 'average of 3' (or 5)
tests, because I would be very surprised if the input file format
changes the final frame-rate after loading - it's all uncompressed to
the same format in GPU memory, as far as I know.
Yes, I checked it (I couldn't believe
With the clouds issue, I have this feeling that something is amiss with
the
way clouds are generated, but i can't put my finger on it.. :(.
Thorsten, have you done the same test with individual textures instead
of a
big one ?
Huh? Not sure what you mean, I don't think I have a single
when playing with the Local weather menu, i get the following message
Nasal runtime error: setprop() value is not string or number
at /../data/Nasal/weather_tile_management.nas, line
189
called from:
/../data/Nasal/local_weather.nas,
line
Hmm... I did not have found time for a detailed table of fps
comparement, but it seems to me that some of your clouds are decreasing
fps more than the default 3d-clouds. It looked different to me at the
beginning, but making some videos showed me this.
If you use default settings, you're
Well that's exactly what I was proposing you to test, split the big
texture
into 9 smaller ones, thus making 1texture/model. If the graphic engine is
somehow being stupid and forgets that it has already loaded that
texture we
should see a dramatic improvement in performance and loading
Hmm, I'd say it's rather critical when in place of one highly detailed
airplane you can have about four with the same level of detail in the
texture
;)., or a texture with doubled dimensions, thus having more detail
;)(since,
as Gary said .dds files get loaded compressed in video RAM).
Okay, to summarize what I take from the discussion and all the tests:
1) Texture types: png seems to be best for load-once, then-keep problems
because it has the smallest filesize, but takes a lot of time to load. dds
seems to work well for some problems, possibly those involving opaque
textures
Sorry what do you mean with
(= tick the option box). ?
The menu 'local weather tiles' has an option called 'debug output', if
that is ticked, a log is written to the console.
however just try to modify the wind kt within the local weather tile gui,
iget nasal error
I don't.
So in
Maybe someone could do some tests when changing the setting
(SGPagedLOD.hxx:56) from CACHE_NONE to CACHE_IMAGES or even to
CACHE_ALL (then recompile/install sg+fg). Would be interesting to know
how this changed loading times, run-time fps and memory consumption.
I've just done a very quick
Maybe someone could do some tests when changing the setting
(SGPagedLOD.hxx:56) from CACHE_NONE to CACHE_IMAGES or even to
CACHE_ALL (then recompile/install sg+fg). Would be interesting to know
how this changed loading times, run-time fps and memory consumption.
After 30 minutes more of
however just try to modify the wind kt within the local weather tile gui,
iget nasal error
After some reflection and a similar problem discussed in the forum, I
think I start to see a potential misunderstanding here.
In an integrated weather system, there's no way to 'just modify the wind'
To fly within Flightgear we have a lot of ready made aircraft model , we
are
not obliged to make the aircraft.
With your local weather system we must build the weather.,
No, you certainly don't have to build the weather. Your problem appears to
be in fact the exact opposite - you were trying
The local weather menu option is first before the other local weather
options. This does open up a dialog box where you do have to create
clouds
1-by-1. Looking at this, it appears that the intent of this is more for
debugging. Maybe it would make sense to move this option over to the
The main thing that bugs me with the system is that the view frustum
culling
around the edges of the screen is visible, so you continuously see the
clouds being created and disappearing at the edges of the screen as you
turn
or change views. If it was once in a while I could live with it,
This happens here as well (nVidia 8600GT (256MB VRAM) on linux). Now
that I
think of it it looks and behaves like graphics card memory bandwidth
issue,
maybe it is cured with the image cache set with CACHE_ALL? as by adding
some
more sistem RAM things haven't improved here.
Hm, I'm running
Yep things improve, noticeably. And I'm more convinced it's a lack of gpu
memory issue (as in it gets filled up pretty quick with the clouds), as I
caught a glimpse of scenery getting redrawn too.
You may be right - I looked up the specs of my computer, and it seems I
have 512 MB VRAM, so
How about using plain old textured plane crosses for clouds at bigger
distances? (the way trees are done, only with a (or several) horizontal
plane(s) added)
These might work better for bigger structures like cumulonimbus, and
such,
too, as you can control the shape a bit. (no fancy shader
For the time being, we'll have to live with this. We should just be
aware, that introducing too complex data structures and too
heavy/complex computations in Nasal isn't a good idea. Even when their
average execution time looks ok, they will eventually trigger noticeable
frame rate jitters.
Since I don't follow the 'rule' by coding 10.000+ lines in Nasal, I
suppose that is partially thrown into my direction. From where I stand,
there are good reasons to use Nasal - first of all the userbase which
regularly compiles their own code is small, whereas people do install
addon
FYI I'm currently looking at adding support for creating a 3D shader
cloud
using Nasal, to bypass the need to have XML wrappers etc. I'm hoping
that this can off-load some of the low level quad-tree work you
currently
have to do.
That's absolutely splendid news! If there's a hard-coded
Hi Cathy,
Let me know if you'd like some performance tests.
My system is relatively old and slow. Without local weather on, no
shadows, no 3D clouds, and no material shaders, I typically get frame
rates around 20. With no local weather, shadows on, 3D clouds on,
material shaders on, I
And since something like don't complain, just do it was mentioned:
I'm not complaining (my new machine is doing fine for now). I've just
analyzed it and mention the facts.
Yes, actually your post is quite the opposite of complaining - it's very
informative and constructive in that it suggests
To follow up Stuart, here are some of my thoughts:
FYI I'm currently looking at adding support for creating a 3D shader
cloud
using Nasal, to bypass the need to have XML wrappers etc. I'm hoping
that this can off-load some of the low level quad-tree work you
currently
have to do.
(...)
Yes, in fact, my basic strategy was to use the existing default 3D cloud
code almost untouched from the perspective of creating a set of sprites
that are built up into a cloudlet. So, you can define (amongst other
things)
- the texture sheet to use,
- the number of sprites,
- min/max width
Since my basic Cu texture image is often 1024x512 (sometimes larger),
sorting through the y-coordinate of the texture sheet isn't an option
unless you use 4096x4096 sheets - which may not be so nice. (?) Well, I
guess that depends on the texture cache which you seem to have anyway.
The
Which reminds me, a long time ago (in the cutover from PLIB to OSG) we
lost the ability to detect clouds using the Weather Radar.
It would be very nice
to restore that function. The code still exists, it's just the 3d clouds
are
no longer accessible.
What would it need, and what can it
Comments welcome. If there are no objections, I'll update fgdata/Nasal
shortly, moving some initial modules to separate folders. I've tested
this locally with the multiplayer, local weather, wildfire and ATC
chatter scripts.
Sounds all good to me.
I'm currently setting the default properties
You can say THAT again! I wonder if OSG people know that they should
also throw out stuff from cache, not just put things in!
I have been bold enough to use the CACHE_ALL for today's TGA
multiplayer event ... at the end of the 6th hour or so, FG's memory
usage reached 7.5GB, with the
So when wrap=true the core code will wrap the edges, shift the layer
with altitude and move it with the wind With wrap=false, we'll just move
it with the wind.
OK?
Sounds good to me.
One function I had on my TODO list was something to return the cloud
position in lat/lon. However, it's a
And even less that could
have been related to this besides:
Loading local weather routines...
Compatibility layer: testing for hard coded support
* can set light saturation:yes
* hard coded terrain presampling: yes
* terrain presampling initialized: no
* can disable
I have just posted a longer collection of my thoughts and experiments with
what makes a scene (a cloudy sky, a cockpit, a forest,...) credible and
what isn't helpful in the forum (it contains a lot of pictures, so it
simply isn't useful to post it here as well).
If you find either this
To save others some time, here is the direct link to the forum post:
http://www.flightgear.org/forums/viewtopic.php?f=5t=11992
Thanks... I can't believe I missed to include that!
* Thorsten
--
WhatsUp Gold -
Sorry to bother with trivia, but my inability to use GIT properly starts
to annoy me.
What I want is my personally customized branch of FGData in which I can do
texturing experiments and develop Local Weather ahead of what is in
master, which is then periodically updated to whatever else has
Anders, you're my hero! It actually worked :-)
Maybe I should add that to the wiki?
* Thorsten
to keep your commit. Even if you merged your changed branch (e.g.
with git pull) rather than rebasing it you'd get the conflicts.
git status to check which files are in conflict.
I've finally managed to find an (in hindsight rather obvious) way to
regionalize textures and have started working on a rice terrace texture to
represent irrigated crops in Asia.
So far, I'm quite happy with the texture, but since so many aerial
screenshots of rice often show clusters of trees,
Current terrain engine makes flights on high altitudes or long flights
on high speeds unreasonable. There is no Earth surface visible, only
blue fog, but lags very big, fps may drop to one per second or less,
simulation may crash on attempt to switch to other window and so on,
because it
I've recently done a visual comparison between hires Flightgear scenery
and reality - for those interested, see here:
http://www.flightgear.org/forums/viewtopic.php?f=5t=12259
One of the striking points is that in reality even in partially clouded
skies distant objects do not start to fade into
Following the idea of placing conditionals on position in materials.xml, I
have created a rather nice demo for regional textures. But the problem
remains that only the startup position counts, i.e. I suspect
materials.xml is parsed only once during a Flightgear session.
Is there a simple way to
As I said previously, it's gotta be implemented not on model level but
on whole FG level, or not implemented at all.
Nobody is talking about implementing anything on *aircraft* model level -
the idea is to represent *Earth* by a model the same way we can represent,
say, clouds by a model.
Part of the problem is that FlightGear almost always renders ideal
situations for the skydome.
If you look at this picture you see there are situations where white fog
is natural:
http://upload.wikimedia.org/wikipedia/commons/2/2a/St.Gilgen_Panorama_2007-02-22.jpg
But you obviously won't get
1 - 100 of 258 matches
Mail list logo
