I think that you have to add new techniques (an XML element) to
existing effect file. You leave the current technique intact and
copy/paste it in the same file, add or change what is needed and
Modify its predicate.
Look at model-default.eff that implements 2 techniques.
Techniques (with their predicate) are tested in
ascending order of their index (the n attribute), so you can
create a new technique with a lower index than the one for the
current technique and add a predicate that test (for example)
Thanks Frederic - this seems to
I still have two small (weather-related) issues which I can't resolve myself:
* rain is still 'smart' i.e. de-activates above the lowest cloud layer.
Since Advanced Weather has its own precipitation region control, I'd need
a dumb version which just rains when I set the property
Do you mean that v1.1 as posted on the forum can't be committed
as is to git ?
Technically it could, but at the expense of forcing everyone to use
lightfield shaders. It overwrites for instance the default terrain and
The reason why this is implemented in that way is that I have
There is an important issue though, the functions appear to be different
for objects and terrain.
What?? Both model-default.eff and terrain-default.eff refer to
terrain-haze.vert/frag as shaders - how can the fog function be different
if they're using the same shader code???
I think you're
I agree that we should merge the project rembrandt work sooner rather
later. However, we should also take some time and effort to make sure
Thorsten's sky/haze/horizon effects are accounted for as well. I don't
know what issues we will find when trying to merge these two efforts, but
Actually I wonder a little why you accept using a modern tool like LaTeX
being just 20 years old - while we all learned that the optimum
scholar-environment was developed by the old Greeks (to my knowledge
without any computers and/or LaTeX) -- after that we never had such a
1a. wind turbine orientation and rotation/spin speed is bound to
/environment/wind-from-heading-deg and /environment/wind-speed-kt which
represent current wind at the FDM position. This should probably change
to ground wind. The same is true for the windsock, btw.
Turbines should probably use
~20 years ago: Those wonderful PDF-files were introduced - we now could
even transfer documents from one PC to another - even with different
Operating Systems and/or different printer capabilities! That was also
when LaTeX was developed [...]
I'll skip all the other stuff because I've
I discovered I really need a break from coding and debugging (found myself
dreaming about haze rendering lately, and that's usually a warning sign),
so I may have time for some philosophy (feel free to skip, it's not about
FGFS in particular).
I was surprised that this shift in Paradigms has
The end result is that I'd like to do the following:
- Create a new Materials directory under fgdata
- Move materials-dds.xml and materials.xml into it
- Create a new Materials/materials-base.xml file containing material
to both materials files.
- Create a number of small
Basically I see two different approaches in FlightGear Scenery world
(aside from a few minor blends):
1.) Focus all ressources on one common World Scenery.
2.) Build pools of individual (and sometimes even contradicting)
scenarios - also known as the M$FS way.
It's obvious that 1.) was
As we accept that any professional can
participate in the design, we should also trust our users to generate
and maintain their manuals by themselves! FGFS, FGFS-wiki, Wikipedia,
Linux, etc. etc. -- they all proved that it works!
Here's an actual user commenting on the state of the Wiki:
All people need to know that 60% (or more... it's approximate) of
aircraft available for flightgear are created by helijah.
More than 80% of them are totaly crappy ! They aren't a good point for
FlightGear project !
I think you're mistaking Flightgear for a commercial project here.
The fact that we have now 3 different threads about the same topics:
DC3, licence violation and cooperation in an OpenSource project, makes
it difficult to see where the real problems are.
There's a number of separate issues here.
* license violation of some commits
- this is a real problem,
The second problem is the 'checkerboard' appearance of fog rendering over
ocean. To the limit of my ability to test, the cause is incorrect
interpolation of distances and angles due to very large vertex spacing
Update: Emilian kindly educated me how to deal with this properly:
If the relative
I've spent four hours yesterday to trace down the cause for fog
inconsistencies which I observed in custom terrain.
One of them was the fact that the top fog level was sometimes displaced by
some offset from terrain chunk to terrain chunk in the new CORINE Italy
scenery and the other is the
Best of all, the new features are based on user community requests, and
not driven by economic incentives. Some of these features are already in
the works for the next FG release [give continuity message about the
That'd be suspiciously close to dishonest advertizing. I spend a
I feel a bit bad that it has taken that long to get it done, but at least
I made it before the 2.6 release - here are the updated documentation
files for Advanced (Local) Weather 1.4
including the description of the new gui and updates on the 'known
After a few more tests, some more observations which seem to be right to
me listed here (if that is confirmed, we may perhaps gather these and
other statements to the Wiki to get some guidelines for efficient shader
* 'big' performance users seem to be the scientists's friends, i.e.
Gary adressed those creating the 3d-models and aircraft in FGFS.
Yes, quite. And since your own aircraft doesn't repeat and is there
independent of visibility range, so in some sense this is a special case
Problem is, once you have created a model, you don't control what others
And especially in FGFS not really Vertices is one of the big problems,
but .xml's and nasal-scripts.
No, you can't say that in general. It quite depends on what you do and
what options you use. Whatever you compute, it costs some amount of
resource, and how long your frame takes
Pushing most of the haze shader computation from the vertex to the
fragment level would seem to suggest an approximately constant cost for
the haze for the same view regardless of scenery complexity since the
number of hazy fragments remain about the same.
Thanks for the explanations - that
I haven't really seen any guidelines about efficient shader coding, but
I've come across a few statements here and in the forum now and then,
which I so far assumed to be true. I've now spent the last few days
benchmarking my lightfield/terrain haze framework to see if I can't
squeeze a bit more
I just faild to set the wind speed and direction in the new weather menue
structure (up to date next-branch). My intention was to set the wind
from ground up to 3000ft.
Hence I used the Basic Weather menue and set the desired values in the
But I found that I got the wind
The change is releatively small but I'd feel better if ThorstenR tested
it before it gets picked.
The menu structure works like a charm - I think the switching button is a
very elegant solution. I did a couple of tests yesterday, and I didn't run
into any problems here.
I've also had a look at
I am hesitating from picking this into the release branch as one could
argue if that was a bug fix. But if it's general consensus that this a
an improvement that should make it into the release, we should do it.
The change is releatively small but I'd feel better if ThorstenR tested
Just an idea: as global and local weather are mutually exclusive, what
about having just one single weather menu item and add button in each,
global and local weather dialog causing the current dialog disappear and
open the other dialog.
While we are at it, I'd like to rename global and local
My GIT is now a week old, but in all likelihood this hasn't changed and is
in the release branch:
In reaction to concerns about a confusing menu structure, I moved all
relevant configurations to
(insofar as they are not controlled by the rendering dialog,
It's not clear from your mail whether the local_weather_config dialog in
release branch can be removed once this checkbox issues is resolved.
Can you confirm?
I haven't actually tried if removing it causes an error somewhere, but
it's not needed any more - all functions are either shifted
And with Project Rembrandt waiting in the wings is this worth doing
at this stage at all?
Project Rembrandt seems to be about something different - detailed
rendering of shadows in the near zone (~15 km) - what I do is about
approximate rendering of atmospheric shading in the far zone
I've noticed recently more or less by accident and to my dismay that
model-default.eff is used both by models placed in the scenery and by
typical aircraft 3d cockpits.
This is rapidly looking like a bad idea when a more detailed atmosphere
model enters the game - the terrain haze shader has
This behaviour is hardcoded, as there needs to be a default fallback
effect/shader when none is specified in the model and shaders are turned
Yes, I know that - but can you somehow catch that it's a cockpit you're
loading rather than a scene model and hard-code that pointing to a
If I understand this correctly, you want to change the default behaviour
the scenery models while leaving the cockpit as is with the current
behaviour? Does it also involve changing the behaviour of the non-cockpit
parts of the aircraft model?
That depends... For most external
I don't think you want to be changing the behaviour for all cockpits,
the one that is your aircraft. For other aircraft (AI/MP), you want
them to fade
etc. just like the scenery and the rest of the aircraft model.
We seriously show cockpits over MP?? I actually wouldn't want to show
* All major bugs fixed?
I found three in the last days - one major and two minor - since I have
added some sunrise/sunset support features to my working copy of Local
Weather, I'll just list the fixes rather than provide the updated files:
local_weather.nas, line 2917 (just after 'Starting
weather_tiles.nas, line 1004;
var alt = spread * 400.0 +
* 0.5 * m_to_ft;
has an obsolete altitude correction in and should just be
var alt = 400.0;
to get the correct altitude for Nimbostratus layers
var alt = spread
If you want to know the altitude, you need to have the matrix that
from the current view position/orientation to the earths center. And you
to transform from cartesian space into the earth ellipsoid. The best you
do is to do this per vertex. And even that is way too much
Which motor aircraft do you use for towing ? Given the above figures I
suspect you're using the Piper Cub, right ? Did you ever try the Grob
G115 ? I've never flown that one, neither in RL nor in FG, but I
*guess* it's probably the closest in performance and FDM credibiliy to
Rather than passing in the eye position as a uniform, why not
pass in the cloud altitude instead? Is this simply to avoid
needing to modify the C++ code?
I thought uniforms are things which are per frame constant in the scene
and apply to all objects the same way - i.e. I pass light
is gl_Vertex.z a reasonably approximate guess for the altitude in which
the cloud finally appears or do I have to look elsewhere? There's lots of
reshuffling of the vertex coordinates going on in the shader, and I've
kind of lost track a bit...
Thorsten, can you make a test flight and see if the instruments behave
as they used to?
I've just updated everything and had a short hop with Vostok to ~100 km
altitude and 2nd stage burnout - at least five minutes into the mission,
everything was looking and responding normally, so I'd assume
I don't think the Model matrix will help you much either, as IIRC
(0,0,0) is the center of the earth spheroid.
Hm, the line is
gl_Position = gl_ModelViewProjectionMatrix * gl_Position;
Doesn't gl_ModelViewProjectionMatrix transform things into 2d screen
Would it work if I use
Thorsten, can you make a test flight and see if the instruments behave as
they used to?
To try it get the vostok-1 branch from my fgdata clone:
If you tell me how to pull only Vostok from your fgdata? I have a GSM
connection from home and
I've just committed to origin/next a better fix for the LoD range that
based on the view distance, and also attempts to account for the possible
size of the cloud itself.
Thanks - working fine here!
Does this contain the impostor functionality already or not?
Continuing the list:
I tried to do some soaring in the DG-101G. There seems to be something
wrong with the plane's inertia.
* To turbulence, it reacts much more violently than other planes. I
thought a while ago that this may be due to a different implementation of
turbulence in YaSim
An (incomplete) list of issues I have observed in flying various aircraft
recently - maybe some of them can be fixed by maintainers before the
* Vostok-1 is currenty a no-show - it crashes before doing anything, the
log seems to point to a property as the cause. I guess it *may* be a
In case there is any lingering doubt that Flightgear can't deal with
horizon curvature at high altitude:
(taking the X-15 to 270.000 ft)
Done with recent Local Weather (which, as I discovered, is fine with Mach
6) and Terrain Haze
The LoD is currently hardcoded to 20km, so if visibility 20km, it
before the transparency effect.
I have a good fix that takes into account the current visibility as part
the Impostors work, but that won't be available until after the release.
In the meantime, I can
At view distances 100 km it becomes more and more apparent that the
flightgear scenery is flat and not a sphere, doesn't it?
I think a realistic horizon is impossible as long as scenery/world is
What's more important from high altitude is what happens beyond view
distance where no
We should agree on a common place to publish actual surface wind (for
one or many given locations?) in the property tree. /environment/config
is definitely not the best place to use but due to historical reasons,
many objects rely on these properties (windsock, chimneys/smoke, many
Local Weather is now (almost) in the shape I would like to see in the
release, and I've worked quite a bit through the list of issues:
1) Local Weather places clouds at the wrong altitude.
I've corrected that.
2) The GUI is not consistent with the system (I will fix that)
A new gui combines
And another materials.xml issue:
materials.xml has the spelling 'Grassland' whereas materials-dds.xml knows
both 'Grassland' and 'GrassLand'.
I believe the intended spelling is 'GrassLand', at least the other
spelling leads to problems with the newly compiled Colorado and
Does anyone know how to switch AI traffic off? I edited preferences.xml
and autosave to verify that it's set to false, I checked
/sim/ai-traffic/enabled to be 'false' - and yet tons of messages still
pass my screen about AI aircraft starting up.
Am I missing something obvious?
We are still looking into this one. At first glance there doesn't seem
any good reason for the wind not being honoured. The overcast is a
of interpreting different implementations between Global and Local
Now you are back operational we will try to come up with a
I've just placed a patch into the forum fixing the altitudes, providing a
new GUI which makes Local Weather Config obsolete and ports Cb towers also
to the new rendering system. I haven't tested it excessively yesterday,
but most of it was written and tested before my computer died, so it
Thanks to Hooray who helped me setting up the CMake environment and the
guys at Infocare who finally managed to fix heat management of my
computer, I am now back on the devel tree. I've done a few tests yesterday
and identified a list of weather-related issues which I think should be
IIRC clouds were moved into bin 10 to improve appearance vis-à-vis
particles. If we put clouds back into bin 9 and particles remain in 10
the cooling towers, chimney efflux, aircraft contrails, exhausts etc. are
drawn after the clouds i.e, in front. Rather looks as if we can have
But this is definitely some food for the brain.
Here is what they write:
So, how do we render these clouds in x-plane 10?
the answer is levels of detail, which is a display of resolutions of
NO MATTER HOW BIG THE SKY, EACH LEVEL OF DETAIL ONLY COSTS US 1,000
Since according to the newsletter Stuart's current ongoing quest is to get
better performance for 3d clouds, here are some of my observation:
* I've noticed that when I use the relatively lowres Altocumulus texture
sheet (3x3 on one sheet) I can basically use a ridiculous number of
We also note that you are back to using the .png textures with their
edges etc., rather than the .dds that we provided. Use of .dds textures
should at least be no worse than .png and at best will provide a small
That's a technical requirement of Stuart's
Not related to Flightgear, but with the hope for some help from
Linux-knowledgeable people here:
I received my laptop back with a replaced motherboard yesterday, and it
seems to be working fine apart from... a suspicion that I've lost fan
control. I can't be sure, I never checked the state of
Spoke too soon. The trees look great, but the frame rate hit makes it
unusable (from 30-35 to 2-4) even with the other shaders disabled.
Thank you! I haven't had seen trees in FlightGear for ages (can't run
with shaders). I didn't realize the trees were supported at all
In any case, the 3
frame rate killers here are 3d Clouds, Trees, and AITraffic. Compared to
these, the effect on frame rate by shaders is trivial.
Not for me. For me, the landmass effect at quality 3.5 (or 4? - I can't
check without computer) is the killer - with nothing else enabled, it
I know that Thorsten Renk is having to deal with
some hardware problems, so that he may not be around for sometime.
Nevertheless, we have been promoting the local weather stuff quite
exensively, so I would really like to demonstrate it at FSWeekend.
The problem here is that still the
My current setup can be found here
I've now tested a few more things: There are still some issues with ocean
tiles left - I *think* throwing in more vertices will fix this, or
Emilian's hack of testing point altitude against
Also there's a bigger issue here. The number of varyings is limited (in
it's the most constraining limit of all the limits present), and
this with other shaders will become problematic. Moving stuff in the
shader has the unwanted effect of requiring more varyings...
Yes, doing stuff once per vertex rather than once per pixel is faster,
may lead to poor results. The more stuff you do in the vertex shader the
visible the mesh grid will be.
Maybe someone can really enlighten me on this point:
My understanding is that
* the vertex shader
1. You forget the fact that in the end this all gets applied to faces
(triangles), and a point inside the triangle will have a value
between the values of the three corners. I don't think that's a linear
Then the fragment shader would never get correctly
I'm using 100-300m thick layers with visibility anywhere between 200 to
meters, in the layer.. then I play with the global visibility using
Problems arise with increased global visibility, at higher altitudes.
Okay, got it - thanks - mean one.
Basically, you're never looking
After spending half an evening trying to wrap my head around the ocean
problem, here's what I found out:
Just to be sure, I moved the geometry back into the fragment part - this
indeed seems to work more accurately. Then I switched ground layer effects
off and computed just with distance
Emilian and I have been busy investigating the integration of these
into the shader system that we are evolving. The good news is that we
come up with a fog function that can be easily included in all relevant
shaders. The bad news is that in doing so we have bumped up against
As for the topic brought up here, I sense a bit of sentimentalism
clouding the technical judgment of some.
In a positive creative development structure you leave the contributors
Contribute your planes! rather than Come to Gitorious, ask for our
permission to get your
This is exactly the deal which I think you are rather hurting yourself
with. I allege, that contributers of planes are not looking to make a
deal with you, at least I would not.
First, you're talking to the wrong person. I'm not Thorsten B, I am
Thorsten R, and I do not represent the core
I would have happily continued to
maintain/upgrade them , and I,m hoping this change might make things
easier ... but if Im now being told that my work can be changed
without any notice to me , that i have no say over my own
contributions, then I wont waste any more time here.
I think that
The Models folder for example, since that's not maintained there -
it's just a copy of what is maintained in the scenery database
and we shouldn't modify it directly in fgdata.
Um... not true. Cloud textures and models currently reside in
/Models/Weather/ and as far as I know are modified
Yes, true, we noticed that already. Hence we'll have to leave it as it
is right now. A bit unfortunate, this would have really shrunk the
archive significantly. But we may still be able to do that one day...
The two biggest chunks in Models/ are Weather/ (110 MByte) and
Geometry/ (35 MByte).
Just adding to the list of issues which might need attention:
I've recently noticed a weird behaviour of rain - was okay on the ground,
but it faded out 300 ft above ground in spite of /environment/rain-norm
being set to some number. After some thinking, I think I understand why:
after some testing of the new scheme, I have two minor and one major
comment. Minor stuff first:
* how is the cloud density slider supposed to influence the clouds
generated by add-cloud? Heiko claims that he gets to see an effect, I
tried to reproduce that but all that happened is
Im the last weeks, I've been working on integrating Lauri's skydome
scattering shader in a seamless way with the rest of the environment. I
have now a working version of the shaders available which could be
* the original skydome shader, with an added simulation of a low
This should now be fixed, and the clouds should be white once more.
Thorsten R. - regarding the 3000ft altitude offset problem, can you
check that you haven't got an altitude set for the layer itself?
Offsets as such are okay. I used to have some models with internal
Hmm - after double-checking, it looks good to me.
Checked with running --prop:/environment/terrain/area/enabled=1
That seems to be the key, thanks. Works fine if I set the property on
startup in the commandline, doesn't work if I don't. We used to have a
state where it wasn't necessary to
Torsten has kindly committed my recent merge requests.
So, not only should the curved field be fixed, but there are also many
more shading parameters available for the top/middle/bottom/shaded
part of the cloud. See README.3Dclouds for details.
Thanks, I'll pull this right away!
We would like surface-wind/speed-kt, /direction-from-deg,
/velocity-from-east-fps, velocity-from-north-fps, (please not 'from
), but use whatever is easiest, we can handle the conversions easily
Torsten, does that sound viable to you? I'll be happy to write them from
We already adjust the greyness of the sea to reflect the overcast
value. (It would also be nice if the visible weather in Global matched
description a bit better: we make the sea grey when it's overcast, but
the sky is still mostly blue).
This sounds all really nice and thank you very
So, not only should the curved field be fixed, but there are also many
more shading parameters available for the top/middle/bottom/shaded
part of the cloud. See README.3Dclouds for details.
Somehow, that didn't work out for me.
* clouds are now black
Some observations I've made in the last couple of days:
* hardcoded terrain presampling: This seems to have died on me after the
last pull (probably even earlier?) - currently all I get out is zero
everywhere. Since geodinfo() is now 50 times faster than it used to be,
falling back to the old
I see. So what do I do when I want to change the wind and want the
to follow the new setting? Simply do a setprop for the layer height
setting it to the same value it was?
For the moment, Yes.
At some point in the future we should fix it so that we're picking up
the wind from the
What's the status of the flat layer on curved Earth problem by the way?
This should have been fixed since September 12th in git.
Are you still seeing the problem?
Unfortunately yes. I've pulled and compiled
thanks for your comments and explanations.
We always recognized potential difficulties with blending the sky into
the terrain. The original design used the fog color as the opengl clear
color (the color that the display buffer is cleared to before starting
to draw any
(Apologies if I've missed this already) Are you planning put this into
Should actually be in now - you might have to activate it though, because
I haven't changed the gui and some menu options cause errors with the new
rendering system because they are not implemented or
I've spent some time over the last days to add a model for an optically
thick regime to the skydome scattering shader. I am rather happy with the
model (as far as the skydome is concerned, it now renders visibilities
down to 1000 m in a plausible way, the transition to the optically thin
LaTeX is not a word processor, it is a professional typesetting tool.
I see all the reasons to keep the docs in LaTex (like keeping the
process efficient at the moment), but this sentence here about
professional tools is probably not that serious as I read it, right ?
I don't know how you
Thorsten Renk - If this something we need to be thinking about for the
Local Weather as well?
We've been tossing the idea around in the forum that Local Weather stops
using the rand() function from Nasal and uses its own internal random
number generator. In this way, it could be initialized in
Thanks for the info - that confirms what I noticed: After Installing and
doing some tests with LaTex and LyX I did not find a feasible way to
import the newly designed appearance - seems you really have to just
extract everything except the plain text and and build it up new -
Nasal can handle pretty general problems (you can run a whole weather
system in it...).
3) Finally, what seems most general would be to write some code in
nasal that can read in a csv file, and then to display objects in those
locations. Is this feasible? Can nasal import a csv file or
for inspecting the upcoming Swiss airports, I obviously needed to zoom
out (see my posts in the forum's hardware and scenery
After looking through the Forum - I guess what you mean is that you want a
viewpoint from high above (outer space)?
As established in lengthy discussions with
See some screens. Default before and after
using local weather. both with high z
Yes, just shows that you haven't understood the issue.
Fact 1: The Scattering Skydome shader doesn't work for low visibility
(100 km) because the haze it creates (the yellow-black stuff) doesn't
blend with the
no definitely not not even your explanations...so i have to live with
such as local weather is not capable of doing
such? ok no problem
This has *nothing* to do with Local Weather, it's only related to the
value of /environment/visibility-m at your position.
What in these
If you can provide the parameters of a cloud that is exhibiting the
problem, that would be most useful.
Okay, I've decided over the weekend that I'll make my current code
available this week, because there's so much new stuff in which is not
related to the transition to the new
1 - 100 of 258 matches
Mail list logo