Re: [Flightgear-devel] A collection of issues
> -Original Message- > From: Torsten Dreyer [mailto:tors...@t3r.de] > Sent: 07 October 2011 10:49 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] A collection of issues > > Am 07.10.2011 08:55, schrieb thorsten.i.r...@jyu.fi: > >> 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 set it in the command line any more - > > so something there might have changed (?). > > In the initialization sequence of the environment subsystem, a > terrainsample instance is created for each "area" node under > /environment/terrain (you can have as many areas sampled as you like). > However, these nodes have to be there during subsystem-init. Maybe you > create it from Nasal which probably initializes later? > If that worked before - I have no idea what might have changed to break > it for you. The last nontrivial update on the terrainsampler was in > August 2010. > Well, thanks for all the help with tied properties etc. We've managed to work around most of the problems so far and Phase II of the improvements to the water shader are in git. The waves now align with the surface wind, and we try to adjust wave height with the wind speed. Here are some examples: http://imageshack.us/f/830/fgfsscreen070.jpg/ http://imageshack.us/f/571/fgfsscreen069.jpg/ We know the wake could now do with some improvement, and we have some ideas that we will work on before embarking on our planned Phase III, which will have improved integration with Global and Local weather. This only works with materials-dds.xml Vivian and Emilian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Am 07.10.2011 08:55, schrieb thorsten.i.r...@jyu.fi: >> 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 set it in the command line any more - > so something there might have changed (?). In the initialization sequence of the environment subsystem, a terrainsample instance is created for each "area" node under /environment/terrain (you can have as many areas sampled as you like). However, these nodes have to be there during subsystem-init. Maybe you create it from Nasal which probably initializes later? If that worked before - I have no idea what might have changed to break it for you. The last nontrivial update on the terrainsampler was in August 2010. Torsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
> 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 set it in the command line any more - so something there might have changed (?). Cheers, * Thorsten -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On Oct 6, 2011, at 2:33 AM, Vivian Meazza wrote: >> >> >> So, how's it done in practice for weather reports? Is there a precise >> attenuation definition, or is it more or less guestimated? > > See > > http://www.e-publishing.af.mil/shared/media/epubs/AFMAN15-111.pdf > > It is estimated by an observer, or measured by an instrument. You can expect > the METAR visibility to be a pragmatic estimation of what you will > experience at the airfield. > > I was up in a control tower a number of years ago talking to a controller. I was told something along the lines of, "That mountain is 10 miles away. If we can see it, then we put on the ATIS 10 miles visibility. That building over there is 3 miles. That tower is 1 mile" --Adam -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Am 06.10.11 11:33, schrieb Vivian Meazza: > 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 much for improving this shaders. But for visible weather we need shadows. Just "dimming reflection" by some general cloud density makes no sense for me. Cheers, Yves -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On 6 Oct 2011, at 18:17, ThorstenB wrote: > However, when someone writes to the tied property using the "normal" > property interface (setprop in Nasal or via the C++ SGProperty::setValue > methods), then property's change listeners should fire normally. > So, it depends on how a value is changed. But generally listeners aren't > guaranteed to work with tied properties... Except, it's possible to manually fire the listeners on such properties, eh, during subsystem::update. Of course, this means there's little point in having a listener, since you may as well have used a Nasal timer and just read the property each time. James -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Am 06.10.2011 17:06, schrieb Torsten Dreyer: > Am 06.10.2011 09:22, schrieb thorsten.i.r...@jyu.fi: >> me 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 system doesn't really make a huge difference in >> performance though. Whatever you think is best - fixing or going back to >> geodinfo() - just let me know please. > Yep - seems to be broken. It hasn't been touched in a while, so I assume > something in the surrounding framework has changed that broke the > terrainsampler. I'll dive deeper into the issue later this week. Hmm - after double-checking, it looks good to me. Sampling results at KHAF: alt-layered-ft: 0 alt-mean-ft: 114.5 alt-median-ft: 0 alt-min-ft: 0 alt-offset-ft: 0 and the results for LOWI: alt-layered-ft: 2500 alt-mean-ft: 4681.5 alt-median-ft: 4500 alt-min-ft: 1500 alt-offset-ft: 3500 or KGCN alt-layered-ft: 4000 alt-mean-ft: 5949 alt-median-ft: 6000 alt-min-ft: 2500 alt-offset-ft: 5500 Checked with running fgfs --prop:/environment/terrain/area[0]/enabled=1 --prop:/environment/terrain/area[0]/input/use-aircraft-position=1 Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On 06.10.2011 12:43, Vivian Meazza wrote: >> > Maybe because some properties are directly tied to C++ variables and >> > can't have a listener. >> > > That is a reasonable theory, and one which we have tried to test - but some > tied variables seem to work while others don't: is this consistent with your > analysis? When a property is tied to a C++ variable and the C++ variable is changed directly (only possible in the C++ code), then the property's listeners won't fire. The property has no way of knowing about the change. However, when someone writes to the tied property using the "normal" property interface (setprop in Nasal or via the C++ SGProperty::setValue methods), then property's change listeners should fire normally. So, it depends on how a value is changed. But generally listeners aren't guaranteed to work with tied properties... cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Am 06.10.2011 09:22, schrieb thorsten.i.r...@jyu.fi: > me 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 system doesn't really make a huge difference in > performance though. Whatever you think is best - fixing or going back to > geodinfo() - just let me know please. Yep - seems to be broken. It hasn't been touched in a while, so I assume something in the surrounding framework has changed that broke the terrainsampler. I'll dive deeper into the issue later this week. I'd prefer to not restore this in Nasal but leave it as a c++ encoded subsystem. But as you already have >12000 lines of Nasal, this probably doesn't really matter much ;-) Torsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On Thursday, October 06, 2011 10:22:18 thorsten.i.r...@jyu.fi wrote: > 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 system doesn't really make a huge difference in > performance though. Whatever you think is best - fixing or going back to > geodinfo() - just let me know please. > Hi Thorsten, I just checked, and src/Environment/terrainsampler.cxx hasn't been changed since July. My radio code also relies on terrain sampling and today's git works as before. Perhaps the problem is somewhere else. Cheers, Adrian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Stuart Buchanan wrote: > What specifically is the "hardcoded terrain presampling"? http://mapserver.flightgear.org/git/gitweb.pl?p=flightgear;a=blob;f=src/Environment/terrainsampler.cxx Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
On Thu, Oct 6, 2011 at 8:22 AM, Thorsten Renk wrote: > 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 system doesn't really make a huge difference in > performance though. Whatever you think is best - fixing or going back to > geodinfo() - just let me know please. What specifically is the "hardcoded terrain presampling"? -Stuart -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Frederic > > > Unfortunately, we don't know what causes some properties to work and > > others not, just that this is the case. > > Maybe because some properties are directly tied to C++ variables and > can't have a listener. > That is a reasonable theory, and one which we have tried to test - but some tied variables seem to work while others don't: is this consistent with your analysis? Vivian -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
> Unfortunately, we don't know what causes some properties to work and > others not, just that this is the case. Maybe because some properties are directly tied to C++ variables and can't have a listener. Regards, -Fred -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A collection of issues
Thorsten > > 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 system doesn't really make a huge difference in > performance though. Whatever you think is best - fixing or going back to > geodinfo() - just let me know please. > > * new water reflection shader - since it doesn't talk too much to Local > Weather, I had completely missed it has plenty of features. Great work, > Vivian and Emilian - the foam caps look gorgeous. I'd like to talk to the > shader better from Local Weather as well. Thank you for your kind remarks. They look nice but in practice have a number of defects: an improved version is in the pipeline as Phase II. We had/have a great deal of trouble finding properties in the tree that actually worked with the shader at all - see Issue #445. From our side we picked what was a. surface wind, and b. worked. We had to use wind from N and E because direction and speed don't. We then need to construct both these values inside the shader. We have tried to accommodate Local Weather as best we can, but we would dearly like commonality between Local and Global Weather, using properties that the shader can read. Unfortunately, we don't know what causes some properties to work and others not, just that this is the case. > I've had a look what parameters you're probing, and for example you use > the wind from the global weather lowest boundary layer config. Now, I can > write that from Local Weather, but that's not a clean way to do things and > I'd like to avoid going back to writing into the global weather config to > get things done, Torsten spent a lot of time on making it possible to > avoid that workaround. > > Instead, we could maintain properties 'surface-wind-fps' and > 'surface-wind-direction-deg' under Environment which are continuously > updated by the weather system (global weather has also interpolation and > continuous time dependence, so if I'm not mistaken the actual value > doesn't have to be the one in config/). That set of properties could also > be used by any other wind-dependent surface objects (smoke effects on the > ground, windsocks,...) - which somebody else on the list wanted to have > implemented a while ago anyway. Yes, surface wind is much needed. We don't mind if it's interpolated or not, we can handle either inside the shader. We expect other users would like an interpolated value. We just hope interpolation isn't what causes values not to be read. 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. > > Likewise, with total cloud cover - currently the shader tries to deduce > that from a number of sources. But for the weather systems, it'd be rather > easy to add the coverage of the individual layers probabilistically to get > a total coverage and simply provide that number to be used by the shader. > > (adding layers probabilistically: say I have a 5/8 and a 2/8 - the total > coverage is then 5/8 * 6/8 (I'm hitting first layer but not second) + > (3/8 * 2/8) (I'm hitting second but not first) + 5/8 * 2/8 (I'm hitting > both); or simply 1 - 3/8*6/8 - which is 0.718 or a bit less than 6/8.) > > Does that sound like a reasonable way to transmit info from the weather > system to shaders? That would be great - we thought perhaps this is what the property overcast was intended to do, but it's different in Global and Local weather. The math can be done out in the GPU - there's plenty of scope to offload tasks from the CPU. 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). > > * visibility: Comparing X-plane and Flightgear screenshots for supposedly > the same visibility, I've come to think about the definition. > > In nature, things fade exponential in distance, so the contrast goes away > as exp(-distance/lambda) where lambda is the mean free path of photons in > the medium. Any physicist would usually take lambda and say that this is > the visibility. But after the distance lambda, of course 1/e ~ 36% of the > contrast is still there and you can recognize objects. So what's the limit > when we conclude we don't see anything any more? 1% of contrast? 0.1%? > Dependent on that limit, the relation of lambda to visibility can be a > factor 3 different. > > Flightgear currently seems to fade with exp(-(distance/visibility)^2) by > default, which sort of lessens the question by a harder cutoff at the > expense of being unphysical for small distances. X-Plane
[Flightgear-devel] A collection of issues
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 system doesn't really make a huge difference in performance though. Whatever you think is best - fixing or going back to geodinfo() - just let me know please. * new water reflection shader - since it doesn't talk too much to Local Weather, I had completely missed it has plenty of features. Great work, Vivian and Emilian - the foam caps look gorgeous. I'd like to talk to the shader better from Local Weather as well. I've had a look what parameters you're probing, and for example you use the wind from the global weather lowest boundary layer config. Now, I can write that from Local Weather, but that's not a clean way to do things and I'd like to avoid going back to writing into the global weather config to get things done, Torsten spent a lot of time on making it possible to avoid that workaround. Instead, we could maintain properties 'surface-wind-fps' and 'surface-wind-direction-deg' under Environment which are continuously updated by the weather system (global weather has also interpolation and continuous time dependence, so if I'm not mistaken the actual value doesn't have to be the one in config/). That set of properties could also be used by any other wind-dependent surface objects (smoke effects on the ground, windsocks,...) - which somebody else on the list wanted to have implemented a while ago anyway. Likewise, with total cloud cover - currently the shader tries to deduce that from a number of sources. But for the weather systems, it'd be rather easy to add the coverage of the individual layers probabilistically to get a total coverage and simply provide that number to be used by the shader. (adding layers probabilistically: say I have a 5/8 and a 2/8 - the total coverage is then 5/8 * 6/8 (I'm hitting first layer but not second) + (3/8 * 2/8) (I'm hitting second but not first) + 5/8 * 2/8 (I'm hitting both); or simply 1 - 3/8*6/8 - which is 0.718 or a bit less than 6/8.) Does that sound like a reasonable way to transmit info from the weather system to shaders? * visibility: Comparing X-plane and Flightgear screenshots for supposedly the same visibility, I've come to think about the definition. In nature, things fade exponential in distance, so the contrast goes away as exp(-distance/lambda) where lambda is the mean free path of photons in the medium. Any physicist would usually take lambda and say that this is the visibility. But after the distance lambda, of course 1/e ~ 36% of the contrast is still there and you can recognize objects. So what's the limit when we conclude we don't see anything any more? 1% of contrast? 0.1%? Dependent on that limit, the relation of lambda to visibility can be a factor 3 different. Flightgear currently seems to fade with exp(-(distance/visibility)^2) by default, which sort of lessens the question by a harder cutoff at the expense of being unphysical for small distances. X-Plane seems to cut visibility even sharper with some kind of smoothed theta-function, so no attenuation up to a point, then sudden fog. So, how's it done in practice for weather reports? Is there a precise attenuation definition, or is it more or less guestimated? Cheers, * Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
