Re: [Flightgear-devel] FG vs. FSX demo
Hi geneb, all, De : geneb ge...@deltasoft.com Envoyé le : Jeudi 28 février 2013 15h41 It's a best foot forward kind of thing. The quintessential default airplane in MSFS has been the 172. The default set of airplanes in FG should be the absolute best of the best, simply because that's what a new user is going to be exposed to for their first time. First impressions are everything. Someone will see the FG 172 and instantly assume that the rest of the simulator is like that. 100% agreed. Probably we should update it (especially the cockpit), because I think the rest of it is pretty neat. Or think about a replacement, like the DR-400 or the cap-10b. I think the cap10b could be added in the default aircraft set. Oliver -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
Am 28.02.2013 16:38, schrieb Curtis Olson: We've always been able to set the individual weather parameters, either through the built in weather dialog box, or by setting raw property values. Setting raw property values allows nasal script control over the weather (as I'm sure you well know) :-) but it also allows external control of the weather, for instance by some external gui tool, or by some tool that wants to setup equivalent visual conditions across multiple FlightGear PC's running in sync. And please don't forget, there are command line options like --visibility, --wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic-weather and I'd love to keep all that functionality. Best, Torsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adds on FlightGear.org
Curt, are you there? Repeating the links in case you missed them: http://www.flightsim.com/vbfs/content.php?13546-FlightGear-v2-10-Is-Released#comments http://www.flightsim.com/vbfs/showthread.php?260718-FlightGear-2-10-is-now-available-!p=1747315#post1747315 Thanks! Gijs -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
Torsten wrote Am 28.02.2013 16:38, schrieb Curtis Olson: We've always been able to set the individual weather parameters, either through the built in weather dialog box, or by setting raw property values. Setting raw property values allows nasal script control over the weather (as I'm sure you well know) :-) but it also allows external control of the weather, for instance by some external gui tool, or by some tool that wants to setup equivalent visual conditions across multiple FlightGear PC's running in sync. And please don't forget, there are command line options like --visibility, -- wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic- weather and I'd love to keep all that functionality. At a very personal level, I like being able to adjust the vis other factors using the keyboard with my left hand while using a joystick with my right. I certainly can't imagine flying the Camel and trying to manipulate a mouse and menu. Vivian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] How to get my bug fix into the git?
Hi everyone, I am new to the FlightGear project, I just found and fixed my first bug, I am wondering how to get my fix into the main git next branch? Thanks! Sincerely Godspeed -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
So whatever we do, we can't override the ability to get low level granular control of the weather parameters, and not just so that advanced weather can manipulate them exclusively, also so that external tools can manipulate them without advanced weather getting in the way or overriding the settings. (...) And please don't forget, there are command line options like --visibility, --wind, --random-wind etc. All those options override the other weather-magic. It took me quite some time to make all this behave in a somewhat reasonable way with basic-weather and I'd love to keep all that functionality. I don't think any of this is a real issue or under debate at the moment (?) - the whole discussion about z/Z is if the keybinding should be removed, but the internal control structure of the system shouldn't change. The current structure seems sane to me: * shaders which render the visibility take values from the property tree and are agnostic to how these got there * so does the terrain manager * the weather system has an 'idle' mode in which no properties are set by the system automatically, and it is possible to define weather with the property browser * Basic Weather can run and fill the properties based on interpolation tables * Advanced Weather can run using the idle mode and set the parameters from Nasal - once you stop the Nasal loops, you're back in idle mode and can set properties by hand * any external/future system can likewise use the idle mode to set parameters - any shader will render these parameters regardless of how they were put into the tree. - what you can't do is run two different systems at the same time The only problem arising is that Atmospheric Light Scattering uses three visibility-defining parameters to render rather than one, so if you define only one of them on the commandline, the rendering task is ill-defined and the framework falls back to the defaults as specified in environment.xml - which may or may not be appropriate for the weather situation you have in mind. The system is sane in the sense that it will always use the lower of visibility and ground visibility, so if you set visibility to a very low value, you'll not get to see the higher default ground-visibility on the ground. You can in any case specify the info by setting /environment-ground-visibility-m and /environment/ground-haze-thickness from the commandline and you will see the system responding appropriately, and Basic Weather or any external application could likewise set these parameters to other than default if so desired. There's a also host of secondary calculation of light attenuation and color rotation underneath clouds which are pretty complicated, and there's no chance to just set them to the right defaults - so unless you have a system which does the equivalent of these computations as done by Advanced Weather and sets the properties for the shader, you will get implausible lighting under some conditions. But that's an aestetic issue - FG remains usable with the defaults, it just doesn't give you the full eye candy. The whole part of the discussion about the max. visbility slider and realistic visibility checkbox in Advanced Weather is a completely different beast because it refers to Nasal-internal parameters which are not seen when any other system runs and not relevant for the shaders or the FG core. I think we need to keep parameters which are exchanged between subsystems in the discussion separate from parameters which stay inside a subsystem - there are many different wind parameters set by property rules for the water shader, others written for internal reference by Advanced Weather, yet others used to store the config of Basic Weather - but none of them has any relevance for the FDM for instance. So if there's any genuine concern that we might block options for any other development, I'd like to know what it is, because keeping options open is something which is high on my agenda as well. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
Say, while you all are on the subject of key bindings, could anyone tell me where these keymappings are defined in flightgear? My friend is having a severe (to him) issue with the program, in that he loves flying in the sim but is running I believe three monitors. He is able to get the view across all three of his monitors by setting a very wide field of view, but this involves clicking for a _very_ long time on the widen field of view key. I'd love to be able to customize his build for him so it either defaults to where he wants it or else changes in much larger increments. Also, I just got myself a new joystick with fancy buttons all over it, and would like to remap some functions to them. Any advice appreciated! Thanks, Chris On Thu, Feb 28, 2013 at 1:31 AM, Renk Thorsten thorsten.i.r...@jyu.fiwrote: You asked for ideas for a more descriptive text - I've gone one better and added descriptive texts to the gui. My design aim was to provide the average user with some indication of which option he should choose and in which circumstance. It's only a shallow redesign. It would be nice, I think, to allow max vis range to be as low as 10kms, and also if this could be driven by z/Z. However, these items are beyond the scope of what I set out to do. Thanks. I can do the first item easily (I do think 10 km max visibility are a bit on the low side, but it doesn't hurt anyone..). As for z/Z - can we reach a decision first what to do with this? James and Stuart seemed to be considering to drop this key binding, and I would actually prefer that as well. Is there a compelling reason to manage visibility by key? For me, this resembles more an arcade game strategy than a realistic simulation. (If we keep z/Z, it'd be nice if anyone can give me a pointer how to link it with the max. visibility or just do it, because I don't know how it's done...) * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
On Fri, 1 Mar 2013 02:14:59 -0700, Zhitao wrote in message 004601ce165d$409a80c0$c1cf8240$@gmail.com: Hi everyone, I am new to the FlightGear project, I just found and fixed my first bug, I am wondering how to get my fix into the main git next branch? ..you put it here?: https://code.google.com/p/flightgear-bugs/ ..attach your patch to your message, or to your bug report. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Low visibility issues
On Thu, Feb 28, 2013 at 4:47 PM, Chris Calef wrote: Say, while you all are on the subject of key bindings, could anyone tell me where these keymappings are defined in flightgear? My friend is having a severe (to him) issue with the program, in that he loves flying in the sim but is running I believe three monitors. He is able to get the view across all three of his monitors by setting a very wide field of view, but this involves clicking for a _very_ long time on the widen field of view key. You may also wish to visit this page on our wiki which talks about how to create a custom xml configuration file for multiple cameras on multiple displays: http://wiki.flightgear.org/Howto:Configure_camera_view_windows The system even allows you to define an independent camera for each display so you don't have to deal with increasing distortion at the fringes and can spread the view offset by a little extra to account for the margins on your monitor (so a straight line such as a runway edge flows straight into the next display without forming a stair step. You can search out README.multiscreen -- located in $(FGDATA)/Docs/README.multiscreen if you have FlightGear installed. There are a couple approaches that are supported, ranging from creating a 3 windows, one for each display to creating a single window that spans all the displays and defining separate camera parameters for each 1/3 of the window. If you spend a bit of time tweaking this, you can get way better results than simply stretching a window across three displays and. Regards, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Advanced Weather updates
I've pushed some updates to Advanced Weather and the cloud shader of Atmospheric Light Scattering. Clouds now fade to transparent at distances between the visibility and 3 times the visibility. This gives a much better impression when in heavy groud fog (CAT I to CAT III) and shouldn't be a problem above the cloud layer for semi-realistic visibilities (if you have 20 km, you get clouds drawn out to 60 km or so). CAT IIIb using Atmospheric Light Scattering and Advanced Weather should now give better results (I won't start thinking how to support Basic Weather properly before this actually works) - although it takes a while for the system to ramp down the visibility to very low values (the interpolation routine has a time delay) - you may have to wait for 20 seconds till the visibility is actually all the way down. However, the change does mean that if you leave the visibility at cruise altitudes of airliners at 10 km, you will not get to see many clouds regardless of how the cloud visibility range is set (because they now respect the real visibility setting in addition), so this is potentially an issue for Basic Weather users. If this is a show-stopper, then we may need to undo the changes, but fading to alpha is by far the fastest way to deal with heavily fogged clouds. Please test and give feedback! Runway lighting and the sun are still not okay and seen through fog - any pointers as to where to modify the lights are highly appreciated. I've also tinkered a bit with the thunderstorm scenario and reduced the density of clouds surrounding the Cb towers as well as the number of sprites being used - I now get quite acceptable framerates of ~20-30 fps in the scenario - maybe it also helps for others. One problemhere is that rain textures are still orphaned (i.e. don't move in the wind with the clouds) - I'm running out of ideas here - my Nasal moving code creates frame spacing issues, Vivian's C++ moving code patch wasn't accepted, so I'd appreciate a helping hand from C++ coders before the next release. * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG vs. FSX demo
Hi Vivian, That's really good to hear - but if we are falling behind in some respect then we will make an effort to improve. I am reminded that the flag and wake shaders are inoperative when Atmospheric Light Scattering is activated. With the departure of Emilian, I see no prospect of this being fixed unless someone else steps up to the plate. Well, we couldn't possibly leave the flag just hanging around, could we? :-) http://www.gitorious.org/fg/fgdata/commit/be7ee7e06cf4237d60cf8ae5849cf098308b7cd8 (The flag shader is a simple variant of the default model shader, so just 5 minutes of Copy/Paste the flag-specific code into the default model fragment shader did the trick - that must have been my new record for shader conversion. Also, in ubershader-lightfield.frag we now have all the code blocks of the atmosphere effects nicely separated and lined up in a fragment-only environment, so when you need to write a shader which isn't performance critical, then I recommend just copy-paste of the four blocks, supplying them with properties, and you should be almost there...) As a suggestion to improve the Vinson, I would ask for some dirt/rust/stains on the Flightdeck - the homogeneous grey appearance is the thing that sticks out most to my eye. I recently saw a short video of FSX with moving cars and trucks populating the roads. We can do that up to a point, and trains as well, and I forgot to mention that we can also texture tracks and roads properly: We can only have a few - around 50 if we are to keep framerate within bounds. If we ever get the Kent scenery fixed up well enough for release I'll include this around Manston/EGMH. You seem to have managed the trick to align the uvmapping of the street texture with the direction of driving. If so, I think we could have an almost arbitrary number of (low resolution) cars for cheap by shader magic: * use an overlay texture which is transparent except where the cars are supposed to be * use the heightmap technique of the urban shader to give them some substance * overlay them on the lane and move one coordinate along the driving direction over time (* add light effect in dark and so on) Since this could all be in the fragment shader, and only a vanishing amount of screen pixels would usually be occupied by linear features such as roads at any given time, you could generate tens of thousands of cars that way without hitting the performance badly. Of course they'd suffer from the same artefacts as the urban effect from close-up, but the sheer number may completely make up for that. Cheers, * Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adds on FlightGear.org
Anders Gidenstam wrote : If it is not possible to be more restrictive on what ads to show (and even if that can be done I'm sure the guys paying for these sort of ads would do their best to by-pass any such restriction) then IMO the ads should go. Maybe the text ads could stay but the big blobs - no, thank you. I'm agreed with your opinion, ads should go in this case. Is the hosting really that expensive that we can't raise enough donations to cover it? (I have to admit I have not donated to FG, though.) I'm pretty sure that if some of us makes a donation, we could be able to cover hosting costs. Let us know how many, and we could try to organize a donations campaign. If it's necessary. Cheers, Clément -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How to get my bug fix into the git?
Hi Godspeed, Am 2013-03-01 10:14, schrieb Zhitao Li: I am new to the FlightGear project, I just found and fixed my first bug, Great ;) I'm not sure if your fix [2] is really a fix or just hiding symptoms. I currently have no VS available for testing but eg. at [1] it seems like its a linking problem instead. I am wondering how to get my fix into the main git next branch? You can always open a merge request into the next branch at gitorious. Tom [1] http://stackoverflow.com/questions/8740500/heap-corruption-with-strdup?rq=1 [2] https://gitorious.org/~plutonium/fg/plutoniums-simgear/commit/0455e8f3253a2bc26e4a34265e1227984408713a -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
