Re: [Flightgear-devel] Aerial photos
Hello Richard, Sorry for the long delay, but I've been bussy creating new runway textures, and that took more time than I had hoped. I had the good fortune to be given a flight in a hot air balloon for Christmas last year. I finally got around to arranging the flight last month (The outbreak of Foot and Mouth disease had grounded all ballooning in the north eats of England until May this year, and then the weather was non-cooperative) and took some straight down pictures of the ground with the intention of making some textures. I have discovered that I am not, and will never be, a texture artist :-(, however I hereby offer the images to the project for any use that is beneficial to the project. I'm sorry to day that the photos aren't of much help for using them in the textures itself (they aren't actually 90 degrees downwards) but these type of photos prove to be a great help in designing textures (to get actual colour and layout). See http://sucs.org/~mocelet/fgfs/ for thumbnails and links to the big pictures. Thanks for the pictures. Having experienced flights in commercial, GA, glider and now balloon I can say that ballooning is a completely different experience to all other types of flying. For one thing there is no airflow past the aircraft for the majority of the flight. I've always wanted to take a ride in a hot air balloon myself, but haven't done it yet. Good to hear it's a great experience. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] concerning FlightGear on Solaris/Sparc
Martin Spott wrote: Once upon a time I promised to try building FlightGear on Solaris/Sparc. Unfortunately this has been without success because 'plib' refuses to compile partially. This is valid for the plib-1.6.0 as well as for the current CVS tree. Did you report the problems to the PLIB list? I didn't even have the time to read the list archive :-/ As they want portable code (that's the P of the PLIB) they are allways interested in incompatabilities. I'll go for it as time permits, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KJFK at night
Jim Wilson wrote: That's a little too small to resolve differences at 16bpp. Try the patch below. It decreases the lifting substantially. You will see a slight increase in z-buffer flickering but it isn't bad. Has anyone tried offsetting the lights in the direction of the viewer? While this might look weird for off-axis lights (they would appear to move a little bit as you turned or changed the view), it would (might?) require far less offset to get the same effect. Shouldn't be too difficult to try, anyway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Cool, someone's playing with the 747. This model hasn't had a lot of tweaking yet beyond the engine thrust bugs that Jim Wilson dealt with a few months back. Manual Bessler wrote: Here are a few things I wanted to ask about the 747-yasim: Does it model the thrust reversers ? What about Speedbrakes/Spoilers ? No, no, yes. The spoilers control is mapped to the /controls/spoilers property, which doesn't have a default input binding. I have it wired to one of the thumbwheels on my Saitek throttle. Thrust reversers and speedbrakes wouldn't be hard to support, I've just been lazy. The Boeing obviously doesn't have a speedbrake, but the A-4 and Harrier should. There are still some (much harder) issues with drag scaling that I'd like to get fixed first. None of the planes need a brake right now, since they all sit way behind the power curve during approach and dump speed really fast. Bouncing: * Landing is relatively hard, esp. since it bounces much. Part of this is due to a blindingly stupid bug with ground effect that I discovered this weekend. It should interpolate the effect from zero at one span height to one at ground level, but it did the opposite. You got full effect instantly at about 200 ft, and the aircraft sorta bounced in midair, spoiling the approach. I don't have this checked into CVS yet, but it'll be there today or thereabouts. Another factor is the lack of automatic wing spoiler deployment, which helps a lot to keep the airplane from getting airborne again after a hard landing. This would require just a tiny amount of C++ code right now: watch the /gear[n]/wow properties and set the /controls/spoilers to 1.0 when they transition from false to true. This would be a great application for interactive scripting from the aircraft definition; a feature that has been long talked about but not yet moved on. And finally, I agree. The default gear damping is a little too light. YASim computes a default damping coefficient automatically, based on the weight of the plane and the placement of the gear. But it's not going to work perfectly for all aircraft. There needs to be a per-gear tunable for spring and damping coefficients, but there isn't yet. This is like the reversers/speedbrakes issue -- something unimplemented only due to my laziness. * Prior to takeoff, if I keep pressing 'b' and let the engines spool up to full throttle (or less), the front gear starts bouncing quit a bit after I release the brake. Well, pumping the brakes during the takeoff is hardly standard procedure; I'm not sure what the real aircraft would do. :) The joystick trigger is mapped to the wheel brakes, by the way. You can use this to get constant braking instead of pounding on your keyboard. The wheel bounce issue is real, though. In my copy, I got better results by changing the compression distance of the nose wheel strut from 2m to 1m in the Aircraft-yasim/747.xml file. This has the effect of making the nose gear much stiffer, reducing the pitch change from gear oscillations. Try this, and see if it feels better. I have no idea what the compressibility of the real thing is -- I made the 2m number up too. (BTW: the parking brake doesn't seem to work w/ the 747) Uh, true. This is trivial to fix, just add a mapping from the parking brake property in the 747.xml file. Everywhere you see: control-input axis=/controls/brakes[n] control=BRAKE/ add a: control-input axis=/controls/parking-brake control=BRAKE/ I don't know why this wasn't done to begin with. Maybe it's because I'm not sure how the parking brake functionality is handled on a 747; I'm sure it's more complicated than this, but this is a start. Another thing: It does not seem possible to start fgfs with the 747's engines off. This is true. The YASim jet model doesn't handle starting and stopping behavior. Unlike piston engines, starting procedures and behavior for turbines are very complicated, and vary widely from engine to engine. The idea behind YASim is to provide good and sane behavior for all aircraft, or at least as many as practical. I suppose I could wire up an eye candy starter, which spooled the engine up and down from zero while diddling the temperature and fuel flow variables in a vaguely plausible way. But features like realistic engine start aren't possible for this code; they'll need to wait for someone with the patience and dedication to model one specific engine (and electrical system, and APU, and...). :) Why are the four engines mapped to two thrust[n] properties instead of four ? Would it work if I map them to 4 throttles ? There are only default input bindings for two throttles. While I was happy leaving spoilers out of the default configuration, a 747 with its two starboard engines fixed at idle is kind of a showstopper. :) It will work just fine to map them to as many properties as you like. You can map any joystick/keyboard input to any property, and any property to any single YASim
Re: [Flightgear-devel] 747-yasim Questions
Andy Ross writes: And finally, I agree. The default gear damping is a little too light. YASim computes a default damping coefficient automatically, based on the weight of the plane and the placement of the gear. But it's not going to work perfectly for all aircraft. There needs to be a per-gear tunable for spring and damping coefficients, but there isn't yet. This is like the reversers/speedbrakes issue -- something unimplemented only due to my laziness. Speaking of gear modeling in the 747-yasim, have you tried getting the aircraft up to say 40kts. taxiing and then hit the brakes ... there is clearly something going on with the 747 gear modeling that is not physically possible ... best seen when viewed from the chase view. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Curtis L. Olson wrote: Speaking of gear modeling in the 747-yasim, have you tried getting the aircraft up to say 40kts. taxiing and then hit the brakes ... there is clearly something going on with the 747 gear modeling that is not physically possible ... best seen when viewed from the chase view. Without having tried it, I assume you mean that the nose dives straight through the ground when the aircraft pitches down during hard braking? That's actually not a gear issue. What you're seeing is a difference in coordinate origin between the YASim description and the AC3D model file. The YASim origin is at the nose of the plane, while the model places it closer to a nominal c.g. at the back of the hump. So the nose of the plane drawn on the screen is actually ~25m in front of the real nose as modeled by YASim, and therefore moves more due to orientation changes. You can see a similar effect with the A-4 model. This is tedious to fix, so no one has bothered. There's also the question of whether it should be fixed in the YASim file or the model file. I contend that the nose is a much better origin, since a c.g. value is meaningless unless you have the mass distribution handy. YASim recomputes the c.g. dynamically anyway based on fuel load and cargo and whatnot. The FDM configurer and the model author might not be expected to have the same c.g. numbers (in fact, they probably never will -- most 3D artists aren't aero geeks), but hopefully they can always agree on the position of important parts of the airframe. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Curtis L. Olson wrote: Speaking of gear modeling in the 747-yasim, have you tried getting the aircraft up to say 40kts. taxiing and then hit the brakes ... there is clearly something going on with the 747 gear modeling that is not physically possible ... best seen when viewed from the chase view. Without having tried it, I assume you mean that the nose dives straight through the ground when the aircraft pitches down during hard braking? That's actually not a gear issue. What you're seeing is a difference in coordinate origin between the YASim description and the AC3D model file. The YASim origin is at the nose of the plane, while the model places it closer to a nominal c.g. at the back of the hump. So the nose of the plane drawn on the screen is actually ~25m in front of the real nose as modeled by YASim, and therefore moves more due to orientation changes. You can see a similar effect with the A-4 model. This is tedious to fix (for me, anyway -- I don't have a registered AC3D copy that can save), so no one has bothered. There's also the question of whether it should be fixed in the YASim file or the model file. I contend that the nose is a much better origin, since a c.g. value is meaningless unless you have the mass distribution handy. YASim recomputes the c.g. dynamically anyway based on fuel load and cargo and whatnot. The FDM configurer and the model author might not be expected to have the same c.g. numbers (in fact, they probably never will -- most 3D artists aren't aero geeks), but hopefully they can always agree on the position of important parts of the airframe. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] What source code doc generator ?
What source code generator is being used/recommened for Flight Gear ? I currently use CPP2Doc for my own code but Flight Gear seems to use another one, which one ? If possible if URL :) thank you = My Flight Gear Multiplayer Stuff (work-in-progress): http://www.kbs.twi.tudelft.nl/People/Students/L.Otte/ OK, I admit it: My girlfriend's just an object to me. Unfortunately, there is some information hiding, but thankfully, she's fairly encapsulated, nicely modular, and has a very well defined interface! __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerial photos
Erik Hofman writes: I've always wanted to take a ride in a hot air balloon myself, but haven't done it yet. Good to hear it's a great experience. A while ago,we had a hard-coded balloon model. I don't think it works any more, but now that we have wind and weather, it would be nice to whip one together in YASim or JSBSim if they can support it. I could do a bit of work on a 3D model. We have a lot of balloon traffic around Ottawa; amazingly, they let them drift right through the Class C (= U.S. class B, I think) control zone around and over CYOW. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Andy Ross writes: This is tedious to fix (for me, anyway -- I don't have a registered AC3D copy that can save), so no one has bothered. There's also the question of whether it should be fixed in the YASim file or the model file. I contend that the nose is a much better origin, since a c.g. value is meaningless unless you have the mass distribution handy. Along the longitudinal axis, I think that we should use whatever the published weight-and-balance reference is for each aircraft, since that's what any published figures and distances will use. For single-engine Cessna's, it's the firewall; for some Piper Cub data I found, it's the leading edge of the wing at the fuselage; and so on. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerial photos
On Mon, 4 Nov 2002 14:03:19 -0500 David Megginson [EMAIL PROTECTED] wrote: A while ago,we had a hard-coded balloon model. I don't think it works any more, but now that we have wind and weather, it would be nice to whip one together in YASim or JSBSim if they can support it. I could do a bit of work on a 3D model. I've thought about this a *little*. It would involve adding bouyancy forces, and perhaps suction/inertia kinds of effects. Haven't really gone past that. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerial photos
David Megginson wrote: Erik Hofman writes: I've always wanted to take a ride in a hot air balloon myself, but haven't done it yet. Good to hear it's a great experience. A while ago,we had a hard-coded balloon model. I don't think it works any more, but now that we have wind and weather, it would be nice to whip one together in YASim or JSBSim if they can support it. I could do a bit of work on a 3D model. MY balloon model is still there and should still work - with the same limitation it had from the beginning: it can only move up and down. Moving sidewards (e.g. due to wind) is possible and the direction and amount is calculated, but I don't know the correct API calls to convert the linear movement to a change in lat/lon. It also has the problem that it's hardwired to the WeatherCM code. But it should be easy to replace the calls to WeatherCM with property lookups. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KJFK at night
David Megginson writes: Here is a screenshot of KJFK from 3900ft with a 16-bit buffer: Now, with that out of the way, when you look closely, you'll notice that the lights are clearly floating 40 or 50ft above the runways. I wonder if there's any formulation we can come up with that could avoid this. For example, let's say that at a certain distance we need the lights to be 50 ft away from the ground to avoid z-buffer problems. If I'm looking at the airport from 2 miles away at 1,000ft AGL, then my view has slope of about 1:10, so the lights need to be lifted only about 5ft from the ground to get 50ft between them and the ground directly behind (from my current viewing angle). Does this make sense to the math types? My guess is that the real solution requires taking a different approach http://www.opengl.org/developers/code/sig99/advanced99/notes/node20.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Clickable 3D panel
Lovely stuff. For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). So there are two places you can click to get the autopilot wing leveler button, or any other button. One where you can see the button, and another where the same button would appear on the other type of panel. A minor misalignment of some of the hotspots makes one or two controls a little awkward (e.g. COM1 tuning button). That is nothing to do with the 3D code; they are misaligned in the 2D view as well. That is, if you click just to the left of the centre of that knob it should decrease the digits but it increases them instead. A way to display the hot-spot outlines would be useful for checking and debugging ... don't know if that's as easy as it sounds though. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Julian Foad wrote: For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). Are you sure? I thought this might be it too, and tried tracking it down. The 3D panels are loaded through the model code, and never get a chance to register themselves as the current_panel object in globals. Is there an invisible 2D panel loaded from somewhere else? FWIW, I still haven't been able to duplicate the rogue mouse click problem. If you're right, though, good catch. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross writes: FWIW, I still haven't been able to duplicate the rogue mouse click problem. Try this: fgfs --aircraft=c172p-3d Don't change the view direction or FOV. Click on the ident switch or the hi/low/off knob on the ADF and watch what happens. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross wrote: Julian Foad wrote: For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). Are you sure? I thought this might be it too, and tried tracking it down. The 3D panels are loaded through the model code, and never get a chance to register themselves as the current_panel object in globals. Is there an invisible 2D panel loaded from somewhere else? FWIW, I still haven't been able to duplicate the rogue mouse click problem. Well, I'll put it this way: If I turn the 2D panel on and off with P while flying --aircraft=c172-3d, and note where a particular button is, and then turn it off so that only the 3D panel is visible, I can still click where the 2D button was as well as where the 3D button is visible. Clicking in either place has the same result of activating the feature. As I said, if the position of one of these invisible 2D hot-spots obscures a 3D hot-spot, then the 3D one appears not to be working, until you change view direction a bit or zoom so it is in a different area of the screen. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Julian Foad wrote: Well, I'll put it this way: If I turn the 2D panel on and off with P while flying --aircraft=c172-3d, and note where a particular button is, and then turn it off so that only the 3D panel is visible, I can still click where the 2D button was as well as where the 3D button is visible. Heh, hard to argue with that. Indeed, there was no check for panel visibility in the input code. I guess we've never noticed because nothing was fighting for the same real estate in the past. This one-liner appears to fix the problem. And, since you were right, good catch. :) Andy RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Input/input.cxx,v retrieving revision 1.4 diff -u -r1.4 input.cxx --- src/Input/input.cxx 29 Oct 2002 19:44:03 - 1.4 +++ src/Input/input.cxx 5 Nov 2002 01:38:23 - @@ -379,6 +379,7 @@ if (puMouse(b, updown, x, y)) return; else if ((current_panel != 0) + current_panel-getVisibility() current_panel-doMouseAction(b, updown, x, y)) return; else if (fgHandle3DPanelMouseEvent(b, updown, x, y)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross writes: Heh, hard to argue with that. Indeed, there was no check for panel visibility in the input code. I guess we've never noticed because nothing was fighting for the same real estate in the past. This one-liner appears to fix the problem. Committed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Andy Ross [EMAIL PROTECTED] said: Curtis L. Olson wrote: Speaking of gear modeling in the 747-yasim, have you tried getting the aircraft up to say 40kts. taxiing and then hit the brakes ... there is clearly something going on with the 747 gear modeling that is not physically possible ... best seen when viewed from the chase view. Without having tried it, I assume you mean that the nose dives straight through the ground when the aircraft pitches down during hard braking? That's actually not a gear issue. What you're seeing is a difference in coordinate origin between the YASim description and the AC3D model file. The YASim origin is at the nose of the plane, while the model places it closer to a nominal c.g. at the back of the hump. So the nose of the plane drawn on the screen is actually ~25m in front of the real nose as modeled by YASim, and therefore moves more due to orientation changes. You can see a similar effect with the A-4 model. This is tedious to fix, so no one has bothered. It isn't tedious at all, we can offset the origin to where we want without messing with the ac file *and* it won't affect the animation. The reason I put it where it is now is because placing it in the cockpit put the main gear in the water. The A-4 could be changed easily, just hadn't thought of it ;-) Having the FDM origin at the center of gravity should improve the appearance of the 3D modeling since pitching of the model would appear more realistic. That said, I still think there is something not quite right. If you move the 3D model it just flips the tail up higher. It could be that the brakes are too good. If you locked the wheels up at 40kts the 747 _maybe_ would stop that quickly...not sure. It is quite a mass, as you know. Flipping the tail up in the air might be exactly what it would do in that case, but the tire tread would need to have a hell of a grip. Anyone have a real 747 they can try this on? :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
How hard would it be to have a property that toggles hotspot visibility? It'd be nice to be able to turn it on and have yellow rectangles show up on the hotspots...or something like that. Thinking about making hotspots to control some of the 3D instrumentation. Best, Jim Andy Ross [EMAIL PROTECTED] said: Julian Foad wrote: Well, I'll put it this way: If I turn the 2D panel on and off with P while flying --aircraft=c172-3d, and note where a particular button is, and then turn it off so that only the 3D panel is visible, I can still click where the 2D button was as well as where the 3D button is visible. Heh, hard to argue with that. Indeed, there was no check for panel visibility in the input code. I guess we've never noticed because nothing was fighting for the same real estate in the past. This one-liner appears to fix the problem. And, since you were right, good catch. :) Andy RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Input/input.cxx,v retrieving revision 1.4 diff -u -r1.4 input.cxx --- src/Input/input.cxx 29 Oct 2002 19:44:03 - 1.4 +++ src/Input/input.cxx 5 Nov 2002 01:38:23 - @@ -379,6 +379,7 @@ if (puMouse(b, updown, x, y)) return; else if ((current_panel != 0) + current_panel-getVisibility() current_panel-doMouseAction(b, updown, x, y)) return; else if (fgHandle3DPanelMouseEvent(b, updown, x, y)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson wrote: It isn't tedious at all, we can offset the origin to where we want without messing with the ac file *and* it won't affect the animation. Cool. Uh, how? :) Having the FDM origin at the center of gravity should improve the appearance of the 3D modeling since pitching of the model would appear more realistic. It wouldn't matter. The FDMs do the dynamics for you. You could put the origin of the model on Mars* and the model would rotate correctly on the screen so long as the origins agreed. The aircraft rotates about its real c.g., which has nothing to do with either the 3D model coordinate conventions or the YASim coordinate origin. * Well, not on Mars due to precision issues. Maybe Sri Lanka. It could be that the brakes are too good. If you locked the wheels up at 40kts the 747 _maybe_ would stop that quickly...not sure. It is quite a mass, as you know. I think the tires get a 0.6 dynamic friction coefficient. The way the physics works, the mass doesn't matter. Anything (aircraft, trucks, bicycles, roller blades) sitting in 1G of gravity on a flat surface decelerates by the same amount. The reason the real aircraft can't stop via wheel braking alone is because the brakes would melt. The tires could stop it just fine if you could put all the kinetic energy somewhere. The reason the pitch changes so much when braking is because the nose gear travels too far. Try the gear compression fix I mentioned earlier. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Jim Wilson wrote: How hard would it be to have a property that toggles hotspot visibility? It'd be nice to be able to turn it on and have yellow rectangles show up on the hotspots...or something like that. Thinking about making hotspots to control some of the 3D instrumentation. That's not a bad idea. It shouldn't be that hard, actually. Just draw a final layer around the hotspots with some OpenGL lines. The existing layer offset code would insure it gets drawn on top of the rest of the panel, and the matrix environment is already set up so you can draw 2D panel coordinates directly. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerial photos
Tony Peden writes: On Mon, 2002-11-04 at 11:15, Jon S Berndt wrote: On Mon, 4 Nov 2002 14:03:19 -0500 David Megginson [EMAIL PROTECTED] wrote: A while ago,we had a hard-coded balloon model. I don't think it works any more, but now that we have wind and weather, it would be nice to whip one together in YASim or JSBSim if they can support it. I could do a bit of work on a 3D model. I've thought about this a *little*. It would involve adding bouyancy forces, and perhaps suction/inertia kinds of effects. Haven't really gone past that. I think we could do a decent job of it with just a drag coefficient and a propulsion model that took care of the burner and buoyancy. I believe everything is in place for a decent balloon model it just needs someone to hook in the horizontal forces wind details for doing this @ http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-January/002677.html Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
