Re: [Flightgear-devel] Aircraft modellers - is a grain texture useful?
Ive been thinking about this since since you posted, and now i'm curious to see it.My initial fear was more framerate drop, but if it can be truly disabled I think its worth a try I think one thing we have pretty consistently implemented in the effect framework is that all effects can be switched off. The whole model ubershader is implemented in such a way that it affects you only if you have a model shader on. The grain texture can be implemented such that it affects you only if you have the model shader on at high quality and your model has a flag set such that it is used. Water reflection used to have nearly zero impact on my framerate , now its unuseable over the ocean or large lake. Which one? We used to have two of them, a silvery one at lower quality and the sine wave variant at high quality. Even the high quality variant can be made to run almost twice as fast by dropping half the partial wave calculations (this is implemented in the lower quality version of Atmospheric Light Scattering). I haven't been following the shaders in the default framework so much, but if a shader suddenly eats up twice the performance, there usually is a reason worth understanding. Not sure why but the skydome shader had very little effect on my framerate when it first appeared , now it drops fps to 10 from 40 . Well this at least I know. When the skydome shader first appeared, it did this when you didn't have mountains on the horizon: http://www.phy.duke.edu/~trenk/pics/skydome1.jpg Your framerate has gone into fixing this problem by providing consistent fogging and lighting of the terrain under all conditions such that terrain matches with the skydome. And unfortunately, the terrain part is way more expensive than the skydome part (and if you run at higher quality, there's a gazillion of additional goodies). The skydome code itself is pretty much as fast as it used to be (and if you delete all skydome-switched techniques from terrain-default.eff and model-default.eff, you can get if back if you really like). * Thorsten -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
Stuart, Having talked about it for months (years?) I've finally written some property rules that improve the integration of Basic Weather with the Atmospheric shader. In particular the skydome properties are now calculated using formulae very similar to those of Advanced Weather so there's no need to set rayleigh/mie/density properties directly, and appropriate levels of ground haze are estimated based on the lowest cloud layer. Some of the integration is quite basic, and there's plenty of room for improvement in the Basic Weather METAR parsing to set up appropriate visibility settings in particular. Feedback welcome as always, though I suspect almost everyone these days is using Advanced Weather... This also removes another roadblock from possibly making the atmospheric shader on by (non-Rembrandt) default. Ooohhh, controversial :) I still use basic weather with mp so that I get the same clouds in both clients - is this still the case? Your most recent change seems to have broken the manual input gui here - sometimes it works, and sometimes the values revert to the default. We seem to have lost the ability to use /NIL as a METAR input - very useful during fdm development to remove weather effects. I'm not sure when this broke, I think it might have been something James did. Vivian -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
On Fri, Apr 19, 2013 at 9:18 AM, Vivian Meazza wrote: I still use basic weather with mp so that I get the same clouds in both clients - is this still the case? The clouds are unchanged by this, though I don't think that you will get the same clouds in MP on both clients unless they are started at the same time. The only changes I made with this were to ensure that Basic Weather generates the appropriate properties for the atmospheric shaders. Your most recent change seems to have broken the manual input gui here - sometimes it works, and sometimes the values revert to the default. Hmmm, odd - I made the changes specifically to fix the manual input UI that I thought your Weather UI changes had broken! :) I suspect that you and I are using the UI in a different way and there's something broken in the (complex) UI logic. I'll take a look over the weekend - sorry for the inconvenience. If you're able to nail down the specific actions that cause it to fail, vs. the actions that make it work that would be useful. We seem to have lost the ability to use /NIL as a METAR input - very useful during fdm development to remove weather effects. I'm not sure when this broke, I think it might have been something James did. That shouldn't have been changed by anything I've done recently. -Stuart -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [FGx-project] multiplay refuel test
Hi Geoff *Equipment* What equipment are you using? a KC-10 with a 'probe and drogue'? *The Prize* I will offer a VIRTUAL bottle of good Bordeaux rouge to the first pilot who maintains drogue contact for say a minute Good luck. Am I correct in thinking that a sudden movement of a foot or more will cause the probe to miss the drogue? And a sudden movement forwards or backwards of, say, ten feet may cause a disconnect? If so, consider: At the equator a degree of latitude or longitude is about 69 miles. Therefore one foot equals 0.0274483 degrees. I note that http://crossfeed.fgx.ch/data supplies latitude and longitude of six decimal places - in other words down to a precision of one foot increments. This kind of appears to be OK. but there are other factors to consider. For example perhaps the numbers are bogus. The explanation is hiddden in this complex article: http://en.wikipedia.org/wiki/Floating_point What it's saying is that if, in determining positions, heading, speed or delts and if there is a sin, tan or square root used in the calculation, then you are hosed if there is a 32-bit or longint anywhere in the code. Intermediate products wreak havoc on accuracy. Playing with big numbers and little numbers at the same time produces odd results. [Harking back to the conversation a couple of weeks ago between you and Peter on 32-bit vs 64-bit: My vote is for 128-bit.] I could go on and on. 220 knots is over 371 feet per second. At a 10 Hz interval the planes have moved over thirty feet. In order to calculate an accurate delta then you need to eight or nine digits of degree precision *The easy answer: Cheat* It would be far easier if you could lock your deltas to those of the probe. If the probe moves an arbitrary distance forward then your position would be its position plus X. Is there some 'over the shoulder view' set of numbers that you could use to lock your plane's deltas to the movement of the other plane? If so that would be great. Of course, trying to refuel two planes at the same time might make the ride a bit jerky for your passengers. *10 Hz* I laugh when I see such a number. Do you really expect something as silly as a computer to be that reliable? In my highly asynchronous animation world we have no use for setTimeout, fixed intervals or whatever. Their behavior causes logjams and fails. The current device/trick/whatever is a called Request Animation Frame. See https://developer.mozilla.org/en-US/docs/DOM/window.requestAnimationFrame http://paulirish.com/2011/requestanimationframe-for-smart-animating/ http://updates.html5rocks.com/2012/05/requestAnimationFrame-API-now-with-sub-millisecond-precision Yes, I know this is all browser-based stuff but could work just as well in an executable - and how about the thought of running FG on a laptop for hours without draining the battery? *Why UDP?* I have asked several times but nobody answers: Why does FG still use UDP when there are so many easier more modern alternatives - ranging from a RESTful system to RTC? ** I'd love to see some logs of two planes trying to refuel. My guess is that from a global point of view they are touching, but when it gets down to inches - the two planes are all over the place. - lost in a rounding-error space. In any case, good luck with giving out the Bordeaux! Theo On Wed, Apr 17, 2013 at 4:13 PM, Geoff McLane ubu...@geoffair.info wrote: NOTAM: To flyers who fly 'probe' enabled aircraft in Europe... or even if NOT... I will be flying the 'victor' refueling tanker for the next few days from KFPY, south 180 track, then turn around at the southern mountains, north on 360, at 12,000 feet – FL120 STD QNA – and am interested in 'hot' flyers who want to try air-to-air REFUELING (AAR) in suitably equiped aircraft, well ANY aircraft... The tanker will maintain, under autopilot, 220 knots (KTAS), at the said 12,000 feet, either 180 or 360, under the callsign GA006. The flights will commence about noon, or before, UTC, and close about 20:00 UTC. The track can be followed using http://test.fgx.ch, or other mp map URLS. Click on 'GA006' to localize... Reason: (a) I have tried with several aircraft over the last few days, and learned that this is QUITE difficult, but I hope NOT impossible! (b) The present suggested pps (Hz) is 10 when you set up –multiplay=, but FG 2.11 has fill-in extrapolation code when fgfs packets do not arrive in time, so maybe this is too high. This is the basic question... So the idea is to reduce this IFF this fill-in code helps, ie does its job... The theoretic idea is that with this code we can reduce the bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs to be FULLY tested, and confirmed... Now I have tried this over several day, in several aircraft – A-10, f-14b, a4 and failed, FAILED to touch the trailing drogues... it is TOUGH... autopilots help you get to the 'zone' but it needs manual flying to get to the RIGHT
Re: [Flightgear-devel] multiplay refuel test
Hi Jano, Thanks for the video links... these were great... So far I have had 5 others, aside from myself, trying to get to touch the R or L drogue, and while some got quite close and were able to maintain a close position, several factors came into play which made it difficult, if not impossible... The tanker used is the 'victor', probe-drogue type, flown on autopilot at 12000 feet (STD 29.92), 220 knots on either 180 from Paris LFPY, or 360 on the return. I usually turn N shortly after Toulouse in the south... So far, as the other aircraft, have had Citation-II, Mirage_F1, m2000, f16, and ???... A big thank you to them for joining in and trying... And I understand some screen shots were posted on the PAF forum, but still to find these... a link would help... I also tried with a 2nd victor, running in a 2nd machine... Oh, and I always use mpserver14.flightgear.org, Switzerland, and perhaps attempts while using the SAME fgms server may be better... but still saw the following assumed due to 'lag' problem when flying victor to victor where this is the closest you can see the following plane, but in fact he see itself very close to the drogue This difference between whether you are looking from the aircraft to the tanker, or from the tanker to the aircraft is certainly ONE of the problems. Usually the tanker will see the aircraft still back some 10s of meters behind the drogue, while the pilots sees the drogue up very close, perhaps even touching... And assume it can be the reverse of this... http://wiki.flightgear.org/Mp-patch Have downloaded and am looking at your wiki lag patches with an aim to patch my 2.11... in Windows 7 and Ubuntu... but not sure how far I will get... It would certainly be nice if both pilots saw the same scene ;=)) But this is not the ONLY problem... basically the mp sending rate is fine with 10 pps Well yes if the packets flow, but many things do seem to interrupt that flow... One of the biggest is F3 - take a screen shot - This seems to stop packets for a seconds or more... Loading a new scenery tile can be another... new weather metar, although in the victor I usually select simple Fair weather... but there seems to be a number of things that 'change' the packet flow... I even suspect mp chat causes small blips... There is already some form of predictive code in 2.11, but this to not yet very accurate or successful, but seems a very good start... If the aircraft IS maintaining close proximity to the drogue, and I press F3 in the tanker, the tanker seems to slide forward faster and further than it should! So the aircraft pilot sees the tanker quickly move away... accelerate and moves forward... quite un-nerving... And this can happen even without a heavy F3 event... perhaps even due to system thread changes, ie nothing to do with the running fgfs... Now if [s]he does nothing but hold, usually things will settle back into close proximity, but the pilot has LOST some visual clues aiding to maintain position so by the time things resettle [s]he is no longer so near the drogue ;=(( So I must take another look at this fill-in code, and would like to hear from the person or persons who implemented it... and understand why the very apparent slide fast forward, and what controls how quickly the position returns to that of the current packets after such an artificial change... any README, links, etc... And then there is how will your 'lag' correction effect this current extrapolation code? If at all... So lots of things to explore here ;=() Over the coming days I will try to maintain my victor tanker runs... but it too can be quite stressful even just watching and chatting... Maybe later try an E-W run, since you do mention some differences depending on direction... So still invite others to try, but they should read and understand the above - it is difficult if not impossible - so expect more of the same frustrating efforts until some more CODE changes can be put in place... As one trier sort of put it - it is like the tanker has some 'shield' around it... things are good while you close in, but at very close proximity all HELL breaks loose ;=)) Have FUN! Regards, Geoff. On Thu, 2013-04-18 at 08:18 +0200, jean wrote: Hi Geoff i guess you are seing something like that: http://www.youtube.com/watch?v=VWn6_RFp97Y where this is the closest you can see the following plane, but in fact he see itself very close to the drogue and what you want is like this: http://www.youtube.com/watch?v=kGHRDrc_n98 you should have a look at this page, wip but working fine for the few pilots testing it : http://wiki.flightgear.org/Mp-patch basically the mp sending rate is fine with 10 pps, but you need a way to compensate for the lag. I can't try a refuel with you before this WE, but i will if you are still flying the victor somewhere. jano NOTAM: To flyers who fly 'probe'
Re: [Flightgear-devel] multiplay refuel test
hi Geoff , And I understand some screen shots were posted on the PAF forum, but still to find these... a link would help... http://equipe-flightgear.forumactif.com/t1096p15-vol-en-formation-avec-un-fg-patche#20638 Oh, and I always use mpserver14.flightgear.org, Switzerland, and perhaps attempts while using the SAME fgms server may be better... yep, that's the rule we are following during our formation flight: to be on the same mpserver. Being on different servers give more jitter and lag, and there's no way to compensate for the inter-server lag now, as we have no information about them. http://wiki.flightgear.org/Mp-patch Have downloaded and am looking at your wiki lag patches with an aim to patch my 2.11... in Windows 7 and Ubuntu... but not sure how far I will get... good luck :) , for your information, a patched 2.11 windows binary is available and updated once a week, if you can't compile it yourself, see detail on the wiki. It would certainly be nice if both pilots saw the same scene ;=)) But this is not the ONLY problem... basically the mp sending rate is fine with 10 pps Well yes if the packets flow, but many things do seem to interrupt that flow... One of the biggest is F3 - take a screen shot - This seems to stop packets for a seconds or more... i never use F3 for screenshots, as it freeze fg , instead i use the os printshot feature, much better and harmless (and it has the antialiasing from the gpu) Loading a new scenery tile can be another... new weather metar, although in the victor I usually select simple Fair weather... but there seems to be a number of things that 'change' the packet flow... I even suspect mp chat causes small blips... those are not change in paquet flow, but 'freeze' in FG itself, when some frame take time to render, being stuck on a model loading, or a metar change, or a F3 etc To avoid mipmap generation hang, I use dds texture for all the planes in my aircraft folder (with a script), the mipmap are not generated on the fly and the loading is faster (taking less space in ram too). that's why in the paf hangar we are providing both a .png and a .dds version of the planes. So the aircraft pilot sees the tanker quickly move away... accelerate and moves forward... quite un-nerving... And this can happen even without a heavy F3 event... perhaps even due to system thread changes, ie nothing to do with the running fgfs... we call this the rubber band phenomen :D, mainly caused by jitter, and worse if we are not on the same server. So I must take another look at this fill-in code, and would like to hear from the person or persons who implemented it... and understand why the very apparent slide fast forward, and what controls how quickly the position returns to that of the current packets after such an artificial change... any README, links, etc... the current code in AIMultiplayer.cxx got a prediction system, but try to nether use it. this is done to have only an interpolation between two packets to do. so we display the mp plane at least one packet late to have a margin. And then there is how will your 'lag' correction effect this current extrapolation code? If at all... I reused the existing code, with some modifications wich are: - very slow response to jitter: the rubber band phenomen is just a little noticeable, seen as a speed variation of the followed plane. - i'm sending and using planes's accelerations (only for yasim and jsbsim yet), so the position is predicted using position, speed and acceleration with a basic equation. If some are interested i can detail a little more this on the wiki page. if you are using the patch, be aware that non patched yasim planes transmit a velocity in airmass instead of ecef, so they are very shaky if displayed in the futur with some wind. Maybe later try an E-W run, since you do mention some differences depending on direction... this is an effect of the patch with jsbsim aircraft, i needed to find an acceleration suitable, so i added one in jsbsim, but aparently this is not perfect yet, but at 10 pps, it nearly unnoticeable. I guess this should be a jsbsim expert job :) jano -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..is defusedxml useful in FG? Provides another way of memory protection.
Hi, ..is defusedxml useful in FG? Provides another way to protect memory, summary of wishlist bug #705691: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705691 Package: wnpp Severity: wishlist Owner: Luke Faraone lfara...@debian.org * Package name: defusedxml Version : 0.4.1 Upstream Author : Christian Heimes christ...@python.org * URL : https://pypi.python.org/pypi/defusedxml * License : Python Programming Lang: Python Description : XML bomb protection for Python stdlib modules The results of an attack on a vulnerable XML library can be fairly dramatic. With just a few hundred bytes of XML data an attacker can occupy several gigabytes of memory within seconds. An attacker can also keep CPUs busy for a long time with a small to medium size request. This library allows for XML to be parsed in a manner that avoids these pitfalls. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
