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 can
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)
/sim/rendering/lightfield.
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
* for
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
model shaders.
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
than
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
development of
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
definitions common
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.
Sure, in
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
development]
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
http://users.jyu.fi/~trenk/doc_update.tgz
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
coding):
* '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
anyway.
Problem is, once you have created a model, you don't control what others
do with
Heiko wrote:
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
profile
from ground up to 3000ft.
Hence I used the Basic Weather menue and set the desired values in the
table.
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
it
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
/gui/dialogs/local_weather_tiles.xml
(insofar as they are not controlled by the rendering dialog,
It's not clear from your mail whether the local_weather_config dialog in
the
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
on.
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
different
If I understand this correctly, you want to change the default behaviour
for
the scenery models while leaving the cockpit as is with the current
default
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,
just
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 +
local_weather.cloud_vertical_size_map[Nimbus]
* 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
***
make that
var alt = spread
If you want to know the altitude, you need to have the matrix that
transforms
from the current view position/orientation to the earths center. And you
need
to transform from cartesian space into the earth ellipsoid. The best you
can
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
commonly used
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
Hi Stuart,
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
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
coordinates?
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:
git://gitorious.org/~andersg/fg/anders-fgdata.git
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
adjusts
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?
Cheers,
* Thorsten
Continuing the list:
DG-101G:
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
release:
* 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:
http://www.flightgear.org/forums/viewtopic.php?f=19t=14844
(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
kicks in
before the transparency effect.
I have a good fix that takes into account the current visibility as part
of
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
a disc.
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
more).
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
Minneapolis sceneries.
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?
* Thorsten
We are still looking into this one. At first glance there doesn't seem
to be
any good reason for the wind not being honoured. The overcast is a
problem
of interpreting different implementations between Global and Local
weather.
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
should
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
addressed
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
all
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
realism
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
buckets.
(...)
AGAIN!
NO MATTER HOW BIG THE SKY, EACH LEVEL OF DETAIL ONLY COSTS US 1,000
PUFFS!
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
sprites
Vivian:
We also note that you are back to using the .png textures with their
black
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
performance advantage.
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
without shaders.
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
Hi,
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
http://www.phy.duke.edu/~trenk/files/terrain-haze-shader24102011.tgz
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
fact
it's the most constraining limit of all the limits present), and
integrating
this with other shaders will become problematic. Moving stuff in the
vertex
shader has the unwanted effect of requiring more varyings...
Yes, doing stuff once per vertex rather than once per pixel is faster,
but also
may lead to poor results. The more stuff you do in the vertex shader the
more
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
interpolated
between the values of the three corners. I don't think that's a linear
function anymore.
Then the fragment shader would never get correctly
I'm using 100-300m thick layers with visibility anywhere between 200 to
600
meters, in the layer.. then I play with the global visibility using
z/shift-z.
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
shaders
into the shader system that we are evolving. The good news is that we
have
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
their freedom.
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:
The current
Hi Stuart,
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
committed.
This is:
* the original skydome shader, with an added simulation of a low
Hi Stuart,
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
coordinates
Hmm - after double-checking, it looks good to me.
Checked with running --prop:/environment/terrain/area[0]/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!
* Thorsten
We would like surface-wind/speed-kt, /direction-from-deg,
/velocity-from-east-fps, velocity-from-north-fps, (please not 'from
heading'
), but use whatever is easiest, we can handle the conversions easily
enough.
Torsten, does that sound viable to you? I'll be happy to write them from
Local
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
the
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
(see also
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
clouds
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.
https://gitorious.org/fg/simgear/commit/d2dfb81a0907276f36cf7582c4274fa1784972d6
Are you still seeing the problem?
Unfortunately yes. I've pulled and compiled
Hi Curt,
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
of the
Hi Stuart,
(Apologies if I've missed this already) Are you planning put this into
git?
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
regime
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 -
without the
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
section)
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
Quoting myself:
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
3) Antishading
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
