Re: [Flightgear-devel] Mipmapping of liveries
On Tue, Sep 24, 2013 at 6:04 PM, Tomash Brechko tomash.brec...@gmail.com wrote: Hello, Recently I was told that some planes have liveries of so high resolution that you have to install low resolution versions to have a decent fps during multiplay. But doesn't FG use mipmaps for liveries? If not then are there plans to do so? Or should the livery be prepared in a certain way to trigger mipmap generation? Perhaps mipmaps should also be applied to interiors as sometimes you can see the insides through the window. -- Tomash Brechko Use of mipmapping only mitigates the issue. If a very high resolution 4096x4096 texture is being used, the first level of mipmapped texture reduction is 1/4 of that in pixel area, or 2048x2048. If a texture of more modest resolution like 1024x1024 is used, then the first level of mipmap reduction would result in a 512x512 texture. So a high resolution base texture is still going to result in a larger mipmap texture than a lower resolution base texture at the same mipmap reduction level. This is true of any texture in the scene where the object is not culled by LOD settings, etc. Liveries just tend to be the biggest hits. The results are cumulative for your video hardware. So in multiplayer, all those additional aircraft in the scene using high-resolution textures will tax your video card more heavily than aircraft using lower resolution images, even with mipmapping enabled. Hope that helps, -Gary aka Buckaroo -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
On Wed, Sep 25, 2013 at 3:37 PM, Tomash Brechko tomash.brec...@gmail.com wrote: Why limit yourself to only one downscale level? Mipmap can go several levels down, so it doesn't make much difference whether you started 4096 or 2048 (leaving space issues aside). I used the first mipmap level as an example of the effect at any given mipmap reduction level, not an artificial limit. Mipmap level is determinied by virtual viewing distance to the object and image filtering mechanisms. For any given mipmap level, a mipmap for a higher resolution texture compared to a mipmap of a lower resolution texture will have the same size ratio as their base images. So the initial texture size makes a substantial difference. -Gary -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mipmapping of liveries
On Wed, Sep 25, 2013 at 4:46 PM, Tomash Brechko tomash.brec...@gmail.com wrote: 100 / cos(45), but you get the idea ;) OK, I see what you're getting at now-- the selection of the mipmap for rendering rather than the memory footprint. Yes, that makes sense to me-- the engine should be able to choose a mipmap that best fits the screen scale based on distance, so for a larger base image it's dropping down deeper into the mipmaps. There is still the issue of resources. A 4096x4096 texture without an alpha channel is about 50MB, a 1024x1024 is about 3MB. Add +33% for mipmaps. So a single 4096 texture would buy a lot of 1024's. Also, I believe the larger the image, the more initial overhead is necessary to create the mipmaps, unless the image is a DDS type in which case mipmaps can be pre-generated. So the larger the image, the more memory resources required, and there's a bigger load hit when the resources are initially loaded. I've felt my machine come to a crawl while certain planes are loaded in MP-- I had to remove some because they were too much of a hit for my poor aging system. -Gary -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60133471iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Website down?
Same here. Fatal error: Out of memory (allocated 2621440) (tried to allocate 7680 bytes) in /home/flightge/public_html/wp-includes/pomo/mo.php on line 229 -Gary aka Buckaroo On Wed, Jun 19, 2013 at 2:38 PM, Wil Neeley bentchic...@gmail.com wrote: Its down for we too, and delivery failed for webmas...@flightgear.org Wil Neeley On Wed, Jun 19, 2013 at 2:36 PM, Chris Calef chris.ca...@gmail.comwrote: Hello, Just wondering if flightgear.org is down for everyone or just me? I'm getting fatal server errors like this: *Fatal error*: Out of memory (allocated 1048576) (tried to allocate 7680 bytes) in */home/flightge/public_html/wp-includes/compat.php* on line *41 * Cheers, Chris C -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- 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)
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] 2.10.1
On Wed, Mar 13, 2013 at 9:31 AM, James Turner zakal...@mac.com wrote: Hi, As previously suggested, I am going to attempt a 2.10.1 release, to see if this improves our perceived quality. There's some bug fixes I am already aware of, including a Windows path-handling one which is quite significant. I would appreciate nominations for other bug-fixes and low-risk tweaks, to be merged to the release branches, including fgdata. Ideally give me SHAs of commits on next, which I can safely cherry pick to the release branches - if commits need editing, a merge-request would be easier for me to process. Or you can merge yourself to the release branches, providing you exercise suitable diligence :) Regards, James Howdy James, With regard to the Windows release, after installing Setup Flightgear 2.10.0.3.exe on Windows XP, when launching fgrun I immediately get the following error/warning: There is no disk in the drive. Please insert a disk into drive D:. It does it upon launch of fgrun, and it will also do it later upon selection of the dhc2 aircraft. After removing all aircraft and cleaning out the fgrun preferences file, fgrun still gripes about no disk in drive D: on launch.Everything still works if one simply selects Continue, though it's a bit annoying. I haven't seen this mentioned elsewhere, though I didn't search rigorously. If this is related to the Windows path-handling thing, then please ignore me. :) -Gary aka Buckaroo -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
On Fri, Mar 9, 2012 at 5:58 PM, syd adams adams@gmail.com wrote: On the subject of novices, would it be a good idea to have an idiot-startup button or menu, which makes everything all systems go and ready to take off? Alan Mine already have such a button , in the menu called autostart'. I do the same on my models, following Syd's example. I think a number of others also do so. A location for such an item might be standardized, but the functionality would vary considerably, since the properties that must be set may vary widely with each aircraft. I don't mean to get too far off topic though. -Gary -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a small set of minor aircraft model question...
On Mon, Mar 5, 2012 at 6:05 PM, Ron Jensen w...@jentronics.com wrote: On Monday 05 March 2012 02:53:59 Francesco Angelo Brisa wrote: * Analogic instruments: I was looking at two amazing done aircrafts: the DR400 and the Cessna 337; the DR400 has instruments with a glass reflection (Which is very nice and realistic) the C337 does not have it. I personally slightly prefer the C337 way, a little more clean, but it is just my feeling. the question: what would you suggest to do, if I want to take an aircraft, add a instrument, which type should I use ? i.e. if I want to add instruments to the C310. Personally, I hate the glass shaders covering instruments and windows. I want to actually fly these aircraft and not drool over how 'real' they look. Flying means I need to be able to actually read the instrument, so I often prefer larger fonts and bolder lines than perhaps the original had. +1 I'd think that real aircraft engineers would seek to minimize these effects, and that they would manifest significantly in some but not all lighting conditions. In any case, I greatly dislike these glare/reflection effects on instruments and interior windows, though many effects might be made more user-friendly if the effect was diminished or made more transparent. I know enough to be able to remove these effects from models, but it can be tedious and lots of folks either aren't that handy with modeling or don't have the time. Just my $.02. -Gary -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft ratings on the download page
On Fri, Feb 17, 2012 at 7:10 PM, Heiko Schulz aeitsch...@yahoo.de wrote: On a slightly related note, stumbled accross this: a HTML5 JavaScript library to render 3D models in .ac format using WebGL. Might be a nice addition to our download page... Demo: http://inmensia.com/files/hangar/flight-gallery/index.html Source: http://code.google.com/p/hangar/ Hmmm... The latest version of Opera doesn't show me the models. Mozilla Firefox is able to do, but with render artifacts. I would rather see a search system, so people can search for their wanted criterias. Heiko Demo: http://inmensia.com/files/hangar/flight-gallery/index.html Firefox 3.6.26 doesn't show anything either, just a mostly blank gray page. -Gary -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
On Sun, Feb 5, 2012 at 7:50 AM, thorsten.i.r...@jyu.fi wrote: I haven't really seen any guidelines about efficient shader coding, but I've come across a few statements here and in the forum now and then, which I so far assumed to be true. I've now spent the last few days benchmarking my lightfield/terrain haze framework to see if I can't squeeze a bit more performance out. Since the results somewhat contradicted things I have assumed to be true before, I thought I might share my observations. 1) vertex shader is fast and efficient, fragment and geometry shaders are comparatively slow and cost performance I don't know who stated that here, but I intuitively assumed that this must be right. You can imagine that I was surprised that when I trivialized the fragment part of my code, the performance didn't change at all, but when I trivialized the vertex part, the performance doubled. So it seems like the whole performance drain of my code is caused by an overworked vertex shader. I then transferred the haze color computations to the fragment shader, which improved overall performance in my benchmarks by 20-40%. It seems the optimal results appear for a shared workload between vertex and fragment shader. Since for instance 3d clouds run almost exclusively via vertex shader, this may not be an otherwise irrelevant observation. 2) vertex count doesn't matter I've read that in the forum as advice to model-builders quite often. For all I can test, that's wrong. In order to get the same framerate in default scenery and custom Italy CORINE scenery, I have to set the visibility range ~a factor 10 different. That's consistent with a hundred times higher vertex count in the CORINE scenery, or with a factor 10 higher linear resolution of landcover and elevation data, which seems about right. So the vertex count more or less directly sets my framerate. This is also relevant for models, because having a cluster of ~ 5 AI planes (which happened to be stuck into each other) in my view or not caused a 25% change in framerate, so the vertex count of models matters compared with the vertex count of scenery and is not some insignificant correction. Thorsten, #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. I've worked in the gaming world long enough to know otherwise. Total scene resources matter. Sure, graphics cards are optimized to quickly render large, well-designed objects. You can build a beautiful model with hundreds of thousands of polygons and that's great. But when it's in a scene with gazillions of other objects, it's a hit. Animate it and the situation just gets worse. This is why game designers build objects with minimal vertices and create detail using good texture and shading tricks. People need to understand that their wonderful creations must live and play in the same sandbox as other wonderful creations. But I am not going to rant. I am not going to rant. I am not going to rant... ;) -Gary aka Buckaroo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader performance
Dang, I shouldn't have ranted. This added nothing to Thorsten's discussion. My apologies to the list and to Thorsten. -Gary Thorsten, #2 has long been a point of frustration for me. I've given up trying to address folks on the forum who say throw all the vertices/polygons at it that you like! Graphics cards can handle millions with no problem! Last time I looked there was even an FG wiki article that advised modelers to use as many polygons as they like. I've worked in the gaming world long enough to know otherwise. Total scene resources matter. Sure, graphics cards are optimized to quickly render large, well-designed objects. You can build a beautiful model with hundreds of thousands of polygons and that's great. But when it's in a scene with gazillions of other objects, it's a hit. Animate it and the situation just gets worse. This is why game designers build objects with minimal vertices and create detail using good texture and shading tricks. People need to understand that their wonderful creations must live and play in the same sandbox as other wonderful creations. But I am not going to rant. I am not going to rant. I am not going to rant... ;) -Gary aka Buckaroo -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Models generating OpenGL invalid operation warnings
On Mon, Dec 26, 2011 at 4:53 AM, James Turner zakal...@mac.com wrote: On 26 Dec 2011, at 00:54, Gary Neely wrote: For quite some time many models will endlessly spew the following warning to the console: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) I'm having something which *may* be similar. To check if it's the same issue, please set the following environment variable, and run fgfs again: OSG_GL_ERROR_CHECKING=ONCE_PER_ATTRIBUTE And post the actual attribute number that is logged) This may be dependent on graphics cards-- I have an ATI-based HD 3850 from a few years ago, so maybe many folks don't see this warning. I think there's also a way to suppress it. But it was bugging me that my own older models spew this warning while my newer efforts don't. At first I figured it was a 3D model or shader issue, but I found that eliminating all 3D models and animations down to a simple non-textured cube had no effect. That sounds like a different issue to mine, but we shall see. In general, the Ati drivers seem much stricter in checking state that the nVidia drivers accept and tolerate. Working under FG 2.4 with various -set.xml files, after a lengthy process of elimination and replacement I finally found what is triggering the warnings: the 'radar' instrumentation module. When I remove that module from the instrumentation import XML, the warnings stop. The radar module is included in the generic instrumentation file that many aircraft use, Aircraft/Generic/generic-instrumentation.xml, which explained why so many planes generate the warning. That's strange indeed - as you say, the radar should not be used if not included, since it can eat a few FPS to generate the texture. Its state-sets are pretty simple, so I will be very interested to see what error is reported once you set the environment variables above. James James, Setting the above environment variable (I'm using Windows XP) changed the warning output to: Warning: detected OpenGL error 'invalid operation' after applying attribute View port 16776AD0 I loaded various planes that used the radar module and all generated the above warning, but the View port value was different for each plane and usually different for each run using the same plane. -Gary -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Models generating OpenGL invalid operation warnings
Howdy, I hope I'm not posting on an already solved issue-- a search didn't find anything that directly addresses this, though I found lots of tangential stuff. For quite some time many models will endlessly spew the following warning to the console: Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) This may be dependent on graphics cards-- I have an ATI-based HD 3850 from a few years ago, so maybe many folks don't see this warning. I think there's also a way to suppress it. But it was bugging me that my own older models spew this warning while my newer efforts don't. At first I figured it was a 3D model or shader issue, but I found that eliminating all 3D models and animations down to a simple non-textured cube had no effect. Working under FG 2.4 with various -set.xml files, after a lengthy process of elimination and replacement I finally found what is triggering the warnings: the 'radar' instrumentation module. When I remove that module from the instrumentation import XML, the warnings stop. The radar module is included in the generic instrumentation file that many aircraft use, Aircraft/Generic/generic-instrumentation.xml, which explained why so many planes generate the warning. Maybe this has already been found and addressed for the next FG version. If so, cool. I wonder though, should the radar module be enabled in the default instrumentation file, rather than at least commented-out? It seems a hefty module, and many general aviation models wouldn't need it. Anyway, hope this helps others. -Gary, aka Buckaroo -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem restarting YASim aircraft after fuel starvation
Stuart, Hopefully others will also confirm, but I'm fairly certain fuel.nas is used only for YASim support. I always swap it out with my own custom routines since it's limited and problematic, but it's useful for early prototyping support. Without it there are no default routines to reset the fuel-consumed-lbs property under engines. Also it's not needed for YASim aircraft lacking normal YASim engine support, such as sailplanes or helicopters. It might be nice if there was an easy way to disable it in such cases, perhaps a simple /sim property that if set, prevents fuel.nas from initializing. I'm thinking fuel-freeze wouldn't serve that purpose well since custom engine/fuel routines (helicopters) might use that property. My $.02 thoughts. -Gary aka Buckaroo On Tue, Dec 20, 2011 at 4:16 PM, Stuart Buchanan stuar...@gmail.com wrote: Hi All, I'm investigating http://code.google.com/p/flightgear-bugs/issues/detail?id=526, which appears to be a long-standing bug that after fuel starvation it isn't possible to restart YASim engines. The problem appears to be in fuel.nas line 25, which drops out from making any fuel calculations if the engines aren't consuming any fuel. Unfortunately this means that there's no opportunity to reset the out-of-fuel flag. I think this line is also intended to drop out for FDMs other than YASim, which don't use fuel.nas, but instead have their own fuel management. Can anyone confirm that fuel.nas is only used by YASim? If so, I'll change the FDM initialization listener to simply never start the update loops for FDMs other than YASim, and remove the code that drops out. -Stuart -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] turbine inlet temperature in the seneca (TIT)
On Mon, Dec 5, 2011 at 6:08 PM, Tuomas Kuosmanen tuomas.kuosma...@gmail.com wrote: Hello. I am working on some XML 2D gauges for our aviation club flight training device. We have a twin engine trainer I built over the years which runs on top of MS Flight Simulator, and I am making a flightgear setup for it to have a platform that stays alive :-) The SenecaII looks like the best choice for FDM, and I started to model some gauges in the SenecaV style (as our trainer has the two columns of small engine gauges on the right -panel cutout in place). However, SenecaV new style engine cluster has a turbine inlet temperature gauge (TIT). Does FG model this value? The property tree seems to have a tit property but it seems to be empty no matter if engines run or not. Does anyone have a clue on how to do this? Or should this be done somehow via nasal / other assumptions based on manifold pressure and environment etc..? Or should the TIT value show something? Best wishes, //Tuomas Tuomas, I can say for certain that YASim does not model TIT, and I believe JSBsim doesn't either, though there seems to be a stub for TIT modeling which may be where that property comes from. Someone please correct me if I'm wrong about JSBsim and TIT. A developer may have written custom code to model turbine inlet temp for a specific model, but I'm not aware of any examples. I'm currently working on a project that aims to handle multi-cylinder temperature reporting and yield results good enough to at least teach the concepts of best power/best economy and LOP operations. Unfortunately my effort doesn't yet model turbocharged engines. Since you're using the JSBsim-based Seneca II, you might want to consider working with JSBsim to add the necessary modeling for TIT, if it doesn't already exist. You might try posting on the JSBsim forum on this topic, as someone may already be developing this. -Gary aka Buckaroo -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] turbine inlet temperature in the seneca (TIT)
On Tue, Dec 6, 2011 at 6:13 AM, Tuomas Kuosmanen tuomas.kuosma...@gmail.com wrote: On 6 December 2011 11:07, Gary Neely grne...@gmail.com wrote: I can say for certain that YASim does not model TIT, and I believe JSBsim doesn't either, though there seems to be a stub for TIT modeling which may be where that property comes from. Someone please correct me if I'm wrong about JSBsim and TIT. A developer may have written custom code to model turbine inlet temp for a specific model, but I'm not aware of any examples. Yeah, maybe one could do this with nasal, some educated guesswork etc.. As long as everything is working normally, it should follow other engine parameters and ambient air properties, I guess. I'm currently working on a project that aims to handle multi-cylinder temperature reporting and yield results good enough to at least teach the concepts of best power/best economy and LOP operations. Unfortunately my effort doesn't yet model turbocharged engines. That is important stuff too, would be useful for me also. Actually it would be nice to have something like the EDM-800 gauge (http://www.jpinstruments.com/edm_800.html) to show the values. Unfortunately my skills with fg / nasal / programming are not very high, as I am more of a designer, but let me know if I can help with graphics. I am better with that stuff. :) Well, I don't seem to have any 800's handy, but... http://www.jubjubjamboree.com/grn/flightgear/images/fgfs-screen-002.png maybe something loosely like an 830 would do for ya? -Gary, aka Buck -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 11:23 AM, Heiko Schulz aeitsch...@yahoo.de wrote: If your using dxt compression, which is why most people use dds, then it is NOT equal to the original image. Amount of degradation will depend on the image, resolution, type of dxt used, etc..but will never be the same or better quality. This applies to every texture file which use compression. So it belongs to .png, .rgb and .jpg as well. I never heard that anyone asked for the source here There is always a degradation, the question is, is it visible to human eyes? Well, not quite-- PNG and SGI/RGB use non-lossy algorithms for compression-- when uncompressed you get back exactly what you put in. They don't degrade the data, so archiving in these formats is fine. Formats like JPG and DDS/DXT use the source data to generate a compressed version, but the new version can't be restored to the exact original data. (Try a comparison between original and compressed versions examined on the pixel level-- it's interesting and revealing.) This means these are not good formats for archiving source material that might be edited later. With lossy formats using high-quality, low-compression settings, you might not visually notice degradation on the first edit, but you will eventually see substantial differences on subsequent edits. Each time you edit from an new lossy-compression source, you lose information, but you do not with the algorithms used by PNG and SGI/RGB. On a personal note, I had a lot of trouble getting co-workers to stop archiving their source images as JPG files. It took a lot of explaining and re-explaining. ;) -Gary -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
On Sun, Nov 6, 2011 at 7:50 AM, Heiko Schulz aeitsch...@yahoo.de wrote: Hello, I just noticed today that the textures folder in scenery growed from 50 MB to ~200 MB. But I don’t see that many new textures ? I read once here that the benefit from getting DDS is also we get smaller file sizes for the textures. But now I see textures like crop (and cropA) DDS files that take ~20 MB. Is this for testing purposes only, or do we use the space we get by splitting aircrafts in near future for the textures ? ;-) No one said, that the benefit of .dds is smaller file size! The benefit of .dds is, that it can be loaded much, much faster into Video-Ram as mipmaps can be saved directly into the texture. With other formats it has be done seperatly and that's slow. So perfomance has even increased with. Quality compared with other compressed texture-formats like .png is btw. much higher. And Mipmaps also allow some interesting effects which you can see when you enable the use of .dds-scenery-texture in FGFS. Btw. the size of the texture-folder is compared with the aircraft-folder really, really small. Heiko Adding to what Heiko mentioned: The main win for DDS, at least from a game design point of view, is the ability to maintain a kind of compression while loaded into the graphics memory. This is (as far as I know) unique to DDS/DXT. It uses an interesting technique where data is loaded as tiny unique blocks that are indexed and mapped to locations within the image as needed. The bottom line is that game designers can pack many more textures into large but still limited memory resources. DDS is relatively fast because it is natively supported by video cards. But if I remember right, for pure speed of loading it's hard to beat good-ol' RGB. -Gary -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures sizes, DDS
This topic raises a point about distribution of non-critical files. For example, my 1049H Constellation has a number of large files that aren't necessary for flying the plane. I have source PSDs for livery-makers, and Yakko's terrific How-to for flying the 1049H. Both are directly beneficial to interested Flightgear users, but not essential, and both sets are large files (10MB or so each) that would bloat the plane's base distribution. Currently these are maintained and available at my home site. Provided that all materials are GPL, it would be nice to attach them somehow to the plane as a kind of optional secondary download, a sort of 'developers kit'. Does this concept make any sense? Would it be too seldom-used to be worth it? Is it even possible? Or are others already way ahead of me on this kind of idea? I'll stop cluttering up the bandwidth now. :) -Gary -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgdata: Important note
On Tue, Oct 25, 2011 at 7:33 PM, HB-GRAL flightg...@sablonier.ch wrote: Am 25.10.11 18:54, schrieb Gijs de Rooy: No matter what aircraft-split we end up with, aircraft authors will always be able to update their own aircraft at any time. Hope so ;-) With the current setup you can for example commit (and accept merge requests) for your EC130:https://gitorious.org/flightgear-aircraft/ec130 But I want to give commit rights to my wife to my repo, without asking you, can I do that ? Why not ? What gives the team the right to decide if my wife could be contributor in my aircraft project or not ?! When you start on a new aircraft and would like to have its repository under the FlightGear Aircraft project, you do have to ask one of the people from the team: https://gitorious.org/+flightgear-aircraft For every single aircraft ? Hm, everyone ? You also have to contact that teammembers when you'd like to get access to an existing repo (or give someone else access to your aircraft's repo). Sorry, Peter is not here since six months, but Paul - ok, he does not know a lot about your project - but he will give access to Alex, to update Sabins repo permissions. The #1 reason I haven't added my projects (MD-81, Grumman Goose, Edgley Optica, Velocity XL RG) to the repository is that I have no ability to perform my own commits. Possibly I haven't earned the right and I can understand that. But I would like to learn and understand the procedure for how one earns these rights, and maybe others would too. Don't get me wrong-- for core FG work I readily see the value in maintaining a short-list of those with commit rights and/or peer-review before commits. But for non-core work such as aircraft projects, it's somewhat bothersome. In the past Durk has been kind enough to submit my 1049H Constellation to the repository. I'm grateful and I am certain he would readily continue to do so. But I dislike troubling him (or anyone else) to do it. Durk and others do great work here and I don't like adding busy-work to their plate. -Gary aka Buckaroo -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
On Mon, Aug 15, 2011 at 12:18 PM, Viktor Radnai viktor.rad...@gmail.com wrote: Hi all, Athanasios Goritsas (cc-d) created a nice Falke 3D model with a basic Yasim profile, based on the aircraft he flew with. I would like to develop his model further (I'm doing my PPL on the real thing atm). We would both like to see it in Git (under a GPL license), maybe more people would join in developing it further. (If you need a statement on this directly from Athanasios, as he's the primary author, let us know.) In the meantime, could you please check out the plane and shed some light to some Yasim parameters. You can grab it from http://www.avatarzenekar.hu/files/sf25b.tar.bz2 The biggest issue with the FDM is that the plane does not seem to have enough drag -- it easily goes over Vne, and it's impossible to land without spoilers unless you stop the engine (and even then it takes forever). Compared to the Grob 109, I had to use an absolutely huge drag multiplier to force the bird down (150 instead of 2.5). 150 is probably a bit much -- maybe 100-120 would be enough, but I think the airframe or the wings are just not generating enough drag. Not sure if I did a good enough job with the fixed prop. The diameter should be correct, not sure about the rest. My school's falke has the 2L engine and it spins up to about 2600 when stopped. No idea about the prop's most efficient speed and horsepower values are pretty much guesses. Anyway, please let us know if this is good enough to go into the repo, and any suggestions for improvement. Some (working) 3D instrument panel would be great, but I have no idea how to make that. Any pointers on that would be very much appreciated. Since Falkes have fairly varying instrumentation, even a copy of the Grob 109's panel could be OK. Ah, and the splash screens I've made do not load. What did I do wrong? Thanks in advance. Cheers, Vik Vik, Looks like a great start. The first thing I would do before anything else is make sure your CG is positioned reasonably. In your SF-25, the CG is much too far back; given the forward-swept wings, it looks to be about a meter behind MAC: E:\FlightGear projects\sf25byasim sf25b-yasim.xml Solution results: Iterations: 1292 Drag Coefficient: 10.955851 Lift Ratio: 291.677826 Cruise AoA: 1.469686 Tail Incidence: 2.793443 Approach Elevator: -0.014301 CG: x:-0.900, y:-0.000, z:0.284 Inertia tensor : 1831.357, -0.000, 78.171 [kg*m^2] -0.000, 2075.542, 0.000 Origo at CG 78.171, 0.000, 3856.738 The command-line YASim solver is showing CG at x=-0.9, well behind the wing's root chord position at x=-0.371. It isn't worth messing with other YASim values until CG is about right. I'd first try to locate the real CG range from a certification sheet or pilot's handbook and then use a YASim ballast element to shift some of the plane's mass forward toward the nose. Once you get CG better positioned, you'll have much better luck with other factors. After CG, a couple of other things to watch in the solver: Lift ratio is very high-- this indicates the glides-forever issue. For this plane I'm guessing you'll want a value somewhere between 100-130, but the actual value will depend on flight experimentation. Lots of YASim parameters affect that value. (Note that these YASim drag and lift numbers should not be treated as real lift/drag ratios; don't try to make them match a real L/D ratio.) Approach elevator is much too small-- this value means you'll need almost no elevator to hold an approach. Look for something in the -0.7 to -0.9 range for starters. In any case, don't try to tweak these until CG is resolved. Wing and hstab stall AoA values look really high at 30 degrees. Most conventional high-lift general aviation airfoils seem to be in the 15-18 range. If you know the airfoils used, you can get camber and stall values from the airfoil data. I have a little and rather incomplete YASim guide that might be helpful: http://ltts.crlt.indiana.edu/grn/flightgear/ -Gary, aka Buckaroo -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New aircraft: SF-25
Vik, Based on Maik's CG information and a little nosing around for performance information online, I made an el-cheapo quick and dirty FDM: http://ltts.crlt.indiana.edu/grn/flightgear/sf25b-yasim.xml Feel free to use it, lose it, abuse it, or whatever. It's a bit tricky to takeoff and land, especially in any kind of crosswind-- it takes a fair hand on the rudder. It also likes to glide and glide once it gets close to the ground, so you'll definitely not want to approach over 50 kts or you'll never get down. I often side-slipped to help me get down. I disabled the linkage of the spoilers with the wheel brake-- According to the book, brakes are engaged only on the maximum spoiler setting, but I got tired of nosing-over when I landed. ;) You might want to restore that. I didn't try to match sink rate to real, I only tried to get the speed range within reasonable norms and bring control surfaces effects to something that felt reasonable. You might want to mess with the spoiler settings, maybe increase the drag a bit, as the handbook says they're pretty effective, and I tend to err on the understrength side. I'm not a pilot, so definitely feel free to disregard anything I did. -Gary, aka Buckaroo -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Having an issue with my mags
I have two questions for you. First one is what is the differance between the Yasim engine and what you have here? Like I said, only been diving into this a week and am still figuring things out, so a simple answer would be best. ;) Hi Rob, As Syd said, a YASim aircraft doesn't use the YASim fixed-wing engine declarations, but uses a different set of specifications for the rotor and its drive train. I'm not a helicopter developer, so I can't help with details of rotor stuff, but maybe Heiko other helicopter gurus will drop in with comments. What I can say is that you don't have to rely on the YASim FDM to do all the simulation and in some cases you're better off not using YASim's results. For my own projects (fixed-wings), I'm increasingly taking engine parameters into my own hands, crafting my own code (nasal scripts) to supplement, modify, or replace the engine parameters YASim provides. If you want to simulate a helicopter engine you could write your own routines to manage the engine itself; temperatures, pressures, RPMs, start-up, shut-down, fuel, that sort of thing. Some things might link to YASim's rotor outputs, like RPMs etc. Others might be managed separately with no FDM dependencies. Since you're fairly new to Flightgear it may take a little while to get comfortable with all this. If you study the configuration files of many planes and helicopters, you'll encounter a lot of clever ideas and solutions. There really aren't many restrictions other than what you are willing to do. That's kinda the cool thing about Flightgear. -Gary, aka Buckaroo -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Having an issue with my mags
On Wed, Aug 10, 2011 at 7:57 PM, Rob r...@dragondark.us wrote:
Hi all, another question.
I'm trying to get control of the magnetos to give me off, left,
right, and both conditions. Right now I have this bit of code:
In -set.xml:
key n=111
nameo/name
descToggle Mags Off/desc
binding
commandnasal/command
scriptR22.Off_Mag()/script
/binding
/key
Which should
take the key 'o' and send to the R22.nas for the next bit of code.
In R22.nas
var Off_Mag = func{
setprop(controls/engines/engine[0]/magnetos,0);
setprop(engines/engine[0]/running,0);
}
According to
what I have been able to gather, this should set the mag position to
'0', or off, and kill the engine.
Unfortunately, nothing happens when I run the code, the helo continues
to run as if nothing has happened. Is there something obviuos I am
overlooking?
Thanks,
Rob
Howdy Rob,
A YASim FDM helicopter doesn't usually define an engine in the
conventional sense. In addition to what you've already done, you might
have to terminate the fuel flow to kill the engine. I had a quick look
at the R22-- it looks like Syd has a similar routine for killing the
engine in R22.nas, but he calls it /after/ fuel supply is terminated.
You might have a look at that for ideas if you haven't already. I'm
guessing Syd will come on after a while and give you some more
information.
-Gary aka Buckaroo
--
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
On Sat, Jun 18, 2011 at 10:38 AM, Bertrand Coconnier bcoco...@gmail.com wrote: 2011/6/17 Gary Neely grne...@gmail.com: I've always understood actionpt to be the location where thrust should be applied with respect to the airframe. For a propeller-driven engine, I use the approximate location of the main thrust bearing. For a jet, I reckon it depends on the type of jet and the degree of bypass. An older jet engine develops its thrust from the exhaust chamber region. Modern engines with high bypass ratios develop more of their thrust from the fan, so the action point would likely move forward closer to where the main thrust bearings of the fan are located within the engine. I'm not an engine expert by any means, but these are the assumptions I've used. Moving the point of action of a force along the line of action of the aforementioned force does not change the moment. Since the thrust line of action is almost parallel to the turbine/propeller/fan shaft, moving the point of action from the fan bearing to the exhaust region will only marginally change the resulting moment. So my advice FWIW is to not bother about that. Bertrand. I agree, with reservations. Some engines, for instance some turboprops, have thrust bearings significantly offset from the engine/prop mass. Perhaps that's trivial in most cases, but in my opinion if the designer has good information on where an actionpt would reside, it makes sense to use that information. Working toward fidelity is part of the fun of this stuff. -Gary -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Clarification on YASIM input (actionpt)
On Fri, Jun 17, 2011 at 12:17 AM, xsaint xsa...@gmail.com wrote: Hello Folks... Was wondering if any nice souls will assist clear this doubt on mine... In YASIM, what does actionpt really refers to? Is it the point the engines pull the air through? which the point will be ahead of the engines or is it the point at back the end of the engine where the exhaust takes place? OR Do we have different application for actionpt based on the aircraft we are modeling. For example, if it is a passenger jet, the actionpt is ahead of the engines and if it is a military jet, then the actionpt is behind the nozzle? Thank you all for the clarifications cheers I've always understood actionpt to be the location where thrust should be applied with respect to the airframe. For a propeller-driven engine, I use the approximate location of the main thrust bearing. For a jet, I reckon it depends on the type of jet and the degree of bypass. An older jet engine develops its thrust from the exhaust chamber region. Modern engines with high bypass ratios develop more of their thrust from the fan, so the action point would likely move forward closer to where the main thrust bearings of the fan are located within the engine. I'm not an engine expert by any means, but these are the assumptions I've used. -Gary aka Buckaroo -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Future repository for non-GPL aircraft
Just a thought: The Flightgear wiki currently has a small page devoted to links to personal hangars. It is rather obscure, being a simple link embedded in text and buried in the Using Flightgear-Additional Aircraft page, but it has greater potential. Perhaps this link could be more prominently displayed and expanded. It could become similar to its parent page-- the Additional Aircraft page expanding on various GPL aircraft, many of which are hosted outside of the FG repository. Of course it would be up to individual owners to develop and maintain their portion of that page or pages, but that likely wouldn't be a problem. Such a page could serve to introduce some of the many Flightgear-related projects people are doing, would provide a location to give exposure to otherwise orphaned projects, and bring more value and attention to the wiki with little or no cost to the rest of the project. -Gary -- Fulfilling the Lean Software Promise Lean software platforms are now widely adopted and the benefits have been demonstrated beyond question. Learn why your peers are replacing JEE containers with lightweight application servers - and what you can gain from the move. http://p.sf.net/sfu/vmware-sfemails ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
Adrian, Great catch on the fuel and glideslope issues. You're right-- despite parsing the fuel attributes and supplying defaults if necessary, it has the defaults hard-coded right in the Airplane::compile block. It seems to consider the user-supplied values for aircraft mass, but not elsewhere. Makes me feel dumb that I'd not noticed this before. I hope this one makes it in the new build! -Gary On Thu, Apr 14, 2011 at 9:06 AM, Adrian Musceac kanto...@gmail.com wrote: Hello, I have found a couple of YASim issues, more details here: https://code.google.com/p/flightgear-bugs/issues/detail?id=302 https://code.google.com/p/flightgear-bugs/issues/detail?id=303 Would anyone still maintaining YASim please have a look and provide some feedback? Cheers, Adrian -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adventures in dds
Just to add to the fun, .dds has an added benefit that I didn't see mentioned here-- unlike other formats, .dds has the ability to store textures compressed in memory, not just on disk. This can result in a considerable savings of graphic card RAM. Most .dds formats are lossy though, which requires some consideration and care. The .dds format is natively supported on graphics cards, which accounts for much of the speed given all that is happening. I'm not particularly advocating .dds, but it's worth considering for certain applications, especially where large numbers of textures are used for a similar task. -Gary aka Buckaroo -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Thrust reversal for YASim turboprops?
On Thu, Mar 17, 2011 at 10:14 PM, Ryan M tpbspamm...@gmail.com wrote: I'm trying to implement thrust reversal (if possible) for the ATR 72, a YASim turboprop, but I can't seem to find a way to do so. I've tried the same parameters used for jets: control-input axis=/controls/engines/engine[0]/reverser control=REVERSE_THRUST / control-output control=REVERSE_THRUST prop=/engines/engine[0]/reverser-pos-norm / But YASim spits out a solution failure error. Changing /controls/engines/engine[X]/propellor-pitch to 0 or 1 does not seem to have an effect, and I haven't been able to find reverse thrust on any other YASim turboprop. I recall that Syd Adams added the possibility of reverse thrust for propeller engines a couple of years back. Looking at the YASim 2.0.0 source code and the Gitorious repository though, I don't see any references to reverse for propellers where I'd expect to see it. I wonder if this one didn't get approved/committed? Syd, if you're listening, any thoughts? -Gary -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Sat, Mar 5, 2011 at 3:58 PM, Chris O'Neill chrison...@yahoo.ca wrote: Wait a minute! If we're going to look the other way and breach someone else's trademark rights, then why would we get snotty with someone who breaches our copyright? It seems a bit hypocritical to me. I don't know, I haven't researched it, but shoveling a problem around is not solving it. I agree, but removing trademarks from the official FG distribution doesn't shovel the problem but, rather, removes the Project's risk and places it exactly where it should be placed... solely on the author of the livery. If Mack Jermod (or anyone else for that matter) wants a Red Bull (or any other trademark) on their livery, then so be it but let Mack Jermod (and the others) distribute it themselves and assume any and all risk, not the FG Project! ... Regards, Chris The man's name is Jack Mermod. While I may not declare for any position here, when taking a position it seems discourteous, unnecessary and counter-persuasive to make sport of someone's name. -Gary aka Buckaroo -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Two questions: Texture efficiency and METAR loading rules
Thorsten, A few thoughts: I would have guessed that loading these images would be an infrequent hit making file size a relatively small factor, but if the system is continually swapping them out and reloading them for some reason, that might not be so. Where cloud appearance approaches photograph quality, PNG probably won't buy you a lot in terms of file size, though it's worth experimenting. Their size when loaded will be the same regardless of file format (with one exception, which I'll get to in a moment), so I'd expect no gain there. 2048x2048 is getting pretty hefty at nearly 13 MB of memory consumed per image, which I could see being problematic if multiple different images are used to create a scene, especially given all the other textures typically in play at any given time. Would the environment settings give us the option to use textures of different sizes? Some users with high-end rigs might like the 2048 option, though I expect that would murder my system. ;) You might consider the dxt format. dxt needs some additional work to prepare, and has a few caveats to its use, but the dxt format is compressed when loaded into video RAM. The format is often used in gaming, and can do a lot to conserve video memory and possibly improve performance. You might find it worth exploring, especially for this dedicated operation. -Gary aka Buckaroo On Tue, Mar 1, 2011 at 3:00 AM, thorsten.i.r...@jyu.fi wrote: After some more grey hair, I believe I talked the Local Weather package into working with live METAR data such that it is competitive with the default system. In some areas it performs worse (especially getting denser coverage of convective clouds right is a bit of a problem, it doesn't do time interpolation if a METAR station updates), in others better (it has a vertical model of the visibility and aloft winds, lateral interpolation of weather parameters, gets closer to the real sky appearance in comparison with webcam images,...). So - I am working towards a new version v1.0 soon. In that context, I have two questions: 1) What is the best texture format for what I want to do? I've noticed that hires cloud textures take a long time to load and drain performance quite a bit. It seems Flightgear is loading a constant rate of texture pixels / time, which roughly says that I should not migrate to 2048x2048 cloud textures (although they look *really* impressive in tests) since the time to load a sky will increase by a factor four. In my current experience, loading new clouds is already a significant performance issue. What I have been wondering is the following: Currently I am using *.rgb textures. I have noticed that the filesize can be reduced by a factor 2 or so by going to *.png textures. However, what is the format which would most efficiently into the scenery? If *.png saves filespace at the expense of time, then there's no point in converting, but if png also loads a factor 2 faster, I would convert all texture sheets. I could of course run my own performance tests, but maybe someone simply knows? 2) What are the rules for loading live METAR? The context of this question is that I have the impression that if I would fly transatlantic (I have never tried, since I don't like the ocean view so much...) the METAR string would not change for a long time, and hence the weather would not change. That's not very realistic. On the other hand, I have a rather well-developed and plausible offline weather system, so I imagine that the controller switches from METAR to the offline system when the station is too far away and back when another station comes into range. Switching to the offline system while keeping all weather parameters plausible is not an issue - you just select an appropriate tile when the last METAR station has reached a distance d. But switching back to live weather is - because the offline system can't possibly guess correctly what the weather is on arrival when it switches over the Atlantic - so the matching has to be done carefully. To think this through, I'd like to understand how the weather fetching works - does it always pick the nearest station, even if that is 3000 miles away, or is there a distance cut, or some other criterion? Any help is appreciated! Thanks in advance, * Thorsten -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another fuel change...
On Mon, Feb 28, 2011 at 10:27 PM, syd adams adams@gmail.com wrote: Me again ... As Heiko mentioned , my S76C broke due to a fuel.nas change . If the change was mentioned here , I guess i missed it completely. After some experimentation, I finally got it running again ...it wouldn't start due to empty tanks , and trying to fill them with the dialog didn't work they would immediately snap back to 0.I removed my nasal fuel routine , and everything worked again ,except with no fuel consumption now... would I be correct in assuming that I only have to supply the amount of fuel consumed per frame and fuel.nas will manage the fuel flow ? Thanks agaian, Syd Syd, I don't have the latest and greatest fuel.nas so there may be changes that affect the following: in general for a conventional YASim aircraft with one or more engines, the FDM increments each engine's fuel-consumed-lbs every frame (or whatever update period it is using), and that value continues to increase until fuel.nas (or whatever) does something with it. Typically it iterates over each engine, copies the fuel-consumed value, decrements the amount across the tanks (the default is a cross-feed like system), and resets the fuel-consumed value to 0. Since a YASim helicopter doesn't use a standard defined YASim engine, if you provided code that continually increments an 'engine' fuel-consumed-lbs value (or some other fuel-consumed value you define) and pointed fuel.nas to that value, you should be able to get it to do the rest. It's a little different from directly managing fuel levels in tanks the way I think you used to do the s76c. In that case you directly decremented tanks, here, you'd kinda do the opposite-- increment a fuel-consumed value, feed that to fuel.nas, and let it do it's tank-management thing. Hope this makes some kind of sense and is useful. -Gary -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c172j
Syd, I had to fix fuel usage for the Goose to drop fuel usage to about 65% of YASim's guestimate. I generally replace the default nasal fuel system with my own version these days, and as part of that, at least in the Goose, I included a fuel-scalar that reduced the fuel-consumed amount. Unfortunately this is in my later Goose build-- the one on my site hasn't been updated in forever. If interested, I could send you my work-- you'll readily see what I did as it's pretty easy. Unfortunately a windstorm just blew part of my roof off, so I might be busy with other things for a while. -Gary On Mon, Feb 28, 2011 at 1:48 AM, syd adams adams@gmail.com wrote: Hi guys , I modelled a c172j , the aircraft i trained in , and got the fdm working pretty accurately (except for slipstream effect) , but noticed that the yasim piston engine burned about 11 gallons per hour , about 3 gallons an hour more than the real one does full rich. Would it be possible for someone to make that an option in the config file similar to tsfc ? Or is that changeable and I just never found it ? My own yasim patches never made it further than this mailing list (not surprising considering my coding skill), but it would be nice to tune this parameter. Thanks, Syd -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
I agree with Melchior. In the most situations they will be obliged to say no. It's the easiest, safest, most proven course for them. It seems rare that someone in our community is approached by a copyright-holder and told to remove some objectionable element. Even if it does happen, it's likely that someone will get a letter from a law firm saying Take-XYZ-down-or-else. You shrug, comply, and move on. There's a saying in English about bearding the lion in his den. It's probably better to stay beneath the lion's radar. -Gary -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On Sat, Feb 26, 2011 at 2:42 PM, Jon S. Berndt jonsber...@comcast.net wrote: Staying beneath the radar might be effective but do you feel good about it? Is it the ethical thing to do? Unethical? Hoping that ignorance is bliss? Trying to ignore a perceived problem and wishing it would go away because it is too hard to do things the right way? OTOH even if a company feels that a violation is taking place they would surely make a friendly request first. Jon I don't want to be misunderstood: I applaud Heiko's sentiment. But in this case, yes, I would feel good about it, and yes, I believe it's a reasonably ethical position for a loose collection of people who make non-commercial virtual aircraft and who are totally willing to comply with legal requests. -Gary -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal-based generic electrical system
A few months ago I created a nasal-based generic electrical system modeled after the built-in Flightgear system. I thought I'd offer it up here for those who might be interested: http://ltts.crlt.indiana.edu/grn/flightgear/electrical_1.html My goal was to achieve something similar to the hard-coded C-based system, but open it up for easy customization of handlers for suppliers, etc. Like the original, it is a voltage-propagator; it does not yet model amps or battery charging. There are a few differences. Where the Flightgear system defines suppliers, buses, components and connectors, I use only components and connectors. A supplier is treated as a component sub-type to simplify processing, and a bus is simply a component treated as a bus by contextual usage. My system may also offer a few advantages in switch modeling. XML configurations for the built-in Flightgear system can easily be modified for use in this method. Most will likely find this work a curiosity at best, but I hope someone finds it interesting or useful. I've been using it successfully in my latest project, and intend to retrofit it to my other projects. -Gary aka Buckaroo -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal-based generic electrical system
(Note: most of this was written before I saw Curt's response.) Heiko, Flightgear has a built-in generic electrical system written in C by Curt I believe. It's generic in that it can be set up using a simple XML file and requires no programming or scripting. All you have to know is how you want your compoments linked together. In other words, a tranceiver is fed power by an avionics bus, which is fed power by the main bus, which is fed power by a generator and/or battery system. The XML file lets you express that in terms of components and switches etc., and the underlying system does the magic. Systems like Syd's and others are usually tightly customized to an individual aircraft, and often get down to the level of amperage modeling, i.e., modeling the current drawn by various systems, the charging/discharging of batteries, etc. This requires a lot more knowledge and lots of nasal coding. My first efforts at doing electrical modeling used ideas like this, though perhaps not so well refined. The main problem I've found with these implementations is they're unfriendly when adapting to other aircraft. For me, the disadvantage of the generic Flightgear electrical system is that you get only the functionality that's built into it. Which is pretty good for the basics. But if you want to change something, like how an alternator's voltage is modeled, or under what conditions are external power sources available, you may have a problem. If you want to add modeling of battery charging or other amp-related factors, you're probably looking at doing custom nasal coding anyway. When I finally took the time to understand what Curt's system was doing, I thought the concept was great. It was easy and handled 90%+ of the things I'm interested in electrically modeling at this time. I didn't want to go much deeper, because in most cases I simply lack the data to know how much current various things draw. Voltage propagation is pretty straight-forward and doesn't require as much knowledge. Often it's sufficient to ask: is it getting power? Great! But there were a few interesting cases that the C-based system didn't model, mostly related to power sources and switches. I thought it might be fun to do something similar using nasal, which would then let me tweak various underlying systems for each model I work with. I tried to minimize the amount of work the electrical system is doing. I'm running the system on my current project with a full suite of flight instruments and radios, and a few other support systems such as light rigs, etc., everything on the electrical system. I've seen no performance issues. Of course this is a little Edgley Optica, not a Lockheed Constellation with gazillions of instruments. I wrote a nasal system for the pnematic system of my MD-81 last year, and the issues are so similar that I've been considering a parallel version of this to handle pneumatics as well, swapping in pressure values for voltages. Hey, why not? -Gary On Wed, Feb 23, 2011 at 4:39 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Hi, A few months ago I created a nasal-based generic electrical system modeled after the built-in Flightgear system. I thought I'd offer it up here for those who might be interested: http://ltts.crlt.indiana.edu/grn/flightgear/electrical_1.html I must admit, I'm a bit confused now about the electrical systems in FlightGear. I know the one used in the c172p, the ones created by Syd Adams which I use by myself in my projects (Ec130) and now this one. What are the advantages, where are the issues? I must admit creating the different systems in FlightGear (electrical, hydraulic, pneumatic, etc...) is quite difficult for those who aren't that into programming and scripting... Cheers Heiko -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] Default Aircraft Candidates
Syd places an enormous amount of effort and care into his models. If it were me, I'd think twice before questioning something he did, and I'd be darned sure I did my homework first, because it's certain he will have. But if he says he's interested in suggestions for improvements, he means it, and without ego. I have a friend who worked as a mechanical safety inspector at the Miami airport cargo facility back in the mid-90's, and he used to tell me of how unladen aircraft would sometimes depart at seemingly unbelievable steep angles. It was from his descriptions that I first started to understand the power of those engines that sit hidden in the throats of airliner intakes. -Gary aka Buckaroo On Mon, Feb 21, 2011 at 7:41 PM, Jack Mermod jackmer...@gmail.com wrote: I wasn't planning to get into an argument over the 777-200, but yes it does have an unrealistic FDM. See here: http://img219.imageshack.us/img219/891/picture5mj.png Are you telling me this is realistic too? Check Six, Jack -- Index, Search Analyze Logs and other IT data in Real-Time with Splunk Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. Free Software Download: http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear model animation question
On Wed, Feb 16, 2011 at 12:46 PM, Curtis Olson curtol...@gmail.com wrote: I was browsing the flightgear wiki pages on doing model animations. Everything is written from the perspective of a single model with named parts and the animations refer to the part names. What I have here is two version of the same model as separate 3ds files. I realize it's a crude hack, but I'm short on time. What I would like to do is create an animation that selects one entire model or the other depending on the state of a property. I assumed it would be easy to do so I left it to the last minute ... I've probably done it in the past, but now I can't find any documentation or examples ... is this possible to do? Thanks, Curt. Curt, One way to do this, set up the primary model XML file: ?xml version=1.0? PropertyList pathmymodel.ac/path model nameModel1/name pathAircraft/myplane/Models/model_1.xml/path /model model nameModel2/name pathAircraft/myplane/Models/model_2.xml/path /model animation typeselect/type object-nameModel1/object-name condition ... /condition /animation animation typeselect/type object-nameModel2/object-name condition ... /condition /animation /PropertyList So you import the primary model 'mymodel.ac (or whatever) in the path (this could be a null model), and specify two submodel imports and two selects that determine when the submodels appear. Then each submodel XML file will reference its model: ?xml version=1.0? PropertyList pathmodel_1.ac/path /PropertyList Hope this helps, -Gary aka Buckaroo -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear model animation question
On Wed, Feb 16, 2011 at 2:57 PM, Curtis Olson curtol...@gmail.com wrote: Thanks Gary, Worked perfectly ... turns out I don't need to specify a global model ... I can just load submodels and give them names and use them. A global offset/rotation does work. Now I'm having trouble with that whole ambient/diffuse thing and my model surfaces that aren't pointed at the light are all black ... this is a 3ds model ... is there an easy way to patch that up? I've figure out about 0.01% of blender ... and so far that hasn't included material properties or object hiearchies. Thanks! Curt. Curt, I'm not siginificantly familiar with the 3ds format-- it might be possible to directly edit the material settings and augment ambient values, etc. Someone else may be able to answer that. Is conversion to another format like .ac an option? If so and the models are not terribly complex, I would be happy to attempt the conversion for you. I deal with this sort of thing frequently at work, so it's probably not a big deal. If interested, feel free to send me the models and I'll give it a shot. -Gary -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear model animation question
On Wed, Feb 16, 2011 at 4:05 PM, Curtis Olson curtol...@gmail.com wrote: Hi Gary, I think I've beat the model pretty much into submission now. I was able to export as .ac, but the scaling was off by 2.54 ... hmmm where have I seen that number before? I figured out how to scale and reposition the model in blender wow! and there was much rejoicing. :-) Then all the faces were totally faceted so I figured out how to smooth the surfaces in blender wow!!! three exclamation marks on that!!! That got me to the point where I could manually edit the material definitions in the .ac file and setup the ambient and diffuse properly, also got the tires back to black ... and rescaled the textures 3000x3000 is probably over kill. So I'm learning more about blender than I want to know ... and I hesitate to even say this because in 2 years some guy in some far away land is going to be googling, decide I'm a blender expert and now I'll be doing blender tech support for the rest of my life ... got to love the internet! Curt. Cool-O on your conversion success! Oddly enough that's kinda how I got into my current position. I used to be a coder but played with 3D work on the side and advised grad students and professors at work from time to time, doing the odd model here and there. Eventually our director asked if I'd do that sort of thing full-time. So I am. :) -Gary -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender question?
Curt, To add to what Anders and Chris have said: Mirroring an object reverses the order of vertices in faces, which results in polygon normals pointing in the opposite direction-- outside becomes inside. If you're mirroring in Edit mode, you should only need to do the flip normals command. I.e., with the mirrored elements selected, hit the 'w' key and select 'Flip Normals'. After doing this, consider selecting everything and doing a w-Remove Doubles. This will take your two halves and create a single unified whole, eliminating overlaping edges and vertices, which helps avoid unwanted seams when rendered. Anders mentions the ctrl-a command. When mirroring an object in Object mode to create a second object for later merging with the first, it's a good idea to select the mirrored object and hit ctrl-a-Scale and Rotation to ObData. Blender keeps a stack of modifying operators on an object, but isn't perfectly consistent about considering stacked operators. This can yield unexpected results when mirroring and flipping normals. So I recommend using the ctrl-a command at the object level to apply and clear operations to the object, then go into Edit mode and do the flip-normals thing. It can save you some headaches, particularly if an object seems stubborn about being inside-out when exported. -Gary, aka Buckaroo On Thu, Feb 10, 2011 at 4:55 PM, Curtis Olson curtol...@gmail.com wrote: Hi Chris, I turned on normals and they are all pointing outwards on both halves of my model. It looks good in blender, but when I export it to 3ds and open it up in osgviewer, the mirrored half is still inside out. Curt. On Thu, Feb 10, 2011 at 3:45 PM, Chris Wilkinson wrote: Hey Curt, This is the process I use in Blender 2.49 - its slightly different but similar for Blender 2.5x Use face select mode, select the faces you need to flip, and in 'mesh tools' click 'flip normals', then re-save your model - that *should* do the trick. Another useful trick is to click 'show normals' - you'll then see a small blue line extending from the centre of each face in the positive direction - if the normals point inward then they need to be flipped. The normal size can be changed if they are too hard to see. Regards, Chris Wilkinson, YBBN/BNE. From: Curtis Olson curtol...@gmail.com To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Fri, 11 February, 2011 7:24:32 AM Subject: [Flightgear-devel] Blender question? I have a hopefully quick question. I've generated a 3d model mesh in ac3d format. I'm doing this from a perl script and I posted some pictures and details of the actual model here: http://www.flightgear.org/blogs/curt/uas/misc/3d-modelling-with-perl/ My script just generates the left half of the model. I assumed I could just import this into blender, duplicate the half and mirror it and produce the whole model. I'm new to blender, but I managed to duplicate the side and mirror it and the mesh looks perfect. My problem is that when I export the full model, the mirrored half is black from the outside. When I look inside of it, it's shaded properly. It appears that when I mirrored the surface, the face ordering didn't change so the mirrored half is inside out. I've been trying every possible face/normal/edge option I can find in blender and haven't been able to figure out how to get my faces back the right way. The original half of course looks just fine. It's probably something super simple, but I've googled and haven't found the right set of keywords I guess. Is there an easy way to get all my faces the right way so both sides of my model are right side out and look correct? Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance.
Re: [Flightgear-devel] mouse acceleration
Brilliant, a huge leap over click-click-click. Thank you Syd!
-Gary aka Buckaroo
On Fri, Jan 7, 2011 at 12:45 PM, syd adams adams@gmail.com wrote:
Hi guys.
Is there any interest in mouse acceleration properties, besides myself ?
I,ve added it locally , and have mouse drag pedestal controls in the
Aerostar .
The calculation is already done in the code, FGMouseInput.cxx , so
I've simply written each to a property:
At line 317:
if (x != m.x) {
int delta = x - m.x;
fgSetInt(/devices/status/mice/mouse/accel-x, delta);
for (unsigned int i = 0; i mode.x_bindings[modifiers].size(); i++)
mode.x_bindings[modifiers][i]-fire(double(delta), double(xsize));
}
if (y != m.y) {
int delta = y - m.y;
fgSetInt(/devices/status/mice/mouse/accel-y, -1 * delta);
for (unsigned int i = 0; i mode.y_bindings[modifiers].size(); i++)
mode.y_bindings[modifiers][i]-fire(double(delta), double(ysize));
}
I figured there was no point doing a patch for 2 lines of code , and
if no one else sees a use for it , it's easy to do with nasal...
Cheers
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Flight Pro Sim Statement
On Mon, Dec 13, 2010 at 9:35 PM, Curtis Olson curtol...@gmail.com wrote: On Mon, Dec 13, 2010 at 6:08 PM, Victhor wrote: The individual responsible for the page put this there: 1.Sponsoring a child - many kids in our world that aren't able to get even the basic stuff, like food, simple health care, and school. I never knew they were going _that_ far in dubious marketing tactics. Wow, that is truly sad ... they are making a mockery of people who take charity seriously and make a legitimate effort to help others. Well I sure hope that people take a look a the respective communities (pro sim flight versus FlightGear) ... how long they have been established, the spirit and nature and intelligence of the discussions and I sure hope that reality will be obvious. Look at the discussions on the pro-flight-sim areas which are all about people complaining about being ripped off and not getting their money back, versus the discussions in the FlightGear areas (tons of technical development material, fun aviation stuff, etc.) But in a world where people can say anything they want with no consequences, you suddenly aren't sure who you can trust. I believe this to be true and I lament it. But perhaps it places a great deal more importance and value on those who do stand by what they say and are willing to take on the consequences. -Gary There will always be some low hanging fruit to pick off, but if we make our best effort and act in a positive way, we can be proud whatever the result. Curt. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Ridding Multiplayer of Abusers
A few additional details can be found by reading the relevant post as jackmermod in the FG forums: I experienced a horrible attack over mp today. I ended up flying up on the attackers 6 o'clock in my F-14 and firing upon him with over 20 Aim-9's in hopes of causing him to lag. Luckily I caused him to crash.(which pissed him off enough to leave) :) the things he said accumulated to the most disgusting words I have ever seen put together in my life. While I am not affected, many others who may have to go through this would probably leave flightgear. http://www.flightgear.org/forums/viewtopic.php?f=10t=8432st=0sk=tsd=astart=270 Behavior was clearly not the best on either side. In my experience, technical solutions can't prevent this sort of thing. I work in the education field on a project involving online communities of grade school children. We employ language filters. The result has little effect on what the children can communicate. They can always find ways around the filter or re-phrase their meaning. The real behavior checks come from the community: the moderators, their peers, their teachers. -Gary -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] buying server bandwidth (was: mpserver02 close down)
On Thu, Oct 7, 2010 at 11:51 AM, Stuart Buchanan stuar...@gmail.com wrote: I'd be prepared to contribute some money for a dedicated MP/code/download server, even if it was in the US and I wouldn't benefit personally. I'm sure with a bit of publicity using the newsletter we could get together sufficient contributions. We could even offer immortality in the THANKS file for the project, if we were feeling particularly generous. Just to back Stuart up, I had similar thoughts about contributions and use of the newsletter. I would be pleased to donate funds regularly to help maintain suitable MP servers. I can't speak for others, but I'm willing to bet there are many like-minded members of the community out there. -Gary aka Buckaroo -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] buying server bandwidth (was: mpserver02 close down)
On Thu, Oct 7, 2010 at 6:28 PM, Stuart Buchanan stuar...@gmail.com wrote: We could certainly explore the donation route. I'm doing a little bit of research to try to determine what the realistic costs would be to setup a dedicated server to run a multiplayer system. That will give us a better idea what we need to shoot for. I agree that we need some real numbers before we can say what is realistic. I'm firmly of the opinion that whatever we do has to be completely voluntary. I don't really like the idea of a subscription based MP server. Neither do I like an advertising supported model. It feels like a pain to manage. The model I do like is one that seems to work for a jazz station I listen to: KCSM. They have fundraising drives every six months or so to cover their running costs. People give what they can but there is no obligation and no set amount. I like the idea of outsourcing the collection if we can find a suitable organisation but I suspect there are enough people with moderately deep pockets that it could be managed informally. The fewer actual donations, the less admin is required. I'd be willing to contribute £100 a year if someone else matched me. A couple more pledges like that and I'm sure we'd get there. I've known many people on this list long enough that I'd be happy to send them that amount of money on trust. -Stuart I need to spend some time following-up what Curt has suggested, and I would agree that no-money options are always welcome, but if decisions should result in a donation or fund-drive solution, then I'll pledge to match Stuart's £100 contribution. -Gary aka Buckaroo, Windows user. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Metapost for drawing instruments?
On Fri, Jun 11, 2010 at 2:00 PM, Patrice Poly p.pol...@gmail.com wrote: Hi, Does anyone have any examples of using metapost to draw instrument graphics (arcs, ticks, etc.) Or are there other free tools that have good primitives for drawing instrument/gauge graphics? I have a little side personal project here and I'd like to play around with it a bit. I personally use Inkscape with much satisfaction. Drawing arcs, marks and numbers is very easy with the vectorial capacities of Inkscape. At the end of the job, I export as a bitmap ( png is default in Inkscape ) , then I import the result in GIMP to add shadows or other fancy eye candy. Same process for me. Inkscape has worked out great for my instrumentation. -Gary aka Buckaroo -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim effectiveness tag
Andy, James, Syd, Much thanks for helping me understand this. -Gary On Wed, May 26, 2010 at 12:24 PM, Andy Ross a...@plausible.org wrote: On 05/26/2010 12:44 AM, James Turner wrote: This is a wild guess, but from memory (of discussions here), and reinforced by the code snippet above, effectiveness is a hack/tweak to account for surfaces/controls that work better/worse than YASim predicts. So effectiveness of 1.1 makes the flaps 10% more effective. I would assume it's a tweak so you can say, well, the model is basically okay, but it doesn't respond to xyz quite right. Heh, I actually noticed my name on the list in time to respond this time! Yes, this is exactly right. The effectiveness is just a scalar multiple on all force produced by the component which is otherwise (mostly) linear with surface area. It's a useful lever for tuning, but if you find you need to go beyond a factor of two (i.e. 0.5 - 2.0) I'd look elsewhere for the problem. Andy -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim effectiveness tag
I'd like to gain a better understanding of the effectiveness tag available for YASim flight surfaces. Example from the F-14: hstab x=-6.565 y=2.301 z=-1.153 length=2.839 chord=3.674 taper=0.3 sweep=45 dihedral=-2 camber=-0.01 effectiveness=2.0 It's particularly common in hstab definitions. Since it isn't mentioned in the distributed YASim documentation and I could not find definitive explanations in message archives, I wonder if someone could describe its purpose, practical uses, and pitfalls? Thanks in advance, -Gary, aka Buckaroo -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT or CVS - Confusion
On Wed, May 12, 2010 at 4:37 PM, Heiko Schulz aeitsch...@yahoo.de wrote: So the next question is: Will be the system of permission to upload things to the repo be the same like we had with CVS? My opinion on this is, that it was not always easy to maintain your work of you don't have permission to upload things. Just to back up Heiko, I'm interested in the answer to this question as well. -Gary, aka Buckaroo -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Reducing AI Model complexity
On Sat, Apr 3, 2010 at 3:30 AM, Gijs de Rooy gijsr...@hotmail.com wrote: Rob wrote: However, would the one stated above prevent models which use submodels for wing-flex effects from appearing to have wings? (Wait... are there any such models, or are the wings animated components of the main model?) A much bigger problem are those aircraft (like my 744) that are split into several models, for easy maintenance/development. Wings, fuselage, gear area all seperate models, with seperate animation files... Cheers, Gijs I'd like to second Gijs' concerns here. I build my models in sub-units partly to facilitate ease of maintenance and development, and partly for easy LoD range logic. My model units tend to be: airframe, external details (antennae, etc), external lighting rig, cockpit, instruments, cabin, propellers. IIf I understand the proposal right, I would be concerned about losing the propellers in an automatic AI implementation. I wonder if the proposed implementation might benefit from a new optional element within models that allows the developer to specify that the AI scheme must load the sub-model. For example: ... model nameCockpit/name pathAircraft/Goose/Models/Goose_Cockpit.xml/path /model model nameExternal Lights/name pathAircraft/Goose/Models/Goose_Lights.xml/path /model model namePropellers/name pathAircraft/Goose/Models/Goose_Props.xml/path force-ai-importtrue/force-ai-import /model ... This might solve Gijs' problem as well. Just a thought. -Gary aka Buckaroo -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug #99 (chase view broken)
James, you get my vote for hero of the day! Thank you! -Gary aka Buckaroo On Tue, Mar 30, 2010 at 6:30 PM, James Turner zakal...@mac.com wrote: http://code.google.com/p/flightgear-bugs/issues/detail?id=99 describes (rather briefly, but the linked forum posts give more flavour) some broken behaviour caused by refactoring in FGViewer during the 2.0 development timeframe. The viewer damping code (which is a horrible piece of logic) was subtly sensitive to the ordering of recalc / update calls, and as a result any view with damping would not work correctly in 2.0 - noticeably, in the chase view which some people apparently use a large portion of the time. I've committed a fix, such that the damping should work regardless of the order of update/recalculation of the view. Any and all testing of view behaviour after this commit would be greatly appreciated. Regards, James -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Web Site
I have to support Ron and others on this-- I much prefer usability and speed of access over visual gimmicks, especially Flash-based content navigation. -Gary aka Buckaroo On Tue, Mar 23, 2010 at 11:42 AM, Ron Jensen w...@jentronics.com wrote: On Tue, 2010-03-23 at 09:17 +0100, Erik Hofman wrote: Michael Sgier wrote: Yea not bad but still a little low-tech. What about such: http://www.activision.com/index.html#home|de_DE I hate websites that consists only of flash content. In fact I've added a flash blocker because of that. Erik Completely agree with Erik here. Flash is pretty lame as the main content wrapper. I much prefer pure html sites. Even using javascript to create menus sucks, IMHO. Thanks Jentron -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub
The Cub was the first plane I ever flew in, before I'd even been in a commercial jet. A friend's father owned a Cub (probably a J-3, not a Super Cub-- pretty sure we didn't have flaps though that was 30 years ago and I'm not totally certain now), and we'd scrounge up some fuel money and take it out from time to time. When the Cub was down for maintenance or whatever, we'd reach deeper in our pre-college savings and rent an Aeronca Champ. So for some time now I've considered modeling the Super Cub (as the J-3 has been done) or the Champ. For me, much depends on getting good plans with lots of detail and exact measurements, and a half-hour's searching shows sources are available without much effort. So-- Syd, if no one else steps up and you're busy, and no one is in a screaming hurry to have the model (I work pretty slow), I'd be interested in taking this on as a YASim project, otherwise I'll defer to you and consider the Champ again, no worries. -Gary aka Buckaroo http://ltts.crlt.indiana.edu/grn/flightgear On Wed, Mar 3, 2010 at 3:22 PM, syd adams adams@gmail.com wrote: Ive been considering it ... unless someone beats me to it. I did some quick browsing and Im guessing the desired aircraft is the PA-18 I flew in one almost 30 years ago , and its amazing how small a sand bar in the middle of a river you can land on :) Cheers P.S. I could probably get a decent yasim FDM built , but someone else would have to do a JSB fdm , I still dont know what Im doing when it comes to jsbsim . -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft modeling idea/request: Piper Super Cub
On Wed, Mar 3, 2010 at 7:47 PM, syd adams adams@gmail.com wrote: So-- Syd, if no one else steps up and you're busy, and no one is in a screaming hurry to have the model (I work pretty slow), I'd be interested in taking this on as a YASim project, otherwise I'll defer to you and consider the Champ again, no worries. -Gary aka Buckaroo Well I'm definately stepping aside now :) ,... and considering the quality and detail of your previous work , I cant wait to see the final results . Cheers Thank you Syd! I am interested in doing a classic Super Cub using one of the more common engine variants to establish a baseline model, but a follow-on version based on a CubCrafters design, perhaps the Carbon Cub, would make a very interesting comparison within Flightgear. Curt, I think it's early, but if you wanted to pursue that contact with CubCrafters, I would be willing and excited to work with you on such a project. -Gary http://ltts.crlt.indiana.edu/grn/flightgear -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
I don't know about dynamic positioning of instruments, but I would find it interesting to have an easy method of selecting alternate instruments for the same position. For example, I have several attitude indicator variations that could be used based on period or pilot/owner preference. This would have application in aircraft like the Grumman Goose, which spans many decades of instrument development. It would be interesting to have a menu of instrument choices that I could then be saved with other user preferencess. Other than including the different instruments in the same xml/model package, which is clearly not the goal, I don't know how to do this, especially without burdening the system by loading instrument resources that are not used. Currently to do this I write up a little how-to for pulling in a different instrument in the relevant xml, but many folks don't read those details and perhaps miss the configuration possibilities. It would be great to offer an easier more dynamic scheme. -Gary On Sat, Feb 27, 2010 at 3:58 PM, syd adams adams@gmail.com wrote: I can see 3d instruments being easier position them on the panel with a mouse click then drag them like i did the b1900d manual ... or menu buttons in a dialog like the ufo does scenery objects for finer adjustments ... I suppose the 2d instrument placement would be almost the same... Dont know if I like the idea of moving instruments around in flight , but then I guess the new arrangement would need to be written to a file to be permenant . Cheers -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed new set of splash screens
I believe it makes the most sense for the featured aircraft to be both commonly recognizable and present in the Flightgear repository. It might confuse some people if they go looking for the featured aircraft and didn't find it in the official downloads page. The Concorde and the 747 make fine exemplars and look great in those images. I'm wondering what is the significance of the curious white or yellow parallelogram seen near the Flightgear lettering in some of the most recent batch of suggested images? This may be what Syd was asking about as well. -Gary On Tue, Feb 23, 2010 at 7:57 PM, Peter Brown smoothwater...@adelphia.net wrote: It's the Fouga Magister, from GRTux's site. It is not included in the base package, but like Dave Culp's and Gary Neely's aircraft, IMHO ...some of the best models designed for FlightGear and used by many in FlightGear... are not included in the base package. While some may disagree with me on this, I believe that promotion of any sort should be the best it can be. I think these images are great - http://www.sablonier.ch/flightgear/splash/typosplash05.jpg http://www.sablonier.ch/flightgear/splash/typosplash06.jpg http://www.sablonier.ch/flightgear/splash/typosplash07.jpg And no offense to the creator, but I don't think these provide any advertising excitement at all - http://home.telfort.nl/sp004798/emh/Splash5.png http://home.telfort.nl/sp004798/emh/Splash4.png Peter On Feb 23, 2010, at 6:46 PM, Martin Spott wrote: Peter Brown wrote: Just to make available some more images if anyone wants to create splashes from them, I found a few of these to have nice lighting effects with the setting sun. http://s512.photobucket.com/albums/t325/barefootr/FlightGear%20Screen%20Shots/ Is this really one of FlightGear's aircraft ? I'm unable to identify such variant. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Can i use Maya 2009 building Aircraft for Flightgear 1.9.1 and v 2.0?
On Sun, Jan 31, 2010 at 1:46 PM, Peter Meyer pmvs...@yahoo.de wrote: I mean the technical Part. because iam socialiced with Maya and i can do some fine modelling with it. AC3D is an ugly Tool and no good alternate. Myays of cause has an *.obj Exporter but it is old and complex Objects are cripplet durning Exportation (iam no Friend of Exporting 3D Objects at all, there is everytime a loss of something). It would be great if there was 3DS Max File Support, Maya File Format Support or Lightware File Format Support. Blender isnt bad but all 3D Objects are shaped with the Blender touch wich i will try to avoid! Greetings Peter I'm with Heiko. I use XSI, Blender and others for my work and for my Flightgear projects. Like a carpenter with many different saws, every 3D application is just a tool in my toolbox, each with different qualities and features. -Gary, Buckaroo on MP -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Can i use Maya 2009 building Aircraft for Flightgear 1.9.1 and v 2.0?
On Sun, Jan 31, 2010 at 2:57 PM, Peter Meyer pmvs...@yahoo.de wrote: Of cause but as i said im socialised with Maya and i know its Toolset. I dont like 3D Max, Lightwave is ok, XSI is also ok, but can XSI directly Export the 3D Modells to FG? I dont like the Idee converting arround, there is everything a bit of loss wich i will try to Avoid. AC3D is not Solution for me, is primitive and not comparable to Maya or XSI. Peter I agree, converting between formats can be problematic. XSI has very powerful and versatile scripting tools, Maya has MEL for scripting, and the .ac format is text-based and relatively simple. With a little research and effort you can create your own exporter script and exactly control your exported mesh. I've been tempted to do this for XSI, but Blender already has a Python script included with the base package that does a very good job of exporting to the .ac format, and this works for me as I'm comfortable with both applications. There may be scripts out there to do this for XSI or Maya now, I haven't checked in a while. The answer to your question likely depends on what you are willing to do. -Gary, Buckaroo on MP - Ursprüngliche Mail Von: Gary Neely grne...@gmail.com An: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Gesendet: Sonntag, den 31. Januar 2010, 20:41:25 Uhr Betreff: Re: [Flightgear-devel] Can i use Maya 2009 building Aircraft for Flightgear 1.9.1 and v 2.0? On Sun, Jan 31, 2010 at 1:46 PM, Peter Meyer pmvs...@yahoo.de wrote: I mean the technical Part. because iam socialiced with Maya and i can do some fine modelling with it. AC3D is an ugly Tool and no good alternate. Myays of cause has an *.obj Exporter but it is old and complex Objects are cripplet durning Exportation (iam no Friend of Exporting 3D Objects at all, there is everytime a loss of something). It would be great if there was 3DS Max File Support, Maya File Format Support or Lightware File Format Support. Blender isnt bad but all 3D Objects are shaped with the Blender touch wich i will try to avoid! Greetings Peter I'm with Heiko. I use XSI, Blender and others for my work and for my Flightgear projects. Like a carpenter with many different saws, every 3D application is just a tool in my toolbox, each with different qualities and features. -Gary, Buckaroo on MP -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim and dedicated fuel tanks
When employing YASim, is it possible to have a given engine draw from a specific tank? I've noticed that by default the engines draw evenly from tanks marked as 'selected', rather like a cross-feed situation. I'd like to simulate situations where engines draw from dedicated tanks when cross-feeding is disabled (like the Grumman Goose and Lockheed 1049 series). The YASim documentation doesn't appear to elaborate on this. Can anyone elaborate on a YASim method to accomplish this, or point me to an exemplar aircraft? Thanks! -Gary -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim and dedicated fuel tanks
After studying Melchior and Vivian's aircraft I was able to put together a crude but functional version of what I was hoping to do. Essentially it's just a simple re-write of fuel.nas that maps engine[n] to tank[n] for purposes of drawing fuel. This allows me to set up dedicated tanks and/or small buffer tanks that can then be fed by additional code like the Bo105, Buccaneer, and Lockheed 1049H. Thanks everyone! I really appreciate the help. -Gary -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Solid MP Models
Collision detection is a desirable feature and and a separate issue from player muting. I suggest collision be its own option defaulting to off so as not to affect new participants just getting their start as KSFO. -Gary On Sun, Sep 6, 2009 at 7:00 PM, Gene Bucklege...@deltasoft.com wrote: Finally camping at the Runway starting point will most likely upset any ATC. This way people might begin to take care not to stand in the way. You'll need something to combat that with people that do it on purpose. I would suggest extending Anders mute player function to not only ignore text from them, but not display or collide against their aircraft model. g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double sided in Blender
Innis, Now you have me puzzled and I love a puzzle. Yes, an object that is marked as double-sided should render both sides, because in effect the double-sided toggle is telling the render engine to consider each polygon as two polygons with the normals inverted. If you like, feel free to take this off-list and contact me directly, perhaps sending me your Blender scene file with the two objects as they are just before they are joined. I'm certain we can figure this out. I'd like to export the results and have a look at the .ac file being generated. -Gary On Fri, Jun 12, 2009 at 1:20 AM, Innis Cunninghaminn...@hotmail.com wrote: Thanks Gary I don't think that is it I have checked the normals and flip them to no avail. Correct me if I am wrong but if the object is double sided then you should not be able to see through it from one side.As I said before when the faces concerned are separate objects they show double sided in FG it is only when they are joined together that they become one sided. Cheers Innis Innis, It sounds like some polygon normals are inverted. This is pretty common after joins. After doing a join on objects in Blender, select your object, go to Edit mode, and on the button bar find the Mesh Tools More menu. From there, select Draw Normals. The normal is a line perpendicular to the surface and extending outward from the center of the polygon in the polygon's facing direction. Generally you want all normals pointing out, indicating the facing sides are on the outside of the object. I suspect you'll find some normals are not pointed the right way. To fix this, you can select the problem polygons and then: Mesh Tools--Normals--Flip (also available from the specials key: w), or you can also try to recalculate all the normals to face outside, (ctrl-n in Windows). Usually ctrl-n does a pretty good job of resetting normals of simple objects in the right direction. Feel free to contact me off-list if I can be of more help. -Gary, aka Buckaroo on MP On Thu, Jun 11, 2009 at 11:23 PM, Innis Cunninghaminn...@hotmail.com wrote: Hello All I am trying to build a hangar with Blender 2.48 not a hard task you might say but for some reason when I join two objects to one some of the sides become single sided that is they become transparent from one side in FG.If I leave them as separate objects they show double sided in FG.Does anyone know what I am doing wrong?. Cheers Innis Find your next place with Ninemsn property Looking for a place to rent, share or buy this winter? -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Make ninemsn your homepage! Get the latest news, goss and sport -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Smoothing issues on some models
On Thu, Jun 11, 2009 at 10:39 AM, Jim Wilsonj...@kelcoindustries.com wrote: For those who are modeling and are not bothering with setting the crease value now (and letting it default to 30) I would strongly recommend removing all the lines from the ac files that contain the word crease before committing them to CVS. I think you will really enjoy the improved appearance of your work. Best, Jim I've used the crease setting to get a very passable rounded appearances on surfaces like landing gear struts using surprisingly low polygon counts. A tube with a cross section having only 8 vertices can give very pleasing results after you play with the crease setting a bit, to values like Vivian suggests. The application can have considerable effect on polygon counts. I learned this trick from examination of the A-10 model done by Lee Elliott I believe. -Gary, aka Buckaroo on MP -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double sided in Blender
Innis, It sounds like some polygon normals are inverted. This is pretty common after joins. After doing a join on objects in Blender, select your object, go to Edit mode, and on the button bar find the Mesh Tools More menu. From there, select Draw Normals. The normal is a line perpendicular to the surface and extending outward from the center of the polygon in the polygon's facing direction. Generally you want all normals pointing out, indicating the facing sides are on the outside of the object. I suspect you'll find some normals are not pointed the right way. To fix this, you can select the problem polygons and then: Mesh Tools--Normals--Flip (also available from the specials key: w), or you can also try to recalculate all the normals to face outside, (ctrl-n in Windows). Usually ctrl-n does a pretty good job of resetting normals of simple objects in the right direction. Feel free to contact me off-list if I can be of more help. -Gary, aka Buckaroo on MP On Thu, Jun 11, 2009 at 11:23 PM, Innis Cunninghaminn...@hotmail.com wrote: Hello All I am trying to build a hangar with Blender 2.48 not a hard task you might say but for some reason when I join two objects to one some of the sides become single sided that is they become transparent from one side in FG.If I leave them as separate objects they show double sided in FG.Does anyone know what I am doing wrong?. Cheers Innis Find your next place with Ninemsn property Looking for a place to rent, share or buy this winter? -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Dave, Thank you for saying what has been on my mind for some time after reading the previous posts about the kids. I too spend a great deal of time around KSFO and the kids, and I've taken the time to help and encourage many with their How do I fly a helicopter? questions. Yes, it makes me cringe a bit, and the chat box is a poor medium for lengthy explanations. Yes, most of the time it's a waste of time. But not always. Sometimes it pays off, and sometimes that person settles down or goes off and reads the how-tos and comes back days later with a real working knowledge of how to fly a helicopter. I like to think that a few of those kids have added to community, or at least added to themselves. There are many ways to enjoy FG. Not all of them involve serious flying. I find it disturbing to see 787's doing loops and rolls, but if there is no active ATC, who is to say they should not? I often fly the Su-37 in seemingly aimless loops. Why? Because I want attention from flying some absurdly fast and extreme aircraft? I fly it because my first few dozen attempts at flying it beat me and I determined to learn it. I fly it because it's fun to find its envelope-- just how low and slow can it go? I fly it because, briefly, in a virtual world, I feel something that a bird must feel. I cannot fly for real due to monetary and medical reasons. But I can fly virtually, and I can fly for free. I'm on the network to mess-around and socialize. By doing so I've met wonderful and creative people who I now consider my friends. Some pursue realism in their flights. Some fly for other reasons. They all come because they like something about aircraft or flying or flight sims, and all have been willing to help others learn. We sometimes encounter disruptive individuals, but they are few and usually do not stay long, and the experience on the whole remains vastly positive. Like Woddy, I've found FG to be a great gift that has occupied much of my time over the last year. I've learned a lot. Maybe one day I will submit a model. But that shouldn't matter. A community needs members and not all can participate on the same level and not all have the same skill or learning as others. But they may one day, and I hope the development community will encourage rather than screen. Cheers, -Gary Buckaroo Neely On Mon, Nov 17, 2008 at 9:57 PM, dave [EMAIL PROTECTED] wrote: Dear Rob, From your description it appears that I am one of those kids. A 43 year old kid mind you. I am always polite to others on the MP system. I sometimes perform stunts in unusual aircraft and show off just for a laugh. I demonstrate what can be achieved with practise. I push the flight envelope on occasion. What I do as well though, is encourage the use of FG and Linux through my usage. I help those kids who say how do I fly a helicopter? learn to fly a helicopter. I remind the kids that this a shared realm and that people aren't required to follow orders. Most of the people on there are good folk and treat each other respectfully. I would rather have the less-than-serious kids use FlightGear than alternatives and rather kids than a bunch of stiffs who just don't approve because of their personal mind set. I think that if you need to have serious, trying to fly as realistically as possible events, then go ahead and organise more of them and publish a code of conduct for those attending. Who knows? you could have it as often as weekly. Weekend flightschool/control tower practise anyone? I'll turn up and make you proud! On the subject of IVAO, I think that even entertaining the idea of closing access to the FG-MP server for IVAO is the tail wagging the dog. The connection to IVAO should be the exceptional case, not the general one. Getting to know FlightGear was/is not an easy experience and at least some benefit of the doubt should be afforded to those who obviously aren't at your level of familiarity/usage or have a different attitude to FG in general. I suppose what I am trying to say is that your idea of what FG is, may or may not be at all like what I see it as. People need to remember what the open part of open source implies and what free spirit is about as well. While I am here, I thank you all for FG. Because of FG, not only do I have have a great simulator (free too) I have learned to use blender and am a long way into a new model to hand over one day should it past muster. I am even considering dusting off the old coding me and diving into the guts. Such a great gift, is FG, that I feel the need to contribute and learn more to be able to do so as well as the need to encourage and help others use it. cheers, Dave McLoughlin. (Woddy) Rob Shearman, Jr. wrote: I wrote: It seems that a large number (often, the majority) of FG-MP users are on the network to mess around and socialize rather than participate in a multi-aircraft scenario with any degree of realism. Arnt wrote: ..my impression from what
