Re: [Flightgear-devel] Query about groundradar Instrument module
On 30 Sep 2011, at 19:52, Michael Robson wrote: Essentially what I am looking to do is create some instruments of my own with some detailed generation of graphical entities that are being continually updated. I am therefore assuming that a 'dynamic texture' is the way to go with this. If there is another way, perhaps better, then I am open to suggestions! Correct, basically. Also note i just added a 'NavDisplay' instrument to Git, which is another kind of dynamic texture, along with ground-radar. It's new, untested code (that's part of my plan for this weekend), but is designed to show navigation type info (route, waypoints, traffic, airports, navaids) in a customisable way, and hence be used to simulate the navigation modes of various modern cockpits. Depending on what you want to do, you might be able to use the code as is, or certainly use it as an example (along with the other render-to-texture instruments) But, be aware I'm still shaking the bugs out - and then I need to write some docs :) James -- 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] Query about groundradar Instrument module
Another way is to use the ZKV1000 instrument. See http://wiki.flightgear.org/FlightGear_Newsletter_October_2010. It is so far in the Hondajet and Diamond DA42 aircraft. I have re-used the moving map code from ZKV1000 in my TSR2 project. The moving map takes a set of map images (in windows these have to be stored in C:/user/yourname/AppData/Roaming/flightgear.org/zkv1000/maps/terrain !!). The code choses which image contains the current A/C position and uses a virtual texture to present a section of this image, shifted X and Y for lat/long, on the moving map display. This method makes use of already existing code in Flightgear. Chase Zakharov for a better description of what is happening. Alan -Original Message- From: James Turner Sent: Saturday, October 01, 2011 9:40 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Query about groundradar Instrument module On 30 Sep 2011, at 19:52, Michael Robson wrote: Essentially what I am looking to do is create some instruments of my own with some detailed generation of graphical entities that are being continually updated. I am therefore assuming that a 'dynamic texture' is the way to go with this. If there is another way, perhaps better, then I am open to suggestions! Correct, basically. Also note i just added a 'NavDisplay' instrument to Git, which is another kind of dynamic texture, along with ground-radar. It's new, untested code (that's part of my plan for this weekend), but is designed to show navigation type info (route, waypoints, traffic, airports, navaids) in a customisable way, and hence be used to simulate the navigation modes of various modern cockpits. Depending on what you want to do, you might be able to use the code as is, or certainly use it as an example (along with the other render-to-texture instruments) But, be aware I'm still shaking the bugs out - and then I need to write some docs :) James -- 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 -- 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] Query about groundradar Instrument module
James, this sounds very interesting. I will check out the code this weekend if I get time and have a look through. I am pretty sure that this is the way I need to go to implement my instument! Alan, that instrument looks interesting. I may be able to use the technique for a 'layer' on my display. Is it essentially 'redrawing' parts of image texture tiles, calculated by position? I think my solution could use the tiled background with a dynamic layer on top. Robbo On Oct 1, 2011 9:40 AM, James Turner zakal...@mac.com wrote: On 30 Sep 2011, at 19:52, Michael Robson wrote: Essentially what I am looking to do is create some instruments of my own with some detailed generation of graphical entities that are being continually updated. I am therefore assuming that a 'dynamic texture' is the way to go with this. If there is another way, perhaps better, then I am open to suggestions! Correct, basically. Also note i just added a 'NavDisplay' instrument to Git, which is another kind of dynamic texture, along with ground-radar. It's new, untested code (that's part of my plan for this weekend), but is designed to show navigation type info (route, waypoints, traffic, airports, navaids) in a customisable way, and hence be used to simulate the navigation modes of various modern cockpits. Depending on what you want to do, you might be able to use the code as is, or certainly use it as an example (along with the other render-to-texture instruments) But, be aware I'm still shaking the bugs out - and then I need to write some docs :) James -- 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 -- 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] Atmospheric haze modelling
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 frame). We blended the bottom of the skydome into the fog color. And then made sure we drew enough tiles to extend at least to the fully fogged range in all directions. This allowed us to hide the seam between the sky and the ground in the fog/haze at the horizon. Yes, as far as I can see, that's the only way this can be done and why the scattering skydome shader never worked with the default terrain shading. As a side note: I've observed that we're currently fading into fog with exp(-d^2/vis^2) where d is distance and vis is visibility where I believe the physically correct behaviour would be exp(-d/vis) Now, the only reason I can think of to do the square fading is that you really get a hard cutoff after d = vis and minimize the amount of terrain tiles you need for a seamless blending. On the other hand, the square fading brings less fog for d vis than there should be, and actually many optical integrals rely on the factorization transmission (layer a) * transmission (layer b) = transmission (layer a + layer b). So I would prefer linear exponential fading. If the hard cutoff is the only rational for square fading, then I'd propose to use exp(-d/vis - 0.1 (d/vis)^6) instead which for any distance d vis gives linear fading and then has a cutoff as efficient as square fading. Please let me know if there's any other reason why the current code is as it is! One problem: tall mountains in the distance would be fog colored and extend visually up into the blue part of the skydome and look weird -- so the original design worked pretty well, but wasn't perfect. I would guess it is visually acceptable to let mountaintops never blend into the horizon fog. In my current design it would be possible to do so, provided the visibility passed to the tile manager is a clever combination of ground and aloft visibility. Maybe that's actually the general solution - pass a function of different visibility properties used by the shader to the tile manager. The simplest solution is to pass the maximum of all visibilities, but that may load more than one ever needs, so probably an angular weighted version dependent on current altitude would be more useful. I can work the math out... as long as it's possible to go for a solution like that. Oh, and we also had some additional code that would change the fog color depending on your view angle relative to the sun ... so at sun set/rise the fog color would be oranger/redder looking at the sun versus looking away from it. I'm currently using gl_LightSource[0].diffuse as fog color - to the degree that sunlight light changes, my version inherits that (seems to be working fine so far). So definitely we should try to figure out how to make your sky model blend with the terrain some how. It *seems* to be doing fine now after I introduced the harder fogging cutoff - above the ground layer, it still uses /environment/visibility-m to keep track of this part of the optical integrals, so the amount of tiles loaded is actually sufficient - but at 50.000 ft or so I rountinely have visibility values of 100 km. For me, Flightgear renders that still stable and reasonably fast (I tried Custom France scenery, Hawaii as well as Pacific Northwest as test cases), and only above 140 km I get unstable behaviour (some of my Blackbird Screenshots were rather difficult). But on slow machines, this'd probably be a show-stopper. But that's not a shader problem but related to the weather code - that can be instructed to provide a cutoff for visibility that is never exceeded. One more thought while I'm writing. The current scattering effect skydome has a glitch/seam at the azimuth. Depending on the time of day it is more or less visible. It can be really ugly, I'd love to get this fixed if you happen to stumble on what's causing it as you play with all this code. I know... I'm really not a shader person, I have just one idea as to what the cause might be (?). I've often observed that the edges of scenery tiles with the water reflection shader have different colors. I have also on occasion seen fog artefacts at just the same position. My theory as to what happens is that the vertices in this case (= the tile edges) are rather far apart, so when the vertex shader is asked to compute an angle for reflection or light scattering or fogging, it must interpolate over a large area because the vertices are far apart. If it interpolates linear, but the quantity to interpolate is (as in this case) non-linear, then in a certain angular regime there must be artefacts. In this case, there'd be nothing wrong with the shader, the vertices would just too far apart to get it right. Now, I have
Re: [Flightgear-devel] Default 3d clouds in Local Weather
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 obsolete. Find var hardcoded_clouds_flag = 0; in Nasal/local_weather/local_weather.nas and change it to var hardcoded_clouds_flag = 1; All the parameters for the layers are in cloud_definitions.nas I've had another look. The property is /environment/wind-speed.kt However, the layer only gets updated when the layer height (/environment/clouds/layer[n]/elevation-ft) is subsequently updated. A similar thing happens with the wind direction. 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? 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] Scenery Creation/TerraGear problems
On 1 Oct 2011, at 03:33, Curtis Olson wrote: That could very well be true ... and I don't think it would be a huge coding change ... but it should be done in a way that bumps up the btg version number and picks a new packet id so as to maintain backwards compatibility with all the existing scenery out there. Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short counts, adding a new version increment and making the values longs looks pretty easy. BUT, if I modify the current Simgear code on 'next', is that the only place that needs to be changed, or is there another copy of this code somewhere in the terragear repo? I know terragear depends on simgear, but I've not looked at which code is actually shared. James -- 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] Scenery Creation/TerraGear problems
On Sat, Oct 1, 2011 at 9:29 AM, James Turner wrote: Just looking at the relevant Simgear code - it already runs through GZip, so I'm not worried about overhead there - and the versioning system looks pretty sane to deal with too. There's already the version check for short-vs-unsigned-short counts, adding a new version increment and making the values longs looks pretty easy. BUT, if I modify the current Simgear code on 'next', is that the only place that needs to be changed, or is there another copy of this code somewhere in the terragear repo? I know terragear depends on simgear, but I've not looked at which code is actually shared. Hi James, the answer is yes. :-) We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Query about groundradar Instrument module
Now that G1000 looks promising, but I get while compiling Atlas on Ubuntu 10.04: make[2]: Betrete Verzeichnis '/media/DATA/FGFS/Atlas/src' make[2]: *** Keine Regel vorhanden, um das Target »MPAircraft.o«, benötigt von »Atlas«, zu erstellen. Schluss. make[2]: Verlasse Verzeichnis '/media/DATA/FGFS/Atlas/src' make[1]: *** [install-recursive] Fehler 1 no rule for making MPAircraft.oAny ideas/help on what to do? In GIT the Honda and DA20 are black/off?ThanksMichael --- On Sat, 10/1/11, Alan Teeder ajtee...@v-twin.org.uk wrote: From: Alan Teeder ajtee...@v-twin.org.uk Subject: Re: [Flightgear-devel] Query about groundradar Instrument module To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Date: Saturday, October 1, 2011, 11:07 AM Another way is to use the ZKV1000 instrument. See http://wiki.flightgear.org/FlightGear_Newsletter_October_2010. It is so far in the Hondajet and Diamond DA42 aircraft. -- 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] Scenery Creation/TerraGear problems
On 1 Oct 2011, at 15:37, Curtis Olson wrote: We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James -- 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] Scenery Creation/TerraGear problems
I think the original intention was to keep the read/write together and centralized so it was easier to keep format changes compatible. That said, I haven't been tracking terragear-cs changes so I don't know what version of simgear they are using or if they've made other changes around this area. Curt. On Sat, Oct 1, 2011 at 10:51 AM, James Turner zakal...@mac.com wrote: On 1 Oct 2011, at 15:37, Curtis Olson wrote: We need to modify the loader in simgear as well as the format generation code in terragear. Right now the indices are packed as 2-byte short ints in the binary .btg file so of course making a change only to the simgear side will do nothing to fix the problem. Whatever we do needs to happen in close coordination with the terragear code in order to make sure that the changes match and are sane and reasonable from both perspectives. Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James -- 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 -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Atmospheric haze modelling
Thorsten -Original Message- From: thorsten.i.r...@jyu.fi [mailto:thorsten.i.r...@jyu.fi] Sent: 01 October 2011 11:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric haze modelling 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 frame). We blended the bottom of the skydome into the fog color. And then made sure we drew enough tiles to extend at least to the fully fogged range in all directions. This allowed us to hide the seam between the sky and the ground in the fog/haze at the horizon. Yes, as far as I can see, that's the only way this can be done and why the scattering skydome shader never worked with the default terrain shading. As a side note: I've observed that we're currently fading into fog with exp(-d^2/vis^2) where d is distance and vis is visibility where I believe the physically correct behaviour would be exp(-d/vis) Now, the only reason I can think of to do the square fading is that you really get a hard cutoff after d = vis and minimize the amount of terrain tiles you need for a seamless blending. On the other hand, the square fading brings less fog for d vis than there should be, and actually many optical integrals rely on the factorization transmission (layer a) * transmission (layer b) = transmission (layer a + layer b). So I would prefer linear exponential fading. If the hard cutoff is the only rational for square fading, then I'd propose to use exp(-d/vis - 0.1 (d/vis)^6) instead which for any distance d vis gives linear fading and then has a cutoff as efficient as square fading. Please let me know if there's any other reason why the current code is as it is! One problem: tall mountains in the distance would be fog colored and extend visually up into the blue part of the skydome and look weird -- so the original design worked pretty well, but wasn't perfect. I would guess it is visually acceptable to let mountaintops never blend into the horizon fog. In my current design it would be possible to do so, provided the visibility passed to the tile manager is a clever combination of ground and aloft visibility. Maybe that's actually the general solution - pass a function of different visibility properties used by the shader to the tile manager. The simplest solution is to pass the maximum of all visibilities, but that may load more than one ever needs, so probably an angular weighted version dependent on current altitude would be more useful. I can work the math out... as long as it's possible to go for a solution like that. Oh, and we also had some additional code that would change the fog color depending on your view angle relative to the sun ... so at sun set/rise the fog color would be oranger/redder looking at the sun versus looking away from it. I'm currently using gl_LightSource[0].diffuse as fog color - to the degree that sunlight light changes, my version inherits that (seems to be working fine so far). So definitely we should try to figure out how to make your sky model blend with the terrain some how. It *seems* to be doing fine now after I introduced the harder fogging cutoff - above the ground layer, it still uses /environment/visibility-m to keep track of this part of the optical integrals, so the amount of tiles loaded is actually sufficient - but at 50.000 ft or so I rountinely have visibility values of 100 km. For me, Flightgear renders that still stable and reasonably fast (I tried Custom France scenery, Hawaii as well as Pacific Northwest as test cases), and only above 140 km I get unstable behaviour (some of my Blackbird Screenshots were rather difficult). But on slow machines, this'd probably be a show-stopper. But that's not a shader problem but related to the weather code - that can be instructed to provide a cutoff for visibility that is never exceeded. One more thought while I'm writing. The current scattering effect skydome has a glitch/seam at the azimuth. Depending on the time of day it is more or less visible. It can be really ugly, I'd love to get this fixed if you happen to stumble on what's causing it as you play with all this code. I know... I'm really not a shader person, I have just one idea as to what the cause might be (?). I've often observed that the edges of scenery tiles with the water reflection shader have different colors. I have also on occasion seen fog artefacts at just the same position. My theory as to what happens is that the vertices in this case (= the tile edges) are rather far apart, so when the vertex shader is asked to compute an angle for reflection or light scattering or fogging, it must
Re: [Flightgear-devel] Atmospheric haze modelling
On Sat, Oct 1, 2011 at 11:13 AM, Vivian Meazza vivian.mea...@lineone.netwrote: Emilian and I have been working on the water shader, and have run into some show stoppers caused by the lack mf vertices in the ocean tiles - there are just 4 so far as we can see, so the junctions between tiles always show up as you speculate. It might be we can do something about this in due course. Hi Vivian, Another interesting thing is to turn on wireframe rendering and you can see exactly where the triangle seams are in the ocean surface. I noticed visual seams in the sea foam and reflections that weren't related to the underlying structure and seemed more likely to be a texture wrapping problem (i.e. one of the textures wasn't fully tileable?) Either that or there is a texture coordinate problem introduced in the latest water effects code. The original ocean auto-gen code was intended to keep things simple and keep polygon counts low. We certainly could generate more vertices in the ocean auto-gen code. That shouldn't be too hard and probably is worth doing now with computers that could easily handle a few more polygons. The challenge would be mating these autogen tiles up with adjacent terragear-generated tiles that are part land part ocean. Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- 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] Query about groundradar Instrument module
From: Michael Sgier Sent: Saturday, October 01, 2011 3:43 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Query about groundradar Instrument module Any ideas/help on what to do? In GIT the Honda and DA20 are black/off? Thanks Michael I hit Ctrl-C to find where the hotspots were and then pressed all the buttons to see what works. The map will not work unless you first generate a set of special format maps using the buildmaps.pl script that is in the ZKV1000\Systems directory. It took me quite a long time to get this working. Perhaps the authors will be along to help. Alan-- 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] Atmospheric haze modelling
Vivian, - Mail original - Emilian and I have been working on the water shader, and have run into some show stoppers caused by the lack mf vertices in the ocean tiles - there are just 4 so far as we can see, so the junctions between tiles always show up as you speculate. It might be we can do something about this in due course. You can use the geometry shader to amplify the geometry if you want to. I used it to build forests walls in the landmass shader. Regards, -Fred -- 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] Query about groundradar Instrument module
From: Robbo Sent: Saturday, October 01, 2011 10:57 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Query about groundradar Instrument module Alan, that instrument looks interesting. I may be able to use the technique for a 'layer' on my display. Is it essentially 'redrawing' parts of image texture tiles, calculated by position? Robbo The map uses the property-base animation (usually used in Livery over MP) to select which image tile to display, and the textranslate animation to pan the image with lat-long. Alan -- 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] Scenery Creation/TerraGear problems
James Turner wrote: Okay, but the relevant source file (sg_binobj) appears to contain both the read *and* write code paths - which is really what I was asking - is the write logic in sg_binobj.cxx the one terragear uses, or 'something else'? James Please be aware that TG uses SG-CS currently. I used it with the normal SG for a while but this was no longer possible recently. It exposed weird behaviour and crashes. Chris -- 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] Scenery Creation/TerraGear problems
Christian Schmitt wrote: Please be aware that TG uses SG-CS currently. I used it with the normal SG for a while but this was no longer possible recently. It exposed weird behaviour and crashes. Indeed, we're still maintaining a simgear-cs for terragear-cs to keep a working source tree as a fallback in those situations when essential features are removed from stock simgear (which already had happened). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Default 3d clouds in Local Weather
On 1 Oct 2011, at 11:25, Thorsten Renk wrote: 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 appropriate aloft layer. -Stuart -- 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] Scenery Creation/TerraGear problems
Martin Spott wrote: Indeed, we're still maintaining a simgear-cs for terragear-cs to keep a working source tree as a fallback in those situations when essential features are removed from stock simgear (which already had happened). http://mapserver.flightgear.org/git/gitweb.pl?p=terragear-cs;a=commitdiff;h=4e9a529b1f0da025c61dc73503cef6d55daa51f5;hp=f68f25e0c5c7477905173ed9a94aa53e5c624719 -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Query about groundradar Instrument module
Ok so I think that I am making some progress here, but what I really need to do is 'register a listener', so that my code can be called for updating the dynamic texture. I have looked, but I am not too sure what to register my object as a listener with, can anyone point me in the right direction? I can see that in 'groundradar' there are two listeners registered, one with radar-range and one with airport, but what i really need is to have my code called continuously as part of the osg::frame! Any help would be appreciated, Robbo On 1 October 2011 18:23, Alan Teeder ajtee...@v-twin.org.uk wrote: *From:* Robbo robbo_b...@hotmail.com *Sent:* Saturday, October 01, 2011 10:57 AM *To:* FlightGear developers discussionsflightgear-devel@lists.sourceforge.net *Subject:* Re: [Flightgear-devel] Query about groundradar Instrument module Alan, that instrument looks interesting. I may be able to use the technique for a 'layer' on my display. Is it essentially 'redrawing' parts of image texture tiles, calculated by position? Robbo The map uses the property-base animation (usually used in Livery over MP) to select which image tile to display, and the textranslate animation to pan the image with lat-long. Alan -- 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 -- 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] flight recorder / replay system
Hi, finally had the time to complete the replay system overhaul. Thanks to everyone providing input. Some people had sent me longer wish lists – unfortunately I'm unable to fulfill all of them - at least not now :). But some things are still high on my list: specifically the option to easily save/load and stream recorded data using a format that doesn't break easily. Also, the option of taking over flight controls at any point during a replay. The latter isn't as easy as it sounds, since most FDMs don't really like being repositioned or even having the speed changed externally. Another thing, since the topic was raised: since FG2.4.0 the multiplayer system is already aware of replay sessions - and already freezes the state. Other pilots are no longer annoyed by remote replay sessions. It's still a good idea though to start the replay only while in a parking position – since other MP players could still see your aircraft squatting the runway or frozen in mid-flight. Now to the overhaul: main improvement is the option of making it work properly with any type of aircraft and any custom properties. The old system only worked perfectly with certain propeller aircraft and piston engines. Important to mention though: by default, nothing changes for existing aircraft. The old system already covered a huge number of properties - but it's impossible to just record everything. I did some tests trying to auto-detect aircraft types and properties to be recorded - but that cannot really work with all aircraft for a number of reasons. And any fixed selection eventually doesn't work perfectly with some aircraft. Hence, it seems a better idea to avoid any kind of guessing and hard-coded logic - and rely on configuration alone. The default, obviously, is the same set as hard-coded for FG2.4 and earlier. The new system is still easy to adapt since several ready-to-use configuration files are available - which simply need to be included, depending on aircraft/engine/.. type. And it's not much more work to customize. For those interested, there's a README.flightrecorder in the Docs folder. There's also a few examples in fgdata showing different levels of customization: the ASK13 (glider), the c172p (prop/piston), the b1900d (turboprop), the UH-1 (helicopter), and the 777-200ER (jet). As announced, I haven't changed the actual replay buffering. But, as someone requested, all buffer properties are now configurable (see /sim/replay/buffer properties). So, if you have enough memory, you could increase the buffer sizes/rates. There's still no configuration GUI for these properties though. The most obvious change though is probably the new GUI dialog: looks like a video player, provides play/pause/skip controls, also controls replay speed. You can also use the 4 arrow keys to control replay (they were useless during replay so far). Finally, since replay can be paused now, it was necessary to move the stop replay key binding to the ESC key (instead of pressing pause twice) – which feels more intuitive to me anyway. Hope some people find all this a bit useful - so have fun. I recommend you take your favourite aircraft for a ride and then replay and evaluate your landing using the new slow-motion support... ;-) And I'm sure you'll let me know when things aren't working as expected... cheers, Thorsten On 04.09.2011 20:56, ThorstenB wrote: Hi, I'm currently looking into an overhaul of the replay system. The buffer mechanisms of the existing replay system itself won't change, but I'm replacing the hard-coded recorder/FDM interface. Instead, I'll introduce a fully configurable flight recorder. It's basically a property recorder, so anything that's in the property tree can be recorded - and replayed. Aircraft-specific XML descriptions can be used to specify properties, data type and interpolation method (discrete, linear, or rotational in degrees/radiant) for each signal. There'll be a set of default property lists which can be included, so only custom properties need to be specified manually. Naturally, all (existing) aircraft not providing any recorder configuration will use a default, matching the hard-coded system of = FG 2.4.0. I have a prototype which also shows the new system is going to be faster, mainly since it doesn't resolve property paths at run-time and avoids copying data around. It'll also use less memory, since most properties can be recorded with reduced precision, e.g. it's unnecessary to record things like flap or gear position with full double precision. And the current system always records properties for 4 engines + 4 propellers + 6 tanks + 3 gear. With the new system, this can be easily adapted - a glider doesn't even need tank/gear/engine/propeller properties. On the other hand, most jet engine properties weren't recorded so far - this will also improve. And the obvious advantage of the new system is the option of recording custom
Re: [Flightgear-devel] flight recorder / replay system
On Sat, Oct 1, 2011 at 5:58 PM, ThorstenB bre...@gmail.com wrote: Also, the option of taking over flight controls at any point during a replay. The latter isn't as easy as it sounds, since most FDMs don't really like being repositioned or even having the speed changed externally. Many (many) months back I had a build of flightgear where there was a bug-feature that actually allowed this to happen. I forget exactly how I triggered it and maybe it is/was still possibleI think it was some magic combo of reset/pause/unpause during a replay. It worked quite well and smooth on some aircraft, I remember shooting an approach over and over again by triggering it. Would be cool to see that work again, as an actual feature this time. :) Another thing, since the topic was raised: since FG2.4.0 the multiplayer system is already aware of replay sessions - and already freezes the state. Other pilots are no longer annoyed by remote replay sessions. It's still a good idea though to start the replay only while in a parking position – since other MP players could still see your aircraft squatting the runway or frozen in mid-flight. Could we have replays broadcast over mp as a hidden option or something, something that is disabled by default? It was actually kind of useful sometimes to be able to see other peoples replays. Having it hidden and/or disabled by default should prevent most/all unintentional bad behavior. And we have the ignore options on MP to get rid of any intentionally annoying people. The most obvious change though is probably the new GUI dialog: looks like a video player, provides play/pause/skip controls, also controls replay speed. You can also use the 4 arrow keys to control replay (they were useless during replay so far). Finally, since replay can be paused now, it was necessary to move the stop replay key binding to the ESC key (instead of pressing pause twice) – which feels more intuitive to me anyway. Hope some people find all this a bit useful - so have fun. I recommend you take your favourite aircraft for a ride and then replay and evaluate your landing using the new slow-motion support... ;-) And I'm sure you'll let me know when things aren't working as expected... This sounds really awesome, really. I'm really looking forward to the future when all aircraft have configured themselves to have flawless replays, instead of being half crippled most of the time like they have been for so long. :) cheers..and thanks! --Jacob -- 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
