[Flightgear-devel] --jpg-httpd command line option
Hello all, I'm a developer using FlightGear in a simulation project for work, and I'm currently getting imagery from FlightGear by triggering screenshots from my application and loading the screen captures from disk. It's kinda Rube Goldberg, but works well enough for a first draft. What I'd /really/ like to do is stream the imagery directly to my application. Googling around, I notice that there's a command-line option to do exactly this! It's not enabled in v2.10, but some more searching and I see that it can be enabled by setting -DJPEG_FACTORY:BOOL=ON in CMake. My question: before I go down that road, does anyone know if the JPG HTTPD functionality works? If yes, does it work well? The fact that it's turned-off by default makes me think that it might not be ready for prime-time. Any advice is greatly appreciated. Regards, Rick Armstrong Portland, OR, USA P.S. We're using Windows 7 VS 2010 and would be looking to build 64-bit binaries. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --jpg-httpd command line option
On 17 Sep 2013, at 10:41, Rick Armstrong waitingfortheelectric...@gmail.com wrote: -DJPEG_FACTORY:BOOL=ON in CMake. My question: before I go down that road, does anyone know if the JPG HTTPD functionality works? If yes, does it work well? The fact that it's turned-off by default makes me think that it might not be ready for prime-time. Any advice is greatly appreciated. It's turned off for build reasons, not because it's new or untested. I believe many people have used it exactly the way you describe. If you encounter problems, they should be easy to fix and patches are welcome! (The build reasons could actually be solved by using OSGDB to write out the files instead of using libjpeg directly - this would mean the feature could be enabled all the time, i.e removed from CMake, and also we could write out PNGs instead of JPEGs if desired - if you have any interested in doing this, I can point you at examples since the screenshot code was converted to do the same thing recently -it's probably a couple of hours hacking at most) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] disable generic-autopilot-helper.xml
Is it possible to disable the loading of generic-autopilot-helper.xml for an individual aircraft? –i.e. without editing the default preferences.xml TIA Alan-- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --jpg-httpd command line option
If someone decides to jump into this, another feature that would be cool would be to stream the display out as a video stream which could then be played by any number of video players on a remote computer (like mplayer.) ffmpeg probably would provide library support to make this pretty straightforward, but I haven't had a chance to dive in and see how easy/hard it would be. One area where this feature could be useful is in UAV research and simulation where you'd like to emulate a live video feed back to a ground station. It could also be fun for sharing/broadcasting your simulator session and probably could be made to work with a web video server. In my own experimentation I've been able to sort of do this by using ffmpeg to capture an area of the screen, encode it as h.264 and send it off to a remote destination as a udp video stream, for example: ffmpeg -f x11grab -s vga -r 15 -b 100k -preset ultrafast -tune zerolatency -maxrate 100k -i :0.0+1,58 -f mpegts -vcodec h.264 udp:// remote.host.name.org:1234 But this requires careful manual sizing and placement of my flightgear window and it would be cool to have this built right in... I've seen other apps that can do this so I know it's technically possible, and I imagine not too much coding once you figure out the magic to make it happen. Curt. On Tue, Sep 17, 2013 at 6:16 AM, James Turner zakal...@mac.com wrote: On 17 Sep 2013, at 10:41, Rick Armstrong waitingfortheelectric...@gmail.com wrote: -DJPEG_FACTORY:BOOL=ON in CMake. My question: before I go down that road, does anyone know if the JPG HTTPD functionality works? If yes, does it work well? The fact that it's turned-off by default makes me think that it might not be ready for prime-time. Any advice is greatly appreciated. It's turned off for build reasons, not because it's new or untested. I believe many people have used it exactly the way you describe. If you encounter problems, they should be easy to fix and patches are welcome! (The build reasons could actually be solved by using OSGDB to write out the files instead of using libjpeg directly - this would mean the feature could be enabled all the time, i.e removed from CMake, and also we could write out PNGs instead of JPEGs if desired - if you have any interested in doing this, I can point you at examples since the screenshot code was converted to do the same thing recently -it's probably a couple of hours hacking at most) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ 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 -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --jpg-httpd command line option
On Tue, Sep 17, 2013 at 6:16 AM, James Turner zakalawe@... wrote: ... It's turned off for build reasons, not because it's new or untested. I believe many people have used it exactly the way you describe. If you encounter problems, they should be easy to fix and patches are welcome! (The build reasons could actually be solved by using OSGDB to write out the files instead of using libjpeg directly - this would mean the feature could be enabled all the time, i.e removed from CMake, and also we could write out PNGs instead of JPEGs if desired Indeed, PNG would be ideal! - if you have any interested in doing this, I can point you at examples since the screenshot code was converted to do the same thing recently -it's probably a couple of hours hacking at most) I'd be happy to take a crack at it. This would be my first foray into the FlightGear source tree, so a pointer to some sample code would be great. Thanks, Rick -- *Information contained herein is subject to the Code of Federal Regulations Chapter 22 International Traffic in Arms Regulations. This data may not be resold, diverted, transferred, transshipped, made available to a foreign national within the United States, or otherwise disposed of in any other country outside of its intended destination, either in original form or after being incorporated through an intermediate process into other data without the prior written approval of the US Department of State. **Penalties for violation include bans on defense and military work, fines and imprisonment.* -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgelev
Hi Tom, On Mon, Sep 9, 2013 at 8:24 PM, Thomas Albrecht wrote: Hi, can someone (Mathias?) please enlighten me about fgelev usage? Skimming through the source, I understand that I need to provide --fg-root and --fg-scenery, but how do I specify which location to probe? I had a quick look at a perl script I wrote a while back to use fgelev: my $elev = `echo 1 -$lon $lat | fgelev --fg-scenery /home/stuart/FlightGear/Scenery/TerraSync --fg-root /home/stuart/FlightGear/data`; I did a quick test, and the first element appears to be an label so the input format is label lon lat\n Then the output is label: elevation You can enter multiple entries on separate lines, and then finish with a Ctrl-D. Hope that helps. -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Textures separation, cleanup
Hello, For the next release (3.0, I think), I want to reduce the size of the installers by making parts of the base package optional. Some are easy, like AI Traffic and ATC chatter - the first time you enable that feature, we'll download (well, terra-sync, really) the relevant files. If you don't use the feature, you don't download the files ever. One large piece (480MB of the base package / fgdata at current counting) is the Textures and Textures.high directories. Originally I believe Textures.high was a partial subset of Textures, at higher resolutions, but that's no longer the case (nor has it been for a long time, I think) What I'd like is: - a baseline texture set that is of adequate, but not high quality (e.g. max 1024x1024 size for landcover, or something else agreed to be good enough) to be included by default in the installers (this would also be friendly to people on older hardware with limited VRAM) - high res (and even, ultra-high res) sets, plus a DDS set for those who want it, which can be downloaded + updated later via terra-sync. (of course we can have discussions about if the default set should be really low quality or quite high - but the point is to have levels we can switch between centrally ) However, my impression is the current switching is done at the effects / material level (especially between DDS and PNG). I.e C++/Nasal code is not involved in any such switching. (Which will need to be changed, assuming it can be) I'm not clear where the texture file names are being referenced from, and how the paths are being searched. E.g, do the shared Models reference these textures, or do they include their own (my impression is the latter, but maybe it's a mix?). If it's not the models, is it 'just' effects/shaders and scenery materials? Do aircraft reference them? And if so, is it via an arbitrary mixture of Textures, Texture.high and DDS paths? I am assuming we would fallback to the Textures/ dir, so I hope the only fixing of aircraft / scene models required would be replacing any references to Textures.high or DDS files. Any hints on how the mechanism is currently working, and how it could work in the future would be interesting. This is a 'look at in the next few months' task, not something I'm planning to tackle next week, so there is no rush. Indeed, if it turns out to be more complex than I realise, it might even be too big to tackle for 3.0, but the first step is to understand how it does work, and how it could work :) Regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures separation, cleanup
Hi James, On Tue, Sep 17, 2013 at 9:56 PM, James Turner wrote: Hello, For the next release (3.0, I think), I want to reduce the size of the installers by making parts of the base package optional. Some are easy, like AI Traffic and ATC chatter - the first time you enable that feature, we'll download (well, terra-sync, really) the relevant files. If you don't use the feature, you don't download the files ever. One large piece (480MB of the base package / fgdata at current counting) is the Textures and Textures.high directories. Originally I believe Textures.high was a partial subset of Textures, at higher resolutions, but that's no longer the case (nor has it been for a long time, I think) snip Any hints on how the mechanism is currently working, and how it could work in the future would be interesting. This is a 'look at in the next few months' task, not something I'm planning to tackle next week, so there is no rush. Indeed, if it turns out to be more complex than I realise, it might even be too big to tackle for 3.0, but the first step is to understand how it does work, and how it could work :) As I'm sure you're aware, most of the space is taken up by Textures[.high]/Terrain The files there should be exclusively used by our terrain definitions under Materials/ - or at least I've made no attempt to keep them consistent for other uses! The actual textures are referenced in the various .xml files under Materials/. The code to do so is in simgear/scene/material/mat.cxx (read_properties). It's pretty basic - looking for a Textures.high variant of the file first, then falling back to a Textures/ directory if it doesn't exist. However, in most cases the textures under Textures/ are very low rez indeed - 256x256. That's a texture typically covering 2kmx2km, so a resolution of 8m/px. I'd be surprised if anyone is deleting the Textures.high directory these days and falling back on them. Note that the files with a mask.[png|dss] are used for object/vegetation placement and are typically low resolution and only in the Textures/Terrain directory. The Textures.high versions are typically 1024x1024 or 2048x2048. Perhaps we could replace the Textures/Terrain with the 1024x1024 versions? That doesn't save us much space overall, but would make having Textures.high optional a more reasonable option. Note that the dds textures are referenced explicitly by a separate Materails/dds/materials.xml file, so an alternative would be to make some of the different materials.xml/Texture combinations as separate packages. I.e. package the basic materials (base/materials.xml and default/materials.xml) in the base package, then make the dds/materials.xml and regions/materials.xml and the textures that only they reference separate. I don't know how much a difference that would make for the non-dds textures though as there's a lot of overlap. Finally, one of the things on my TODO list is improve the organization of the materials definitions. At the moment it's a bit of a mess, relying on a single massive list of materials definitions using condition blocks on each one. I'd like to provide mode structure so we can have more sensible separate definitions. -Stuart -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
