Hi Stuart,
I'd really like the 3D cloud infrastructure to be used for all the
clouds, so
if there are features missing we should address them.
Would it be possible to modify the 3D clouds so that they can be used for
the rain texture as well? For example, I could provide a sprite
ZLT-NT and Nordstern: I can't place the mooring mast, which is supposed
to be alt+click.
I would suspect the window manager, both aircraft use the same mechanism
and I've seen it working here as recently as yesterday. It should be a
left click while holding the (left, on my keyboard) Alt
Hi Stuart,
Thorsten R. - please feel to provide a prioritized list of
fixes/enhancements you need.
A summary list of current issues ordered by priority (leaving out what
your recent commit addressed - I still need to pull that):
1) placement in flat layer instead of curved
That is currently
BTW, feature freeze is meant to be exactly this: No addition of new
features. There's no point in delaying feature freeze specifically for
aircraft as the feature set of the core, which aircraft are supposed to
run on top of, is already supposed to be stable by definition of the
feature
Doesn't make sense to me (I have no clue what you mean).
No problem, that's something I'll be able to cope with,
And aren't we charming today? Well, since I know first hand about the joy
of nightly diaper changes, I'll just add my best wishes for a more
relaxing time here.
Cheers,
* Thorsten
Doesn't make sense to me (I have no clue what you mean).
No problem, that's something I'll be able to cope with,
And aren't we charming today? Well, since I know first hand about the
joy
of nightly diaper changes, I'll just add my best wishes for a more
relaxing time here.
False
Congratulations to everyone for the hard work - in front of and behind the
scenes.
Let me take the opportunity to say that I really liked the way the release
process worked:
* everything was announced well in advance so that everyone had (make that
'could have...') opportunity to adjust his own
2) I have the Corse custom scenery
http://helijah.free.fr/flightgear/scenes.html#Corse
installed under my FG 2.0.0 FGData. With my GIT version, I don't
actually
have any scenery under FGData but instead use the commandline option
--fg-scenery=/usr/share/FlightGear-2.0.0/Scenery/
That
Try adding --prop:sim/paths/use-custom-scenery-data=false to the command
line. I had the same issue, and thanks to help from list members that
was and still is the only way my custom scenery can work with
git/2.4.0...
I don't have a clear understanding why, but that fixes the issue.
*
... and yet another issue:
On a first long-range test yesterday, I observed that the cloud base of my
convective layer was continuously rising. At takeoff the clouds were
exactly as specified, later still plausible given terrain, but by the time
the cloudbase had reached my curise altitude of
Two things which might be worth mentioning (both with recent GIT, pulled
and compiled ~ a week ago)
1) One of my rendering performance benchmark tests is to use the ufo
transport it, using the location dialog, exactly 30.000 ft over the
starting position (then increase FOV to 120 deg and create
I've got a patch to do this that I'll submit shortly. the parameter is
height-map-texture, and it defaults to false.
I'm also taking the opportunity to change some of the defaults, so that
the
max-[cloud|sprite]-[width|height]-m parameters default to 1.5x the min
equivalent.
I suspect it
That should be 1 second for most systems, so that's great. Does that
just cover the elevation queries or generating the full model?
That should be 1 sec for everything (I don't have any measurement for
how fast generating the cloud models is, but it is *very* fast.
If so, then I wonder if
This is basically an answer to Vivian who asked me why my Cumulus layers
look like stacks of cardboard rather than smooth volumetric objects like
Stuart's 3d clouds - I thought that maybe some others are also interested
in some background info, and maybe someone even has a new idea.
Basically,
Some progress and minor issues:
I am in the process of redoing textures and cloud definitions for Cu
layers (the toughest nut), about halfway through converting all available
cloud types.
I have implemented tested tile management functionality (automatic
building and removing clouds) and it
Unless there are any objections, I intend to push Emilian's and my work
to Git later today.
Has been working fine for me the last days - no problems with dds
textures, and I've been using your reworked texture sheets as basis to
generate the regular m x n structures needed for Stuart's system.
I've spent 20 minutes yesterday to get the parameter lists I need for
Stuart's system into a new module 'cloud_definitions.nas' to unclutter the
code - when I had that ready, I generated a runtime error that
'cloud_definitions.select_cloud_model()' would reference an unknown
object.
I
Instead there are two shadings taking place:
1) Shading based on distance of the sprite to the sun. Effectively
we compare a vector from the center of the cloud to the sprite location
with the light normal.
2) Shading based on the vertical placement of the sprite in the cloud, so
lower
I think the problem is that you are expecting the cloud height to
indicate the location
of sprite centers, wherease the code is expecting it to be the height
of the actual
cloud.
The code actually _subtracts_ the minimum texture height from the cloud
height to determine where to place
Please note, the check for
features.can_disable_environment == 1 is gone now. It doesn't make any
sense there.
In a current GIT, none of the checks make any sense, because current GIT
always has all the features. On the other hand, the purpose of the
compat_layer.nas is to provide
I've finally (I guess you all know the feeling of too much other stuff to
do...) managed to start some tests with Stuart's Nasal interface for 3d
cloud generation. Right now there is only a very rough placement structure
and no real management (no removal, no distinction of cloud size, all same
We don't normally maintain 2 versions: we leave the last stable as is,
and
only work on the Git version. If it's too much work, or too confusing I
would suggest you abandon the version intended to be distributed via
Forums, since that is not how we usually conduct our business.
That's
Sorry, I was unclear.
The computation of wind-from-down-fps can not be disabled at all, it is
independent of the feature can_disable_environment.
Thanks for clarifying - that makes sense. Sorry for the confusion then.
* Thorsten
Even though your previous testing showed no perf difference between the
default 3d clouds and the models, I am slightly disappointed there isn't
some
intrinsic perf benefit to the default 3d versions.
It's not been a fair comparison as such. Let me try building clouds from
the same texture
Even though your previous testing showed no perf difference between the
default 3d clouds and the models, I am slightly disappointed there isn't
some
intrinsic perf benefit to the default 3d versions.
It's not been a fair comparison as such. Let me try building clouds from
the same texture
Fixed in master and release/2.4.0. For some reason that code did got get
upstream when I opened up the system for local weather. Must have been
broken since September 2010!?
Thanks for the quick attention!
It's quite possible that it's broken for a while - there are not so many
glider
Meanwhile - at the cheap end of the market, Emilian and I have cleaned up
most of the textures, made some of the AC3D models single-sided,
reordered
the objects, provided unique names, and converted everything to .dds.
This has much improved loading/unloading, and given a much better
Hmmm - just notices you are setting wind-from-down-fps in your local
weather. This is a bad idea as it is a computed value
wind-from-down-fps =
thermal-lift-fps +
ridge-lift-fps +
local-weather-lift
That's how it was hardcoded in the old weather system and what I
forgot to
Following the report of a Forum user, I've just tested ridge lift near
Innsbruck with the ASK-13 with a recent (yesterday) GIT binary. It appears
to me that ridge lift is indeed broken in the sense that the number
computed and visible under /environment/ridge-lift-fps is fine, but the
FDM doesn't
So, I quickly wrote an alternative to the current Nasal system
geodinfo(),
using the groundcache instead of the current scenery method.
(...)
Comments?
You just made me a rather happy person :-) That seems like a sizeable
improvement in performance!
One question - do the two methods have
I'm not sure if increasing the tree count could trigger the same
problem.
I've been flying with 8 times the default tree density for the last half
year (I edited materials.xml) - apart from the (expected) general overall
impact on framerate, I haven't seen any issues like second-long lags when
I think it's grossly unfair to mix these issues: Spaceflight requires
to essentially write a space simulator. One of my first statements in
the
forum was:
Orbital flights opens a whole new can of worms besides the need for
different rendering - completely different physics, completely
It's a dead end time when someone who had asked for changes leaves
before that changes comes because it not comes too long and that makes
some issue area related development impossible.
(...)
If that dead end will come seventy years after now then for sure I had
missed the point. If not then
@ Vivian:
1. No one EVER reads the manual. Not for nothing is our manual called
'The FlightGear Manual' - so we can justifiably say RTFM.
Now that I have read
your manual, I would say most of it would go right past the average user,
who wants to simulate flying, look out of the window and
You mentioned earlier that a lot of the performance issues would
disappear
if we could probe the terrain 100 times faster. I've been thinking about
this for a while for ai traffic, skyop's moving map instrument, and
weather.
I'm thinking of storing some resolution of altitude data in the
If I may be permitted some personal comments about things which bug me?
I've been thinking quite a bit (possibly more than it's good for me)
triggered by responses on the list during the last days, and I would
perhaps take the time to clarify my position on a few things.
I get the impression
Here, with a Core 2 Quad, 4Gb RAM, nVidia GTx285 with 2Gb VRAM there is a
huge difference in performance. At EGMH and using METAR, I get 75 fps
with
Global Weather, but when I use Local Weather, using the same METAR, I
get a
little over half that.
I hate to repeat myself, but what set of
You can enable a better property to compare performance using View =
Show worst-case frame delay. It shows the longest delay in between two
frames within the last second of simulation (lower left corner). The
lower the number, the better. In order to maintain an acceptable 25Hz
simulation,
I also wonder if the terms global and local are really applicable.
Would
static weather modeling and dynamic weather modeling be better terms,
or how about simple/complex?
I guess the key differences in philosophy are:
* terrain interaction: clouds in Local Weather 'know' terrain type and
What I'd really love to see in the mid-to-long-term range is some kind
of unified weather system. It does not really make sense for an average
user to have two systems to choose from.
Well, there's also a reason - the different design philosophy - and at
some point you may want to consider
I've recently tested the DG-101G which is (I think) the first JSBSim
glider I've been flying in Flightgear. I've noticed a rather strange
issue:
In Local Weather, I added some amount of turbulence around a thermal
proportional to the strength to simulate the fact that a thermal is not a
laminar
2) As it stands, it's very difficult for a new user to understand the
difference between Local Weather and Global Weather. let alone how
they inter-relate. Enabling the Local Weather package requires
setting Enabled local weather module from the Local Weather Settings
menu, yet the rest of
Sounds logical to me ...the double weather systems are a bit of
nuisance , would be nicer, in my opinion , if they could be combined
in a single dialog but not sure if that's possible.I use real
world weather anyway , so i never use those settings.
That misses the point - you can use
Rest assured, the Concorde has its share of oddities :)
See the known problems part in the ReadmeConcorde-jbsim.txt.
Yes, it sure does. But I guess I mean something slightly different.
I have tried to fly AP-controlled IFR approaches in a number of planes
(since I can do really good-looking
I spent several hours in RL flights measuring the behaviour and timing
of the CENTURYIII and several days to implement the measured values in
it's digital counterpart in the SenecaII.
I am confident that the SenecaII has an autopilot capable handling all
published procedures including flying
Hm, while people revisit the Lightning, maybe also this is interesting -
what's wrong with the picture?
http://www.phy.duke.edu/~trenk/pics/lightning_wind.jpg
The plane is at rest and faces 350 degrees (i.e. up), the wind comes from
260 degrees (i.e. left) and the drag chute goes... hm...
We currently have
- 777-200
I have been trying the CRJ700 lately, and I think this might be an option
for an airliner as well - the cockpit has a nice visual quality, it comes
with engine start procedure, the AP seems to be well-tuned and free of
oscillatory behaviour and the night lights in
I've just placed an updated version of Local Weather online. This version
doesn't contain any genuinely new features but fixes one timing problem in
loading the Nasal modules and a couple of issues which have been bugging
me for some time (some improved textures, a couple of cloud model changes,
Further research indicates that the F1A, modeled here was NOT capable of
M2.0 at 36000ft. M1.9 seem more likely. Moreover, due to structural and
stability problems the F1A was operationally limited to M1.7 or
approximately 700KIAS. We have pushed a small change in Mach drag to
model this
A bunch of issues I've seen - maybe some folks want to fix them before the
release (all in a GIT pull of 5 days ago):
* The B29 (JSBSim) doesn't run, but rather prints out an error message
YOU HAVE AN INCOMPATIBLE CFG FILE FOR THIS AIRCRAFT. RESULTS WILL BE
UNPREDICTABLE !!
Current version
A bunch of issues I've seen - maybe some folks want to fix them before the
release (all in a GIT pull of 5 days ago):
* The B29 (JSBSim) doesn't run, but rather prints out an error message
YOU HAVE AN INCOMPATIBLE CFG FILE FOR THIS AIRCRAFT. RESULTS WILL BE
UNPREDICTABLE !!
Current version
Well, FlighGear has its own atmosphere model that is also used by the
other subsystems (e.g. instruments, weather reports, visual system, AI
traffic and whatnot). So far there has been few reasons not use that
model also for the FDM.
I think the FDM only needs to know the atmospheric
Hi All,
I've had a short look at how ThorstenB has implemented Local Weather as a
run-time loadable submodule, and for me it performs just fine, but in the
Forum I had a few people reporting problems either with METAR mode or in
general (unfortunately not with enough info so that I could
BTW, while I'm very much in favour of having FlightGear's various
subsystems split into distinct parts, I think the bad design claim
coming from you is pretty weak. Where was your voice when the Local
Weather subsystem was added ?
Gentlemen, it's so nice to be mentioned so often if an
..protection under the GPL, depends on a willingness on the
part of the copyright owners to actually exercise their rights
under copyright law to defend or enforce their copyrights.
Correct me if I'm wrong, but I can't see how willingness to exercise
copyright under GPL would require moving to
I've just pulled the new version and had a look and... it looks *very*
impressive - with just a few property edits, one can generate a dark,
overcast scene from a summer sky, and the diffuse haze comes out very
nicely.
Come to think of it, this might not be exactly what you're looking for
but
If two users in parallel flying spacecrafts will see the same good then
there is no problem. But everything on Nasal is on local level, not
global core level.
At least one of us is confused about how things are structured.
My understanding is that there's nothing in Flightgear which
I'll see what I can come up with this weekend.
Thanks, much appreciated!
On another note: I seem to remember you had another request for the
weather system but I was too busy to remember it. Do you remember what
that was?
I was toying with the idea to model diffuse high-altitude haze by
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
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
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,
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 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 -
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
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
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
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
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
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
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.
(...)
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
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.
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
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
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
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
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
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
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
101 - 200 of 258 matches
Mail list logo
