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
> 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).
> 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 loadi
> 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 c
> 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,
> 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 i
> 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
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
> 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
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
While test-flying METAR functionality with my weather system over the
weekend, I had two times the following scenario:
The loop controlling the generation of new weather as one flies to a new
location died (telltale symptom - clear skies in spite of METAR saying
otherwise), other loops were still
> 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
> 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 th
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 in
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
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 privat
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
> 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
Does anyone understand how turbulence is modelled?
I've had the following experience: I've been soaring using the ASK-13 in a
test of the new convective cloud life cycle implementation (nothing is as
frustrating as a nice Cumulus dissolving just as you are about to reach
it...), and by a bug which
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=5&t=7358&p=106546#p106546
(If t
>> 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
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 Fligh
> 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
> 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.
Fir
> 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 su
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 aircr
> 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?
> 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 fe
> 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
> wo
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
> assig
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=4&t=10080
Why did I do
> 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 i
> 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.
(...)
>
> 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 avail
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
>> 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_ muc
> 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
differences
>> 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 (rea
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
>> 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
>>
> 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 t
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
> 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)
> interpo
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 f
To follow up on my previous message:
> Not so with my GIT binary: Loading of the initial cloud configuration
> brings me down to 4 fps, and every time (!) a cloud is loaded from the
> buffer my framerate drops from 34+ to something like 20+ for a moment -
> which makes the whole experience rather
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 facto
> 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 someh
> 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
tel
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 reins
>> 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.
> 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
> certa
> 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 w
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 t
> 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 li
> I haven't fully tested all the options, but in general the frame rate
> cost seems very heavy.
> Regarding frame-rates: yes, the Local-Weather implementation kills
> non-high-end systems (mine, too).
I'm getting slightly frustrated here. I've spent months to improve
performance, and I feel by
> 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 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
> 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
--
Sta
> 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 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++
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 i
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 h
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:
range
0
31000
Using that tool, you c
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 gen
> 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
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-deriva
>> 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 t
> 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
ch
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 loose
> Glad to know it's just not me. I wonder if it has anything to do with
> this new cloud creating menu ?
Certainly not - completely separate system.
> Which I haven't quite figured out the purpose of ,
> wasn't the METAR string supposed to
> handle the user defined weather ?
If you pass a META
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 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
201 - 272 of 272 matches
Mail list logo
