Re: [Flightgear-devel] JSBSim - how to model piston en gine exhaust thrust?
On Tuesday 31 August 2010 21:08:32 Jon S. Berndt wrote: > Ron, Hal, > > Just a reminder that this feature (arbitrary functions in engine > definitions) - I believe - works and is now in JSBSim CVS. Maybe it should > be moved to FlightGear? > > Jon I tend to keep my FlightGear up-to-date with the latest JSBSim. I keep a git clone of this at http://gitorious.org/fg/jentrons-flightgear. I don't have write access to the master repository. I haven't done anything (yet) with Hal's exhaust thrust function. I was waiting for someone else to work out the math... The exhaust thrust function should return a force. Newton tells us: F=ma or Newtons=kg*m/s^2 (SI) lbf=slugs * ft/s^2 (US pound as force) poundals = lb * ft/s^2 (US pound as mass) For the rest of this discusion I'm going to use the US pound as a force system. Hal had said something like F=m*v^2 but that yields slugs*ft^2/s^2. Not the correct units. F=m_dot * v_e [1] where m_dot is total mass flow per second and v_e is the velocity of the exhaust stream. lbf = (slugs/2)*(f/s) = slugs* ft/s^2 m_dot = m_dot_air + m_dot_fuel for our model. FGPiston currently calculates m_dot_air internally, but does not expose it as a property. m_dot_fuel is a property, and we could potentially use it, along with the mixture setting, to estimate m_dot_air. The problem with this approach is m_dot_fuel can be zero while m_dot_air still has a non-zero value. m_dot_air could also be estimated as a function of RPM, engine displacement, and manifold air density. Something like: m_dot_air = (1/2)(RPM/60)(rho_manifold)(displacement)(volumetric_efficiency) [2] gives us a formula for v_e: v_e = sqrt( (T*R/M) (2k/(k-1)) [1 - (P_e/P)^((k-1)/K)]) See the wikipedia article for a full explanation of the formula. k~= 1.4 for exhaust temperatures up to 1000 degrees C. so the second term becomes: (2k/(k-1)) ~= 7.0 The third term [1 - (P_e/P)^((k-1)/K)] Can be thought of as an efficiency factor, It should always be greater than or equal to zero and less than or equal to 1. Its value probably increases with pressure altitude as I believe that will lower P_e (pressure at the exit end of the exhaust manifold); P (pressure from the cylinders when the exhaust valves open) is probably related to manifold pressure and RPM. It may be appropriate to think of this as a constant, too. A first guess would be ~0,4. The first term: (T*R/M) contains two constants, R and M, so this value is completely controlled by T, our exhaust gas temperature, Exhaust gas temperature is available as a property in FlightGear but not JSBSim stand-alone. In short, I propose the following formula for v_e: v_e = sqrt( egt * k) where k = R/M * 7 * 0.4 Thanks, Ron --- [1] http://en.wikipedia.org/wiki/Rocket_engine_nozzle#Specific_Impulse [2] http://en.wikipedia.org/wiki/Rocket_engine_nozzle#1-D_Analysis_of_gas_flow_in_rocket_engine_nozzles -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Request to Compile Beta Scenery
Hi All, I have failed yet again to get TerraGear running on two computers. I recently tried a technique for the first time to determine land cover from satellite images. I am glad to say I succeeded, but there are still a number of problems with the scenery, from null values to cloud cover. This is 45Mb worth of shapefiles, beta land cover for northern Switzerland (Zurich, Bern, Neuchatel, Luzern, Interlaken), eastern France (Mulhouse) and southwestern Germany (Konstanz, Friedrichshafen). I would like to have compiled before I submit it to the land cover database so the community has a chance to fly over the area and note any special problems. My hope is this landcover will ultimately be a high-interest area for FlightGear users. Please reply here or email me off the list if you are able to download and compile this area - I think it is 3x2 degrees. Thanks John -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Airport Textures
Hi All, Recently, I have been working on Switzerland scenery for FlightGear. Hopefully beta landcover will be released soon. At the moment, I've been making use of as many materials as I can find to accurately model the control tower at LSZB - Bern/Belp, and through some pictures I've noticed the arrows in the displaced threshold are different than the FlightGear textures. I would very much like to represent this if I can as it adds a level of localized realism. I also thought of another previous mailing list discussion about aiming point textures in Great Britain, and of yellow runway markings in northern Japan. This leads me to my question: Is there an easy way to replace the default textures on an airport-by-airport basis? Currently there is one texture set for every airport. I am thinking of possibly indexed airport folders, such as Airport_1. If the airport is somehow classified as taking the textures from Airport_1, then load the textures (with the same file names) from that airport folder, and then fall back to the main texture folder if the texture is not found. For instance, Heathrow uses different aiming point marks than most airports. If you had a folder: Runway/EGLL_Textures with only the file pc_aim.png, and then you somehow had a file telling the program to look for textures in /Runway/EGLL_Textures BEFORE it looks in /Runway JUST for Heathrow, you could load the different pc_aim.png just for Heathrow. My gut thinks this is impossible, but my gut is also very hungry. Thanks John -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Newsletter - August 2010
> Jon wrote: > Nice! How does one begin writing for the next issue? Is there a particular > format to follow? Order of stories? Nice to see you're interested Jon! I've written a little guide a while ago, which is available at the forum: http://www.flightgear.org/forums/viewtopic.php?f=28&t=7794 It is not a big deal to contribute. You just need a wiki-account (free to register); you don't even need an idea on what to write about, as checking other people's texts for typos or adding screenshots is also welcome! I can imagine that you would like to write something about JSBSim-updates? That is exactly the kind of thing I would like to see more often in the news letter! A list of updated aircraft is nice of course, but it does not make this into a newsletter... Feel free to ask if things are unclear. However, to free-quote the IRC-topic: "Don't ask to add, just add!" :) Looking forward to your contribution! Gijs -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shaders heads up
Am 28.08.10 12:34, schrieb HB-GRAL:
> Am 28.08.10 01:16, schrieb Tim Moore:
>> There needs to be some coordinate for the fog. You could try using
>> gl_FogFragCoord instead.
>>
>> Tim
>
> Thanks for your answer Tim. And what should happen when I change
> gl_BackColor.a from 0.0 to 1.0 in default.vert? I see here that this
> makes the terrain shaders (or the light) running at least for some older
> ATI cards (and .z/.w is def. not the problem).
>
> What do I loose with this change? What do I have to check? And could
> this work for terrain also for other cards with gl_BackColor.a = 1.0?
>
> Thanks, Yves
Ok, I can keep all the new code now with my older ATI. For my card I
only had to add 'if (gl_BackColor == 0.0) { n = -n; }' again in
default.frag and that seems finally to work with recent changes. Maybe
this makes not a lot of sense, but I do not care anymore ;-)
-Yves
--
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
