Re: [Flightgear-devel] Upcoming Random Buildings changes
On Wed, Sep 18, 2013 at 4:16 PM, Stuart Buchanan wrote: This is to give a heads up on some changes that I'm planning for Random Buildings for the V3.0 release, and to allow for comments/suggestions/ideas. I've now got the new system broadly working on a private build: http://www.nanjika.co.uk/flightgear/buildings.jpg I've managed to minimize apparent tiling by randomly choosing between building sizes and random objects at each point (subject to dimension restrictions). I need to sort out the random objects which need to be rotated by 90 degrees (see the bottom left where an orange school building goes across the road). As expected, the downside is that creating the object masks takes quite a bit longer. It's taken me about 4 hours to generate the mask used here for the city1.png texture. Generating the buildings at runtime is also a bit slower so I expect to implement the PagedLoD next. -Stuart In 2.12.0 the algorithm for the placement of random buildings is a rather scattergun approach. materials.xml sets a building density (amongst other building attributes) which is used to generate a number of random points on each triangle that makes up the scenery. These random points are checked against a mask to ensure they aren't being placed in the middle of roads, and then rotated to the correct orientation to match the texture (using the red channel of the mask). This broadly works, but the placement is fairly unrealistic: - The mask is quite broad, and some buildings quite large, so they can still stick out into the roads, and generally don't line right up against the street. - The spacing of buildings has to be quite conservative. So, in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Creating masks is going to require quite a bit more work in the new world, but the end result should be better. There is an open question of how to handle random object placement, which also use the blue channel of the object mask: - For areas that don't use random buildings, I'm tempted just to leave it as-is for the moment, as it reduces the number of object masks that need to be re-created. - For areas with both random buildings and random objects I'm planning to make groups of objects to specific blue values. So, a blue value of 234 might equate to placing a silo or a farmhouse, while a blue value of 233 might place a church, or tower block. The mapping will be defined in the materials.xml file. Command, questions and offers of help to update some object masks are all welcome :) -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
Hi Tim, On Fri, Oct 11, 2013 at 12:55 PM, Tim Moore wrote: Cool stuff. Are those all individual models, or instanced geometry, or what? :) The vast majority are instanced geometries, though there are some random models interspersed. As mentioned previously, I'd like to move back to the previous implementation from (IIRC 2.8.0) where the buildings were collected into massive objects as it provides collision detection and more variety. On Fri, Oct 11, 2013 at 1:54 PM, geneb wrote: Is it possble to place buildings manually and have the random buildings fill around them without interference? Not yet, but that's a known bug that I would dearly like to fix. I'm hoping that the refactoring required to implement the PagedLOD will provide access to the data required. At present the static objects (e.g. manually placed buildings) are only ingested after the geometry and random objects have already been generated. With the PagedLOD approach the random objects will be generated only when the aircraft gets into range, so I'm hoping I can simply check against the bounding box of each static object. -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60134071iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
On Thu, Sep 26, 2013 at 8:27 AM, James Turner wrote: Just to say, Thorsten has in this case saved me writing an email, thanks. To re-iterate - GPU VRAM is a precious commodity, so we should spend it on texels you can actually see. One further point to make is that we do have the AI/Aircraft directory specifically used for low-poly/resolution models. So, if there are specific aircraft that are causing problems, arguably the correct way to resolve them is to create an AI version. This would be quite a good task for someone wanting to get to grips with modeling, as it's easier to remove things than add them. Perhaps we should mandate that aircraft over a certain size should have an AI version created? -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Help for Aircraft Graphics
Hi Satish, On Thu, Sep 26, 2013 at 10:50 AM, Satish Srivastava wrote: Kindly tell me the platform and code for only simulating the some aircraft like jaguar graphics. My interest is to simulate flight by giving string of aircraft data necessary for flight like velocity, acceleration, roll, pitch, yaw and control surface positions. If you want to use FlightGear to visualize data from another source, there are lots of options. Under the Docs/ directory of your Flightgear installation there will be various README files, and a README.pdf file which is compilation of all of them. Have a look at README.IO and (IIRC) README.generic for information. -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Moving menus (aka, usability)
On Thu, Sep 26, 2013 at 11:45 AM, James Turner wrote: I was reviewing the current menu structure and would like to propose a couple of changes. Partly because we have too many menus, all quite short, but also to remove some bad terminology. Each of these changes is independent, comments explicitly requested: - merge 'Autopilot' into the Equipment menu, as a section (probably the first section) Autopilot is just another piece of equipment, and route-manager and GPS are really parallel features, since route-manger is basically the FMC. The combined menu is still a reasonable length. Aircraft without the default autopilot (including the C172) would need to disable just those menu items, but that's ok OK with me. A while back I introduced a Nasal abstraction layer so that aircraft could disable particular menu items without needing to know the the structure of the menu itself. So, in theory this should be pretty straightforward and not require any aircraft updates. However, I think you'll need to update the Nasal code (in gui.nas IIRC - not at my FG computer right now) so that the autopilot item now maps to the full set of autopilot items. That's slightly ugly, but at least hides this from the aircraft developer. - potentially rename 'Environment' to 'World' This is less of an issue, but makes sense with the next one: - Move the AI items elsewhere -- Traffic / Scenarios move to 'World' menu -- ATC services mode to World or Equipment (opinions requested) -- All the 'controls' for tanker/carrier/wingman also move to world (or somewhere even smarter … unfortunately PUI doesn't support sub-menus) The rationale here is that 'AI' is a completely meaningless term for most users, and the way we use it in FlightGear has long since ceased to be accurate. 'AI objects' are really what is normally called a 'mobile' or 'actor' in most game engines. So the menu needs to either be removed or renamed, and I don't think there's a sane meaningful new name, compared to relocating the items. If most of the AI stuff moves to 'World', I think that name makes sense - it's about things outside your aircraft, which does include tankers, carriers and scenarios, as well as the weather and time/season. I'm OK with this as well. I expect that such large changes will require a significant update to The Manual, so please let me know what the final changes are once you make them and I'll update The Manual code. A separate step, much harder to make happen, would be to explicitly reserve the Ctrl (Command on Mac) keybinding space for menu/non-aircraft keyboard shortcuts. I would really like to do this so we can have user-friendly key-bindings for dialogs and standard items, such as Ctrl-Q to quit, Ctrl-A for autopilot dialog, Ctrl-P for pause, Ctrl-R for reply, etc. [And the entire normal key / key + shift / key+alt ranges available FOR aircraft functions, of course) The problem is right now we have aircraft using Ctrl- shortcuts for many things (usually because they're the only choice), and I can't decide a sane way to migrate to this split without lots of breakage and frustration. Any ideas welcome. I think this is a good idea. I think it would be worth doing this as part of a wider re-org of the keyboard so we only have to re-assign keys on aircraft once. I'm sure there are various keys (time/sim acceleration) that pre-date the GUI and really no-longer need/deserve key bindings for the majority of users. Hopefully that would free up some keys, and allow us to set aside a standard set of keys for aircraft bindings. -Stuart -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Thu, Sep 19, 2013 at 3:07 PM, Renk Thorsten wrote: Which would in fact not make them random buildings at all :-) It'll make them less random, certainly :) However, while the placement and size class (small, medium, large) will now be determined by the texture, there will be still be randomness for each building in terms of width, depth, number of floors and texture. I need to prototype this to understand whether that's sufficient to fool the eye or not. The other avenue I'm looking at is whether the texture scale is correct. IIRC the city1 texture is 1024x1024 and covers a 1kmx1km area. I need to measure some street widths, as I suspect that might be a bit small. It may be that we can increase the texture coverage without increasing the texture size, which would reduce the repetition. Or just decide that cities are important enough to be worth a larger texture. May I propose to think about something more ambitious? One thing which bugs me is that we have now well-working de-tiling strategies for terrain, but not really for city textures and agriculture. Forest is effectively de-tiled by placing sufficiently many random trees on top - but we still get huge tiling artefacts for large city areas or fields. Deterministic 'random' building on top of that will make the tiling problem worse, because you get repeating patterns now in both texture and objects on top, which wasn't the case with the scattergun. I think one could at least partially solve this by subdividing the terrain into individual coordinate cells and give each city texture inside the cell a random orientation of the texture. The template would be the sparse dot noise function introduced in terrain-haze-ultra.frag , but instead of creating the dot position and radius randomly, the routine would just create a rotation angle randomly. I believe this would improve city and agriculture, but for this to really work, the 'random' buildings and trees would have to be shifted by the same function - probaby at placement time. Would it be technically hard to design the system in such a way that this could be introduced? I don't have a function ready yet, but it's something I wanted to give a try at some point with running a distinct shader for 'random' and 'civilized' terrain which needs different types of overlay. At the moment, we use a shader instantiate the buildings and forests to the correct locations. That transformation could be made more complicated to allow for texture rotation. Where it would have more difficulty is in handling the random objects, which are masked as well and would need to be moved. It would also be a bit tricky to make the edges of each coordinate cell look. At the moment, the textures edges tile nicely. I guess we could mirror the translation in the C-code, but it feels a bit wrong. On Thu, Sep 19, 2013 at 5:05 PM, Adrian Musceac wrote: Stuart, this is totally unrelated, but what would be the price to pay to have collision with generated buildings, and Rembrandt shadows? Actually, this isn't completely unrelated... The original random buildings implementation (2.8.0) use basic OSG primitives, and so had collision detection and Rembrandt shadows for free. In 2.10.0 this was changed to a shader-based instance approach based on the tree scheme to reduce the memory footprint which was ridiculously high in places like LA or Tehran. With the shader-based approach, collision detection isn't possible as the building doesn't really exist in the scenegraph. Rembrandt should be possible at the cost of running another shader IIRC. I think I had Rembrandt working for trees, but the cost was absolutely huge. Now, the basic OSG primitive approach has some advantages: - doesn't rely on shader support - allows for more variety in the buildings as one isn't instantiating a small set of buildings multiple times. - the code is simpler - more flexibility in adding complicated buildings such as signage, extensions. If I implement a PagedLOD approach, it might reduce the memory footprint sufficiently that we could switch back to the OSG primitives. Now, all I need to do is find the time to code all of this up!. -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
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Fri, Sep 20, 2013 at 11:15 AM, Adrian Musceac wrote: I think one of the problems is that most of our objects have no concept of different LOD's. If we had objects with say 3 LOD, it would ease memory and graphics load. It should be possible to take an object and generate multiple LOD's for it automatically, but I have almost no knowledge about 3D objects. Might be worth checking it out. While a good LoD system helps with graphics load, it doesn't help with overall memory load (unless it's a PagedLOD), which was the problem with the buildings. We have fairly good LoD solutions for both trees and buildings to help with the graphics loads. For example we display the large buildings are further range than the medium or small. Hopefully people never notice it because it's quite subtle. -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
Re: [Flightgear-devel] Updated 707
On Wed, Aug 21, 2013 at 4:45 PM, Stuart Buchanan wrote: On Tue, Aug 20, 2013 at 8:34 AM, James Turner wrote: Given that Innis has given the all-clear, what is the next step? I'm happy to simply checkout a particular branch from the repo above and commit the files to fgdata, but there are other options. Not sure what the other options are, but a simple checkout and commit to fgdata would be straightforward :). This is now checked into git, with the non-GPL sounds removed. Possible candidate for default aircraft for V3.0? Enjoy! -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] Upcoming Random Buildings changes
Hi All, This is to give a heads up on some changes that I'm planning for Random Buildings for the V3.0 release, and to allow for comments/suggestions/ideas. In 2.12.0 the algorithm for the placement of random buildings is a rather scattergun approach. materials.xml sets a building density (amongst other building attributes) which is used to generate a number of random points on each triangle that makes up the scenery. These random points are checked against a mask to ensure they aren't being placed in the middle of roads, and then rotated to the correct orientation to match the texture (using the red channel of the mask). This broadly works, but the placement is fairly unrealistic: - The mask is quite broad, and some buildings quite large, so they can still stick out into the roads, and generally don't line right up against the street. - The spacing of buildings has to be quite conservative. So, in V3.0 I plan to change this. Instead of using a scatter-gun approach to placement and a mask, random building location will be read directly from the mask, defined by a single pixel. The color (actually blue value from 0-255) will define the size of building (small medium, large), and the red channel the rotation. So instead of a material designer blocking out a large area for random buildings to be placed within, they will define the specific location for each random building. Creating masks is going to require quite a bit more work in the new world, but the end result should be better. There is an open question of how to handle random object placement, which also use the blue channel of the object mask: - For areas that don't use random buildings, I'm tempted just to leave it as-is for the moment, as it reduces the number of object masks that need to be re-created. - For areas with both random buildings and random objects I'm planning to make groups of objects to specific blue values. So, a blue value of 234 might equate to placing a silo or a farmhouse, while a blue value of 233 might place a church, or tower block. The mapping will be defined in the materials.xml file. Command, questions and offers of help to update some object masks are all welcome :) -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
Re: [Flightgear-devel] Upcoming Random Buildings changes
On Wed, Sep 18, 2013 at 4:45 PM, James Turner wrote: It would really help memory use if we could defer tree/object/building generation until the tile is close to the viewer. Right now you generate lots of LOD nodes so we don't pay the rendering cost for distant tiles, but we're still paying a memory cost and loading time hit. I did take a look at the PagedLOD approach - Matthias' code made a great template to work from. One thing I wasn't clear on is whether this would move generation of the trees/objects/buildings from a scenery loading thread into some other thread. I'm not sufficiently familiar with our threading to know if there would be any impact. -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
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
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
Re: [Flightgear-devel] Howto download aircraft ( and others data ) from Git
Hi Alan, On Tue, Sep 3, 2013 at 6:07 PM, Alan Teederwrote: Not everyone lives in a big city with fast broadband and the powers that be seem to bury their heads in the sand when the topic is bought up - as it has been and will be – again and again and again. Can I refer you to Jame Turner's posts at 2:28pm and 5:37pm indicating that he is planning to address this for V3.0 at the end of the year? I may have got lost in the other comments. Unfortunately this is a difficult problem to solve without nasty side-effects. Fortunately we have people like James to do so :) -Stuart -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release candidates
On Fri, Aug 30, 2013 at 11:41 AM, Stuart Buchanan wrote: 1) Windows launcher appears to have Rembrandt enabled by default, but set via the Advanced properties, rather than having a checkbox on the launcher. Makes it quite difficult for a new user to disable it. I would have expected Rembrandt to be switched off by default and with a checkbox on the Rendering Options section of the launcher to enable it. Caveat: It's possible that I've lost a config file somewhere on my Windows system, so if someone else could verify this is the case, that would be great. On Sat, Aug 31, 2013 at 10:04 AM, Vivian Meazza wrote: I've checked RC1 - FGRun here - AFAIKS it just picks up whatever you had last set in Advanced/Properties - I had Rembrandt disabled and that's what I got. Ah good - I suspected that might be the case but couldn't work out where the config was being stored. 2) There appears to be some invalid scenery around lat:37.228, lon:-121.9703. Scenery triangles are white and the UFO can't determine the material type. I'll investigate this further - might be an error in the landclass or something we've got wrong in materials.xml. This looks just like a straight terrain build error. The problem appears to be in bucket 958408. Here's the screenshot, just using the terrain in data/Scenery: http://www.nanjika.co.uk/flightgear/fgfs-screen-057.png Here's the equivalent using current terrasync data, which matches what the mapserver is showing as the data: http://www.nanjika.co.uk/flightgear/fgfs-screen-058.png According to the UFO, the forested terrain for terrasync between the river and the road is one of Landmass, SomeSort, Island, Default, which is slightly suspicious. However, it isn't just that terrain that is missing, as the lake and the town are also not rendered which makes me think this is just a build error. I vaguelly recall that the scenery delivered with the base package is a special case and not simply a copy off the standard world scenery build. Can anyone comment if this is so, or whether we should over-write the base scenery with terrasync as a fix? -Stuart -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On Thu, Aug 15, 2013 at 11:54 AM, Gijs de Rooy wrote: Don't have much time today for further troubleshooting unfortunately; should have some after my last exam tomorrow ;-) Hi Gijs, Have you had the chance to look at this at all, and did Geoff's suggestion help? Do we have any active Win developers around who can help fix this? On a related note, once the build problem is resolved, could we generate a full installation RC package for testing? It would make it easier for testers not familiar with Git to use it, and would be quite handy for people like myself who do their development on Linux, but have Windows systems available for testing but without the git infrastructure or the time to download the entire git fgdata repository. Thanks, -Stuart -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On Wed, Aug 21, 2013 at 3:51 PM, James Turner wrote: On a related note, once the build problem is resolved, could we generate a full installation RC package for testing? It would make it easier for testers not familiar with Git to use it, and would be quite handy for people like myself who do their development on Linux, but have Windows systems available for testing but without the git infrastructure or the time to download the entire git fgdata repository. Once the build is fixed, Jenkins should do exactly that - that's part of the automation work I did for 2.10 - Jenkins will produce the complete install EXE, someone just has to grab it from Jenkins and upload / mirror / seed it as they see fit. That's great work, Now all we need is someone with enough Windows knowledge to fix the build. [1] 'where there's smoke there's fire', this is old terminology from the Netscape/Mozilla TinderBox engine. I'm pretty sure the smoke test predates Tinderbox. I came across it when working for Xilinx in reference to hardware testing where the first test is to attach a power feed and check that nothing started giving off smoke :) -Stuart -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated 707
On Tue, Aug 20, 2013 at 8:34 AM, James Turner wrote: Given that Innis has given the all-clear, what is the next step? I'm happy to simply checkout a particular branch from the repo above and commit the files to fgdata, but there are other options. Not sure what the other options are, but a simple checkout and commit to fgdata would be straightforward :). However, Marc wasn't sure whether some of his audio files were GPL compatible, so I think we need to wait for him to remove them before proceeding. Marc - Is that OK ? -Stuart -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some Help
Hi Ante, On Fri, Aug 9, 2013 at 7:21 AM, Ante Cugura wrote: I have recently downloaded FlightGear, and am enjoying it, but I seem not be able to download some aircraft. Even when the program says I have downloaded the aircraft correctly, when I go to use the aircraft, it comes up with a small blue and yellow plane. Also, with the plane which do successfully download, I am not able to get it in the livery which I want, even when it says that I can get it on your website. I use a MacBook Air laptop, and it would be greatly appreciated if you were able to provide some help. How are you running the simulator? From the command line or from a launcher? if you are running from the command-line, can you post your command-line here? Unfortunately I don't run a Mac myself, so I may not be able to provide very specific help on this. You might want to post to the FlightGear forums (http://www.flightgear.org/forums/) where there may be more people who can help. -Stuart -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Updated 707
Hi All, Marc Kraus (CC'd as he's not on the -devel list) has produced a (very) significant update to the 707, a model that Innis Cunningham developed a number of years back. It's available from http://gitorious.org/boeing/707 and is well worth a look, particularly for the fine cockpit and engineer station with extensive start-up tutorial. Marc has asked if it would be OK to replace the existing 707 with this new one. Innis (if you're around) - are you OK with this? If Innis is not around, does anyone have any problems with adding this? If replying - please Reply-All to include Marc in this discussion, Thanks, -Stuart -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
Hi Pat, On Wed, Aug 14, 2013 at 1:11 AM, Pat wrote: One reschedule is a good idea. Would an indefinite delay, with a promise republishing the schedule by a given date be appropriate or desirable? An indefinite delay would risk the release never being completed, and we'd be back where we were before with big gaps between releases. A defined delay gives us all something to aim for :) Plus we want to get this release completed so we can start on the Christmas release, tentatively named 3.0.0. -Stuart -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On Tue, Aug 13, 2013 at 9:38 PM, Torsten Dreyer wrote: Permission granted ;-) As everybody seems to be caught in some real life trouble, I can't see a better way to get the release out than delaying it for a while. Would two weeks be enough for everybody? That will get us to the weekend Aug, 31/Sep 1. I propose pushing out the release by a month. I've got a bit more time available for FG right now, but not as much as I did 12 months ago, and it sounds like James and Thorsten R are similarly time limited. I think it will take longer than usual to address any issues found in the RCs. If we are going to slip the release, we should only do so once :) -Stuart -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
Hi James, On Wed, Jul 24, 2013 at 10:07 PM, Stuart Buchanan wrote: As an FYI, I'm still working on some final updates to The Manual that I want to get committed to the 2.12.0 branch. These have now been committed to master (e87379c). James - if it's convenient could you pull this to the 2.12.0 release branch please. -Stuart -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On Wed, Jul 17, 2013 at 8:38 PM, James Turner wrote: Hi, I've just created the release branches for FG, SG data (at Torsten's request, since he's on holiday in the wild, Internet-less north of Sweden). Thanks James. As an FYI, I'm still working on some final updates to The Manual that I want to get committed to the 2.12.0 branch. -Stuart -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Changelog 2.12
On Mon, Jul 15, 2013 at 9:22 PM, Gijs de Rooy wrote: Hi Stuart, thanks for the improvements! Checking the diff I do wonder if you removed the Microsoft SideWinder Precision Racing Wheel (rudder) pedals line on purpose? Vivian added this one in March... https://gitorious.org/fg/fgdata/commit/9dcb78c2248 Good spot. That was a mistake. Now corrected. -Stuart -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
On Fri, Jul 12, 2013 at 2:54 PM, Stuart Buchanan wrote: Ah, that's my mistake. To avoid .git files corrupting each other, I downloaded your new version as a tarball from gitorious and then copied it over the existing aircraft. Of course, that wouldn't have deleted the removed files. I'll do another clean up when I get a chance over the weekend. No problem. This is now done. Apologies to future generations for the mess in the git logs! -Stuart -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Changelog 2.12
Hi All, I've just taken a trawl through the git logs to find the major enhancements from the last 6 months, the results of which are now in the Changelog: http://wiki.flightgear.org/Changelog_2.12 Comments welcome, particularly on what should be mentioned in the highlights section at the end of the first paragraph: The FlightGear development team is happy to announce the v2.12 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include improved usability, continued development of the Canvas rendering toolkit, and improved scenery rendering. I'd also like suggestions of other new or majorly improved aircraft that have had particular updates over the last 6 months. I'm also not sure whether or not we should include tooltips in the feature list. They are currently switched off by default in preferences.xml and can only be switched on from within the Debug menu. James - are they now mature enough that we should switched them on by default? On a related note there's also the question of the mouse modes to consider. I no-longer use the old-style mouse modes, instead using the right-click-to-pan-view mode instead. Should that be available through the GUI (in which case I've got to re-write various parts of The Manua) Thanks, -Stuart -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
On Fri, Jul 12, 2013 at 12:52 PM, grtuxhangar team wrote: Hello,Stuart Sorry for the huge mistake, thank a lot for the fix, and the time you spent on it. However, when looking at the http://www.gitorious.org/fg/fgdata/trees/master/Aircraft/F-8E-Crusader and http://www.gitorious.org/fg/fgdata/trees/master/Aircraft/PBY-Catalina I notice there is a lot of old outdated files which are longer there ( especially textures.rgb files ). Our updated versions within the https://gitorious.org/eekpo, do not contains these old files. Ah, that's my mistake. To avoid .git files corrupting each other, I downloaded your new version as a tarball from gitorious and then copied it over the existing aircraft. Of course, that wouldn't have deleted the removed files. I'll do another clean up when I get a chance over the weekend. No problem. The process we are working with are surely wrong to you. When we are working on updates what is the best way to help you ? How could we help you to synchronize those updates within fgdata. ? A merge request to fgdata would be easier for me to handle, but that would mean you have to download the full fgdata. On Fri, Jul 12, 2013 at 2:40 PM, Gijs de Rooy wrote: What I always do when I get update packages instead of merge requests is to delete the aircraft locally (not in Git) and then add the new package. That way you will clearly see all deleted files, renamed case-insensitive files etc. Good tip! I'll try to remember to do that next time. -Stuart -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
Hi Ahmad, On Thu, Jul 11, 2013 at 12:30 PM, grtuxhangar team wrote: Hello, Stuart , Thank for your kind effort about it. Since we have again uploaded a new version within our Git Project https://gitorious.org/~eekpo, and since we can't check the actual content of your official fgdata Aircraft directory ( like said we don't have any high speed communication line so too much large for downloading ,), it could be better to update both aircraft with the entire content from: git clone g...@gitorious.org:eekpo/f-8e-crusader.git git clone g...@gitorious.org:eekpo/pby-catalina.git Sorry for the difficulty that we are introducing there , as long as the fgdata is not split in part with individual aircraft ( there was a project, is it given up ? ), we can't be helpful. I've committed the latest set of changes. I made a couple of small corrections to the PBY-Catalina in passing as there were some references to Aircraft/PBY6_Catalina that needed to be changed to Aircraft/PBY-Catalina Thanks again for your contributions. -Stuart -- See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
Hi Guys, A 30 second thought on this: On Tue, Jun 25, 2013 at 10:58 PM, Curtis Olson wrote: Once we clear past the 2.10, 2.12, etc. series, I'd like to go back to keeping things single digits in the major and minor version numbers and when we run out of a single digits bump up the major number (so 3.8.x - 4.0.x). Number are numbers, but this one confused a lot more people than I expected it would or should so maybe it's good to be sensitive to that after we clear the 2.x series of versions. That sounds OK to me, as it would imply a full release every 2.5 years, give a clear flag ahead of time when we're nearing a major release, and save having these discussions in the future. For reference, with the current plan there will be 4 years between 2.0.0 (Feb 2010) was and 3.0.0 (Feb 2014). -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
Hi Ahmad, On Thu, Jul 4, 2013 at 2:28 AM, grtuxhangar team wrote: Hello, Crusader: After check out , we have found some other mistake, landing gear and catapult related. =The landing gear did not behave correctly on water ( it should not take any water solid ). =The catapult force was too weak. the F-8E-Crusader/Systems/landing-gear.xml and F-8E-Crusader/Systems/catapult_free.xml are updated git clone g...@gitorious.org:eekpo/f-8e-crusader Catalina: Same error than Crusader landing gear against water ( only the sea was right ) It want also an update PBY-Catalina/Systems/landing-gear.xml git clone g...@gitorious.org:eekpo/pby-catalina.git Sorry for that huge noise. Thanks for letting me know about the updates, and sorry for the late response. I should be able to look at these later this week. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
On Mon, Jul 1, 2013 at 1:20 PM, grtuxhangar team wrote: Hello, Back to the topic, since it was not a bug our models related, but only an FG/OSG consistency issue, you may update fgdata/Aircraft/F-8E-Crusader and fgdata/Aircraft/PBY-Catalina, both should be right with the coming FG 2.12 . git clone g...@gitorious.org:eekpo/f-8e-crusader.git git clone g...@gitorious.org:eekpo/pby-catalina.git Thank for the FG Fix Hi Ahmad, These aircraft have now been committed to fgdata. Thanks very much for your work. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
On Wed, Jul 3, 2013 at 10:55 PM, Gijs de Rooy wrote: It can be useful to remove F-8E-Crusader/Models/Textures-hires/texture12F/afterburn.png ( which is less eye candy ). Done. Thanks! Thanks for spotting and sorting this out Gijs. I missed it in my review. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] some models updates available
Hi Ahmad, On Sat, Jun 22, 2013 at 3:06 PM, grtuxhangar team wrote: Hello, One of our member within our grthteam has been working on updates gpl compliant regarding some old models which were done by Gérard many years ago. You may find these models updated at https://gitorious.org/eekpo snip you may get them with git clone g...@gitorious.org:eekpo/f-8e-crusader.git git clone g...@gitorious.org:eekpo/pby-catalina.git I was planning to merge these into fgdata this evening, but they appear to have been deleted last night. Are you planning to re-release them? If so, please let me know so I can get them into fgdata. It would be great to have both these aircraft updated for the 2.10.0 release. Thanks, -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On Mon, Jun 24, 2013 at 10:41 PM, Torsten Dreyer wrote: Collecting the arguments from this discusson, I can see good points for a 3.0.0 release. Most convincing was Stuarts comparison against 2.0.0 and the progress we made since that version. My suggestion is, we dare to call the 2013 summer edition FlightGear 3.0.0 and we bump the version number later this week. I'll leave that discussion open for a few days and hope we can agree on the new number. Having thought about this a bit more I'm going to propose we do 2.12.0 now and pre-announce 3.0 as the Feb 2014 release to give us just a little more time to prepare and make the 3.0 as polished as possible. After all, it'll be the third major release in 15 years :) . We currently have about 3 weeks before the release branches are cut, and we'll have some 7 weeks for bug hunting. For a 2.12.0 release, that's business as usual, but I can imagine that many aircraft developers in particular would want to perform some extra TLC before a major release. Externally, 3.0 is going to be considered a bigger deal than 2.12.0. Declaring that the Feb 2014 release will be 3.0 now will give everyone plenty of notice, and might encourage efforts to fix bugs in the next 6 months. I'm aware that my FG development time is more limited these days, and given activity on this list I suspect I'm not alone, so this time might be quite useful. Whatever way we go, I suggest that we zero-pad the minor release digit after 3.0.0 so we have 3.02, 3.04 etc. to reduce confusion if we reach double digits. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On Thu, Jun 20, 2013 at 11:57 AM, Renk Thorsten wrote: - ALS now works much better with the random trees. I think there's still work to be done with other shaders (presumably the wake shader has still to be ported?) Yes (if that is really a major holdup, I can probably do this within the next weeks if it makes Vivian smile :-) ...). I don't think it's a major hold-up, but it would be nice to get it resolved. A more significant problem in my view are the lights which apparently don't go via any shader, so they fog wrongly, and the visibility of the sun below the skydome-drawn horizon or through dense fog - from Fred's answer I gather that they would require some source code work. Ah yes. I remember you mentioning this before, me saying I'd add it to my TODO list, and then failing to do so. Sorry. I've now added it to my wiki TODO list so I don't forget again. Are you thinking about the sprinkling of lights that we put over the terrain, the VASI/PAPI lights, or the approach lights. Or all three? :) -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Rembrandt Investigations
Hi All, I spent a little time this weekend looking through the Rembrandt shader code to gain some familiarity and (naively) see if I could find any obvious performance improvement, in particular by unwrapping loops/if tests, as Rembrandt is just a little too slow on my machine to be usable. Unfortunately most of my efforts actually made things worse, often by a factor of 2. Evidently modern GPU GLSL compilers are more advanced than I had thought, and I should be a little more humble in the future! However, I did notice a couple of things I'd like to get comments on, mainly from Fred I suspect. 1) Shaders/ssao.frag: This is the fragment shader for Ambient Occlusion. Line 54 starts a FOR loop that only executes once. I don't know enough about the shader to say whether it's a straight bug and should execute 4 times, or whether it's correct and the FOR loop can be removed. Can anyone confirm? 2) Shaders/sunlight.frag: I think I can remove the if() tests at the end of the shader (around line 95), so float cosAngIncidence = clamp(dot(normal, lightDir), 0.0, 1.0); float blinnTerm = clamp( dot( halfDir, normal ), 0.0, 1.0 ); if (cosAngIncidence 0.0) Ispec = pow( blinnTerm, spec_emis.y * 128.0 ) * spec_emis.x * fg_SunSpecularColor.rgb; float matID = texture2D( color_tex, coords ).a * 255.0; if (matID = 254.0) Idiff += Ispec * spec_emis.x; can be replaced with the following code: float blinnTerm = clamp( dot( halfDir, normal ), 0.0, 1.0 ); Ispec = step(0.0, dot(normal, lightDir)) * pow( blinnTerm, spec_emis.y * 128.0 ) * spec_emis.x * fg_SunSpecularColor.rgb; Idiff += step(0.996, texture2D( color_tex, coords ).a) * Ispec * spec_emis.x; // 254: Water, 255: Ubershader This doesn't improve the performance on my machine by a significant amount, but it would seem worth doing. 3) From reading Effects/sunlight.eff, I don't think sunlight.frag is ever executed with filtering == 1, (that's what sunlight-nofiltering.frag is for), so the if() test on line 70 can be removed. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On Thu, Jun 20, 2013 at 9:29 PM, James Turner wrote: Emilian has explained on IRC this might be due to the out-of-the-box / default config for Rembrandt being highly suboptimal, which I didn't yet evaluate, I would be delighted to have it more usable. I'm going to test further over the weekend. BTW, from a quick look at the relevant shaders, there are a couple of if tests that might be worth factoring out if possible: gbuffer-functions.frag: 64 gbuffer-encode.frag: 21 Both of these seems to be related to a configuration property uniform, and I wonder if the if() test itself is having significant cost. Like you and Thorsten, I see a very significant drop (50%) in frame-rate with Rembrandt, even without most the nice features such as shadows which has put me off using it. I had thought it was just because my box is now underpowered (the march of technology) but it sounds like other are seeing similar issues and it would be worth some further investigation. I'll have a play over the weekend when I get the chance. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On Tue, Jun 18, 2013 at 11:08 PM, Kleo G. wrote: ALS already has an ON/OFF selection button. Wouldn't it be useful for Rembrandt to also have such a button, thus being able to switch it on or off either without restarting the sim?? It would skip all the inconvenience of restarting the sim for activating Rembrandt. Hi Kleo, I don't think that is possible, as Rembrandt requires a particular graphics pipeline to be set up that can only be done at startup. -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] reminder: entering feature freeze now
On Tue, Jun 18, 2013 at 7:40 AM, Renk Thorsten wrote: What version number will we give to the new release? Are we ready for a 3.0 or is it 2.12? Looking through my list of goals for the last coding period: I also had a look through the 3.0 backlog article (http://wiki.flightgear.org/FlightGear_3.0_backlog), and I was pleasantly surprised at what I was able to tick off: - We now have a unified weather UI that is much more usable. Thanks to Vivian for his help on this. - ALS is now integrated with Basic Weather. While it can't leverage all the features that ALS provides, it's good enough that IMO we have now managed to make the rendering model and weather models independent. - ALS now works much better with the random trees. I think there's still work to be done with other shaders (presumably the wake shader has still to be ported?) So, I think we've managed to polish many of the rough edges, which is good. Vivian wrote: A nice list and it's all worthwhile improvement, but it's all tinkering around the edges of existing stuff. There's no step change which would justify 3.0 IMO. For that we need something major, like new terrain (850) or Rembrandt as the default. Perhaps we should instead look at 2.0.0 as the baseline rather than 2.10.0 and think in terms of the maturity of the features added since that point. With a 6 month release cycle, it's extremely unlikely we'll suddenly have a new feature spring fully-formed in a release - instead we'll have experimental features mature over a period of releases as we've seen with Rembrandt, canvas, ALS. For example, ALS is now pretty mature, and in general our eye-candy has moved on significantly from 2.0.0 (object masking, random buildings, regional textures etc.) Perhaps we should do the work required to make ALS the default, and declare that 3.0? It's not a completely facetious question. I've been wondering whether we should deprecate the standard rendering model (non-ALS, non-Rembrand), and instead have ALS as the default, with a modification so that the lowest quality level matches the lowest quality level of the standard model. Obviously we'd need to do some work to port any remaining standard rendering model features (wake shader?) across. At higher quality levels, I don't think that the standard model is as developed or mature for terrain in particular, and some of the features such as the urban shader have been rendered (pun intended) obsolete by other developments. That would simplify matter from a user perspective, and make it easier for them to achieve graphics similar to the screenshots we publicize. Of course, that is a completely different approach to non-OSS software development, were the X.0.0 release is a bug-ridden mess and the point releases improve quality. :) -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] trees
On Tue, Jun 18, 2013 at 8:22 PM, Vivian Meazza wrote: Syd, We fixed that bug a while back, I hope J. Could you rebuild with the latest FG/SG and try again with the latest FGDATA? I really hope that fixes it! Me too! Syd - if it doesn't fix it, can you let me know the following: 1) Are you seeing this for all forested areas (e.g. around KHAF)? Or is this specific to explicitly placed trees in the scenery? 2) Any errors on the console? 3) What rendering settings do you have? Thanks, -Stuart -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] suggest: divide getstart each language
HI Kiyohito,
Thanks for your interest in the manual.
We made the decision to keep the manual as a single set of source
files with blocks for each language so that the different translations
staying in sync and to make it easy for translators to update a single
section at a time.
Otherwise, it's too easy for the Finnish translation to be out of date
relative to the English version when the latter is updated with the
latest menus.
We didn't consider machine-assisted translation at the time, though
OmegaT looks like a very useful tool.
However, if someone is motivated enough to provide a complete
translation of existing manual in a given language, I'm sure we can
find someone motivated enough to convert it to the existing format if
required.
-Stuart
On Mon, Jun 17, 2013 at 10:38 AM, K.Aoki
athlon64x2.windsor.6000p...@gmail.com wrote:
Hi All,
Sorry, forget before my mail. That's mistake.
I suggest that we divide getstart each language, reason: More easier
to use Computer-assisted translation tool, e.g. OmegaT
--
My suggestion detailed are below. (example from preface.tex)
now:
getstart/source/*.tex
[code]
\iflanguage{english}{Did you ever want to fly a plane yourself,
but lacked the money or ability to do so?...}{}
\iflanguage{french}{N'avez-vous jamais voulu piloter un avion
par vous-m\^{e}me, mais manqu\'{e} d'argent ou de comp\'{e}tences pour
le faire ?...}{}
[/code]
future:
getstart/source/en/*.tex
[code]
Did you ever want to fly a plane yourself, but lacked the money
or ability to do so?...
[/code]
getstart/source/fr/*.tex
[code]
N'avez-vous jamais voulu piloter un avion par vous-m\^{e}me,
mais manqu\'{e} d'argent ou de comp\'{e}tences pour le faire ?...
[/code]
--
Kiyohito, AOKI
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, May 16, 2013 at 11:02 PM, Vivian Meazza wrote: I'm going to have one more attempt to fix the black hat in a square texture before looking into reducing the number of variations. Yup, works nicely here, there's definitely an improvement. I've also modified the predicates for techniques 4 and 9 take that into account I've also fixed the black hat by increasing the bleed margins in treebin.cxx a tad: t-push_back(Vec2(variety + 1.0f, 0.234f)); t-push_back(Vec2(variety, 0.234f)); I'm using the old square texture - that would need adjusting because those margins clip the top of the higher trees. All looking really good here now. Thanks for the pointer. I've committed a change using the reduced UV coordinates, converted all the tree textures back to squares and ensured they have an appropriate spacing at the top. -Stuart -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, May 16, 2013 at 8:58 AM, Vivian Meazza wrote: I'm rather surprised that you can't see the black outline around the trees. It's around all of them, but is more or less visible according to the range and angle of incidence. It is also the cause of the spike arising from the centre of the trees. The proximate cause of the black outline is alpha-to-coveragetrue/alpha-to-coverage. Commenting out techniques 4 and 9 in the tree effect removes all black artefacts. There's a bug in the predicate for technique 4. It should only be enabled if you have ARB_multisample, but is incorrectly being enabled if you have shader language 2. I've got a fix for this that I've still to push. However, I think this issue predates my recent tree changes, though they may have exacerbated them. Were you seeing black borders around the trees before I started messing around with them recently? My system supports ARB_multisample, and IMO it provides quite a good effect at normal tree viewing distances. I'm slightly surprised that Thorsten's new system doesn't support this, as evidenced from his screenshots. Interestingly, when I disable technique 4, I start seeing the black outlines. Evidently there some very GPU-specific things going on here. On the plus side, I can at least reproduce the issue! I _do_ have a good fix for the black outlines in general, and I've modified the current textures to use it. I just need to push it - hopefully tonight. While alpha-to-coverage is intended for dense foliage or grass, I'm not sure that it is appropriate for our trees as presently drawn and textured. I think you are right to try to go back to the square texture. I hope that you can find a fix for this - Unfortunately modifying the mipmap didn't help. Partially disabling mipmaps by setting nearest meant that trees in the medium-far distance look very pixelated and artificial, and I've been unable to get the mipmap alpha channel to work. know how difficult it is to fix a bug that you can't yourself see. In the meantime should we consider reverting to the previous scheme in fgdata while you come up with a fix? Here. I've adjusted the bleed margins and commented out the relevant techniques, which produces nice trees. Let me check in the stuff I've done so far once I run a couple more tests this evening. That should fix the issues you are seeing. However, that still leaves us with very long, thin, textures as I can't see a way to go back to the square textures without causing the black hats. If we want to stay within a total texture size of 4096, the long, thin texture limits us to a maximum individual tree texture of 128x256, as there are now 32 textures in a typical sheet (8 trees, each in summer, summer+snow, winter, winter+snow variants). I think that a 128x256 texture for an individual tree isn't quite enough. While we don't need to go bird-spotting, it's not unreasonable to expect the tree to look good if it fills the screen. So, I think we have the following options: 1) Forget the whole thing. Revert back to the previous model of having one texture for summer and one for winter, no support for snow-covered trees. I'd still commit changes to fix the black outlines and technique=4, so the effort won't have been completely wasted. With a 4096 texture sheet limit we'd be able to have 512x1024 individual trees. 2) Support dynamic changing of snow-cover on trees, but not season changes. This means that to see a winter deciduous tree one would need to change the season and reload the scenery, loading in the winter material definitions which would include both the tree texture and general ground textures. Thorsten R. - what are your plans for ALS support for winter? I think you currently use the summer materials, correct? This would allow 256x512 individual trees. 3) Support dynamic changes of season, but have no support for snow-cover on trees in the texture itself. This is my probably my preferred option. While having snow-covered trees is nice, the actual circumstances when it occurs are fairly minimal as the snow is blown off the trees by the wind. This would allow 256x512 individual trees. 4) Accept the limitation of 128x256 individual tree textures. Let me know what you think. -Stuart -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osm2city.py
On Mon, May 13, 2013 at 9:29 PM, Thomas Albrecht wrote: If I had a limited number of complex (as in 8 vertices per model) shared models, and place a total of 5 instances in a scene, could this be made to occupy significantly less RAM than 5 individual models? In theory yes - that's what the SHARED verb on the .stg file is for. The idea was to only have one model loaded, and then place it multiple times in the scenegraph. However, IIRC there was an issue with memory management in OSG which meant that when a tile containing SHARED entries was unloaded, it caused FG to churn for a while updating various pointer counters. I don't think this was ever resolved, so currently each SHARED instance is loaded individually. While this approach would reduce RAM usage, it would be at the expense of frame-rate, as the 5 models would still each require OSG state change. Sadly, nothing is for free :(. -Stuart -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, May 16, 2013 at 10:28 AM, Renk Thorsten wrote: I'm slightly surprised that Thorsten's new system doesn't support this, as evidenced from his screenshots. glxinfo claims that it does - I get several instances of GL_ARB_multisample or GLX_ARB_multisample shown in the resulting list (at least under Linux, maybe it's a bug in the Windows driver of the card only??? - I'll check next time I boot up Windows). Someone pointed out to me off-list that there are other control properties for multisampling, which I had set in my .fgfsrc file and had forgotten about completely. I've updated the effects file to check for these. I'd highly recommend setting them as I think they improve the visuals on the vegetation significantly: /sim/rendering/multi-sample-buffers=true /sim/rendering/multi-samples=2 I've just checked in something that should fix both issues, along with .xcf source files for the existing trees that shows how they should be created, and a little perl script to generate .dds and low resolution .pngs from a source .png file. I'm going to have one more attempt to fix the black hat in a square texture before looking into reducing the number of variations. -Stuart -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Hi Vivian, On Sat, May 11, 2013 at 9:57 AM, Vivian Meazza wrote: That works - the hat artefact is gone. If I look very carefully I can see a vertical artefact emanating from the centre top of some trees. I hadn't realised that the high res texture was going to be quite so big. Texture sizes 4096 px are not so well supported. I wonder if you wouldn't be better disabling mipmapping for trees - it seems to be the source of all the problems? In particular, the different grazing angle on the crossing panels means that different mipmaps will be used. I can't disable mipmapping AFAIK, but I spent some time looking at the effects source code and found an undocumented (well, not in README.effects) option to control how the mipmaps are generated for each of the RGB and alpha channels.* So, it would appear that I can generate a mipmap where the alpha value is taken as the minimum of the surrounding pixels while the RGB values are created normally. I need to experiment some more with it later in the week, but I may have found a way to use a more square texture without artifacts. It should also resolve the artifact you mention above. In passing I noticed that both your and some of Thorsten's screenshots show a nasty black outline around some of the trees. I don't see that myself except, but I've also got a fix for that issue. As mentioned on the forum, the problem is that the completely transparent pixels have an RGB value of 0,0,0, so mipmaps and interpolations cause this to bleed into the surrounding edges. -Stuart * Kudos to Tim Moore for exposing this - who would have thought we could control how the mipmap of a texture is generated on a per-channel basis through XML? :) -- AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] osm2city.py
Hi Tom, On Sun, May 12, 2013 at 9:35 PM, Thomas Albrecht wrote: Dear list, in particular Stuart, please let me 'officially' announce my project osm2city.py [1,2] here. This python script takes OSM floor plans and generates 3D buildings for use with flightgear. I'm planning to develop this into a procedural city generator which would take a street network and then reasonably places (random) buildings. The ultimate goal is (obviously) to improve FG's representation of cities. It's at a rather early stage, and for the moment I prefer python for quick prototyping. BUT, I know quite some C/C++, and compile from latest GIT sources regularly. In the future, I'm definately willing to move this into FG (in one form or another). Tom [1] http://wiki.flightgear.org/Osm2city.py [2] http://flightgear.org/forums/viewtopic.php?f=5t=19625 To echo what others have said - this looks fantastic, and a major step forward from the autogen buildings that we have at present. I look forward to it making my work redundant! Based on my experience with the random buildings I think that pre-generating the buildings as you are doing at present is a better approach than trying to do things at runtime. There simply isn't enough information available in the tile loader to run a complex algorithm at run-time, and even if we could, my experience has been that the perf impact is too great. For example, we generate random buildings on a per-triangle basis (which allows us to determine the position on a plane and avoid an expensive height query). They cannot overlap the edges of the current triangle, as we can't tell what the terrain is on the other side of the triangle edge. This means you can see odd streets leading to vertices in the terrain mesh. Very distracting when you start spotting them... As you mention on the wiki page, memory occupancy is a big issue. The original implementation of random buildings used OSG primitives to generate a geometry for an entire tile at once. IIRC that was around 10GB for the LA area, and I'd expect the more complex buildings you're generating to need significantly more. As the random buildings are pretty simple I was later able to shoehorn them into a shader approach and improve memory occupancy significantly, but I don't think that'll work with the complexity of buildings you have. Since then Matthias modified the tile loader with an LoD callback, so that model aren't all loaded at the same time as the tile - only when you get close to them. That should help a bit, and might make the memory cost palatable for large cities. I think it would be worth having a discussion with the scenery DB owners about this as part of the scenery DB, automatically generating buildings as OSM data improves and/or the scenery shapefiles are changed. -Stuart PS: There's a util in FG (fgelev IIRC) that provides a much easier way to probe terrain elevation than running a Nasal script in FG. -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree images for texturing
On Thu, May 9, 2013 at 8:50 AM, Renk Thorsten wrote: I have a series of tree photographs if anyone is interested in creating new tree textures. Hi Thorsten, I'm certainly interested, so send them my way if no-one else has already expressed an interest. -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, May 2, 2013 at 8:48 AM, Vivian Meazza wrote: I can still see that hat on middle distance trees. The effect might be less though - hard to judge. It is certainly no worse. I think it would be worth trying to spread the images out on the texture so that you avoid bleed. I'm pretty sure that is what I'm seeing here. OK, I've pushed a new fix for this that goes back to the old approach of having all textures in a strip, and using clamping to avoid bleeding. You'll need a new simgear and data pull. -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader compile failure
On Fri, May 10, 2013 at 9:27 AM, James Turner wrote: On Mac 10.8, latest of nearly everything: NVIDIA Corporation NVIDIA GeForce GTX 670 OpenGL Engine 2.1 NVIDIA-8.10.44 304.10.65f03 1.20 VERTEX glCompileShader /Users/jmt/FGFS/fgdata/Shaders/tree-haze.vert FAILED VERTEX Shader /Users/jmt/FGFS/fgdata/Shaders/tree-haze.vert infolog: ERROR: 0:89: '*' does not operate on 'float' and 'int' ERROR: 0:89: '*' does not operate on 'float' and 'int' Should be fixed now. Let me know if not - I don't see the warning on my NVIDIA GT260M GPU. -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about fdm properties
On Fri, May 3, 2013 at 7:07 PM, Alan Teeder wrote: I think that you a right in assuming that the developers are not interested in the FDMs. I posted this a week ago http://sourceforge.net/mailarchive/forum.php?thread_name=C6C640DA467C4D118C9A794C6A46D433%40AlanPCforum_name=flightgear-devel and have not seen a single comment. It exposes a serious problem in JSBSim which affects all Datcom users. Perhaps eye-candy and endless mud slinging about the merits of various renderers is a more interesting subject. I think its more a reflection of the areas of expertise of the active developer right now. I have no academic aerodynamics background and haven't done physics since high school. I've spent some time reading the MIT opencourseware on fluid dynamics but certainly aren't competent to comment on these sorts of issues. In contrast I do have a degree in Computer Science which included modules on graphics, so that's where I can sensibly express opinions. I know that doesn't help at all with the particular issue... -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Syncing sim time
Hi Jack, On Thu, May 9, 2013 at 3:57 PM, Jack wrote: Thanks to Jan Comans I've been able to sync the 3D clouds across three instances of fgfs running on a multi-core machine. This, in turn, provides for some very respectable frame rates of 40 to 50 fps per core with a three projector system with older generation Nvidia boards ( GT430 and GT440 ) on a 64bit I5 machine. The visuals will be just awesome once the collimated display is completed later this year. Could you (or Jan) share with us what changes you had to make to allow synchronization across multiple instances? I thought I'd added some code a while back to make the pseudo-random number generator used start with the same seed for a given 10 minute window to address this, but was never in a position to test it myself. -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.1
On Fri, May 3, 2013 at 6:15 PM, Vivian Meazza wrote: I re-installed the Jenkins nightly Win build from yesterday – seems OK, although I have NOT done any extensive testing. I’m seeing regular crashes here from ALS and Rembrandt, but that’s nothing new. I’m getting a number of errors on start-up; they seem harmless: Failed to create alias at /controls[0]/refuelling[0]/refuelling-drogues-pos-norm [0]. Source /sim[0]/multiplay[0]/generic[0]/float[2] is already aliasing another property. Failed to set alias to /controls/refuelling/refuelling-drogues-pos-norm FYI, I don't think this is related to the AAR work I've done recently, and looks like it might be aircraft specific. What aircraft are you seeing this with? I would be more concerned over the state of the data. The reinstall has partly solved the Screenshot directory issue – it now uses the default Working Directory, but the gui input is still stuck. We have a small glitch with Stuart’s latest iteration of the Random Vegetation (aka trees) with what I think is probably a mipmapping issue. I thought 2.10.1 data would be taken from 2.10.0, with commits cherry-picked? If not, I'd suggest backing out that commit from the 2.10.1 data branch, as it has a co-requisite simgear change, and as Vivian mentions still has some issues. I've been away for the last 5 days so haven't had the chance to look into the tree problem further, but have a couple of ideas. One option would be to mirror the texture rows, so instead of looking like this: ^^^ ^^^ ^^^ ^^^ It would be top-to-top and base-to-base: ^ That way is the mipmap UV isn't quite accurate, it would just include the tree-top of the texture above, rather than the base. This would certainly be less noticeable. The downside is that I think it would require adding an if() test to the vertex shader, something I've been avoiding due to (unfounded?) concerns about performance. Or I might simply change the textures to a (very) long strip, so instead of 512x128 it would be 2048x128. However that feels rather clunky, and might not make good use of GPU memory. Anyone with GPU experience care to comment? -Stuart -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Thu, Apr 25, 2013 at 11:50 PM, Vivian Meazza wrote: I'm using a very recent pull of fgdata with no local mods. The hat effect shows up from low angles in all material modes - regional/global/dds. It's most apparent at EGMH, but can also be seen at KSFO. At higher angles or if I zoom in it disappears from the closer trees - but, like you, I can still see it at longer ranges. The angle/range effect would suggest that it's a mipmap thing - perhaps try a bit more space around the trees in the texture? I've just pushed a fix to simgear that reduces the height of the UV mapping by 0.004. Please let me know if this fixes the problem. I expect that some trees will have been slightly trimmed by this. I'll go through the textures and correct them once you and Thorsten confirm the issue is fixed. Thanks for your patience. -Stuart -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Further enhancement to checklists - binding support
Hi All, I've just pushed a further enhancement to the checklist feature. Aircraft authors may now add one or more binding elements to a checklist item. Conceptually, these are the actions that the user should execute to complete the item. The checklist GUI displays items with such binding elements with an additional [] button. Clicking on the button executes the bindings, allowing the user to watch as the computer/co-pilot/instructor executes the checklist item. The binding element is exactly as you would expect - so property-assign, nasal etc. works. Due to the power of Nasal and properties, this feature only required 13 lines of code to write, most of which is displaying the button! I'm planning to extend this function so that checklists with one or more items containing a binding element can have an (optional) button to execute the entire checklist. I'm still thinking of how best to implement this, as I think one would want a gap between each item. I'd highlight the property-interpolate command which provides a very convenient way to interpolate a property to a new value. See Docs/README.commands if (like me) you were unaware of this :). I've updated the c172p checklists to use this feature, including some rather cute interpolations of the throttle, mixture and trim controls. Thanks to Hooray on the forum for suggesting this enhancement ages ago. Feedback welcome as always. -Stuart -- Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with 2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Fri, Apr 26, 2013 at 7:28 AM, Renk Thorsten wrote: this tree movement code is wonderful - how could you possibly not implement this? Glad you like it. It got stuck under a bunch of other stuff and forgotten about more than anything else. However, one reason I didn't spend more time on it was that it didn't seem particularly useful from a sim perspective. If found that to see the effect at reason (30kt) winds you either need to be sitting on the ground or at quite low altitude when your attention is elsewhere. Also, the only time I recall seeing trees moving when flying myself was during a circuit to land at the end of a cross-country flight when the wind had picked up a lot and we wanted to get on the ground ASAP. On this particular leg I was doing comms/nav so had a bit of time to look around. The pilot had the bar in a death-grip and was concentrating very hard on keeping us right-side up, and I'm pretty sure he didn't notice any tree movements :) That said, I'm very happy for this to be added. it is quite a neat effect. I've been looking out of the window, timing the movement of trees in our forest, and I think the time constant should rather be 1.7-2.0 and the amplitude about 2.5 times as large - all of which makes it more pronounced. Then I cooked myself a nice tropical storm and went in low level in rain over treetops - very very nice. The constants were just guesses based on an evenings work with no direct observation of reality. However bear in mind that the same constants would be used for both oaks and conifers, which I'd expect to move different amounts. I think I'll be putting this in at high quality and see if I can't get some wind movement of the hires noise to match the impression... I look forward to it. Since I see it reliably, I could have a try how I can make it go away - I think I understand how the tree shader works well enough... Someone contacted me off-list to mention that this is a fairly well known problem and that shrinking the UV mapping slightly (which I'll need to do in the C-code) and ensuring a nice transparent border around all the trees is the normal way to address this. So, I don't think there's anything you or Vivian need to do here. I just need to spend an hour or so adjusting all the textures. I'll also write some better documentation on creating tree textures so scenery modelers can created them right first time. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
Hi Vivian, I'm not going to address the high level debate, but I have some specific comments. On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: I think a more general concern would be that we seem to be developing 3 or 4 different Flightgears, in which different things work or not as the case might be: Rembrandt Basic weather/Advanced Weather Atmospheric Light Scattering (ALS) I've just put in some effort recently to ensure that Basic Weather can take advantage of ALS properly. So while we retain two weather models, there's no longer a dependency of ALS on Advanced Weather. So we're moving in the right direction here. I've also taken a bit of a look at merging Rembrandt and ALS, and I think I understand the Rembrandt pipeline enough that I could add ALS to it. I'm very keen to promote a more consistent experience so that new users don't encounter confusing differences between alternative rendering schemes, and I'm prepared to put time into making that happen. I'll take a look at the wake shader if you want, but I supect you'd prefer me to fix some of the other issues you raised below first :). Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've not had any time to look at the screenshot/terrasync directory issue. I strongly suspect that I could fix it, but I only have so many hours in the day, and as mentioned before am spread pretty thin. Personally I think most of the active FG devs are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Tue, Apr 23, 2013 at 7:22 AM, Renk Thorsten wrote: Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. After fresh pull yesterday, I can confirm the issue. a) Caribbean and French Alps so far b) using regional definitions c) no - just tried out of the box I spent some time last night trying to repro this without much success. There is an issue with the very nice Caribbean texture (Textures.high/Trees/tropical-alt.png) which I've got a fix for, but other than that The only time I saw anything like what Vivian and you have reported is at very very long range where I can just make out a hat if I look carefully enough. This makes me think that this might be something to do with the way that our graphics cards are generating the mipmaps. Do either of you see the same issue with dds textures? I also went through all the tree textures to check that there weren't overlaps on the boundaries, and in all cases except as noted above, there's at least a 1 pixel gap above the top of the UV map. I could push a speculative fix setting the UV map for trees to a maximum height of 0.24 rather than 0.25 and see if that makes a difference, but it feels very much like a workaround. Any other ideas would be most welcome, as at the moment I'm a bit stumped as to how to fix this. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Hi Curt, On Thu, Apr 25, 2013 at 9:42 PM, Curtis Olson wrote: When I've seen the bits of pixels on the very edges of the transparent tree areas it has sure looked like a texture wrapping issue to me. This is a flag you can turn on/off at least at the low level of opengl and I'm sure OSG would expose this. I think you might be thinking of the UV clamping function? Unfortunately the UV coordinates are something like (0,0), (0.128, 0.0), (0.128, 0.25), (0.0, 0.25) and it's that top edge at y=0.25 which is the problem. -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Atmospheric Light Scattering
On Thu, Apr 25, 2013 at 3:28 PM, Stuart Buchanan wrote: On Thu, Apr 25, 2013 at 2:33 PM, Vivian Meazza wrote: Right now FG seems like a mess with lots of things which used to work (tm): Screenshot directory entry in the gui doesn't work Ditto Terrasync directory Tree textures are misaligned (here anyway) Manual Weather Input. Effects as above. I know that this isn't all to do with you - Well, two of these at least are within my bailiwick (tree textures and manual weather input). Manual weather input is on my TODO list, and I'll address the tree texture issue in the other thread. I've just pushed a fix for the weather issue. I found two bugs in it which I've fixed, but there may be more as it's quite a complex dialog. FYI I'm also planning to move some of the buttons around a bit. I think the changes you (vivian) made are an improvement in terms of making the configuration options more understandable, but I can improve the layout slightly I think. AFAICT the screenshot directory entry in the GUI does work. At least on my system I can change the screenshot directory via the GUI and record screenshots to the new directory. On Thu, Apr 25, 2013 at 4:08 PM, James Turner wrote: I suspect both of these are my 'fault', but equally I was only made aware of the TerraSync one a few weeks ago, and the screenshot one, this is the first I've heard of it. Well, the Terrasync was caused by adding an additional nasalopen block at the top of the file, so the one at the bottom was ignored :) snip In the particular case of the Terrasync path I am especially confused because it's not possible to change the terrasync path once fgfs is running, as never has been as far as I know; since we can't adjust scenery paths with restarting the sim. So, to re-iterate, the defect really needs to explain what the intended use-case was here, since I am clueless. I've restored the previous behaviour which did allow one to set the directory. However, on testing, you are absolutely correct - changing has no effect within the current session. I'll add a warning message to that effect to the dialog. I think it's still useful to be able to set the directory within the sim, even if you have to restart. I think I must have added this function under the mistaken impression that it had some effect. Whoops! -Stuart -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On Tue, Apr 23, 2013 at 12:38 PM, Renk Thorsten wrote: Oh, do you still have that somewhere? I would love to play with this implemented in an optional high-quality tree shader - I could probably also add some grass movement by translating the grain texture or the hires noise with time into the wind direction... Fortunately I still have the vertex shader stashed away, but I've lost the effect file. I added additional uniforms to tree.vert: uniform float osg_SimulationTime, WindE, WindN; WindE and WindN are almost certainly /environment/wind-from-[east|north]-fps I think osg_SimulationTime is built in. The actual code to do the translations is this shear code, placed between the rotation and placement in the correct location: // Rotation of the generic quad to specific one for the tree. position.xy = vec2(dot(position.xy, vec2(cr, sr)), dot(position.xy, vec2(-sr, cr))); // Shear by wind. Note that this only applies to the top vertices // [top vert only] [time dependent movement] [seed so trees close together move together] position.x = position.x + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindN; position.y = position.y + position.z * (sin(osg_SimulationTime * 0.7 + (gl_Color.x + gl_Color.y + gl_Color.z) * 0.01) + 1.0) * 0.001 * WindE; // Move to correct location (stored in gl_Color) position = position + gl_Color.xyz; -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
On 23 Apr 2013, at 07:22, Renk Thorsten thorsten.i.r...@jyu.fi wrote: Stuart, is it possible to pass somehow the info what trees are deciduous? I've done some testing, and I can selectively pick 'green' hue in the shader and color-rotate these pixels to autumn colors, but this is not sensitive enough to key on the difference between leaf and needle - if we had that, we could have autumn colors in addition. Yes. If we put the deciduous trees at the beginning of the texture strip I can pass through information on the fraction of trees that are deciduous as a uniform and you can compare the x texture coordinate against that. At most a couple of lines of c code. Then fall and windy could be combined with particles (?) to simulate wind blown leaves and dynamically painting the foliage part of the texture with alpha to make leaves fall off on windy weather..? ;) Kinda special case and maybe not worth the effort but might be quite awesome jaw-dropper on the right moment.. ;-) Yes, let's forget about spending all the framerate for flight and do realistic vegetation - trees and grass should also move in the wind :-) (I like the idea in principle because it's just mad enough to be charming...) Actually, I had this working very nicely a couple of months ago - using a sine function on time multiplied by wind factor to shift the top texture coordinates so the top of the trees move. I even had a nice larger scale effect to produce the sort of wave affect you see across the tree tops However to be visible at normal ranges (500m+) the wind had to be absolutely howling and shifting the tree tops many meters, so it really didn't seem worth the minor computational cost. -Stuart * Thorsten -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Try New Relic Now We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
On Sun, Apr 21, 2013 at 6:17 PM, Vivian Meazza wrote: We seem to have slight misalignment in the tree texture: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-004.png Definitely looks like it. Could you provide some further details on this please: a) Where are you seeing this ? b) which materials file (dds ? regions? ) c) Have you deleted the Textures.high file to use lower resolution textures? The trees in the screenshot look even more blocky than normal. Is having a single texture sheet the most efficient way of doing it? Just asking. I think so. The textures here are very small (512x512) so the difference between a 512x128 and a 512x512 texture would be miniscule while loading 4 textures rather than 1 from disk might be significant. IIRC Thorsten also did some experiments and found that having additional textures references in a shader had a significant performance impact. -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] Terrain self-shading
On Sun, Apr 14, 2013 at 10:41 PM, Stuart Buchanan wrote: As it happens, I'm part way through a change that would allow varying snow- and leaf- cover without having to load different textures, so trees above the snowline could be snow covered while those below are not. This will increase the size of the textures to 512x512, while an individual tree will remain on 128 pixels tall. This is now checked in. Tree foliage is now consistent with the experimental Season slide on the Environment Setting dialog (deciduous trees shed their leaves towards late autumn) and the snow line (trees above the snow-line have a small covering of snow). Of course, we really should only add snow cover to the trees if the snowfall is recent and there isn't much wind, so perhaps we should just have summer/winter variants and no snow-covered... to be discussed. There are changes to both simgear and data for this change. Picking up one or other results in very odd looking trees :). This retires the -summer.[png|dds] and -winter.[png|dds] variants, which have been removed. Those creating tree textures for regional project will now need to follow the new format. I'll update the next newsletter to ensure that this information is distributed. On Tue, Apr 16, 2013 at 7:22 AM, Renk Thorsten wrote: Just to be clear - if we had textures, this is something I would do the work for since I suggested it, I'm not expecting Stuart to do this for me :-) (This is not to imply that I would object against Stuart giving a try, but as long as I can follow up an idea I like myself, I try not to fill someone else's to-do list). That's fine. So I would suggest to implement this as a high-quality option for those who have the hardware to crunch substantial fragment shaders and leave the current implementation as a fallback. That sounds reasonable, though the current implementation has changed in the meantime :). -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] 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
[Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
Hi All, 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 :) -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] Terrain self-shading (plain text)
On 15 Apr 2013, at 21:39, Thomas Albrecht wrote: Sorry for that HTML-crap. Here's the plain text again. No problem. I'm writing this from an iPhone and have no idea whether it's in plain text or not! Thorsten suggested [1] separating foilage and trunk; is this what you have in mind? At the moment I'm simply using 4 separate complete textures ; one for each combination of summer/winter and clear/snow-covered. So I 'just' need straight pictures from summer and winter. Snow-covered would be a bonus, though that can probably be added later. With that I can display different textures above and below the snowline with no computational impact (well, a couple of additions and multiplications at the vertex level plus an additional Uniform). On my system there's no impact to frame rates. I've still to look at Thorsten's idea in detail (my code predates that discussion) and don't expect to have the time to do so in the foreseeable future. I expect it to require additional texture lookup and some perlin noise at a minimum so the perf impact might be significant. That's not to say that the two approaches can't sit side by side. I'm just waiting for the right weather to take pictures of the trunks -- and then of course, for the trees become green again -- but then I can provide hi- res tree textures. That will be great. Thanks. -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] Terrain self-shading
On Sun, Apr 14, 2013 at 9:40 AM, Renk Thorsten wrote: Downstream, to preserve the illusion of shadows, I've had to alter the tree shader to purely ambient lighting based on sun angle above the horizon. But that seems to be a good idea in general - not only is this cheapter to compute, but also our tree sprites have flat suraces with a clear normal, so they have very pronounced directional scattering - real trees have random orientation of leaves and needles and a leaf can also transmit light, so I think real trees have much weaker directional light scattering and isotropic scattering is actually the better approximation. No objection from me. I've never been particularly happy with the directional scatter on the trees, but haven't spent any time trying to fix it. On a related note, the thread highlights that our tree textures are rather small, so our trees look quite blocky. When I initially implemented them, I think I just used the same texture sizes as the existing tree models, so the trees are only 128 pixels tall in a 512x128 strip. As it happens, I'm part way through a change that would allow varying snow- and leaf- cover without having to load different textures, so trees above the snowline could be snow covered while those below are not. This will increase the size of the textures to 512x512, while an individual tree will remain on 128 pixels tall. Given that we've got a very limited number of tree textures and the same texture is used on a large number of objects, perhaps it would be worthwhile increasing the resolution? -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] Improved usability
On Fri, Apr 12, 2013 at 6:01 PM, James Turner wrote: On 12 Apr 2013, at 16:56, James Turner zakal...@mac.com wrote: No, visible handling should be the same as before, but I didn't test the b1900d - will take a look and ensure I haven't done anything silly. The change I have made (which did need some re-work, and may have caused the bug you're seeing) is *visible* pick animations can have invisible 'pick-proxy' elements, specified by 'proxy-name' in the XML. The C172P uses these so tiny switches (on the KMA-20 audio-panel) are easier to hit. (The C172p 3D model already had such polygons, the actual switches were not pickable - this didn't work so well in my new scheme, hence the support for pick-proxies to make things as usable as possible). Again, this is likely 'just a bug', I'll test / fix over the weekend. Based on a *very* quick look, the B1900d seems fine here - can you send me a screenshot of what is 'missing'? I also don't see any errors about bad object names either. I'm seeing a number of missing controls on the a4f as well with current git binaries. They are present with a binary from about a month ago, so I'm fairly sure it's related to the recent changes. I get a bunch of console errors matching the missing instruments: Could not find at least one of the following objects for animation: 'UHFFreqSelectManual' Could not find at least one of the following objects for animation: 'UHFFreqSelectGoXMIT' Could not find at least one of the following objects for animation: 'UHFOff' Could not find at least one of the following objects for animation: 'UHFTR' Could not find at least one of the following objects for animation: 'UHFADF' Could not find at least one of the following objects for animation: 'TACANModeOFF' Could not find at least one of the following objects for animation: 'TACANModeREC' Could not find at least one of the following objects for animation: 'TACANModeAA' Could not find at least one of the following objects for animation: 'RadarModeOFF' Could not find at least one of the following objects for animation: 'RadarModeSTBY' Could not find at least one of the following objects for animation: 'RadarModeSRCH' Could not find at least one of the following objects for animation: 'RadarModeAG' Could not find at least one of the following objects for animation: 'GunSwitch' Could not find at least one of the following objects for animation: 'RadarRangeSwitchLong' Could not find at least one of the following objects for animation: 'BHDIModeSwitchNAVCMPTR' Could not find at least one of the following objects for animation: 'BHDIModeSwitchNAVPAC' Could not find at least one of the following objects for animation: 'SpoilerSwitchArm' Could not find at least one of the following objects for animation: 'SteeringSwitchOff' Could not find at least one of the following objects for animation: 'APCSwitchOff' Most of these objects are animated in AIrcraft/a4/Models/Instruments/a4f-panel-xh.xml Screenshot highlighting the missing knobs: http://www.nanjika.co.uk/flightgear/missing.jpg -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] Joystick dialog configuration fix
Hi Clément, On Thu, Apr 11, 2013 at 1:15 PM, Clement de l'Hamaide wrote: I'm using a Thrustmaster Hotas-x and I noticed that nasal section on top of the original file ( $FG_DATA/Input/Joysticks/Thrustmaster/T-Flight-Hotas-X.xml ) is not copied to the custom file written in $FG_HOME after modification from the Joystick Configuration dialog. This missing nasal section break the behaviour because 2 variables are not declared (in my case, I don't know for other .xml files). Looking at joystick.nas this is expected since nasal is not handled so I've fixed it. Here is the git diff who fix the issue : http://pastebin.com/XaanECUs This has now been committed. Thanks! -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] Air-to-air refuelling enhancement
On Wed, Apr 10, 2013 at 11:24 PM, jean wrote: one more bug (was my mistake ): in tanker .nas, we need to normalise the degre in line 26O-261 to have: me.hOffsetN.setDoubleValue(view.normdeg(me.bearing - ac_hdg)); me.vOffsetN.setDoubleValue(view.normdeg(elev - ac_pitch)); this was done in the 2.10.1, but not in next ( i sent you a mail probably lost in the numerical world). Yes - I lost that email. Now committed. Thanks, -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] Reloading checklist
On Thu, Apr 11, 2013 at 8:35 PM, Jean-Yves LEBLEU wrote: This is what I did : var checklist=777-200-checklists.xml; var checklist_path=sprintf(%s/%s,getprop(/sim/aircraft-dir),checklist); print(checklist_path); var data = io.read_properties(checklist_path,/sim/checklists); It does reload the checklists but conditions are not evaludated Hi Jean-Yves, It is strange that the conditions are not evaluated. Have you had a look using the property browser to see if the property structure is as you would expect? It might be worth trying deleting the /sim/checklists node first, something like: props.globals.getNode(/sim).removeChild(checklists); -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] Improved usability
Hi James, This is superb work. I've just taken a flight in the c172p to try out the new features, and I'm very impressed. On Thu, Apr 11, 2013 at 9:48 AM, James Turner wrote: - made a 'right-drag to look' mouse mode, which I think should be on by default (with the current behaviour available for people who prefer it). Also there is now visual feedback when changing the mouse mode 'statefully', which is still available via the TAB key in addition to right-clicking. Though I'm a dyed-in-the-wool mouse-looker who continually switched between cursor and mouse-look, I'm completely converted to this way of looking - way more intuitive IMO and really easy for users to learn. One minor suggestion - I used the mouse wheel field-of-view control a lot when in look mode. Having it change the field of view while the right mouse button is pressed would be good. - made dedicated animation components for knobs / sliders, with unified handling of buttons / mouse wheel / dragging. I particularly like how this reduces XML file complexity. - added tooltips, and hover-feedback for pickable areas in cockpits I'm seeing some bugs in this, in particular after hovering over some control in the c172p (possibly the alitmeter?) I got Aircraft Help displayed as all tooltips, and the following errors in the console: Nasal runtime error: nil used in numeric context at /home/stuart/FlightGear/data/Nasal/geo.nas, line 241 called from: /home/stuart/FlightGear/data/Nasal/canvas/tooltip.nas, line 167 called from: /home/stuart/FlightGear/data/Nasal/canvas/tooltip.nas, line 119 called from: /home/stuart/FlightGear/data/Nasal/canvas/tooltip.nas, line 91 called from: /home/stuart/FlightGear/data/Nasal/canvas/tooltip.nas, line 270 called from: /home/stuart/FlightGear/data/Nasal/canvas/tooltip.nas, line 313 geo.normgeg should probably be more robust As a bonus function, for multi-mode toggle switches, it would be great to be able to define labels for different values (e.g. 0=OFF, 1=ON) For more complex aircraft such as the Constellation, Concorde or 747, adding tooltips will be a lot of work, but greatly assist in figuring out what everything does. Well, such is the price of progress. -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] Air-to-air refuelling enhancement
I've (finally) managed to add the code to allow offsets for the tanker fuelling positions and the receivers probe position. See the A-4F for an example of how to set this. One can now use small envelope sizes and use the relative drogue and probe position to refuel. On Sat, Mar 2, 2013 at 1:03 PM, jean pellotier wrote: after a few runs behind ai tankers, and some crashs in the sky, i think the a4f need to have at least the drogue and hose not hot. Thanks. This is now done. I've also made a similar fix to the A330-MRTT which I crashed into myself :) the radius definitely need the offsets , i was unable to make contact in the usual position with a short radius :) This is now done. when you're in tanker.nas , I think that in turns, the tanker don't have a rotation correct respect to the bank angle, when you follow you don't have the same bank angle and it's a bit strange. here i got a much better behaviour with this patch: I've committed this as well. Thanks. -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] Reloading checklist
Hi Jean-Yves, On Mon, Apr 8, 2013 at 8:27 PM, Jean-Yves LEBLEU wrote: Hello, I have started to write checklists for 777, is there any way to reload the checklist without restarting flightgear, I tried with shift-esc with no success. Or maybe there is a little nas script to do the trick ? Yes, this should be possible, provided your checklists are in a separate file. See Nasal/io.nas and the read_properties() function. There are some examples in the comments around line 67. -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] Cloud detail range and faint clouds
On Tue, Apr 9, 2013 at 8:12 AM, Renk Thorsten wrote: The problem are faint Cirrus-type clouds which use 2-3 sprites, or in extreme cases just a single one (they have a transparency of more than 90% and are really just a faint haze modulation). Here, dropping half of the sprites essentially mutilates the appearance of the cloud. I have just comitted some very nice undulatus pattern distributions, and dropping half (actually in practice about 2/3 of the sprites seem to go...) just changes the appearance of the sky drastically. IIRC the sprites are distributed on the surface of a squashed sphere, which might explain why with small numbers of sprites more than 50% might disappear. Or it might be a bug. I think ideally a way to drop sprites only for certain types of clouds and protect the faint ones would be desirable. Do we for instance have an unused attribute slot where the number of sprites used to generate the cloud can be passed? I'll add it to my TODO list :) Presumably making cirrus clouds after more sprites doesn't make for very realistic clouds because of the size of the cloud structures? -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] A collection of questions
On Mon, Apr 8, 2013 at 8:04 AM, Renk Thorsten wrote: If I may bother everyone again - here's my current list of open questions. Any help or pointers would be appreciated: Things have been remarkably quiet the last couple of weeks - good to have something to discuss :) * Where do the runway and taxiway lights enter the rendering scheme? They need to be fogged consistently with the rest of the scene, but I do not know where to set this - which effect are they using? I suspect they are just using the default terrain effect, if anything. They are generated from the C-code when the tile it loaded (IIRC simgear/scene/tgdb/obj.cxx though I'm not at my FG computer to check) If you want any changes I'd be happy to make them, though I'd expect it's the sort of change that you could make yourself with a little digging :). FYI, I've got a list as long as my arm of FG things to do, and have struggled to find any time to spend on FG for the last month. Off the top of my head I've got the following things on my plate right now: - Improve Basic Weather integration with Atmospheric shaders. Thorsten's provided soem documentation of the properties to be set, and I need to either write some property rules for Basic Weather or modify the C-code. - Review Vivian's changes to the Weather dialog (this is not to mean I don't think Vivian's work is a step forward, I just need to think about it a bit) - Modify trees so that there's no need to change the texture set under atmospheric light shading. This is almost complete and means that trees above the snow-line are snow-covered, and deciduous trees in autumn/winter lose their leaves - Further improvements to AA refueling - support drogue/probe positions - Move the loading of trees/buildings from the tile loading into a deferred LoD node so that they only get generated when the user gets closer to them. This should improve tile loading times and memory occupancy. Of course, it's nice to have so many interesting tasks to work on, but if anyone is looking for some work to do and would like to take one one of the tasks, they'd be very welcome :) * Where does precipitation enter the rendering scheme? It'll be somewhere in the C code. I'll have a root around for it and let you know. * Why are the runway and taxiway designation signs using the terrain shader? Can (should) this be changed? Yup, I'm sure this can be changed :) I'll take a look if no-one beats me too it. See http://www.flightgear.org/forums/viewtopic.php?f=47t=18999 * Can we generate more vertex attributes than tangents, normals and binormals? For instance, can we do components of the curvature? I would think it would be straightforward to do this, but I don't know the perf/capacity impact of doing so. * How difficult would it be to expand the tree generating system to a multi-tier system in which we can in addition generate a circle of vegetation in the range of ~50-100 m for high resolution scenes landing off airfields? Do we generate the memory load from trees at tile loading time, or at tree loading time? Currently we generate all the trees at tile loading time, and then use LoD to control how many are displayed. So the memory cost of incurred at tile load time. As mentioned above, I'd like to change this so that tree generation is deferred into the LoD node. Mathias has shown how this can be done, and I need to extend his work. I don't think there's a sensible way to generate additional trees at 50-100m. With the changes described above, the overall memory occupancy of trees should go down, so perhaps it won't matter as much? * Just how are the LOD ranges defined in the view menu used? I am genuinely confused, I understand that LOD bare sets the terrain, but that's the limit. Does anyone know? To my embarrassment, I don't know how they are used, except to say that they aren't used for tree, random buildings, and (probably) random objects. That's probably a bug. -Stuart -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compasses, magnetic variation, and stuff
On Tue, Mar 12, 2013 at 5:47 PM, Alasdair Campbell wrote: Now the comments at the beginning of coremag.cxx imply that the module originally implemented wmm2000 and was updated by Wim Van Hoydonck (wim.van.hoydo...@gmail.com) to wmm2005. The current version is now wmm2010, and I wonder if simgear has been updated to reflect this? Could this account for my heading discrepancy at EGPF? Probably not. It's more likely that the magnetic variation has simply changed since the runway number was set, as it varies over time. IIRC Edinburgh airport (EGPH) had to re-number it's runways a while back for exactly this reason. Indeed, I think we may have had to re-number our own runways at East Fortune last time they got repainted. -Stuart -- Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compasses, magnetic variation, and stuff
On 12 Mar 2013, at 20:18, Alasdair Campbell wrote: Thank you Stuart James for your responses, Stuart, I was not so much interested in what is painted on the ground, but what is indicated on the slaved gyro. Your comments have made me reconsider my maths. apt.dat shows a true heading for EGPF R05 of 46.34 (where does one find true runway headings?) Magvar on 2011 was 4.0W (http://www.nats-uk.ead-it.com/public/index.php%3Foption=com_contenttask=blogcategoryid=72Itemid=121.html) Annual Rate of Change 0.17°E (source as above) So current Magvar =3.66W Now I suppose I must ADD? this figure to the true heading? giving 50.00 as the magnetic heading for EGPF R05. The slaved compass reports 50.03, which is good enough for me, But I wonder if, as James suggested, upgrading to ww2010 might lose the tiny difference. I may try this on a local repo and see what happens. Yes, you add the variation in the uk at present (I have a mnemonic of small map, big world, so add the variation. :] ) I think one your talking about small fractions of a degree you are well into noise territory and I'd be surprised of updating the magnetic model would make much difference. Your base data of 4.0W mag variation at EGPF is probably only accurate +/- 0.25. I had a quick look at my chart and the +4.5W variation line is not too far to the west. Sorry for thinking aloud, but I find this wmm stuff fascinating, though complicated. Yes, it's very interesting. My chart for Ireland specifically warns about the large variation (+5W) which I'm sure catches people out. And that's before you have to add variation due to the airframe ! -Stuart-- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crazy usability suggestion of the day
On Tue, Mar 5, 2013 at 11:10 AM, James Turner wrote:
Can anyone tell me a problem, with forcing startup location to 'not a runway'
*when MP is enabled* ?
I'd pick an available parking at semi-random, if the airport has parking
locations. Another option, if the airport has a ground-network, would be to
try to guess a hold-short location for the runway, but that rapidly becomes
tricky with parallel runways, different aircraft radii, and so on. Parking
locations seem safer, but people will have to taxi in MP mode. I'm sure the
ATCs would prefer than anyway.
This *could* disregard the --runway option, but then we're actively
over-riding the user's wishes, rather than just avoiding a default behaviour
which is bad with MP on. In the GUI (airport selector dialog ) we could
disable the 'best runway' option, or even the runway selector combo entirely,
if we wished to be strict about it. ('this feature is disabled in multiplayer
mode' prompt text, of course)
Comments?
I think this is a fine idea. At present working out the available
parking positions for and airport from outside the sim is a bit of a
pain. (In fact I usually start with MP off, then use the Select
Airport dialog to position at a parking position, and then turn MP on)
I assume by semi-random you mean to choose parking positions fairly
close to the approach end of the active runway?
Making a similar change to the airport selector would be a good idea
as well, though obviously we'd only disable the option if parking
positions exist for the airport.
On a related note, I've been wondering whether we should start the sim
with the engines running when starting from a runway. Being on the
runway with the engine off isn't particularly realistic. If we were
feeling particularly keen also having the altimeter set and the radios
tuned to the tower frequency might be nice.
-Stuart
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG vs. FSX demo
Hi Thorsten, :) On Thu, Feb 28, 2013 at 7:57 AM, Renk Thorsten wrote: My problem is that I often know very well how X is implemented in FG, I may suspect that it's not in FSX or X-Plane, but since I'm not running X-Plane or FSX with all addons I don't really know for a fact if it is a genuinely unique feature or if there is a 3rd party addon to FSX/X-Plane which provides the same thing. And we would want to be factually correct here. The 2.10 release has sparked some interest over at avsim.com (http://forum.avsim.net/forum/198-the-flightgear-forum/) where various FS-X and X-Plane users have been giving it a try and comparing it with other sims. It makes for interesting reading - I hadn't appreciated what a big deal not being able to configure a joystick from a GUI was until I read a couple of comments highlighting it as a big V2.10 feature. There's also positive comments about atmospheric rendering, smoothness and FDM quality. I agree that working out what's unique is difficult, and it's a moving target given the add-ons. Just last week I read a thread from someone asking about failure mode (MTBF/MCBF), something we've had in FG for years. Further down the thread someone responded saying they'd just written an iPhone/iPad app to do just that. Ah well, it was unique for a couple of years at least :). -Stuart PS: Further up the thread Thorsten mentioned that FS-X instruments seemed jerky. IIRC the instrumentation in MSFS has a fixed refresh rate (30fps?). -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Checklists
On Mon, Feb 18, 2013 at 1:26 PM, Stuart Buchanan wrote: On Sun, Feb 17, 2013 at 11:56 PM, Alan Teeder wrote: The reason for my query was that I have found making a representative set of checklists is becoming very unwieldy. With just my entering the cockpit checks, I have already made 9 separate checklist. Each one has about 10 checks. I have made one checklist per check list card on the real aircraft. These checklist items disappear off the top of the menu list screen, and there is no indications as to which checklists/cards have been completed, or which is the next to do. Having got this far it is obvious that the current system will not cope for the rest of the aircraft checklists that I intend to replicate. OK, sounds like you've got much longer checklists than I have encountered myself. I'll see what I can do to support multi-page checklists. I can probably add Next and Previous buttons to page through the checklist. This is now available. item nodes can now be grouped under a page, which the checklist display handles as you would expect. I've also added support for marker tags which leverage the existing tutorial markers. I've updated Docs/README.checklist and the wiki to reflect both these changes. As always, the c172p has an example (Aircraft/c172p/c172-checklists.xml). I've still to update the checklist-tutorial converter to support the tags - that's next on my TODO list. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Air-to-air refuelling enhancement
Hi All, I've just committed some small changes to the AI air-to-air refueling function: 1) Added support for multiple tankers of each type, selectable through the AI-Tankers GUI. Tankers are now defined in AI/tankers.xml. 2) Added an A-4F buddy tanker. 3) Enhanced the UI to allow the user to set the speed of the tanker, and the radius at which contact is made. Note that this is based on the origin of tanker and user. As a future enhancement I want to add offsets to indicate the position of the refuelling probe/receiver on the user aircraft, and the location of the boom/drogue on the tanker. 4) Added a user-toggled function to display messages when contact i made or lost. Some aircraft don't seem to have any obvious cockpit indicator that refuelling is in progress, and we don't currently animate the probe being in the drogue :) 5) Added maximum fuel flow definitions to both the tanker and receiver. While the KC-135 supports flow of 6000 lbs/min, smaller tankers (such as the A4-F buddy tanker) only provided ~1300 lbs/min. the actual fuel flow is taken as the minimum of the two. Note that the maximum fuel flow affects both AI and MP tankers. I've been unable to test with the latter, but have set a default to ensure backwards compatibility. Feedback welcome as always. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
On Thu, Feb 21, 2013 at 12:59 PM, James Turner wrote: Suggestion - if z/Z are pressed with advanced weather enabled, make the popup-message say 'disabled since visibility is being controlled by advanced weather'. Another option would be to move the visibility control to a dialog, with a slider / spin box, and explicitly disable it when advanced weather is selection. Then we could lose the keybinding completely, which is something I want to move towards for options that are infrequently used, but taking up 'keyboard space'. I agree that it shouldn't be a keyboard assignment, and we should remove it. I'd need to check, but I thought this was already part of the weather configuration dialog. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Checklists
On Sun, Feb 17, 2013 at 11:56 PM, Alan Teeder wrote: The reason for my query was that I have found making a representative set of checklists is becoming very unwieldy. With just my entering the cockpit checks, I have already made 9 separate checklist. Each one has about 10 checks. I have made one checklist per check list card on the real aircraft. These checklist items disappear off the top of the menu list screen, and there is no indications as to which checklists/cards have been completed, or which is the next to do. Having got this far it is obvious that the current system will not cope for the rest of the aircraft checklists that I intend to replicate. OK, sounds like you've got much longer checklists than I have encountered myself. I'll see what I can do to support multi-page checklists. I can probably add Next and Previous buttons to page through the checklist. One question: Would you prefer that the UI itself split the checklist up, or for the checklist author to do it themselves? The former would be automatic, but wouldn't allow the author to place the page-break where they wished. Yes, my level of simulation will include such detail as the fail to relight in 20 seconds scenario. Very good :) For background info my suggestions were based upon an interactive checklist system that I was involved with in the 1980´s as part of a joint BAC/Hawker Siddeley glass cockpit simulation. This was before the two companies merged to form BAe. AFAIK this was the first glass cockpit project to have an in depth simulator evaluation. Our two target aircraft were the VC10 ( completely eliminating the flight engineer station) and the A300 which was state of the art at that time. This electronic checklist also bought up the relevant systems displays on one or more other front panel CRT´s . In normal use (e.g. start-up) the electronic checklist was selected by the crew, but the relevant set of checks were automatically initiated when aircraft failures were detected. The system was intelligent enough to follow the sequence of events following an emergency (e.g. my relight scenario) , and also had a priority system to deal with the major faults (engine failure, fire, etc) before lesser ones. At the moment my TSR2 is not a glass cockpit, but having a usable checklist system would save a lot of paper. AS an old fogey I am not up to speed with current developments in this field, but am sure that some of our work has a modern counterpart. Yup, and I think that would be the glass cockpit of the aircraft itself rather than the simulator UI. Anyway - you asked for comments on your checklist system ;) Yup, and very good feedback it is as well. Thanks. -Stuart -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Checklists
On Fri, Feb 15, 2013 at 9:23 PM, Alan Teeder wrote: Is there any way to chain checklists automatically so that they follow one another in a pre-defined order? They should appear in the checklists dialog in the order in which they are defined in the XML file, so simply define them in the order you wish. An alternative, which may have further advantages, would be to have a tree structure of checklists, where one branch has to be completed before going back to the trunk and then on to the next branch. Note that the checklist function doesn't enforce any action on the part of the pilot. It simply provides a convenient representation of a textual checklist plus some highlighting to indicate completed steps and (once I get around to it) the ability to highlight the relevant controls. e.g. on cockpit entry I want to do a right to left sequence of checks, starting with the port side panel, going on to the port coaming, then the port instrument panel etc, covering the whole cockpit methodically. Each of these panels has up to a dozen checks. This is how the checks were actually organised (with a book of cards) on this particular aircraft. The cockpit entry checks were then followed by the start sequence, the after starting, the take off, after take-off, circuit ad approach /landing checks. I don't think that's a tree structure, just an ordered list, which is already provided. The emergency checks also follow a tree structure, but in this case the next branch depends upon the result of a particular check. (e.g. did the engine relight within 20 seconds?) I think that's getting a bit specialized, and overly complicated. I'd also point out that we're just supporting the pilot's use of checklists, not attempting to automate them. I don't think it's unreasonable to have a checklist items that says if the engine does not relight within 20 seconds, run the Engine Dead Checklist (Additionally I'd be pleasantly surprised if our systems/failure modelling is good enough that such a decision tree wouldn't always go down the same path.) -Stuart -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autumn colors
On Fri, Feb 15, 2013 at 9:33 AM, Erik Hofman wrote: On 02/15/2013 10:00 AM, Renk Thorsten wrote: So I will remove the option from GIT again and clear out the *-autumn.png textures in the next days and develop this further for my own private enjoyment (with the understanding that I'll make it available on request to anyone interested), which should give anyone else the chance to implement a drop-down seasons model for 3.0 without generating confusing clashes. No hard feelings from my side, I don't come with the expectation that everyone shares my enthusiasm for painting the terrain. Admittedly it's not at the core of what makes a Flightsim. I'm not sure this is necessary. I think an opt-in checkbox would suffice. After all FlightGear has been around for personal experiments for a very long time. So why not this option. +1. I think removing it is going a bit far. It's early in the release cycle as well, so there's plenty of time to iron out issues and work out a suitable scheme that satisfies those who just want a quick'n'dirty way to get a roughly autumnal palette, and those willing to take the time to tune the environment to exactly match what they see outside. I've still to look into this in detail (too many other things on my plate right now), but I'm confident I can some up with a sensible user interface. Finally, it's worth remembering the -devel list only represents a small part of the FG userbase, and those not using git have not even had the chance to try this yet. -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autumn colors
On Thu, Feb 14, 2013 at 9:40 AM, James Turner wrote: In this specific case, that means there shouldn't be a slider, there should be some additional values in a place that can be customised per-region. Since what the *user* wants is that in the region they are in, the colours / effect look plausible - that's all. Messing around with sliders they don't really understand, is not a good thing for them to be doing. We could provide some per-region customization within materials.xml, for example. Unfortunately the current materials.xml format is getting quite unwieldy, particularly with all the regionalized settings. I have a long-term plan to structure the information better. A shorter term solution might be to offer a default Autumn drop-down with generic plausible values, and an Advanced dialog with sliders. I need to integrate support for autumnal trees anyway, so this fits in with that. -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG 2.10 Change Log and Release Announcement
Hi All, The complete 2.10 changelog is available here: http://wiki.flightgear.org/Changelog_2.10 I've now made it read-only. If anyone has any final comments/edits they want to make, please let me know. I anticipate using a slightly modified version of the first couple of paragraphs for the release announcement. i.e.: The FlightGear development team is happy to announce the v2.10 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include improved usability, better terrain rendering and a fully scriptable 2D rendering system. A list of major changes can be found at http://wiki.flightgear.org/Changelog_2.10. Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums. FlightGear features more than 400 aircraft, a worldwide scenery database, a multi-player environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute. Download FlightGear v2.10 for free from FlightGear.org. FlightGear - Fly Free! Comments welcome as always. -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final release checklist
On Mon, Feb 11, 2013 at 6:35 PM, Torsten Dreyer wrote: Do we have the latest getstart.pdf compiled and picked into the release branch? Yes, this is already done. Toshi recently sent some updates that I'll try to get in before the weekend, but they aren't shipstopper issues. Anything else to think about? I committed a change about a week ago to display a warning in the Rendering dialog for those using Intel integrated GPUs. I don't know whether it was pulled into the release branch or not, but it's a safe change that might reduce some support questions on the forum. (Sorry - can't give the commit hash right now as I'm away on business) -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Manual update request (Was: Updated Short Reference for 2.10.0)
Thanks Toshi. I'll try to get these changes incorporated before the
weekend release.
-Stuart
On Tue, Feb 12, 2013 at 3:56 PM, YOSHIMATSU Toshihide
qzt04...@nifty.ne.jp wrote:
Hi Martin and Stuart,
I checked incorrect or dead links in the current version of Manual
(except Appendix).
Following are the results and my suggestions.
* 3.3 Installing documentation
http://www.adobe.com/products/acrobat/
-- Alive, but incorrect. Please change to http://get.adobe.com/reader/
Also it would be better to correct the description:
Adobe's Acrobat Reader, available from
-- Adobe Reader, available from
* 8.10 The autopilot
https://www3.bendixking.com/servlet/com.honeywell.aes.utility.PDFDownLoadServlet?FileName=/TechPubs/repository/006-18034-_2.pdf
-- Connection has timed out. Please delete this link.
* 8.13.1 How to land the Cherokee Warrior II
http://www.alioth.net/flying/pa28-161/index.html
-- Connection has timed out. Please delete this link.
* 10.5 Epilogue
http://worldaerodata.com
-- Very unfortunately, server not found. Please delete this link.
cf. http://www.flightgear.org/forums/viewtopic.php?f=27t=19067
http://www.faa.gov/library/manuals/aviation/instrument_flying_handbook
-- http://www.faa.gov/library/manuals/aviation/media/FAA-H-8083-15B.pdf
or
http://www.faa.gov/library/manuals/aviation/
Also it would be better to correct the description:
It can be downloaded as multiple PDF files.
-- It can be downloaded as a PDF file.
Moreover, I noticed that Part IV Appendices includes no sections, and
Part V Annexes includes Appendix A (Missed approach) and B (Landing).
In the commit log of getstart.tex:
http://mapserver.flightgear.org/git/gitweb.pl?p=getstart;a=commitdiff;h=799005980b3825dfc731e1528473630b9cd906d5
iflanguage{english}{
part{Annexes}
{}
might should be
iflanguage{french}{
part{Annexes}
{}
but I'm not sure if Annexes is French word...
Cheers,
Toshi
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Checklists enhancement
On Fri, Feb 8, 2013 at 11:11 PM, Alan Teederwrote: Is the intention to make tutorials easier to compose, or is it to replace them? Easier to compose. The tutorial system is much richer than the checklists, for example it supports specific error conditions, audio, and multiple messages. At the moment, checklist.nas fails at line 6 – presumably because my aircraft doe not yet have a checklist. Now fixed. Thanks for the report. -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Checklists enhancement
On Thu, Feb 7, 2013 at 10:28 PM, Gijs de Rooy wrote: one request I would like to place is to automatically spread the checklist over multiple pages if it gets longer than, say 20 lines. Especially the complex birds tend to have long checklists ;-) That's a bit tricky to do within the GUI, and the split would be quite arbitrary. I would think it better for aircraft maintainers to split the checklists themselves. That way they can split them at a suitable point. -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Checklists enhancement
On Wed, Jan 30, 2013 at 2:41 PM, James Turner wrote: I'm thinking of combining this with the tutorial system so you can have a virtual co-pilot go through the checklist, calling out the items for you to complete. I'd be interested to hear if those who like flying heavy iron think this would be a useful function. Categorically yes - the checklists are already nice for the 737NG, and the big iron has far greater need for the tutorials - starting the Connie or similar is quite some work :) This is now added. Tutorials are now generated for all checklists at runtime. They are pretty basic, but it's a nice freebie. One future enhancement i've just thought off might be to enhance the checklist so that an item can have a marker associated with it as we have with tutorials. A user could then click on a checklist item to have the appropriate cockpit control highlighted. This further blurs the line between the checklist and tutorial functions, but users might find the self-pacing aspect of checklists easier to use than the forced pace of the tutorial. Useful? Taking things a bit too far? -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. fd8369142a291a473e8d1587ad0d7fcc252b6ad5
On Wed, Feb 6, 2013 at 11:05 PM, James Turner wrote: Is this a significant enough / safe enough change to push to the release branch? It should be safe enough, as it's just applying some techniques already used for the trees. I'm ambivalent about whether it's a release branch candidate though, as building perf isn't a major issue in most circumstances. It does gives me a significant frame-rate boost in very large urban areas (KLAX) from ~6fps to ~15fps with building density = 2.5. Definite candidate for a 2.10 maintenance branch and 2.10.1 release. -Stuart -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Winter Textures ( was Re: Release candidates)
On Thu, Jan 31, 2013 at 9:05 AM, Vivian Meazza wrote: I'm not sure if I'm doing something wrong here: we now have so many different options, but getting snow by method 2 or 3 results in deciduous trees in full leaf with snow coverage on the ground. Not an impossible scenario, but bare trees are more likely. Is this a bug? I'll claim it's a limitation of the current scheme rather than a bug :). As it happens I've got a fix/enhancements for this sitting on my computer right now that's just about ready to push, but which I need to discuss. Basically, at present the trees are represented by a 512x128 texture containing 8 trees in row. My enhancement is to change this to a 512x512 texture containing 4 rows or tree, representing summer, summer+snow, winter and winter+snow. I then have a small change to the shader (that doesn't use an if test :) ) to shift the texture to the correct row depending on the snow level and whether we think it's winter or not. We need both snow and winter as separate states as with snow alone you'd end up with deciduous trees with leaves below the snowline and bare branches above - acid snow ? There are a couple of problems I'd like advice on: 1) (pre-existing) Under rembrandt, the winter deciduous tree texture suffers as it has significant alpha but isn't registered as a transparent object. 2) It's not clear to me that we want to display trees with snow on them above the snowline. In my experience, trees very quickly lose their snow cover after snow-fall if there's any wind. So perhaps the snow-covered trees should only be used if snow is actually falling, and what we really need is a simple way to change from summer to winter tree textures? 3) We use /sim/startup/season to indicate whether it is summer or winter. That's a string (summer, winter) that I need to map into an integer to pass down the stack to a uniform in the shader. There's no obvious way to do this mapping, so I'm thinking of changing the property we currently use (/sim/startup/season) globally to /environment/winter or somesuch, with type integer. And, to go back to the original point about winter textures I agree that we need to keep them. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Random building bugfix for Atmospheric Light Scattering
On Wed, Jan 30, 2013 at 9:16 AM, James Turner wrote: Okay, I'll wait for some feedback from Stuart and then merge, if no one beats me to it. I've had a look, and it all looks fine. Please merge back to 2.10.0. Thanks, -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Checklists enhancement
Hi Guys, Just a quick note to mention that I pushed a change to the checklists function last night that allows you to add condition blocks to checklist items to indicate when the checklist item is complete. If a condition block exists for an item, it's displayed in green when evaluated to true, and yellow otherwise. This provides the user with some feedback that they've completed the checklist item successfully. Documentation is available under Docs/README.checklists, the wiki (http://wiki.flightgear.org/Aircraft_Checklists). The c172p contains a number of examples. I'm thinking of combining this with the tutorial system so you can have a virtual co-pilot go through the checklist, calling out the items for you to complete. I'd be interested to hear if those who like flying heavy iron think this would be a useful function. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated Short Reference for 2.10.0
Hi James, Both HTML and PDF versions of the short reference were checked in (Docs/FGShortRef.pdf). -Stuart On Tue, Jan 29, 2013 at 11:01 PM, James Turner zakal...@mac.com wrote: On 29 Jan 2013, at 21:55, Stuart Buchanan stuar...@gmail.com wrote: I've just pushed a small commit checking in new versions of the FG Short Reference, something I should have done with the updated Manual a while back. How do I generate a nice PDF / similar from this to include in the Mac DMG? (Or can you generate it and email it to me?) James -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Aircraft download page for 2.10.0
Hi Guys, Would it be possible to have auto-filtering of the aircraft download page based on rating for the upcoming release? I know that Gijs did some work in this area prior to the last release, and I think it would really help new users in identifying the really high quality aircraft. -Stuart -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
