Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65
It's now getting on for a week since the build on Simgear was broken for Win 64/MSVC by this mistake. Any chance of a fix sometime soon? Vivian From: James Turner [mailto:zakal...@mac.com] Sent: 03 October 2013 22:53 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Simgear ,mathlib.c line 1 65 On 3 Oct 2013, at 22:20, Alan Teeder ajtee...@v-twin.org.uk wrote: Sorry, but MSVC does not have a round function. ;( Yes, C99 is a cutting-edge spec :) I'll add a replacement for MSVC, thanks for spotting my mistake. Kind regards, James -- 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] Release candidates
Stuart Sent: 30 August 2013 23:30 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Release candidates On Fri, Aug 30, 2013 at 11:41 AM, Stuart Buchanan wrote: Great work James. I should have some time to test over the weekend. Did a quick test on a Windows 7 laptop, and generally looked good. In fact better than good, as under Windows I get x2 the framerate due to a bug in the NVidea Linux driver which meant I could run Rembrandt at a decent frame-rate (until I switched on random buildings whereupon the frame-rate nose-dived)! A couple of things I noticed from a quick flight with the Zero: 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. 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. 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. Vivian -- 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] With best regards...
Thorsten Sent: 20 August 2013 12:31 To: FlightGear developers discussions Subject: [Flightgear-devel] With best regards... ... to Vivian, the converted wake shader appears to be working http://users.jyu.fi/~trenk/pics/als_new_8_13_02.jpg (not sure when I will be able to commit it, but at least the work is done). That sounds like good news, thanks, Vivian -- 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] Changelog 2.12
Stuart Sent: 14 July 2013 23:09 To: FlightGear developers discussions Subject: [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) POI on the map are disabled in Windows (well they are here). Otherwise quite an impressive list. Vivian -- 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
From: Anders Gidenstam [mailto:anders-...@gidenstam.org] Sent: 26 June 2013 07:41 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] reminder: entering feature freeze now On Tue, 25 Jun 2013, Stuart Buchanan wrote: 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 :) . Sounds like a plan. I prefer this option. Makes sense to me, Vivian -- 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] Grain texture for models - a demo
Thorsten wrote Sent: 25 June 2013 10:14 To: FlightGear developers discussions Subject: [Flightgear-devel] Grain texture for models - a demo Since the idea hasn't really caught with modelers yet, I've tried to get a more practical demo of the virtue of a grain texture and tried to put a grain effect on the Vinson flightdeck (I've always felt that the homogeneous grey color doesn't justice to the details of the model otherwise). Here's a comparison http://users.jyu.fi/~trenk/pics/vinson_with_grain.jpg http://users.jyu.fi/~trenk/pics/vinson_without_grain.jpg In my personal view, this makes a hell of a difference. I'm not getting any visible framerate difference, and the GPU memory has to hold just a single 512x512 texture more. If you want to do the same detail level using conventional texturing, you need a texture resolution of 25600x6400 (I'm guessing no GPU can even process this). There's (unfortunately) a catch - the screenshots are taken on the landing strip where the uv-mapping is very homogeneous, but to my surprise I discovered that the rest of the flightdeck has a rather inhomogeneous uv- mapping, i.e. to make the Vinson really make use of the grain effect, the uv- mapping of the Flightdeck would have to be redone. Vinson crew - anyone interested? I'm happy to send the effect definition and the grain texture. We can use this whenever a model has a large crufely textured surface and just should get some hint of metal surface (or any other structure - we can do concrete or wood just as well) - it's tremendous texture resolution for cheap. But I'm a coder, not a modeler, for me things like changing the uv- mapping take unreasonably long, so I would really hope to get folks from modeling interested. I looked at this possibility already. The carrier deck is made up of a number of odd-shaped areas, for historical reasons. I don't think that a complete rebuild of the flight deck is worth it for this very nice eye-candy (just too much work). Alexis might think differently. Vivian -- 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
Thorsten Sent: 18 June 2013 07:40 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] reminder: entering feature freeze now 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: * Get a high-quality model shader running under Atmospheric Light Scattering This is now available, working for random buildings and for several aircraft. A reminder to aircraft creators using the ubershader - normal mapping requires to declare tangent, normal and binormal generation airplane-side. These need to be also declared as vertex attributes in a numbered technique - in order for this to work, the technique n=4 matching the model ubershader effect in model-combined.eff for ALS has to be added, otherwise normal maps do not work and the model receives incorrect lighting. * Implement a scheme for generating autumn colors procedurally The scheme exists and generates autumn colors in central Europe. Since the majority of feedback for this was rather skeptical, I have not pursued the idea much further or extended it to tree autumn coloring, but Stuart has implemented his tree work in a nice way that trees shed all leaves in late autumn, so it's not as good as it could be, but reasonably plausible. At least I like changing the colors a bit. Since autumn coloring doesn't work correctly everywhere in the world (I've mainly adjusted Europe and the North Atlantic Islands), I would regard it as experimental. * make clouds render faster Stuart has done the main work on this one with a LOD scheme dropping sprites beyond some distance. Since this mutilated faint clouds which have just 1-2 sprites to begin with, I recently pushed a way that these clouds are not treated by the LOD system at all. I'd say we need feedback from users playing with the LOD distance if it improves framerates while keeping the visuals or not. We now have overall cloud density, draw distance and the LOD distance to configure the framerate impact of 3D clouds - is this enough? In what form should this best be exposed to the user? What are reasonable defaults? * Improve cloud appearance from high altitude This is mostly done - I've introduced three quite sophisticated cloudlet placement scheme, and it does miracles from high altitude. There are still the rather blocky 8/8 cover scenarios remaining when clouds tend to cover the whole square tile - I wanted to do something to the edges, but haven't gotten around to doing so. Not sure if this qualifies as a bugfix or a novel feature, but I think it's harmless. * The 'ultra' terrain shader This is done - at highest landmass and transition slider setting, the terrain shader renders details to a quality that you can park your helicopter in the scene and have a nice ground resolution (the smallest details are cm-sized, and they move with the wind). From my side, this would be the main selling point for a 3.0 release. The water shader also has received upgrades with color and reflectivty variations of the water and a trick to generate surf at steep coasts. Also drift ice and be procedurally drawn on the water. In arctic regions, we have drifting icebergs by default now. * Regional texturing Since the last release, I've added Indonesia, Madagascar, North Atlantic Islands (Greenland, Faroe, Shetlands,...) and Middle East and Vivian added UK definitions. Combined with Hawaii, Iceland, Caribbean and tropical South America which we've had previously, this is already a substantial variation to illustrate how FG can look like. Especially Hawaii can serve very well as a showcase scenery now. * Atmospheric light scattering and Rembrandt There hasn't been a volunteer to help me look into this from the Rembrandt side, and so according to the plan there has been no development. Based on my current test results, my computer doesn't seem to be able to get Rembrandt fast enough for this to make any sense, although I don't understand this finding. While things can always be better, from my side that's a clear vote for 3.0. With the hires terrain shader and wind effects on terrain and vegetation, combined with the pixel post-processing effects, we can offer much higher resolution visuals on the terrain than before (and I understand with the autum color effect or drift ice some genuine novel effects which are in no other flightsim). 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. Right now we have Terrasync partly broken in Win 64, which will probably not be fixed until after the release. We still cannot select the Screenshot Directory from the gui. I think that all argues for 2.12. Unfortunately, only Fred
Re: [Flightgear-devel] trees
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! Vivian From: syd adams [mailto:adams@gmail.com] Sent: 18 June 2013 19:16 To: FlightGear developers discussions Subject: [Flightgear-devel] trees No one else has mentioned this so maybe its time for a make clean , but this is what Im seeing after the recent tree updates : http://imagebin.org/261806 -- 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] TerraSync libSVN replacement testing
Alan Sent: 17 June 2013 20:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing Does this affect the code freeze? -Original Message- From: Alan Teeder Sent: Tuesday, June 11, 2013 8:12 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] TerraSync libSVN replacement testing James As requested (windows 7, MSVC10 (32bit build): (Sorry) Alan 3 terrasync.cxx 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(58): error C2059: syntax error : 'constant' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(65): error C2238: unexpected token(s) preceding ';' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2146: syntax error : missing ';' before identifier 'failure' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C2270: 'failure' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(67): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(68): error C2059: syntax error : 'private' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(69): error C2270: 'isBare' : modifiers not allowed on nonmember functions 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2143: syntax error : missing ';' before '}' 3C:/FlightGear/simgear\simgear/io/SVNRepository.hxx(74): error C2059: syntax error : '}' 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(90): warning C4067: unexpected tokens following preprocessor directive - expected a newline 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): error C2088: '[' : illegal for class 3C:\FlightGear\simgear\simgear\scene\tsync\terrasync.cxx(124): fatal 3error C1903: unable to recover from previous error(s); stopping compilation 3 Generating Code... -Original Message- From: James Turner Sent: Tuesday, June 11, 2013 4:17 PM To: FlightGear developers discussions Subject: [Flightgear-devel] TerraSync libSVN replacement testing Hi, I've pushed some code to Git, which will ultimately replace our use of libSvn, and hence simplify build and deployment, especially on Mac and Windows. This has an immediate benefit for end-users too: TerraSync will use pretty much half the disk space it currently does, since unlike a real SVN client, we don't need to keep two copies of each file locally. In the longer term, there are many other improvements I will make - to reduce the number of network round-trips to check directories are in sync, to improve the interaction with the main thread so the splash screen waits for terrasync to update a location before finalising position, and others. These things will happen *after* 2.12, and once the code is tested everywhere. First, I need some help; for people to rebuild simgear with - DSG_SVN_CLIENT=1, and mv / erase their TerraSync dir. Then simply run FGFS as normal, as if you were starting on a new machine / account with no previous use of TerraSync. (Remember that TerraSync initially syncs the large Models and Airports dirs, which takes some time - be patient. Also expect some nav-cache rebuilds since the nav-cache will see the paths / stat-times change. This is nothing to do with the revised code, simply what happens if you change your TerraSync dir) If the testing is mostly positive, I will consider making the option default to ON for 2.12, but if people report problems (which cannot be easily fixed!), I will be cautious and leave it OFF by default for 2.12. Soon after 2.12 branches, 'next' will be switched to using the new code exclusively. (BTW, the option to use rsync or external, command-line svnclient still exists, and will be retained - though I am curious if anyone still uses those options!) Haven't managed to get it to work for Win 7 64 bit either - still seems to want LIBSVN to build. Seems to be a cmake issue, but I'm not confident that I know how to fix this one. Vivian -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list
Re: [Flightgear-devel] Rembrandt performance
Thorsten Sent: 13 June 2013 07:25 To: FlightGear developers discussions Subject: [Flightgear-devel] Rembrandt performance I've had a my first short go with Rembrandt on my new machine yesterday. The test case was a small airport in Sulawesi (Indonesia) (WAAJ) where I'm discovering a very nice scenery. There are no static or shared models to speak of, there is some forest around, and that's basically it. I chose fair weather, i.e. a modest cloud cover. The aircraft was the PAF team DR-400 in the latest version. All Rembrandt functions work out of the box very nicely. I started with a dawn scene and tried the landing light illumination first. This gave me a good 30 fps. I then switched to noon and tried shadows. I have to say that since I am more the VFR virtual pilot, I almost never fly at night, lightmap for internal illumination work fine for me, and so shadows are the main selling point of Rembrandt which attracts me. The initial shadows coming up by default were rather ragged and flickery (the last is a problem for me, I tend to get headache when looking at some sort of flickers unfortunately), so I played with shadow map size, cascade ranges and filtering till I had a nice result. To my dismay, at this point the framerate counter gave me a mere 15 fps (no shader effects on at this point). For comparison, the same scene renders in Atmospheric Light Scattering with all details maxed out (including tree motion) with solid 60 fps. Am I doing anything wrong? Did I miss any optimization which makes the shadows run fast enough? Am I just unlucky and my system has some unspecified problems chewing Rembrandt? Does anyone else get significantly higher framerate out of shadows with filtering? I am running on an GeForce GTX 670M, which is usually a pretty fast beast. I mean, maybe it's just me, but this appears to confirm a suspicion I wrote earlier that trying to pack ALS functionality into Rembrandt will end up being way too slow. If I have a mere 15 fps before any shaders, then I can't reasonably apply 800 lines of extra computations and expect no performance impact. Does anyone have a semi-solid case which would argue that this would be fast enough? I'm sort of trying to make my mind up if I should focus on that before the next release (which is why I did the test), but it seems hopeless to me. It's okay and flyable as it stands, but I don't see how to cram lots of extra stuff in. I think your numbers are pretty representative. 15 fps is definitely not enough IMO. I would say that 30 fps would be a good aiming point. Smoothness is also a factor. Vivian -- 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] Bug 772 (Yasim on ground)
James Sent: 11 June 2013 13:09 To: FlightGear developers discussions Subject: [Flightgear-devel] Bug 772 (Yasim on ground) Hi all, Hyde has submitted a work-around for issue 772, which you can see here: https://gitorious.org/fg/flightgear/merge_requests/1572 He'd like this merged before the freeze (actually it's a fix so it can be merged afterwards, but still), I'd like to hear any opinions on if this is a bad idea or good idea. Personally I'm not so affected by issue 772, but if many people are, the work-around seems just-about-acceptable to me. (Obviously it would be nicer to fix Yasim for real, but let's skip that just for a moment) Does anybody feel strongly that either: - the bug is very bad, so that the workaround is definitely needed (keeping in mind it's a long-standing bug) - the work-around is very bad, for some scenario I didn't imagine myself? (Helicopters on the ground? But they likely benefit more from the fix?) I'm happy to merge the change above to get some feedback, with the understanding that if people raise 'problems which are worse than the original issue' before 2.12 is final, we could revert it. I haven't noticed any particular issue with crosswinds myself, but the fix seems to be illogical. I can't imagine what disabling wind on the ground is going to do for take-offs. How would the transition work? Has anyone shown that there is anything wrong with Andy's math? I'd like to hear what Andy has to say about this one. In the meantime I would object to this fix. Vivian -- 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] Bug 772 (Yasim on ground)
Gary I agree with all of this. I have just tested the 777-200 in a moderate crosswind. First time I ever used it. There is a tendency to fly up into wind once the main wheels are on the deck, but nothing which can't be handled with a bootfull of rudder. Perhaps a little more rudder authority would be nice. I would leave well alone unless and until Andy advises otherwise. Vivian From: Gary Neely [mailto:grne...@gmail.com] Sent: 11 June 2013 18:33 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 772 (Yasim on ground) With respect, I'd prefer to hold off on this fix until we have more test data and additional input by experienced Flightgear users. Which planes exhibit this tendency under what exact conditions? What version of Flightgear is being used? Under what OS? Did this effect begin to occur after a specific Flightgear release? Currently I've not experienced anything as severe as what some of the bug posters describe, at least not with aircraft having well-designed and tuned YASim FDMs. Admittedly I fly only a handful of planes, usually my own efforts. I do know that YASim friction effects are not what they could be, and this can be aggravated by poor friction settings or settings that have been compromised to offset some other characteristic. Many YASim planes don't have adequate weight-and-balance settings and commonly aren't tested against pilot handbook crosswind limitations. Because of this they often handle terribly under those conditions, with even modest crosswinds. I know this because I've adjusted the balance and flight surface effects of a number of YASim planes to allow them to handle crosswinds up to the handbook's limits. I'm not suggesting this is necessarily related to the bug problem, only that the bug needs to be tested against aircraft with YASim FDMs that have been designed to reflect the aircraft's limitations. -Gary aka Buckaroo -- 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] Bug 772 (Yasim on ground)
James, Done Vivian From: James Turner [mailto:zakal...@mac.com] Sent: 11 June 2013 22:43 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 772 (Yasim on ground) On 11 Jun 2013, at 22:01, Hyde Yamakawa h...@hyde-tech.com wrote: Hi, I'm a guy who submit that fix. I tested today without my fix, I noticed it's been fixed!! There still be the pulling power but it's controllable by steering now. I'm sorry to bother all of you but I didn't know it was fixed. I gladly withdraw my request. I will report what change fixed the issue later. Okay, thanks to everyone for looking at this, if someone could update the issue as WontFix or Invalid for now it's probably wise, it can always be re-opened if someone disagrees. Regards, James -- 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] Hires runway effect
Thorsten Sent: 07 June 2013 12:40 To: FlightGear developers discussions Subject: [Flightgear-devel] Hires runway effect After a fresh pull and recompile today (I've not had much time for FG the last weeks...) I've noticed that the hires runway effect of ALS appears to have been partially broken by something - I now see a checkerboard pattern when I look at runways and taxiways which hasn't been there before. Is anyone else observing this? Since I've not done anything for the last weeks, something other than the shader must have caused this (coordinate mapping? altered normal?). Can anyone perhaps shed light on this? Unfortunately I still don't have much time right now for a long investigation :-( I can't see a problem here with today's pull of fg/sg/fgdata. The tree wind effect is nice. Vivian -- How ServiceNow helps IT people transform IT departments: 1. A cloud service to automate IT design, transition and operations 2. Dashboards that offer high-level views of enterprise services 3. A single system of record for all IT processes http://p.sf.net/sfu/servicenow-d2d-j ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Restore GPS compatibility with 2.10 - MSVC10
Alan Sent: 01 June 2013 14:51 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Restore GPS compatibility with 2.10 - MSVC10 Stop the celebrations. The laptop still has the fault after a clean build. AFAIK both computers have the same file layout and relevant environment/paths settings. My Bill Gates mannequin now has so many nails in it that it is hard to find space to hammer in a new one. Yup, FG crashes here with the latest pull of SG/FG on Win 7 x64 Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Restore GPS compatibility with 2.10 - MSVC10
James Sent: 01 June 2013 17:28 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Restore GPS compatibility with 2.10 - MSVC10 On 1 Jun 2013, at 16:20, Vivian Meazza vivian.mea...@lineone.net wrote: Yup, FG crashes here with the latest pull of SG/FG on Win 7 x64 A bit of information would be useful since it's not crashing for me :) Alan provided a backtrace but it looks suspect to me, of course if it's memory corruption that may be expected, but I'd appreciate someone running 3-4 attempts and checking if the dump is mangled and different each time (likely memory corruption) or in the same place consistently (could still be memory corruption, but easier to track down). OK - so far I've identified that the cause is one of the 2 GPS related commits - reverting both solves the problem. Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart Sent: 19 May 2013 21:42 To: FlightGear developers discussions Subject: 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. That all looks very good here. No artefacts that I can see, no clipped trees. Job done for now, I would say. Well Done Vivian -- 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] Who is the maintainer for FGRUN?
Pat Sent: 18 May 2013 17:20 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Who is the maintainer for FGRUN? Who is the maintainer for FGRUN? Also, who is interested in the cmake build issue with FGRUN and FGADMIN on Ubuntu 13.04 Fred Bouvier is your man. Vivian -- 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
Stuart Sent: 14 May 2013 09:34 To: FlightGear developers discussions Subject: 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. 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. 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 - I 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. HTH Vivian -- 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
: Stuart Sent: 16 May 2013 22:46 To: FlightGear developers discussions Subject: 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. 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. Vivian -- 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
Stuart -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 10 May 2013 22:50 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Tree issues Stuart Sent: 10 May 2013 20:10 To: FlightGear developers discussions Subject: 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. OK trying that 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. Vivian -- 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
Stuart Sent: 09 May 2013 21:41 To: FlightGear developers discussions Subject: 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. You did indeed add some code - and I have tested it here on 2 machines and on 2 instances on one machine. It doesn't seem to do what you intended. https://dl.dropboxusercontent.com/u/57645542/clouds.png I ensured that the 3D cloud settings were the same, using the same live data. Do I need to do anything else? Vivian -- 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
Stuart Sent: 10 May 2013 20:10 To: FlightGear developers discussions Subject: 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. OK trying that Vivian -- 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
Stuart From: Buchanan [mailto:stuar...@gmail.com] Sent: 08 May 2013 10:56 To: FlightGear developers discussions Subject: 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? General advice that I can find is that GLSL is designed as a linear program: conditionals and loops are best avoided: http://stackoverflow.com/questions/2614622/tips-for-efficient-glsl-code Here's some stuff on textures. http://www.arcsynthesis.org/gltut/Texturing/Tutorial%2014.html I don't think the shape matters as much as the overall size. As I understand it, GLSL optimizes the storage. In this case new the texture would be 4 times as big. I don't think that's optimal, but on the other hand, it's not pushing the envelope. Do you use a shader analyser? I use the AMD one: http://developer.amd.com/tools-and-sdks/graphics-development/gpu-shaderanaly zer/ might help to decide which route to take HTH Vivian -- 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
Brandano, It's possible that it comes from FGRun, but a Nasal warning from the 3d preview code seems a bit implausible. It is recent thing, though. Vivian From: TDO Brandano [mailto:tdo_brand...@hotmail.com] Sent: 08 May 2013 22:12 To: Flightgear Devel List Subject: Re: [Flightgear-devel] 2.10.1 If It's an FGRun problem maybe it's caused by the 3D preview code parsing the planes _ From: gijsr...@hotmail.com To: flightgear-devel@lists.sourceforge.net Date: Wed, 8 May 2013 20:57:33 +0200 Subject: Re: [Flightgear-devel] 2.10.1 Hi Stuart, Failed to set alias to /controls/refuelling/refuelling-drogues-pos-norm I think I've seen that with all aircraft I've flown recently. IIRC they were all non-AAR capable (as in, they had no AAR stuff in -set.xml) but I'm not near my computer, so I cannot confirm that theory. It's even weirder than that. I see the messages in the console whenever I launch FGRun. No matter what aircraft is loaded by default (last flown plane), I always get these lines as soon as FGRun opens; so before starting fgfs. 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 Cheers, Gijs -- 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 -- 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] New features for 3.0 (?) presentation
Tom Sent: 07 May 2013 10:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New features for 3.0 (?) presentation 2013/5/7 Vivian Meazza vivian.mea...@lineone.net: The tracking animation sounds useful - do you have any documentation available? In due course it should end up in fgdata/Docs/model-howto.html with all the other animations. I have now added some examples and a basic documentation to the wiki: http://wiki.flightgear.org/Tracking_animation I will add some more info and images once I find some time for it. Thanks, interesting. As a non-Blender user (it makes my brain hurt) the references are a bit obscure. Are the various axes always orthogonal? Can they also be specified in the alternate form: axis x1-m5.1821/x1-m y1-m0.221496/y1-m z1-m0.794147/z1-m x2-m4.99208/x2-m y2-m0.114133/y2-m z2-m0.842884/z2-m /axis If non-orthogonal axes are allowed they are difficult in the center/axis form in the example in the wiki. Perhaps, when you have time, the information could be consolidated in http://wiki.flightgear.org/Howto:Animate_models and fgdata/Docs/model-howto.html Looks like valuable work to me: gear scissor links were very difficult with the existing animations. Vivian -- 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] New features for 3.0 (?) presentation
Tom Sent: 06 May 2013 23:11 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] New features for 3.0 (?) presentation Am 2013-05-06 10:35, schrieb Renk Thorsten: If you know of anything else which makes good publicity and can be explained in a picture and a paragraph of text, let me know or better let me have the picture and paragraph of text (preferably by the end of the week). * Canvas instances can now be placed on scenery objects. This allows for example creating animated signs/monitors. I've started to create a Visual Docking Guidance System, which is not fully functionally yet but should be complete enough to be used for a screenshot (eg. azimuth guidance is missing) * The new tracking animation (similar to Blender's locked-track constraint) allows easily animating complex kinematic systems. For examples gear scissors, landing gear doors attached to struts (also with links and joints in between) or also torque struts connecting multiple gears with independent compression while still tracking each other can be realized. Also any type of strut for eg. cargo ramps can be easily animated. If you want I can create a video of my work in progress C-130J making use of these animations. The tracking animation sounds useful - do you have any documentation available? In due course it should end up in fgdata/Docs/model-howto.html with all the other animations. Vivian -- 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
Tom -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 04 May 2013 08:27 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] 2.10.1 Am 2013-05-03 19:15, schrieb Vivian Meazza: Check your IOrules! (write to 'Z:/do-not-access' is allowed) Check your IOrules! (read from 'Z:/do-not-access' is allowed) Have you installed a recent fgdata? If so these messages should not appear. Not for a couple of days, I'll update again. Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.1
Tom -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 04 May 2013 09:20 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] 2.10.1 Tom -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 04 May 2013 08:27 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] 2.10.1 Am 2013-05-03 19:15, schrieb Vivian Meazza: Check your IOrules! (write to 'Z:/do-not-access' is allowed) Check your IOrules! (read from 'Z:/do-not-access' is allowed) Have you installed a recent fgdata? If so these messages should not appear. Not for a couple of days, I'll update again. That cured it - one less alert - good Thanks Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.1
James, 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 ALC Error (sound manager): Invalid Enum at context creation. Check your IOrules! (write to 'Z:/do-not-access' is allowed) Check your IOrules! (read from 'Z:/do-not-access' is allowed) Image D:/Git_New/my_fgdata/Textures.high/Terrain/transition1.dds uses compressed textures which cannot be supported on some systems. (about 50 times) These are all of interest to developers only: they are not something about which the user can do anything, so I would suggest that they are downgraded to warnings for the release from their current alert status. 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. Otherwise, I reckon we're good to go so far as Win 7 is concerned. I will have a look with XP later if you would like. Unless that is there's been something since last night . Vivian From: James Turner [mailto:zakal...@mac.com] Sent: 03 May 2013 12:17 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] 2.10.1 On 30 Apr 2013, at 23:22, Saikrishna Arcot saiarcot...@gmail.com wrote: Are there still any plans to release a 2.10.1? I've been very busy the past few weeks, but in theory the binaries are done and exist (on Jenkins) for Windows, Mac and Linux. After some testing, It just needs 'someone' to upload/mirror them I guess. Did any test the Windows installer from Jenkins yet? Regards, James -- 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://p.sf.net/sfu/appdyn_d2d_ap2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart, Sent: 01 May 2013 22:09 To: FlightGear developers discussions Subject: 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. I part-solved the screenshot issue. Here's a pic of the hats on the middle distance trees: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-015.png You have to be really eagle-eyed to spot them, if you change the viewing angle or zoom in they disappear. Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Alan Sent: 03 May 2013 20:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues -Original Message- From: Vivian Meazza I part-solved the screenshot issue. Here's a pic of the hats on the middle distance trees: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-015.png You have to be really eagle-eyed to spot them, if you change the viewing angle or zoom in they disappear. Vivian They look like stork nests to me. ;-) Now all is that is needed are some storks and their chicks. I suppose you will want regional variations to match the stork populations? Ever noticed the bloody great gulls we have winging around the scenery? Well - I suppose it would be doable ... Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Alan Sent: 03 May 2013 22:38 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues They look like stork nests to me. ;-) Now all is that is needed are some storks and their chicks. I suppose you will want regional variations to match the stork populations? Ever noticed the bloody great gulls we have winging around the scenery? Well - I suppose it would be doable ... Vivian - I thought that the storks and gulls were part of the scheme to mark thermals for glider pilots. How did they get into the tree texture code? Birds live in trees - simples. Vivian -- 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://p.sf.net/sfu/appdyn_d2d_ap2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tree issues
Stuart -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 01 May 2013 23:39 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Tree issues : Stuart Sent: 01 May 2013 22:09 To: FlightGear developers discussions Subject: 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. Trying that. 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. I would send a screenshot - but that's still stuck here trying to write to the wrong place. Vivian Vivian -- 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] Lightmap question
Tom, -Original Message- From: Thomas Albrecht [mailto:ra...@web.de] Sent: 30 April 2013 23:48 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Lightmap question Dear shader experts, Can I have a single-channel lightmap, and still use a vec3d in my model.xml to end up with green or red (or whatever) light rendered? As in (roughly) on_screen_color[0] = lightmap-grey-value * vec3d[0] * texture[0] on_screen_color[1] = lightmap-grey-value * vec3d[1] * texture[1] on_screen_color[2] = lightmap-grey-value * vec3d[2] * texture[2] where texture is the base model texture? Docs/README.model-combined.eff says lightmap-color type=vec3d n=0 1.0 1.0 1.0 /lightmap-color - the color of the light for the red channel in the light-map. etc for green and blue channels, but when I use this line, FG complains Failed to load xml: Unrecognized data type 'vec3d' Failed to load model: Unrecognized data type 'vec3d' I guess this works only for multi-channel lightmaps? I.e. with lightmap-multi type=int1/lightmap-multi My .xml looks like this: effect inherits-fromEffects/model-combined-deferred/inherits-from parameters lightmap-enabled type=int1/lightmap-enabled texture n=3 imagetex/DSCF9503_noroofsec_pow2_LM.png/image wrap-srepeat/wrap-s wrap-trepeat/wrap-t /texture !--lightmap-color type=vec3d n=0 1.0 5.0 0.2 /lightmap-color -- lightmap-factor type=float n=01.0/lightmap-factor /parameters object-nameb606/object-name object-nameb610/object-name /effect The lightmap is working correctly - take a look in the b1900d or the b777. The error: Failed to load model: Unrecognized data type 'vec3d' Indicates that you might be using type=vec3d somewhere inside an animation tag - it's only valid in an effect tag. Hth Vivian -- 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] Lightmap question
Tom -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 01 May 2013 08:47 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Lightmap question Tom, -Original Message- From: Thomas Albrecht [mailto:ra...@web.de] Sent: 30 April 2013 23:48 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Lightmap question Dear shader experts, Can I have a single-channel lightmap, and still use a vec3d in my model.xml to end up with green or red (or whatever) light rendered? As in (roughly) on_screen_color[0] = lightmap-grey-value * vec3d[0] * texture[0] on_screen_color[1] = lightmap-grey-value * vec3d[1] * texture[1] on_screen_color[2] = lightmap-grey-value * vec3d[2] * texture[2] where texture is the base model texture? Docs/README.model-combined.eff says lightmap-color type=vec3d n=0 1.0 1.0 1.0 /lightmap-color - the color of the light for the red channel in the light-map. etc for green and blue channels, but when I use this line, FG complains Failed to load xml: Unrecognized data type 'vec3d' Failed to load model: Unrecognized data type 'vec3d' I guess this works only for multi-channel lightmaps? I.e. with lightmap-multi type=int1/lightmap-multi My .xml looks like this: effect inherits-fromEffects/model-combined-deferred/inherits-from parameters lightmap-enabled type=int1/lightmap-enabled texture n=3 imagetex/DSCF9503_noroofsec_pow2_LM.png/image wrap-srepeat/wrap-s wrap-trepeat/wrap-t /texture !--lightmap-color type=vec3d n=0 1.0 5.0 0.2 /lightmap-color -- lightmap-factor type=float n=01.0/lightmap-factor /parameters object-nameb606/object-name object-nameb610/object-name /effect The lightmap is working correctly - take a look in the b1900d or the b777. The error: Failed to load model: Unrecognized data type 'vec3d' Indicates that you might be using type=vec3d somewhere inside an animation tag - it's only valid in an effect tag. Hth My previous answer wasn't all that helpful now that I read it again. You can do what you want, but not inline in the model.xml file - the type=vec3d is not recognized anywhere outside an effect and is causing the error. Do your effect config in a local .eff file, then inherit from that in your model. Hope this is a better explanation Vivian -- 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] Atmospheric Light Scattering
Heiko Sent: 30 April 2013 18:46 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric Light Scattering Now, sorry, FG snapshots With ALS and Without Rembrandt https://sites.google.com/site/grtuxhangarctd/other-download/ P-38_demo1.png Who said we don't need a specific version when using ALS ? I have to wonder- because you don't need a specific version for ALS! Use the shader as it is in current FGData and it will work in ALS, Default- renderer and Rembrandt. The only thing is, that lightmaps, as possible in ALS and Default Renderer, doesn't look all to good in Rembrandt in combination (!) with light volumes. But this can be solved. One model, one version- three renderer. FlightGear! That's not quite right: you should be able to use one _effect_ across all rendering schemes, but under the hood different flavours of shaders do the work. Depending on a number of factors - weather mode selected/light implementation, the outcome on the model can look quite different. I would guess that is what we are seeing on the P38 examples shown (and that's quite some model - wow!). We have recently broken that principle with the grain effect - it only works in ALS. But you are quite right to say that we don't need special models for ALS/Default/Rembrandt rendering schemes. You might choose to implement features in Rembrandt, and then you might want to add different features so that those features would still work in the default and ALS schemes, but you don't have to. A good example of that might be landing lights that are implemented on a particular model under Rembrandt, but are simply absent in other schemes. Apart from making sure that transparencies work in Rembrandt, a modeller doesn't have to anything at all to the effects to make them work right across the board. Vivian -- 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
: Stuart Sent: 01 May 2013 22:09 To: FlightGear developers discussions Subject: 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. Trying that. Vivian -- 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] BUG REPORT Failed Ground Vehicles following waypoints
Michelle, Oh! I didn't know anyone used ground vehicles apart from me - I'm very encouraged J. It's my code, I'll check up on it. Vivian From: Chelley [mailto:chel...@mypostoffice.co.uk] Sent: 28 April 2013 03:45 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] BUG REPORT Failed Ground Vehicles following waypoints AI ground vehicles NO longer following waypoints, this is a major problem for me as I have a few AI models that are supposed to follow way-points like the car and he just drives across country in a straigt line now instead of following the roads as the way-points in (data\AI\FlightPlans) in all version of flightgear since 2010 seem to be just ignored. I have no doubt all the AI ground vehicles including the train in there suffers the same problem. I have spent hours looking through the AI stuff for all my downloaded FGDATA version going back about 4 years and this has been broken a very long time now. Unless someone who knows about the AI stuff can fix this it is going to prevent most of us who use AI Ground vehicles from making use of this feature in flightgear. Michelle -- 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] BUG REPORT Failed Ground Vehicles following waypoints
Michelle, Works here: http://youtu.be/8NW9XdOefCg Can you tell me some more? Vivian From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 28 April 2013 08:25 To: 'Chelley'; 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] BUG REPORT Failed Ground Vehicles following waypoints Oh! I didn't know anyone used ground vehicles apart from me - I'm very encouraged J. It's my code, I'll check up on it. Vivian From: Chelley [mailto:chel...@mypostoffice.co.uk] Sent: 28 April 2013 03:45 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] BUG REPORT Failed Ground Vehicles following waypoints AI ground vehicles NO longer following waypoints, this is a major problem for me as I have a few AI models that are supposed to follow way-points like the car and he just drives across country in a straigt line now instead of following the roads as the way-points in (data\AI\FlightPlans) in all version of flightgear since 2010 seem to be just ignored. I have no doubt all the AI ground vehicles including the train in there suffers the same problem. I have spent hours looking through the AI stuff for all my downloaded FGDATA version going back about 4 years and this has been broken a very long time now. Unless someone who knows about the AI stuff can fix this it is going to prevent most of us who use AI Ground vehicles from making use of this feature in flightgear. Michelle -- 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] Heads Up - SimGear fails to build under MSVC10
Tom -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 28 April 2013 21:17 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads Up - SimGear fails to build under MSVC10 Am 2013-04-27 14:44, schrieb Vivian Meazza: This morning's pull of SG fails to build here under MSVC10 with the following error: error LNK1169: one or more multiply defined symbols found test_animations.exe This seems to be a bug introduced with Visual Studio 2008 while using multiple libraries which have classes deriving form i/ostream. I've pushed a workaround/linker flag which at least allows compiling the tests. I don't know if they run correctly, but it only affects the test and not SimGear itself. Trying that Vivian -- 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] Heads Up - SimGear fails to build under MSVC10
Tom -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 28 April 2013 22:21 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Heads Up - SimGear fails to build under MSVC10 Tom -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 28 April 2013 21:17 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Heads Up - SimGear fails to build under MSVC10 Am 2013-04-27 14:44, schrieb Vivian Meazza: This morning's pull of SG fails to build here under MSVC10 with the following error: error LNK1169: one or more multiply defined symbols found test_animations.exe This seems to be a bug introduced with Visual Studio 2008 while using multiple libraries which have classes deriving form i/ostream. I've pushed a workaround/linker flag which at least allows compiling the tests. I don't know if they run correctly, but it only affects the test and not SimGear itself. Trying that Yes, that works - thanks Vivian -- 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
[Flightgear-devel] Heads Up - SimGear fails to build under MSVC10
Hi This morning's pull of SG fails to build here under MSVC10 with the following error: error LNK1169: one or more multiply defined symbols found test_animations.exe Jenkins has also failed. The workaround is not to build test_animations.exe Vivian -- 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] Heads Up - SimGear fails to build under MSVC10
Tom,
Sent: 27 April 2013 13:09
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Heads Up - SimGear fails to build under
MSVC10
Am 2013-04-27 13:21, schrieb Vivian Meazza:
Hi
This morning's pull of SG fails to build here under MSVC10 with the
following error:
error LNK1169: one or more multiply defined symbols found
test_animations.exe
Does it help if you remove ${OPENSCENEGRAPH_LIBRARIES} from
simgear/scene/model/CMakeLists.txt:62?
Trying that
Vivian
--
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
Thorsten Sent: 27 April 2013 08:11 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric Light Scattering That said - I don't see why an Atmospheric Light Scattering scheme should have embedded in it some ac modelling stuff. That serves to diverge the schemes. And it makes it look like ALS is your private sandbox. Offering new and different options is the whole point of having a different scheme. What would be the point of having Rembrandt if it were to look just as the default scheme and would not offer novel options? You think these options should be limited to the sky (and terrain?) - fine, I don't, I think they may well affect models, trees, all the visuals. Since Emilian accused me of wanting to rule FG anyway - just what would happen if I would start editing some new effects also into Rembrandt or default? Or if I would decide myself how Basic Weather needs to interact with ALS? Let me give you the answer: I would get the same accusations 10 times over - and (at least partially) rightfully so. It's not my call to make - it's up to the maintainers of Basic Weather (Rembrandt,...) to decide what to include and how. There's simply no pleasing some people - if I introduce new effect in my framework, you complain about diverging schemes, if I would do it everywhere you would be complaining that I can't simply make such decisions on my own. So in your book, I just shouldn't introduce any novel effects at all unless you approve? (You didn't say this, but it pretty much follows.) You can't be serious. Last time I checked, I designed or ported something like 95% of the code of ALS. Stuart did some work on the trees, Lauri did the original skydome shader before haze, Emilian contributed insights, corrections and tests to the ported model ubershader - and that's basically it. So I guess that makes me the current maintainer of the scheme. What you (and Henri) are really saying here that you guys should really have a vote on where the scheme is going without investing work into it (and ironically enough, you're both not even users of the scheme), and you should even be able to overrule my own judgement on what is important and how things get implemented and be able to tell me what I should be working on first. Just since when did we start doing things that way in FG? I fully accept that decisions which affect other subsystems, potentially disable them or require substantial action by others must be discussed and voted on, and that coding e.g. an explicit preference for one weather system over the other is a bad thing. So if the choice were that we can have either Rembrandt or ALS, we'd need to have a discussion and a vote. But that's not the case. Thus, you don't get to overrule me if I consider implementing wind effects more useful than the wake effect. You can bring up your case, you can ask nicely, we can have a discussion, but as long as you expect me to do the work, you'll have to live with my decisions and wait till your request reaches the top of my to-do list (in the case of the wake, I have already stated that it's on the to-do list - same with the rainbow). You can do it yourself if it has a higher priority for you (in which case I offered help and expect the customary amount of coordination with what I'm doing, same as if I would start working on one of your aircraft), you can convince anyone else to do it (in which case I'll also help), and that's how it works everywhere else in FG. If I want a particular feature for an aircraft, I ask nicely and try to be convincing, I don't go around claiming the aircraft is broken every time. Why is this mode not acceptable to you? You know, I don't want any special treatment here - I just want that the same standards are applied to me which apply to other people (specifically also you and Emilian). And I can't see that in what you say - I'm always held to much stricter standards. Vivian, for all your eloquence, I don't get the impression that all this is the real sticking point - what is _really_ bugging you here? You're not a user of ALS, I haven't seen it on in any of your screenshots. You're not affected personally by anything I do. I told you I will put the rainbow back and I will implement the wave, and we're in the middle between release periods, just when it's officially time to introduce new features with the idea to consolidate towards the release. So there can't be any serious concern at this point that users might not get to see and appreciate your work sufficiently. You argue against the hypothetical case that you might potentially have to adjust your aircraft for ALS even when this is not factually the case. At every opportunity, you speak up against the way Advanced Weather is done. You implemented, together with Emilian, an environment for the water shader which explicitly favours Basic Weather over Advanced
Re: [Flightgear-devel] Heads Up - SimGear fails to build under MSVC10
Tom
-Original Message-
From: Vivian Meazza [mailto:vivian.mea...@lineone.net]
Sent: 27 April 2013 13:19
To: 'FlightGear developers discussions'
Subject: RE: [Flightgear-devel] Heads Up - SimGear fails to build under
MSVC10
Tom,
Sent: 27 April 2013 13:09
To: flightgear-devel@lists.sourceforge.net
Subject: Re: [Flightgear-devel] Heads Up - SimGear fails to build
under
MSVC10
Am 2013-04-27 13:21, schrieb Vivian Meazza:
Hi
This morning's pull of SG fails to build here under MSVC10 with the
following error:
error LNK1169: one or more multiply defined symbols found
test_animations.exe
Does it help if you remove ${OPENSCENEGRAPH_LIBRARIES} from
simgear/scene/model/CMakeLists.txt:62?
That gives me 5041 errors! Unless I did something wrong ...
Vivian
--
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
Stefan On Saturday 27 April 2013 13:31:33 Vivian Meazza wrote: What is the real problem? I've got a little list: I don't want to download fgdata/fg/sg to find that I have to spend hours fixing up my work. I'd rather get on with my own stuff. I don't want to download fg/sg to find that it won't build. I don't want to download fgdata to find things which used to work. I don't want to have frame-rates of less than 40 and/or jittery. Well then the problem cannot be as large as it looks like since ALS does not cause any of those. I don't want to force users to choose between a nice atmospheric effects or shadows, or anything else. I don't want to force developers to develop ac for one scheme/framework rather than another. Then why have I not read a single email about how Rembrandt diverges from the default rendering scheme and forces users to choose or that aricraft developers have to make adjustments? I only read about ALS which is much less of a problem, since I can use any airplane with it and can turn it on or off at runtime without a problem, so as a user I don't have to decide up front. I don't want to open the Devel List to find yet another storm with Thorsten at the centre of it. And finally - I feel really strongly about this one: I don't want anyone to feel that they have to leave the project because of acrimonious discussions on this list or anywhere else. It has happened only rarely, but I regret each and every one. So why are you with those who are driving Thorsten away if you feel so strongly about this point? If you don't want a shit storm why are you happily contributing to it and siding with people who call others racist just for refusing a huge feature commit during a feature freeze? I know this is unrealistic, but we should all be striving along these lines. I'm horrified that you have received hate-mail. This is only a flight sim for goodness sake. We have a long tradition here of friendly and orderly debate. These are probably the most reasonable sentences within this whole debate. Please re-read what I wrote. I'm not taking sides for or against Rembrandt or ALS - I want them to converge. They are both excellent contributions to FG, and should not be considered to be alternatives or rivals. Did I say that ALS causes jitter or frame rates less than 40? My list appertains to all of FG/SG. You have jumped to conclusions. And before jumping check your facts: AFAIK Rembrandt does not depart from the default rendering scheme. If you think it does tell me where. It remains experimental/WIP which is why the user cannot click to access it. Hey, who has Thorsten upset - the Mafia? You'll be telling me that there's a horse's head in his bed next. I certainly don't side with those calling anyone else racist or trying to drive anyone away - I am unaware of that and I don't care to be associated with it. Vivian -- 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
Curt, There is a proposal to go to higher resolution trees in the near future - Thomas Albrecht has said he will be working on that in the coming year: http://www.flightgear.org/forums/viewtopic.php?f=5 http://www.flightgear.org/forums/viewtopic.php?f=5t=19265start=15#p179241 t=19265start=15#p179241 It might be opportune to rationalise our tree texture structures to take that into account. Vivian From: Curtis Olson [mailto:curtol...@flightgear.org] Sent: 26 April 2013 01:27 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Tree issues Vivian, Your description makes sense in conjunction with a mipmapping issue. Think about how mipmapping works. The default mipmap generation algorithm creates the 1/2 size image by averaging each 2x2 block of pixels in the higher level down to 1 pixel in the next level. Then repeat, generating the 1/4 size image from the 1/2 size image. You can see that at smaller image sizes, each pixel will draw information from a wide block of pixels out of the original so there can be a lot of bleeding across. This also impacts alpha levels so transparency is another one that doesn't usually mipmap as you'd expect/wish. Note to people who hadn't noticed this before -- the requirement that texture sizes be powers of two allows the mipmapping level creating scheme to be well defined, and if your texture dimensions aren't an even power of two, they are probably getting scaled to the next size down under the hood when they are loaded by OSG. I'm not sure what to do about the tree problem though -- it might help to divide up the internal image into power of 2 chunks, go 4 trees across the texture rather than 5 (just for example.) That might split down further before producing artifacts if we aren't already doing that. (?) I've heard graphics guru's speak of using other algorithms to generate the mip map levels, or even manually creating them. In some cases I think you need to consider this sort of thing even though it's a pain and blows up the size of the distributed texture if we need to also include the pregenerated mipmap levels. Curt. On Thu, Apr 25, 2013 at 5:50 PM, Vivian Meazza vivian.mea...@lineone.net wrote: Stuart 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. 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 would give you some screenshots - but that's broken here. Vivian -- 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 -- Curtis Olson: http
Re: [Flightgear-devel] Atmospheric Light Scattering
James, Terrasync now works entirely as expected here - but not quite as you describe. I can enter a path at the gui, and then stop and restart Terrasync from the gui and it will download to the new directory. Of course, the scenery directories remain as they were defined at startup. We can reload scenery at runtime, so perhaps it would be nice to change the Terrasync scenery as well - not quite sure about that because I can envisage situations when it would be advantageous to download to one directory while using another. Vivian From: James Turner [mailto:zakal...@mac.com] Sent: 26 April 2013 08:50 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Atmospheric Light Scattering On 25 Apr 2013, at 22:23, Stuart Buchanan stuar...@gmail.com wrote: Thanks for investigating Stuart! 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. Okay, that's interesting indeed. Keep in mind I've not made an explicit changes to the screenshot directory code, but I have changed the file picker logic recently, which I assumed would be the likely cause. However Windows and Linux use the same code paths for the file-picker. Based on Vivian's report that the path is bad, something else must be going on for him (and other Windows users?) 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 :) Whoops, that is entirely my fault. Many apologies. 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! Okay, I did always wonder why the option was added :) Personally I am pushing people to always use the default TerraSync location unless they are doing 'something special' in which case an entry in fgfsrc seems a better solution to me. I.e keep the GUI simple for the common case, and ensure the advanced case is possible via config files. Changing the code to allow run-time switching of the terrasync dir, and the scenery paths, is not impossible but it would be a fairly large amount of effort, not a worthwhile use of time from my point of view. Regards, James -- 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
Thorsten ALS is very impressive work, but things broken? Have you forgotten the flag shader (now fixed), wake effect and rainbow effect? I don't have a particular problem with these and hope that they will be fixed eventually, although I note that do you seem to have raced on to other things while leaving the wake effect unfixed for some time. I rather fear that that's just going to get lost in the noise and general excitement over the latest bit of eye-candy. That is what I tried to explain in length. My definition of broken is 'used to work, there was a change, now doesn't work'. What is yours? The wake effect used to work in default, and now still does. The wake effect never worked in ALS and now still doesn't. There's nothing broken here, you are talking about non-existing features and a feature request to implement them. Which is very different from breaking existing things. To give you the reverse example - procedural texturing works in ALS but not in Rembrandt - so does this imply it's broken in Rembrandt? Cloud shadows don't work in either Rembrandt or ALS - does that imply we've broken them? Nope - they never existed, and you can make a feature request to implement them. In the event, your feature request for the wake effect is noted, but not my top priority - I prefer to race on to the next bit of eye candy (as you put it) because the wake effect is a very localized effect, whereas I want to address some world-wide stuff which affects a few billion pixels more first. You're welcome to implement it yourself, and I'll be happy to assist you if that is needed. To call a non-existing feature with a feature request attached 'broken' generates a completely wrong impression and a sense of urgency which really isn't there. 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) This may be a question of philosophy, but I don't think OpenSource fares badly with this approach in general. As a Linux user I get a choice between Gnome, KDE and a host of other desktop environments - and I rather like that, I can pick what suits me best. As an aircraft developer, I can pick JSBSim or YaSim, whatever suits me best. So why should we not offer different rendering approaches dependent on what the user wants to burn the framerate for? I don't see this at all as a problem, I rather see it as a huge opportunity. We can ship one rendering approach for the low end graphics cards and are then not restricted in what we offer for the high end. How exactly is that a bad thing? As a developer I have only just finished making my models Rembrandt compatible, and I don't know if I will ever be able to actually make use Rembrandt facilities in all of them. You'll have noticed that the ALS ubershader (short of inserting the tangent, normal and binormal attribute for normal maps which I understand really _must_ be airplane-side) works out of the box without any action required in ALS. So there is no need to make your models ALS compatible, this is not a real problem, but a hypothetical one. The worst case by the way is not that the aircraft can't be flown as in Rembrandt, because you can't see out of the cockpit, the worst case is that your normal map doesn't work. As I understand it, ALS will include modelling facilities which will not work in the other flavours of FG. How is this meant to be used? Optionally. *sigh* When you and Emilian wrote the default ubershader, it provided new features. These were offered to the airplane developers as options - it was their choice to make use of them or not. Now ALS offers an ubershader which might get additional features. There are offered to airplane modellers as options. Just why is it okay if you do it, but problematic if I do it? Yes, they may not work in Rembrandt - and Rembrandt has AO, and bloom, and real internal light sources which do not work in other frameworks. So not every framework has the same visuals. Why is this a problem? In an ideal world everything would work and be compatible with everything else. I don't see how any progress could be made that way. I don't see how Rembrandt could have been made requiring that it must be completely compatible with existing technology and aircraft definitions. We used to characterize the atmosphere by a fog density and a fog color. It's beyond me how one could make ALS by requiring the same thing. JSBSIm has updates, they break some aircraft, developers fix it - somehow I miss all the complaints about this (and JSBSim updates actually have the potential to break aircraft in the sense of rendering them non-functional, not in the sense of bumpmapping not working). Just imagine computers were required to be able
Re: [Flightgear-devel] Atmospheric Light Scattering
Gene Enough, too long already It would have been a LOT shorter had you trimmed his original message down instead of just tacking on to the bottom. :D What and spoil the point? :-) Vivian -- 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
Thorsten ..yes, but we also need some patience with non-native English writers who _should_ include their French etc original so we don't get people wound up on questionable translations of things that may warrant discussion For the record, there is a repeating pattern here on and off list and I don't think I'm overreacting. I don't think you are ignoring the flightgear users community interest, features should be compatible each other, and not breaking each other or You call it Atmospheric Light Scattering, you could call it Renk ALS are particularly prone to mistranslation or are intended to mean something else. I'm not wound up about wording here. I'm wound up about 1) Repeated insinuations that I would 'break' things. Somehow, nobody can seem to come up with an example of what I have actually broken. So I think I'm not out of line in asking that people either say what they think I broke (and give me a chance to fix it) or shut up. 2) A complete lack of explanation why simply not switching on a completely optional framework which they don't like is not an acceptable solution to some people. 3) The inherent double standard in arguments that if other people do the same thing it's completely okay, but if I do it it's very bad. Could somebody who disagrees with me just spell out what I'm supposedly doing wrong, what I should rather be doing and explain to me why? Rather than insinuating, making vague statements, expressing unspecified concerns, hinting at some unspecified group which would be of the same opinion but never committing to any statement which can actually be investigated? Because I'd really really like to see that case reasoned. ALS is very impressive work, but things broken? Have you forgotten the flag shader (now fixed), wake effect and rainbow effect? I don't have a particular problem with these and hope that they will be fixed eventually, although I note that do you seem to have raced on to other things while leaving the wake effect unfixed for some time. I rather fear that that's just going to get lost in the noise and general excitement over the latest bit of eye-candy. 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) As a developer I have only just finished making my models Rembrandt compatible, and I don't know if I will ever be able to actually make use Rembrandt facilities in all of them. I'm sure that there are models in our inventory which haven't even got that far. As I understand it, ALS will include modelling facilities which will not work in the other flavours of FG. How is this meant to be used? Personally, I seem to be forever fixing things in my models that others have broken, to the extent that I'm not actually able to move my own work forward. That's how it feels anyway. In an ideal world everything would work and be compatible with everything else. I realise that might involve a number of intermediate steps to reach the final goal, but right now we seem to be moving our flavours further apart rather than converging them. What are aircraft developers and/or users meant to make of this ? As to Emilian's concerns, I don't really understand the technical details, but I do know that he felt that his advice and expertise was being ignored with the result that FG was headed in the wrong direction, so he folded his tent and left the project. Perhaps you received contrary advice, or considered that his advice wasn't of value, but we never had that debate IIRC. We could have done with not ending up like that. 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 - but from where I'm standing we all seem to be a doing a fair representation of a headless chicken, rushing about in all directions without really finishing anything. I'm having difficulty keeping up with it, but I know that all this work has exciting potential. Oh - and btw the ALS still shows up a tear in the skydome that we have had right from the beginning. I thought perhaps it would be helpful if a native English speaker tried to put things in perspective, Vivian -- 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
Re: [Flightgear-devel] Atmospheric Light Scattering
Stuart -Original Message- From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 25 April 2013 15:28 To: FlightGear developers discussions Subject: 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. Couldn't we just! All the more reason not to bite off more than we can chew. And I know I owe you a more detailed response on the tree stuff - later today perhaps. While I'm on a roll we have had this one in terrasync at KSFO for I can't remember how many years: Could not find at least one of the following objects for animation: 'terminal_2' when using Terrasync data at KSFO, And this one seems to be new: 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 With that I'll get back to some more useless eye-candy of passing sub-models over mp which I left as a TODO more years ago than I care to mention. I promise not to break anything though :-). Vivian -- 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
Stuart Sent: 25 April 2013 22:24 To: FlightGear developers discussions Subject: 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. Not here. It seems to be stuck at this weird default value: C:/Program Files/FlightGear-nightly-2010/osgPlugins-3.0.1 Why there - decidedly odd? Win 7 will not permit a program to write to Program Files, so it fails. I can't enter any different value, or navigate above Program Files using the gui. I have tried deleting the value in AppData\Roaming\flightgear.org\autosave_2_11.xml (which I wouldn't expect a user to do - or even find), but neither doing that nor anything else I can think of has fixed it. 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! It would be nice to be able to direct the output of Terragear at run time without restarting, (we can do that with Scenarios - thanks James), but if that is not possible then after a restart will do. I don't remember if we used to need a restart - I suppose we must have done. What was the pull-down in the menu item for? Nearly back to square one - well done. Vivian -- 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
Stuart 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. 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 would give you some screenshots - but that's broken here. Vivian -- 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] Aircraft modellers - is a grain texture useful?
Thorsten Okay, I've pushed an experimental version of a grain overlay texture for the model ubershader to FGData. It affects Atmospheric Light Scattering only, i.e. will be absent in the default rendering, which should make for easy comparison. For lack of texture units, I had to take the rainbow coloring of reflections out for the moment (again, only in the Atmosperic Light Scattering version). I can't visually spot a difference, and in any case a 2d texture lookup call seems an overkill for a simple 1d color table, so I plan to replace that by a function eventually. As far as I can see and test, this shouldn't take any framerate unless used. The grain overlay is configured pretty much like any other model effect in the ubershader - a model specific effect file needs to set the flags, which are * grain-texture-enabled: does what you think it does, needs to be 1 to work * grain-magnification : the texture magnification relative to the base texture - I think values between 10 and 100 would work here The grain texture itself needs to be declared as n=14. The grain texture should be largely transparent and seamless - I think unlike for the terrain tiling artefacts are not an issue for artificial patterns, they actually occur. For a quick check, inserting the following xml code into Aircraft/Citation- Bravo/Models/Effects/reflect.eff texture n=14 imageTextures.high/Terrain/grain_texture.png/image filterlinear-mipmap-linear/filter wrap-srepeat/wrap-s wrap-trepeat/wrap-t internal-formatnormalized/internal-format /texture grain-texture-enabled1/grain-texture-enabled grain-magnification50/grain-magnification gives me this effect for the hull of the Bravo which is now re-painted using the terrain grain texture at high resolution http://users.jyu.fi/~trenk/pics/overlay.jpg Looks a bit like a military version... So, please play with it - it's basically down to how well the grain overlay can be made. Removing the rainbow effect spoils the highly polished aluminium effect on the b29 and the Lightning F1. It is also incompatible with AO effects. Will this all work with non-nVidia cards/drivers? The grain effect you proposed did not gain much if any support from developers. Do we need to go down this road? We are breaking more and more for minimal gains. Did we ever restore the wake effect on the Carrier with Atmospheric Light Scattering? I think something like the grain effect can already be achieved with the nmap tiling facility in the existing ubershader. Vivian -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain self-shading
Stuart 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 :). We seem to have slight misalignment in the tree texture: https://dl.dropboxusercontent.com/u/57645542/fgfs-screen-004.png Is having a single texture sheet the most efficient way of doing it? Just asking. Vivian -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
Stuart 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 still have the old version: seems to work fine. But I only moved the way it was accessed - not the gui itself. It might be that we have actually exposed some old bugs of course. 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. First problem seems to be related to the mouse - here it gets stuck in the coverage field if you enter it (you don't actually need to). You can get out of it by hitting tab and then right mouse click. Second problem is that if you then close the manual entry window and then hit either OK or Apply the weather reverts to the METAR data and the manual entry fields are all set to the default value. Hitting close works OK and the manual data is applied. Third problem is that sometimes when I enter values on a cloud coverage line then move to another line to fill in data there, the first entry line reverts to the default values. I can't reproduce this reliably, nor can I identify any cause. I haven't seen any of these problems before, but I wouldn't claim that they weren't pre-existing: it is entirely possible that I never tested the right combination of entry conditions. They're pretty obvious though when you do encounter them. 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. No - I think the problem lies elsewhere as I said. Vivian -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved Basic Weather integration with Atmospheric Light Scattering
Stuart, Having talked about it for months (years?) I've finally written some property rules that improve the integration of Basic Weather with the Atmospheric shader. In particular the skydome properties are now calculated using formulae very similar to those of Advanced Weather so there's no need to set rayleigh/mie/density properties directly, and appropriate levels of ground haze are estimated based on the lowest cloud layer. Some of the integration is quite basic, and there's plenty of room for improvement in the Basic Weather METAR parsing to set up appropriate visibility settings in particular. Feedback welcome as always, though I suspect almost everyone these days is using Advanced Weather... This also removes another roadblock from possibly making the atmospheric shader on by (non-Rembrandt) default. Ooohhh, controversial :) I still use basic weather with mp so that I get the same clouds in both clients - is this still the case? Your most recent change seems to have broken the manual input gui here - sometimes it works, and sometimes the values revert to the default. We seem to have lost the ability to use /NIL as a METAR input - very useful during fdm development to remove weather effects. I'm not sure when this broke, I think it might have been something James did. Vivian -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 894: Stuck at loading nav datas while launching FGFS 2.11.0 win32
James On 29 Mar 2013, at 14:08, Heiko Schulz aeitsch...@yahoo.de wrote: Would it be possible to test sensible things BEFORE they went into GIT? I think in the past we tested cross-plattform sensible things before it went into GIT/ CVS. Yes, I'm aware that GIT is the developement place, and with this a larger group of people can be reached for testing. Yes, I'm also aware that developing for cross-plattform is pretty challenging. Correct on all counts :) But Co-Developers depends on the latest developement steps if they want to make it compatible with the next FlightGear release! It is pretty bad for Co-developers when due such failures their own projects are delayed. Not every developer has plenty of time everyday and week to wait until the problem has been fixed. I hoped that I could get my Project EC135 P2 into FGdata in the next weeks since I spent about guessed 100 hrs into finetuning the fdm, but due this bug I'm not be able to make further developement steps, especially regarding tooltips and the new VSI, and so my little project will be delayed now for a indefinitely time since I will probably very busy with studies again until early summer. The issue you are seeing is Windows specific, and only affecting certain machines - Vivian has two machines, one is fine, the other has your issue. Note if you leave the machine for a long time (maybe an hour or more, it depends), it will start fine, and once that cache is built, future launches will not have the same delay. So a work-around is just to leave it starting overnight or while you're studying, and then you should be good to continue work on the EC135. Of course this is a temporary fix, we are looking at making the loading of this data asynchronous so startup is not delayed, but we also lack Windows developers who can investigate the issue, since Linux, Mac and some Windows boxes are absolutely fine. Hmm, not quite true. My fast box (Win7) fitted with an SSD has acceptable load times (2-3 mins), but long for an SSD. My older machine (XP) with HHD can take 20 - to 30 mins to load depending on the scenery selected. Which Windows boxes are absolutely fine? Might help to diagnose the issue. I'm ready to test anything you come up with. Vivian -- Own the Future-Intel(R) Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard bindings
AJ wrote: On Mon, 04 Mar 2013 15:38:45 + James Turner wrote: Aha, and instantly we get a usability discussion: Right, you need the keys because you're working around a simulator bug (frame-rate drops badly) using manual interaction. The correct fix isn't to make the workaround-UI easier, it's fix the underlying issues, by making adaptive-LOD work so we can achieve a target frame-rate reliably. I do agree that would be the ideal... really I'm just saying that the fix ought to come and be proved satisfactory before the established workaround is removed. Hopefully nobody was really suggesting that, but I think there is a horrible tendency in open source projects for similar things to happen - because removing the workaround or cleaning up the UI is generally significantly easier than fixing the problem, it's only the former that gets done! You're the third person to say the same thing. But again, you don't actually want to change the FoV at all. What you're doing (and everyone else) is using this feature to look around 3D cockpits, right? In other word, our cockpit navigation UI needs some improvement :) Actually I think our cockpit navigation UI works better than anything else I've ever used in over twenty years of flying flight sims :-) It's not instantly intuitive, granted, and maybe there's room for improvement there, but I'd want to tread very carefully on this one as I think our method of interacting with the 3D cockpit using the mouse is generally very efficient indeed... Also, usability is hard :) It is... and partly because everyone has different ideas on what's good and what isn't! A lot of people seem to think that Apple's IOS UI approach is the greatest thing since sliced bread and I think it's one of the worst I've ever come across (Win8 is definitely worse, but not many people are insane enough to contest that view!) What I wouldn't like to see (and I'm sure isn't intended) is that we end up with a Gnome3 / Metro style UI revamp where we get what one or two people (who _are_ doing the work from best intentions) no doubt think is great and intuitive but most people find obtuse and retrogressive. At least we're having a discussion about this first - I'm hopefully being excessively paranoid but the sort of baby out with the bathwater scenario has been all too common in recent years! I think AJ has summed it all up pretty well. I almost never used zZ while using the normal scenery, but since I've been working on the detailed customised stuff I've needed it to try to keep performance within reasonable bounds. If we can solve the underlying problems, I would like to think I can go back to letting FG decide the vis for me. Let's put this discussion to one side, and see if we can do something about custom scenery/LOD/linear scenery etc. We might find zZ is redundant (I hope so) or we might need to retain it. It will argue for itself in the light of future developments. No need to discuss how many angels can dance on the head of a pin (no I don't know the answer either). Vivian -- 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] Advanced Weather updates
I wrote -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 02 March 2013 17:32 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Advanced Weather updates James Turner wrote: On 1 Mar 2013, at 07:53, Renk Thorsten thorsten.i.r...@jyu.fi wrote: One problemhere is that rain textures are still orphaned (i.e. don't move in the wind with the clouds) - I'm running out of ideas here - my Nasal moving code creates frame spacing issues, Vivian's C++ moving code patch wasn't accepted, so I'd appreciate a helping hand from C++ coders before the next release. I need someone to reset my brain on this, explain to me what functionality is required, show me the Nasal code and Vivian's version, and so on. I'd forgotten about that. I think my patch is long since gone - probably lost it here at least 1 hdd ago. I'll scratch around a bit and see if anything remains. Vivian Well gitorious is good for something! The patches still exist! I've put them here if anyone wants to do something with them: https://www.dropbox.com/home/Public/Patches/MoveModels They worked, and have no bugs that I'm aware of. They were rejected it was alleged that there are ways of doing it better, but no one could be bothered to actually do the necessary work. I don't know if they still apply. Vivian -- 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] Advanced Weather updates
James Turner On 3 Mar 2013, at 10:29, Vivian Meazza vivian.mea...@lineone.net wrote: Well gitorious is good for something! The patches still exist! I've put them here if anyone wants to do something with them: https://www.dropbox.com/home/Public/Patches/MoveModels Dropbox won't let me in, can you email me the patches? Dropbox won't let you in! Why not? Did you offend it in some way? Have you been black balled? Vivian -- 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] Advanced Weather updates
Thomas wrote Am 2013-03-03 12:56, schrieb Vivian Meazza: James Turner On 3 Mar 2013, at 10:29, Vivian Meazza vivian.mea...@lineone.net wrote: Well gitorious is good for something! The patches still exist! I've put them here if anyone wants to do something with them: https://www.dropbox.com/home/Public/Patches/MoveModels Dropbox won't let me in, can you email me the patches? Dropbox won't let you in! Why not? Did you offend it in some way? Have you been black balled? You've posted your private Link... Perhaps this is a better one: https://www.dropbox.com/sh/js2hm48d5amsjzy/GIhyixKoBa/Patches/MoveModels Vivian -- 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] Advanced Weather updates
James Turner wrote: On 1 Mar 2013, at 07:53, Renk Thorsten thorsten.i.r...@jyu.fi wrote: One problemhere is that rain textures are still orphaned (i.e. don't move in the wind with the clouds) - I'm running out of ideas here - my Nasal moving code creates frame spacing issues, Vivian's C++ moving code patch wasn't accepted, so I'd appreciate a helping hand from C++ coders before the next release. I need someone to reset my brain on this, explain to me what functionality is required, show me the Nasal code and Vivian's version, and so on. I'd forgotten about that. I think my patch is long since gone - probably lost it here at least 1 hdd ago. I'll scratch around a bit and see if anything remains. Vivian -- 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
Gary Carvell wrote: On Thu, Feb 21, 2013 at 10:54 AM, Stuart Buchanan stuar...@gmail.com wrote: 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. On Fri, Mar 1, 2013 at 8:02 AM, Renk Thorsten thorsten.i.r...@jyu.fi wrote: I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed [...] *Please* don't drop the z/Z key binding. This is one of the most useful and direct controls we have to affect the visual experience. It allows the user to directly control the view out the window, trade off visuals for frame rate and smoothness on older hardware or complex scenery, and trade off realism of flight experience for the simple pleasure of looking out the window for those more into tourism. It can be useful for modifying a built-in weather scenario that's close but not exactly what is wanted. In short, it allows even the newest user to control their FlightGear visual experience according to their particular use case and need for realism. I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I agree. I am just finishing a patch which leaves z/Z as is for Basic Weather, but makes z/Z control max vis. for Detailed Weather, just like the slider in the menu. Should give us the best of both worlds. Testing atm, should be in fgdata soon. Vivian -- 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
James Turner On 2 Mar 2013, at 17:09, Gary Carvell gary.carv...@gmail.com wrote: I have no problem at all with disabling the keys when (say) advanced weather is selected, but for several classes of users and types of use, it really is an important capability and is used often. I don't see anything in your list, that wouldn't work as a slider in a suitable GUI dialog. (Which dialog it is, is a question to be decided, for sure) The advantage there being we can disable the slider, when advanced weather is selected, and provide a label explaining *why*. It's fecking difficult to operate a mouse/menu/slider while using a joystick unless you are ambidextrous (which I'm not). And even then I shouldn't think it easy. You can try using the Detailed Weather/Advanced Settings. There is absolutely no need to disable z/Z in Detailed Weather. It ain't broke - could we avoid fixing it and turn our attention to something that is like memory usage or moving clouds? Vivian -- 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
Torsten wrote Am 28.02.2013 16:38, schrieb Curtis Olson: We've always been able to set the individual weather parameters, either through the built in weather dialog box, or by setting raw property values. Setting raw property values allows nasal script control over the weather (as I'm sure you well know) :-) but it also allows external control of the weather, for instance by some external gui tool, or by some tool that wants to setup equivalent visual conditions across multiple FlightGear PC's running in sync. And please don't forget, there are command line options like --visibility, -- wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic- weather and I'd love to keep all that functionality. At a very personal level, I like being able to adjust the vis other factors using the keyboard with my left hand while using a joystick with my right. I certainly can't imagine flying the Camel and trying to manipulate a mouse and menu. Vivian -- 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
Thorsten aka Renk wrote: -Original Message- From: [mailto:thorsten.i.r...@jyu.fi] Sent: 28 February 2013 07:57 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FG vs. FSX demo Renk, you should take a look at the default Cessna 172 in FG and it's mate in FSX. The FSX version wipes the floor with the FG version with respect to the cockpit model. (I'd really appreciate if you guys would call me on first-name basis 'Thorsten'...) We had at one point several Thorstens/Torstens - I suppose Renk was just easier. And if you start your postings Renk Thorsten people will assume Renk is your first name. That's a question of what a fair comparison is. I'm going to assume that whoever put a demo version from FSX together has specifically chosen scenery and airplanes in the demo to impress users. So my standard of comparison is not 'How does the same airplane or the same scenery in FG look like' because I regard that as unfair - they got to chose, we didn't. My standard of comparison would be - if I were to put together a FG demo to impress users, how would that compare? You are certainly right with the c172, but the fair comparison is e.g. our DR- 400 against the FSX C-172, and FG is going to win that one. It doesn't matter so much that many aircraft in FG can not measure up to that standard - I don't usually fly them. We have 20-30 really high quality aircraft, and I doubt FSX has that many out of the box. If you count addons, we can field all the non-GPL hangars in return, where I believe T4T is doing some really impressive warbirds... If you're going into comparing 'the same' (scenery, aircraft,...) than my next question would be - FG has beautiful scenery in central Iran with the Middle- East texturing definitions. I doubt FSX out of the box has any scenery there at all. So we're winning flat out in many cases by virtue of having scenery everywhere. It doesn't make too much sense to me to go into that direction. One thing I'd really like to see put together is a The Hidden Secrets of FlightGear page that illustrates all the little bits that people aren't necessarily aware of. Things like the hard science behind a lot of the things FG tries to get right that other simulation software completely ignores or fakes poorly. We've sort of started this here http://wiki.flightgear.org/Unique_Features 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. While we wait for the FSX screenshot, I'd like to see the FSX equivalents of these as well: Honestly, I have no clue how to make a screenshot in FSX... and I don't want to fiddle around with it much longer, suffice to say it gave me some ideas how the GUI could be, but it doesn't draw me in in any way. And you'll not going to find me argue that the Vinson doesn't measure up. It's a spectacular model, and I do love doing carrier ops in FG. That's really good to hear - but if we are falling behind in some respect then we will make an effort to improve. I am reminded that the flag and wake shaders are inoperative when Atmospheric Light Scattering is activated. With the departure of Emilian, I see no prospect of this being fixed unless someone else steps up to the plate. I recently saw a short video of FSX with moving cars and trucks populating the roads. We can do that up to a point, and trains as well, and I forgot to mention that we can also texture tracks and roads properly: https://dl.dropbox.com/u/57645542/javelin-hst.png We can only have a few - around 50 if we are to keep framerate within bounds. If we ever get the Kent scenery fixed up well enough for release I'll include this around Manston/EGMH. Vivian -- 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
Stefan Seifert wrote: On Wednesday 27 February 2013 07:42:19 Renk Thorsten wrote: * A big plus about the FSX terrain is that it doesn't have landclass seams. That makes it quite a bit nicer to look at from above. It's not so impressive from close-up, and all in all, I would conclude that regions where we did apply a regional texturing scheme and use the best shader effects available are in fact quite competitive. In particular, I think the recent 2nd generation Hawaii in FG or middle-east looks much better from close-up and is still about on par when seen from a few thousand feet. Of course, FG terrain can look much worse in areas where we didn't customize it. - Pretty much a draw. Hiding the landclass seams better would still - be the thing for FG.. it's just not so easy. A small addition: what has always bothered me about terrain in FG is that roads and rivers are all the same size. For me as a VFR pilot they are the most important navigation helpers while in FG, they are useless. There's no difference between the Autobahn and a small country road. Same for the Danube vs. some riverlet. I've tried some version of MS Flightsim once with Austrian scenery and could easily find my way around. So while we may have the prettier scenery with regional textures, in practice, I'd have to call it a win for FGX. Linear features for the scenery (roads, railways, rivers) are already under development for FG: https://dl.dropbox.com/u/57645542/fgfs-screen-129.png That is a small area of Kent, UK. It is very possible to use the accurately placed features for VFR navigation. There are some problems to resolve about memory usage, but it is already possible to generate scenery with these features. However, at the current stage of development it is pushing the memory limits of 32 bit systems. Vivian -- 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
Renk Thorsten wrote: ... snip * Models of trees and of the aircraft carrier in the vicinity where largely on par. Probably FSX has more graphical artists and the quality of for instance tree textures seems to be a bit better, but the technique is otherwise pretty similar. I liked seeing a few other aircraft lined up on a carrier - the FG carriers are usually rather empty. - Ever so slight edge for FSX snip ... Better than this? https://dl.dropbox.com/u/57645542/fgfs-screen-130.png As many ac in the deckpark as framerate considerations would allow. I'd like to see the equivalent FSX screenshot. If it really is better then I'll have to beat up Alexis a bit :-) Vivian -- 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
I wrote: Renk Thorsten wrote: ... snip * Models of trees and of the aircraft carrier in the vicinity where largely on par. Probably FSX has more graphical artists and the quality of for instance tree textures seems to be a bit better, but the technique is otherwise pretty similar. I liked seeing a few other aircraft lined up on a carrier - the FG carriers are usually rather empty. - Ever so slight edge for FSX snip ... Better than this? https://dl.dropbox.com/u/57645542/fgfs-screen-130.png As many ac in the deckpark as framerate considerations would allow. I'd like to see the equivalent FSX screenshot. If it really is better then I'll have to beat up Alexis a bit :-) While we wait for the FSX screenshot, I'd like to see the FSX equivalents of these as well: https://dl.dropbox.com/u/57645542/fgfs-screen-131.png https://dl.dropbox.com/u/57645542/fgfs-screen-133.png Personally, I reckon Alexis is safe for a while yet :-) Vivian -- 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
Thorsten Renk wrote ... snip The design idea behind the current GUI was that the user should no longer be presented with two different weather options to choose from, but just see a single GUI which controls weather. If that is still the idea, it works remarkably well. If you have an idea for a more descriptive text, please let us know. Snip ... You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. I've pushed it to fgdata. Vivian -- 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
Emilian wrote On Saturday, February 23, 2013 07:08:41 Renk Thorsten wrote: A lot of stuff, mostly deflecting the discussion to other irelevant points * Thorsten While I should know better than to answer to this, as it will again get deflected to other areas, let's imagine ourselves a simple scenario: Let's say I'm an average user with a 32bit system, I can barely find my way through the maze of menus and dialogs flightgear presents to me, and I want to use this more advanced weather simulation engine. After I accidentaly find out how to enable it (it's hidden under a rather confusing radio-button selection Model overall weather conditions based on metar), great, select Fair weather scneario, Apply, OK, let's go flying. I muck around, wonder at the nice sky/clouds, notice that my visibility improved somewhat, then bam after 15 minutes flightgear crashes, uhm.. oohh, why did that happen? That didn't happen before? All I did was change the way the weather is interpreted... What's wrong here??? Well, now let's see what actually happens in a default flightgear instalation (all settings are from preferences.xml, and Environment/local-weather- defaults.xml) -trees are enabled by default -default visibility with Fair weather is ~16km local weather comes in -and sets a default value for max visibility of 120km (o.O), ok, that's a bit far, but in practice I see that's actually hovering in the 40km range (+-10km based on altitude). (roughly 3x more than the default) So in the default scheme we load 9 tiles at startup, then we keep loading tiles in the direction we're traveling, and those initial tiles remain resident in the tile cache for a while (in case you decide to double back). But let's stay with the startup condition. when you ramp up the visibility to 40km you demand 3 extra rings of tiles to be loaded. That would give you at least 69 tiles loaded (81 if the rings are square). So that's an instant increase of 7-9x the memory requirements of the terrain + objects + trees (tres being the largest contributor here), just because you click an option that says it just _interprets_ the METAR string differently. Do you think that's an expected result? I don't. Well, our average user might have read the manual, might have mucked about with the visibility setting before, and he remeber that all things being the same, visibility is what impacts performance/memory the most, so he decides to try again, this time trying to use z/Z to limit how far the visibility goes, maybe he gets lucky and it won't crash again, but he's in for a surprise... z/Z doesn't work... You might argue that he should know better, go into the advanced settings dialog, figure out what all those sliders and selection boxes do, etc, etc... But remeber, our user is an average one, he wants things to just work (with time, he might find a use for the more advanced configuration stuff, but for now he's not interested, he just want to click something, and be done with it), The z/Z case above might be a lucky one where he might have read the manual. The problem is not with Advanced weather in itself, the problem is in the details of a part of it, themost important part from the user POV. Your approach might work, given unlimited resources, but as it is Flightgear has to run on a variety of puny little desktop/laptop machines. You have already implemented half of the control, is it so hard to implement the rest and provide a system that's consistent with the rest? Yes it breaks the real world scheme, but this is a simulation, we lie, carefully crafted lies, that give a global impression of truth, of copying the real world behaviour, but in the end they are lies. Fog/view-distance is one of those lies, they need just be plausible, not a faithful representation of the real world (and a faithful representation of the real-world is practically impossible given the current state of the technology). You are comfortable with abdicating from that when it suits you, but where it really matters you defend the minute detail faithfull representation of the real world scheme vigorously... Don't you think thre's something amiss here? As someone said in another thread, there are various techniques that are not constrained by the real-time requirement, that do a pretty good job of giving you real results, but their place is not here. Here we have to do our best to trick the mind, while doing that as fast as possible, with a reasonable usage of resources. Just because you can set visibility to 1000km doesn't mean you should, just because you can shove a lot of data into a shading scheme and get back photoreal results doesn't mean you should, if said results reduce performance, increase the probability of running out of memory, etc. You'll argue again with the IAR as an example. Well, take a look at those numbers again, and you'll see that for the amount of detail it
Re: [Flightgear-devel] Low visibility issues
Stefan Seifert wrote On Sunday 24 February 2013 18:46:08 Vivian Meazza wrote: I'm probably a day late and a dollar short here - but try as I will so far I've failed to find a visibility slider under environment-weather. It's probably staring me in the face - but could someone point it out to me? In the Weather dialog: Model overall weather conditions based on METAR Advanced Settings Thermic Visibility and Settings Max visibility Got it - thanks - as I said staring me right in the face. So, am I right in thinking that we have 3 different ways of setting the vis: 1. z/Z - works with Basic Weather - sets the vis directly. Does not work with Advanced Weather, but is still available when that option is selected and looks as if it should work. 2. Slider in Advanced Weather - Advanced Settings - sets a max value . The displayed vis in the min value of this and the value derived by Advanced Weather. (Is this true? I'm only inferring this). 3. Checkbox named realistic visibility in Advanced Weather - Advanced Settings. What does this do? I can't see any effect here. I used the old terms Basic/Advanced Weather, but I note that these have disappeared from the GUI. How would the user know why or when he would chose ether option? Scope for some rationalisation here I would think. I'm extremely disappointed to see that while I was off on a short holiday that this discussion has deteriorated to the point that one of a valued developers feels that he can no longer contribute to FG. Vivian -- 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
Thorsten wrote: -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 21 February 2013 06:54 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Low visibility issues Vivian: There seem to be significant issues with the loading of terrain. If we load too much, the frame rate drops, if we load too little it looks poor, and AG radar doesn't work. Actually. We don't load enough for AG radar to work realistically in any case. We probably need something between 50 and 100 k for this , and we're unlikely to accommodate the memory requirements of this, at least for 32 bit systems. James: a) is a trivial fix in the tile-manager, I think, and seems reasonable to me. The only issue will be setting a sensible minimum size, since I assume some people are brining the visibility down to reduce number of tiles loaded, and hence RAM use / frame-rate. Okay, here are some experimental facts on my old 32bit system. I had a GeForce 8600M and 4 GB of memory with a 32bit Linux installation. With this setup, without using random vegetation and random buildings, I could render terrain with 250 km visibility range (I patched the binary for that purpose, otherwise it gets clipped at 120 km) without any problems in default scenery. I could easily do 120 km in custom scenery, and even with vegetation and buildings on 55 km were quite safe in custom scenery. So it's not true that fixing a minimum visibility of 20 km we'd run into 32bi memory issues. As for framerate, I'd guess that GPUs which are so old that they have real issues processing the vertex count of 20 km scenery fast enough are hit also hard by the fragment shader - but fragment shader load is independent of the visibility range. There are lots of forum users who have issues with low framerate - about anything (no random vegetation, no shaders, no random buildings, no complex planes, no AI traffic, no 3d clouds...) seems to help more than to get visibility down. I'm not aware of any single user who uses less than 20 km visibility because the framerate is not acceptable otherwise, and I have never seen anyone suggest this to users. Since vertex count goes quadratically in visibility, it matters a lot if you use 50 or 120 km, but not so much if you use 10 or 20. Nevertheless, at some point my suggestion would be to create a commandline-enabled legacy mode for really old hardware which gives you access to a minimal setup in which terrain radars, Advanced Weather Co are disabled, but define the default setup of FG in such a way that terrain interaction based stuff can make assumption about how much terrain is loaded. For a halfway decent system, 20 km should not be any problem if I could run 250 km on a 5-year old laptop, and I think we can at some point make that default assumption and have a fallback option in case it doesn't work. I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392#p177392 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. Vivian -- 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
Thorsten -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 21 February 2013 10:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Low visibility issues I was not referring to a frame rate issue, but FG running out of memory. http://www.flightgear.org/forums/viewtopic.php?f=5t=18913p=177392# p1 77392 It is rare to see that happening using the current scenery, but here if I select random buildings and objects with a high value for trees, I can get Win32 to run out of memory. Apparently at least one other user has a problem. I do not doubt that you can make FG run out of memory on a 32 bit system (you can also do it on a 64 bit system if you try really hard). My point is more that memory issues should be dealt with by eliminating the root cause, i.e. by switching off random buildings and trees on a low memory system and by not using hires textures, not by reducing visibility to low values. Compared to the memory footprint coming from high-detail aircraft and random buildings, the effect of 10 km vs 20 km visibility on memory is negligible. We have aircraft in the repository which fill more than 300 MB of GPU memory - loading terrain vertices worth 20 km is a very small fraction of that, even in hires scenery. Even in custom Italy with 50 km visibility, I had about half a million of terrain vertices in the scene, that's 1.5 million or so numbers. That's the order of magnitude of a good-sized texture sheet - 1024x1024 has about a million numbers - with a lower precision, but with added mipmapping,... Perhaps I wasn't clear enough. Let me try again 20 km isn't really enough for a realistic AG radar - we really need an order more, but we could possibly manage with 50 - 100 km. (To put that in context, the Blue Parrot radar fitted in the Buccaneer had an AG range of 200 nm). It's at these bigger numbers, coupled with detailed scenery, that we run into the problem of running out of memory. I'm not saying that we shouldn't do it, but we should do it with our eyes open. Or perhaps there are techniques, such as an inner and outer scenery caches which would help us to a better solution than tuning off nice features such as trees. We are also facing the user with a bewildering array of options, spread over 2 menus in the GUI, with limited guidance on how or why they should be used. Does anyone actually have a handle on this? I thought I was an experienced FG user, but this one is getting away from me. That said, with the right settings, FG can look absolutely stunning - just before it runs out of memory :-( Vivian -- 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
Thorsten wrote -Original Message- From: Renk Thorsten [mailto:thorsten.i.r...@jyu.fi] Sent: 20 February 2013 08:44 To: FlightGear developers discussions Subject: [Flightgear-devel] Low visibility issues Vivian wrote a while ago: I've only tested Atmospheric Light Scattering for about 10 mins - and so far I've discovered that the Cat III scenario looks decidedly odd with a clear circle around my aircraft on the ground and black skies. I've taken a few hours to look into low visibility scenarios, and it's... complicated. It's not complicated to make a low visibility scenario, but it's complicated to make one which blends smoothly into the rest. So I would like to put this up for discussion as a list of options and get some feedback, with hopefully a decent picture of what we should do for 3.0. Status: Atmospheric Light Scattering is in my tests good to a visibility of ~1000 m - below one starts running into a number of increasingly severe isses - Vivian has encountered a few of them, but there are more. One option is - we can leave things as they are, with no additional complication and framerate cost. That's not unprecedented, the default rendering scheme doesn't deliver good results at high altitude, so if you fly Concorde, SR-71 Blackbird, X-15 or Vostok-1 you don't get to see correct earth curvature or the atmosphere below. We accept that the scheme simply can't handle this and trust that users which want to see plausible visuals at high altitude switch rendering scheme. Similarly, we could accept that anyone who wants to deal with visibility much below 1000 m would have to switch rendering scheme (and even make the Cat II and Cat III shown only optional dependent on what rendering scheme is selected for instance). At the minimum we need to avoid FG just looking broken, so making the Cat II III dependent on rendering scheme would work. Better to fix it properly though Failing that, here's a list of issues which need to be addressed, options to fix them and projected costs: 1) Black skies: This may either be skydome unloading which I can't reproduce (but we should have a property preventing that, I don't know if it's set only by Advanced Weather, if not then this is a Basic Weather problem, not a shader issue) or actually the correct behaviour - if you have 50 m visibility in a 300 m thick fog layer, you're 6 attenuation length down, so the amount of light reaching the ground is just exp(-6) ~ 2 permille of that reaches the top of the layer. Which gives you a pretty dark sky. If dense fog is to appear white, it can't be a very thick layer. Options: a) If the skydome really unloads in Basic Weather, set the property correctly to prevent that. - no bad side effects 2) Clear circle around the plane: A while ago, I presented the problem that fog computations are done for the cockpit as well since they run over the same model shader as anything else, so we waste a lot of GPU time on something that is physically wrong (the cabin interior is not fogged) and results in a close-to-zero result in most cases. The advice I got was to use a distance cut to prevent these computations, so I used 40 m which is supposed to prevent the cabin interior in passenger planes from being affected. Of course, once the visibility gets just low enough, you see this distance cut as the circle Vivian describes. Options: a) We change this against a sliding distance cut not fogging for the closest 5% of the distance with some smoothing. This doesn't fix the issue but makes it a bit more subtle. - there may appear fogging computations on the cockpit, costing extra - framerate, the cabin interior can still be fogged This would be acceptable - I think it's the hard demarcation which catches the eye and looks unrealistic. b) We fix it properly by using a different effect for all aircraft interior surfaces which never does fog computations (easy to do shader-side by passing a flag) - every aircraft needs to be modified and declare surfaces as interior - or exterior for this to work This would be nice - I went go to great lengths to hide exterior surfaces in interior views to improve frame rates when these were a big issue. I think they might be culled anyway nowadays. However, there might be other advantages in doing this. I'd be happy to modify my handful of ac to accommodate this, others with a shed load might not be so happy. 3) Terrain unloads: Currently the terrain manager unloads all terrain not in the visible range. This means that for 100 m visibility, hardly any terrain is loaded. This is bad in a number of ways: * terrain radar code (which'd be especially useful in low visibility conditions) breaks as it can't probe terrain elevations ahead * Advanced Weather can't get terrain elevation info and is unable to assemble a reasonable picture of the surrounding terrain * the light scattering shader does not longer know what
Re: [Flightgear-devel] Autumn colors
Thorsten Renk -Original Message- From: [mailto:thorsten.i.r...@jyu.fi] Sent: 14 February 2013 07:25 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Autumn colors ..maybe in the old days, nowadays, some grass is green, most of it, say 4/5 is a pale dull yellow when the snow comes. Climate change, grass grows about 3 months longer now, than in the 1960-ies when grass was cut once, nowadays farmers get 3 harvests. The whole discussion brings again a long standing issue to my mind. It's a slider. It's in fact part of a menu of several environent-controlling sliders. Which means that you (the user) is supposed to adjust it. Now, my philosophy is - what you get as a user here is a tool which gives you infinite options how precisely your terrain may look like. You can have a dry autumn, a wet autumn, just a bit of snow on dry autumn - all by adjusting the sliders. The price you have to pay is that you actually have to think a bit, because the system allows you to select silly and unnatural combinations. You can have snow in Hawaii, you can have desert dust in rainforest, you can combine dust and season to kill vegetation off completely in central Europe. From where I stand, having infinite possibilities seems more interesting than just having 4 pre-defined season textures. But having 4 pre-defined scenarios is on the other hand fool-proof - you will not be able to select a silly combination. But we may disagree on that. My goal is to be able to simulate a realistic seasonal change of the terrain by _suitable_ slider adjustments which need to be chosen based on region, vegetation and conditions. My goal is not to make any combination of slider adjustments work everywhere. But if there is otherwise general consensus that we should operate FG in such a mode as to prevent unrealistic user input, just let me know, and I remove the environment postprocessing from GIT and keep it in my own devel branch. I am decidedly not keen on feedback along the lines 'Oh, look, if I adjust the sliders like that, it really looks bad!' So if climate change affects your region and you believe that vegetation doesn't get all brown, then just do not move the slider all the way. It's as simple as that, and I really shouldn't need to write that here. I fell into the pooh trap - I read your instructions, looked at the slider, set late autumn, and Kent turned an impossible shade of brown. Now that you have explained it, I see that if the slider is set to early autumn that this gives me much more reasonable results for a southern UK late autumn. What I expected was that having selected Regional scenery, then the slider would give me reasonable results for my region. Perhaps that's simply too difficult, or the region is defined too widely. I also see that the regional scenery for the area is wrong as well, but I'm working on that. Right now there are a number of inconsistent approaches. We can select pre-set Summer/Winter, but not Autumn. We can select snow by METAR, but not in Winter, however, the slider works even when METAR is selected. We can set various parameters by slider for the scenery, which the GUI says requires shader effects, but apart from the snow thickness, in fact all require Atmospheric Light Scattering, which is in a different menu and this connection is not mentioned. In addition one slider only works with Regional scenery, and that's not mentioned anywhere either. Wetness effects the scenery, but not runways, while moss seems to grow on taxiways and runways. It it's raining, there's a nice effect of puddles on runways and taxiways, but nowhere else. I'm not at all sure that I've got that all right, and I can't imagine how the average user is going to figure it out. I suspect that the user will try it, might or might not discover how it works, and never try it again. It's just too complex to get the average head around. Even just trying to summarise it makes mine ache! Finally, I write this in the hope it might be helpful, and not be taken as negative criticism. Vivian -- 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
Thorsten Renk wrote I've just pushed the current state of the autumn color model where the amount of coloring is encoded in the texture alpha channel. I've tried to be very conservative and pushed alternative textures (marked with *- autumn.png) where this is done - I could not see any negative effects in the default rendering scheme (no terrain holes or so), but this way it's easy to roll back in case of unexpected problems - only the regional texture scheme references the alternative textures, neither dds or default do. Please let me know if there is trouble. If anyone wants to try the scheme, use high quality level with the Atmospheric Light Scattering scheme and the regional texturing scheme, then change season in the environment settings. I have tested mainly in central Europe, so it's rather likely that there will be texture sheets without alpha channel set, which will stick out if you test elsewhere. I regard the current state as proof of concept. If there is a graphic artist available who wants to optimize the texture alpha channel settings for best effect, please get in touch - I am not very good with gimp, and I've just coarsely painted on the textures to get a feeling for the effect. Trees are not color-changed, so if you want autumn trees, you have to edit Materials/regions/materials.xml manually and change to the autumn or winter tree variants. It looks nice though... Otherwise enjoy! I think I must have something wrong here: much of the textures which were green turn a horrid brown colour, it looks like nothing I have ever seen on the ground in the UK. Is that what is intended? Vivian -- 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
Thorsten Renk wrote I think I must have something wrong here: much of the textures which were green turn a horrid brown colour, it looks like nothing I have ever seen on the ground in the UK. Is that what is intended? That'd depend on the slider position and the landclass I guess - no way to tell without a screenshot. Full late autumn turns everything earth-coloured and is supposed to be the background for a snow cover. I doubt the UK gets cold enough in winter that the vegetation dies off to such a degree (it does in Finland...) and there is no attempt made to regionalize the slider effect - it probably looks really silly if you use it in a tropical location. Otherwise: I have tested mainly in central Europe (...) I regard the current state as proof of concept. If there is a graphic artist available who wants to optimize the texture alpha channel settings for best effect, please get in touch. OK, now I understand. Here's a screenshot: https://dl.dropbox.com/u/57645542/fgfs-screen-099.png It's not good for UK - but I guess we can fix that eventually. Vivian -- 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 Jenkins Build win32 #926 and older quits
Heiko -Original Message- From: Vivian Meazza [mailto:vivian.mea...@lineone.net] Sent: 09 February 2013 20:40 To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] FlightGear Jenkins Build win32 #926 and older quits Heiko Today I wanted to test all the new things I missed in the last couple of weeks. So updated FGdata, and downloaded the last win32 build on the Jenkins build server. To my surprise, fgfs.exe quits when pressing the launch button in FGRun. The console only shows following strange error message as I haven't used no aircraft with something like that: 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 Setting log level to debug doesn't give anything, but setting to log-level bulk give me following: general:3:..\..\..\FlightGear\src\Main\main.cxx:311:FlightGear: Version unknown version general:3:..\..\..\FlightGear\src\Main\main.cxx:312:Built with Microsoft Visual C++ version 1600 I used the latest win32 build #926, but also tried build numbers down to #920. None of them worked for me. I've just rebuilt SG/FG with MSVC10 using the up-to-date code with the same result: FG quits immediately I reset FG/SG to 23rd Jan - that compiled and ran successfully. Vivian -- 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 Jenkins Build win32 #926 and older quits
Heiko, -Original Message- From: Heiko Schulz [mailto:aeitsch...@yahoo.de] Sent: 10 February 2013 15:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear Jenkins Build win32 #926 and older quits Vivian, I reset FG/SG to 23rd Jan - that compiled and ran successfully. Vivian according to James and fred on the bug tracker, the bug has been fixed already. I just wait for Jenkins running again to test. Yup - looks good here. Vivian -- 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 Jenkins Build win32 #926 and older quits
Heiko Today I wanted to test all the new things I missed in the last couple of weeks. So updated FGdata, and downloaded the last win32 build on the Jenkins build server. To my surprise, fgfs.exe quits when pressing the launch button in FGRun. The console only shows following strange error message as I haven't used no aircraft with something like that: 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 Setting log level to debug doesn't give anything, but setting to log-level bulk give me following: general:3:..\..\..\FlightGear\src\Main\main.cxx:311:FlightGear: Version unknown version general:3:..\..\..\FlightGear\src\Main\main.cxx:312:Built with Microsoft Visual C++ version 1600 I used the latest win32 build #926, but also tried build numbers down to #920. None of them worked for me. I've just rebuilt SG/FG with MSVC10 using the up-to-date code with the same result: FG quits immediately Vivian -- 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] Model shader for Atmospheric Light Scattering
Stuart On Thu, Jan 31, 2013 at 12:25 PM, Renk Thorsten wrote: I've just pushed the first version of the model shader for Atmospheric Light Scattering. It should do random buildings with reflections and all aircraft using the model-combined.eff without normal mapping. The shader still has some quirks, but they're hard to spot if you don't look for them ;-) Thanks Thorsten, and Emillian. So, does this mean we're getting now at the point at which the Atmospheric Light Scattering is a complete replacement for the existing default rendering scheme (with the exception of the farmland shader)? If so, we should definitely remove the experimental label from the rendering dialog, and possibly change this to the default renderer and have a discussion about whether to retire the previous scheme. Early in the release cycle would seem to be a good point to do this. I've only tested Atmospheric Light Scattering for about 10 mins - and so far I've discovered that the Cat III scenario looks decidedly odd with a clear circle around my aircraft on the ground and black skies. So the instant answer must be NO. Vivian -- 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] Release candidates
Thorsten wrote Are the Winter textures still needed? In a sense they were never really needed... for instance I have never used them. Just to summarize the options we have to generate snow: 1) Winter textures They are base texture sheets with snow painted on, which means they have a fixed snowcover and no simulation of a snowline is possible. On the good side, they do not need any shader technology and render with some margin fastest of all snow options. 2) Snow texture overlay This uses shader technology to overlay a snow texture on the terrain, and is the snow feature implemented in the default rendering scheme (I don't know about Rembrandt, maybe also there?). This has a fixed snow coverage but variable snowline and uses significantly more resources than 1) (needs to read a second texture, needs to read noise textures, needs to compute the local amount of snow based on terrain gradient). 3) Procedural snow This is a white base color modified by several noise functions. It has variable snow coverage, i.e. can change from thin patches of snow to a thick layer, and has a variable snowline. It is implemented in Atmospheric Light Scattering at the higher quality levels. This needs about as much performance as 2) and much more than 1) (evaluates terrain gradient and several noise functions, but doesn't read any texture). If we want to have a CD-sized base package, and if we're fine with not supporting snow on less powerful hardware, then we can remove the snow textures. If we want to support snow on weak hardware, then they are needed. A (more complicated) option would be to offer only one set of terrain textures in the base package and offer the others as additional downloads. Both the dds and the winter textures are probably relatively clean to separate - as far as I know they're not shared across different schemes. My private opinion is that aiming for CD-size isn't that important and I would leave everything in. 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? So at least for now we need at least some winter textures and the ability to select to select them. Vivian -- 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] Flightgear-devel Digest, Vol 80, Issue 8
Double, most of the time J Vivian From: TDO Brandano [mailto:tdo_brand...@hotmail.com] Sent: 22 December 2012 20:51 To: Flightgear Devel List Subject: Re: [Flightgear-devel] Flightgear-devel Digest, Vol 80, Issue 8 You mean you speak Dutch? :) Date: Sat, 22 Dec 2012 11:47:19 -0800 From: ge...@deltasoft.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Flightgear-devel Digest, Vol 80, Issue 8 On Sat, 22 Dec 2012, Gijs de Rooy wrote: Better take the drame to your own forum... That makes no sense at all. I'll write it off to a collision between your writing and my understanding. :) With your forum I meant Emmanuel's forum. Didn't mean Gene's forum :-) Sorry for being unclear. No problem. Nothing like two people, separated by a common language. :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.diy-cockpits.org/coll - Go Collimated or Go Home. Some people collect things for a hobby. Geeks collect hobbies. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices and provide instant support Improve your efficiency, and focus on delivering more value-add services Discover what IT Professionals Know. Rescue delivers http://p.sf.net/sfu/logmein_12329d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Real-Time Radio Propagation
Adrian wrote -Original Message- From: Musceac [mailto:kanto...@gmail.com] Sent: 12 December 2012 22:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Real-Time Radio Propagation On Wednesday, December 12, 2012 09:16:50 Renk Thorsten wrote: My suggestion is to include this feature, leave it off, and let anyone interested turn it on. +1 There may be many reasons to reject code, but they roughly fall into two categories: 1) the idea itself which is coded is not acceptable or 2) the actual implementation is not acceptable (unstable, degrading performance,...). Adrian has invested a fair share of time to make it work, and he introduced the project early on in this list. I think fairness asks that any argument of type 1) against including the code should have been given earlier. Otherwise the message sent to possible future contributors is quite negative. That said, I think doing realtime radio signal propagations is much more that we need and much more than we want. At least unless we are multi-threading and have a spare CPU for those computations. Personally I don't need such a feature, since I'm not so much interested in IFR. However, I think in many situations we do have spare CPU capacity (I usually do - with lots of shader work on, GPU speed seems the limiting factor), and I also think it should be up to the user how he wants to burn his hardware performance - VFR sightseeing people like me want detailed shaders, IFR people may want to turn terrain eye candy off but spend the framerate for radio signal propagation. So including the code as optional feature seems entirely fine to me, I don't think there's such a well-defined 'we' with the same wishlist. So I would also suggest to include it unless there are issues about stability, performance degradation if not running, which I'm not qualified to judge. * Thorsten Hi Thorsten, everybody, Thanks for the support messages. I have worked pretty hard to get this feature as stable and performant as possible. Regarding performance of the radio subsystem, I would like to make a technical statement. As most of you know, the main performance issues come from having to repeatedly sample terrain elevation for a large number of points. This is done though and osg::NodeVisitor, which traverses all nodes within the scenegraph which have a certain mask set (in our case, it's SG_NODEMASK_TERRAIN_BIT) Unfortunately, not only the terrain surface has this mask set, but also random objects, random trees, and 'random' buildings. They all share this mask, so an _get_elevation_ call will have to traverse through litterally thousands of nodes which are not related to the terrain surface. In order to improve the performance of the _get_elevation_ method, I have added a new mask, SG_NODEMASK_SURFACE_BIT, which is set only for the surface geometry loaded by the BTG loader. Of course, some other minor code had to be modified, especially for groundcache et al. Very minor modification, basically taking into account of this new nodemask. The BVH bounding boxes stuff has been accounted for (I think I didn't miss anything) Right now, I've modified the _get_elevation_ method to use only this new mask. The performance difference is almost twice as fast, if not more. However, since this might introduce unwanted changes in parts of the code that rely on having radar altitude also from buildings etc., I can write a new function to be used specifically for sampling terrain. I have performed a regular test, with the following parameters: terrain load distance set to 60 km (LOD bare), 3 stations tuned in (2 VOR, 1 VOR-DME), 10 or more minutes of flight. Result here: http://wiki.flightgear.org/File:Radio-perf2.png (enlarge for details). As you might notice, the radio subsystem is not the CPU cycle hungry monster it used to be. The amount of tiles loaded is shown on the map. With less view distance and less terrain, the system will be very CPU friendly but also give innacurate results. Keep in mind that are various other methods to reduce even further the CPU footprint: sample fewer points for an elevation profile, poll a station less often (what polling time would be reasonable for a mean speed of 200 kts?) and disabling landcover influence. Don't we need radar altitude for buildings etc. for radar altimeters, but probably not trees? A radar altimeter needs to sample both the terrain and hard objects on it. However, I watch this work with interest: I think it might make it worth reviewing the AG radar that I abandoned due to the impact on frame rate, and lack of realistic range because not enough tiles were loaded, Vivian Vivian -- LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial Remotely access PCs and mobile devices
Re: [Flightgear-devel] YaSim Aircraft not functional
Hyde Yamakawa wrote -Original Message- From: [mailto:h...@hyde-tech.com] Sent: 02 December 2012 19:45 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] YaSim Aircraft not functional Already reported. http://code.google.com/p/flightgear-bugs/issues/detail?id=953 (2012年12月02日 14:17), Detlef Faber wrote: Hi everybody, is anybody else seeing this? I notice since I compiled git yesterday, that YaSim fixed wing Aircraft don't work anymore (but Helicopters and JSBSim Aircraft do). FlightGear starts until the first Frames of the scenery get displayed, then quits with a SegFault. This happens with yesterdays compile of OSG, Simgear and FlightGear using the Debian/Ubuntu download and compile script. I tried on 3 different Computers with nvidia and AMD Graphics A compile from last Saturday worked without Problem. It's now Monday 3rd Dec, and I'm still seeing this bug here with current FG/SG Vivian -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Simgear Build 2012-11-28 - MSCV10 - Build failure
Simgear fails to build under MSVC10 today, 2012-11-28, with this error: error C2724: 'SGThread::current' : 'static' should not be used on member functions defined at file scope file D:\Git_New\my_simgear\simgear\threads\SGThread.cxx Line 84 Simpits Jenkins is also stuck on this build Again!!! Vivian -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
Stuart, The Buccaneer in fgdata has had a terrain clearance radar for many years now, using just the technique you describe. It's written in C++. It has a horizontal mode - but I never got it to work satisfactorily at a frame rate I liked. Vivian From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 27 November 2012 13:23 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine On Tue, Nov 27, 2012 at 1:03 PM, Adrian Musceac wrote: Hi, I've seen a couple of external radar clients for Flightgear being developed right now. I think that these days, with the advent of Canvas and other improvements, it should be possible and desirable to have a realistic radar station inside Flightgear. I recently implemented a vertical terrain clearance radar for the Douglas A4F Skyhawkd (a4f) using a combination of Canvas and Nasal terrain lookups. The code is checked into git if you are interested. My main concern when writing it was minimizing the number of terrain lookups per radar sweep. For the vertical mode this is quite straightforward as I've simplified the sampling to getting the elevation of points every 1nm ahead. I've still to look at the horizontal modes, but I suspect it would need a Nasal enhancement to perform terrain intersection tests based on a lat/lon/heading/pitch combination. I haven't looked into how much effort it would be to add that yet, though I suspect it should be fairly straightforward given that we already have similar function handling mouse-clicks for the ufo. -Stuart -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
Yes it does, but haven't got any nice textures for that yet. Any volunteers? Vivian From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 19 November 2012 10:05 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FSWeekend 2012... On Sun, Nov 18, 2012 at 5:38 PM, Vivian Meazza wrote: Been doing some more eye-candy myself: https://dl.dropbox.com/u/57645542/fgfs-screen-093.png using our new linear texture facility. It's not it FGdata yet, and I'm not even sure it's going to make the next release. That looks very nice. Presumably it would also work for roads? -Stuart -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
Thorsten wrote Hmm . that's an underwhelming list, and I can't come up with anything that's really any better. Does that encapsulate the problem? Well well, it would seem our shader-based treatment of light and the environment is quite competitive against what FSX has to offer: http://www.flightgear.org/forums/viewtopic.php?f=19t=18325#p170811 Yes, I've been trawling around YouTube for anything which is better, or even as good as our sky and sea. I think we are the at least the equal of FSX and XPlane, and probably better. Slightly subjective though. Been doing some more eye-candy myself: https://dl.dropbox.com/u/57645542/fgfs-screen-093.png using our new linear texture facility. It's not it FGdata yet, and I'm not even sure it's going to make the next release. But I wonder if that sort of thing really gives enough to justify going from 2.10 -3.0? Vivian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Alan wrote: -Original Message- From: ThorstenB Sent: Thursday, November 15, 2012 7:09 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Thortsen Here is my system.fgsrc file and then the log output.~ My TSR2, if you need it, is at g...@gitorious.org:fg-ajt/tsr2.git. The final Nasal error (nil used in numeric context) only occurs when I use the new version of simgear/misc/sg_path.cxx. Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. In each case the property /sim/fg-aircraft is that specified by --fg-aircraft=, except that the trailing \ is discarded. I ran flightgear with the command: C:\FlightGear\install\msvc100\bin\fgfs.exe fgfsrun.txt 21 system.fgsrc:- --fg-root=C:/FlightGear/fgdata --fg- scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\fli ghtgear --fg-aircraft=C:\FlightGear\MyAircraft --airport=EGNO --aircraft=TSR2 --control=joystick --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-ai-models --enable-real-weather-fetch --enable-clouds3d --prop:/sim/frame-rate-throttle-hz=60 --prop:/sim/traffic-manager/enabled=0 --geometry=1024x768 --visibility-miles=30 --bpp=32 --log-level=alert --timeofday=noon --enable-rembrandt Log file: No GAIN specified (default: 1.0) loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26 Switches.nas Annunciator.nas controls.nas timers.nas electrical.nas Engine-Start-Stop.nas TSR2 undercarriage.nas settimer(gearLights, 0); navradiodisplay.nas g-meter.nas ice-warn.nas Init properties.nas startup.nas dropview.nas TSR2-moving-map.nas TSR2 autopilot.nas TSR2 contrail.nas TSR2 liveries.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied (unauthorized access) Nasal runtime error: non-objects have no members at C:/FlightGear/fgdata/Nasal/gui.nas, line 479 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450 called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4 dialogs.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line 7 TSR2 canvas HUD.nas loading scenario 'nimitz_demo' map init-props moving map loaded Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 276 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-g-meter.nas, line 14 icewarn I hope that this helps debug the problem. I was going to check on my version of FG/SG pulled today with MCVC10 but it failed with:
Re: [Flightgear-devel] Bug 479 has come back
Tom wrote: -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 16 November 2012 15:07 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Bug 479 has come back Am 2012-11-16 14:39, schrieb Vivian Meazza: It has also failed to build in Jenkins with the same error. When someone gets around to fixing it I'll try to test again. Just as an aside, would it be possible to test for developers to test their inputs BEFORE they get pushed into Gitorious? I always test my code before pushing anything to gitorious. The problem is that I have not always access to a computer running Windows and Visual Studio so sometimes I have just to rely on the output of Jenkins. Especially the last commits made heavy use of templates where VS seems to be very buggy. If something doesn't work I normally fix it within a few hours, so sorry for any inconveniences if you happen to checkout before I've been able to push a fix. Tom Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
Gijs wrote: http://wiki.flightgear.org/Unique_Features Hmm . that's an underwhelming list, and I can't come up with anything that's really any better. Does that encapsulate the problem? Our USP is that FG is FREE - yes FREE. We might not have as much eye-candy as other sims, some of our ac as good as other sims (and some aren't) but hey - it's free, and cross platform. Anything else? .snip Comparing with MSFS and X-Plane Feel free to use the wiki to make a list of unique features and/or comparison to other simulator. Someone started this a while ago, but it could use some loving care: http://wiki.flightgear.org/Unique_Features I once started on a key binding comparison, (hopefully) making it easier for people to switch: http://wiki.flightgear.org/Key_commands_compared_to_other_simulators In this series, we can also add a dictionary (eg. what we call liveries are called paintjobs in certain communities) etc.. Listing the differences would also make a good feature request list, so we can work on great features that other sims have, but we lack. I think people would like to have at least the same, and possible better/more features before they'd consider switching. snip -- 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_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
Durk, I don't know: FS-X can really impress: http://www.youtube.com/watch?v=XViCj0uqeco http://www.youtube.com/watch?v=XViCj0uqecofeature=related feature=related Lots of wow! While we can do some, or perhaps even most of this, we can't do it at an acceptable frame rate. (Er . can FS-X?) We have this in FG: https://dl.dropbox.com/u/57645542/switcher.png We have all manner of road and rail vehicles available. I'd love to get it them into action someday. Vivian From: Durk Talsma [mailto:durkt...@gmail.com] Sent: 07 November 2012 10:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FSWeekend 2012... Hi Thorsten, On 07 Nov 2012, at 10:55, Renk Thorsten wrote: Sorry, I don't want to talk down on the great job you guys are doing in presenting all this, I'm just trying to understand what it is you consider an eye-catcher. I'm just a bit mystified that somehow a feature which dominated our screenshot contest doesn't count in this department... No worries. :-). This is actually fairly subjective, and I'm afraid that I didn't explain my concern too well in my initial post. The real issue is salience, which you can describe as the subjective property of a percept to stand out from it's environment (see http://en.wikipedia.org/wiki/Salience_(neuroscience) ). So, a cool feature that easily dominates in a screenshot contest may not be able to capture our attention very effectively in a different context, such as the one at FSWeekend, where visitors are usually bombarded with high quality graphics. So, what I was actually looking for was new ways of *using* FlightGear, within the limitations of an internet-free environment. Our lan based multiplayer server was very effiective in the past, and in the last few years we also had some new aircraft and/or a specific theme, or even an internet connection, all of which served as great eye-catchers. This year was a bit of a step back in those respects, so I found myself more often than not reverting back to the tested and tried. Well, yes and no - even if we're just catching up in graphics to what others do (which in many cases we probably do, judging by screenshot googling), isn't the fact that a scene no longer looks like 10 years behind what others do somehow relevant? It might not act so much as catch attention than to prevent immediate turn-aways... Of course it is, and in many cases it does keep visitors attention a bit longer, usually because they don't know what they're exactly looking at. :-) Cheers, Durk -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FW: Simgear/ShivaVG compile fails on windows
I wrote
Thomas wrote:
Am 2012-11-05 18:30, schrieb Vivian Meazza:
I'm using the Nasal API - it used to all work before today's update.
Can't really see what to change
Are you using canvas.setColorBackground(r, g, b, a) I have this:
m.canvas.addPlacement(placement);
m.canvas.setColorBackground(0.36, 1, 0.3, 0.02);
which is a direct copy from
http://wiki.flightgear.org/Canvas_HUD
and is there a function
setColorBackground: func () { me.texture.getNode('background',
1).setValue(_getColor(arg)); me; }
No - there isn't one in
http://wiki.flightgear.org/Canvas_HUD
in your Nasal/canvas/api.nas?
Are there
/canvas/by-index[i]/color-background/[red,green,blue,alpha]
nodes in your property tree or just a single
/canvas/by-index[i]/background string property per canvas?
And no other references to color-background
OK - problem solved - I needed another update to fgdata. I must have just
missed the update to api.nas when I updated everything yesterday.
Vivian
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear/ShivaVG compile fails on windows
:Alan Teeder wrote Am 2012-11-05 12:14, schrieb Alan Teeder: Just a heads up. The error report is :- Thanks for the report. Should now be fixed. Tom Yes - it all compiles and runs again. And my canvas HUD (in development) still works! But mine doesn't :-( https://dl.dropbox.com/u/57645542/fgfs-screen-068.png Any clues/hints? Vivian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear/ShivaVG compile fails on windows
Thomas wrote fails on windows Am 2012-11-05 16:02, schrieb Vivian Meazza: But mine doesn't :-( https://dl.dropbox.com/u/57645542/fgfs-screen-068.png Any clues/hints? Have you also updated fgdata? Yes, using MSVC10, and after the same problems as Alan. The way how the background color is set has been changed (Now it uses only on single property for the whole color instead of one for each color component) and defaults to opaque black. Looks like it might be using the default ... but Using the latest Nasal API for setting the background color should still work the same as before. I'm using the Nasal API - it used to all work before today's update. Can't really see what to change Vivian -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
