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] 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] 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] 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] 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] 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] 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: 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] 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] 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] 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] 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] 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] 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] 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
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] 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] 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] 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] 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
