Re: [Flightgear-devel] Properties under /orientations seem to have taken on offsets after extreme attitude
Ampere K. Hardraade wrote: I was taking the c182 out for some tests last day, and I brought the c182 into some extreme attitudes. Afterward, I notice that the attitude indicator seems to have "jammed"; tilted when the aircraft is in level flight. Upon further testing, I noticed the roll rate of the indicator still corresponds to the roll rate of the aircraft. The similar problem also occurs on the c172. After some investigation, I traced the problem to properties under /orientations. The issue can be reproduced by sending the aircraft into barrel rolls and other extreme maneuvers. This is actually a real feature. Your extreme manuevers have discombobulated your attitude indicator and it takes several minutes for the gyro to realign itself with gravity. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Properties under /orientations seem to have taken on offsets after extreme attitude
I was taking the c182 out for some tests last day, and I brought the c182 into some extreme attitudes. Afterward, I notice that the attitude indicator seems to have "jammed"; tilted when the aircraft is in level flight. Upon further testing, I noticed the roll rate of the indicator still corresponds to the roll rate of the aircraft. The similar problem also occurs on the c172. After some investigation, I traced the problem to properties under /orientations. The issue can be reproduced by sending the aircraft into barrel rolls and other extreme maneuvers. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] Speaking of always turning...
On Monday 10 Jan 2005 23:42, Andy Ross wrote: > [bouncing replies to flightgear-devel] > > David Megginson wrote: > > I don't know if we're modelling this or not, but with full power you > > often need a lot of rudder to keep a plane straight during the > > takeoff roll even when there is no crosswind. During the landing > > roll, with no power, it is a lot easier. > > YASim is definitely not doing this right. This is because in a real > plane the wheel casters a little, which has the effect of twisting the > nosewheel away from the wind. On planes with a direct linkage between > the nosewheel and the rudder, this is essentially the same as applying > a control force. YASim doesn't model this kind of "castering torque" > on the nosewheel. > > I know Curt was complaining to me once about an aircraft that would > yaw violently in crosswinds once the nose came up -- I think this was > the reason. When the nosewheel is on the ground, it isn't trying to > "steer into the wind" like a real plane would be; so on rotation the > pilot hasn't applied the right amount of correcting rudder. > > Modelling this would involve some complicated per-airplane > configuration, I think. I guess we could start by defining a > "castering distance" (distance from the wheel contact point to the > rotation axis) and interpolate the force as linear across the full > rudder travel to get a effecting "rudder trim" setting. Other planes > (I know the 152, probably other Cessnas) have a spring connecting the > nosewheel to the rudder cables, so they will see a similar but smaller > effect. > > Then again, some planes have fully castering nosewheels with no rudder > linkage and steer with braking. These get modelled correctly as-is. > > Andy Getting the whole ground-handling sorted out would be nice. Other things like aircraft weather-cocking while stationary in light winds and odd ground handling etc. Just my 2p worth. (IANAP) ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Speaking of always turning...
[bouncing replies to flightgear-devel] David Megginson wrote: > I don't know if we're modelling this or not, but with full power you > often need a lot of rudder to keep a plane straight during the > takeoff roll even when there is no crosswind. During the landing > roll, with no power, it is a lot easier. YASim is definitely not doing this right. This is because in a real plane the wheel casters a little, which has the effect of twisting the nosewheel away from the wind. On planes with a direct linkage between the nosewheel and the rudder, this is essentially the same as applying a control force. YASim doesn't model this kind of "castering torque" on the nosewheel. I know Curt was complaining to me once about an aircraft that would yaw violently in crosswinds once the nose came up -- I think this was the reason. When the nosewheel is on the ground, it isn't trying to "steer into the wind" like a real plane would be; so on rotation the pilot hasn't applied the right amount of correcting rudder. Modelling this would involve some complicated per-airplane configuration, I think. I guess we could start by defining a "castering distance" (distance from the wheel contact point to the rotation axis) and interpolate the force as linear across the full rudder travel to get a effecting "rudder trim" setting. Other planes (I know the 152, probably other Cessnas) have a spring connecting the nosewheel to the rudder cables, so they will see a similar but smaller effect. Then again, some planes have fully castering nosewheels with no rudder linkage and steer with braking. These get modelled correctly as-is. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange FG crash.
On Mon, 10 Jan 2005 21:25:55 -, Vivian Meazza <[EMAIL PROTECTED]> wrote: > > > Unknown exception in the main loop. Aborting... > > > Possible cause: Success > > WAG - OpenAl? I think it would have to be wrapped in a SimGear exception for that to happen, but I'd have to double-check the code. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Windsocks
David Megginson writes: > OK, thanks for the replies to all who responded. It's clarified things quite a bit. FWIW, I'm not trying to alter the automatic windsock generation, simply tidying up stuff like windsock placement for the airport layouts that I did whilst testing TaxiDraw, before sending them in to Robin. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] John: Church Fenton hangars need fixing?
On Friday 07 January 2005 00:05, Jon Stockill wrote: > Roy Vegard Ovesen wrote: > > Also, if it is supposed to be able to taxi inside the hangar then the > > roof should be double sided and the back of the doors should be properly > > textured. If not then the walls don't need to be double sided and there > > is no need for a floor. > > I had considered doing a version with an open door/doors. How about animating the doors? Hmmm.. I guess that opening one hangar would also open all the hangars in the universe ;-) -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Real weather fetch
* Curtis L. Olson -- Thursday 30 December 2004 17:54: > I believe the weather reports are time stamped so we could ignore > reports that are older than "x" hours. I don't think we are currently > doing that. No, we aren't. I have a patch that does it, currently dismissing reports older than 300 minutes. I'll submit it after the 0.9.8pre feature freeze. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange FG crash.
On Monday 10 January 2005 21:29, David Megginson wrote: > On Mon, 10 Jan 2005 14:20:45 -0600, Curtis L. Olson > > <[EMAIL PROTECTED]> wrote: > > I was just flying in the SFO area with the DHC2-F and flightgear crashed > > with the following message: > > > > Unknown exception in the main loop. Aborting... > > Possible cause: Success > > > > Anyone have any ideas? This is the first time I've seen anything like > > that. > > I did a find/grep through all of the FlightGear, SimGear, and plib > source code as well as the base package, and I couldn't find anything > that looked like a reasonable candidate for an exception returning the > message "Success". > > Hmm, the exceptions that I know of that are still not handled very well are related to unsuccesful loading of AIModels. But usually that's not followed by any message. Just checking: Did you use any AIModels or traffic manager subsystems? Second guess: Could it be related to loading static models?? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Strange FG crash.
David Megginson wrote: > On Mon, 10 Jan 2005 14:20:45 -0600, Curtis L. Olson > <[EMAIL PROTECTED]> wrote: > > > I was just flying in the SFO area with the DHC2-F and flightgear crashed > > with the following message: > > > > Unknown exception in the main loop. Aborting... > > Possible cause: Success > > > > Anyone have any ideas? This is the first time I've seen anything like > that. > > I did a find/grep through all of the FlightGear, SimGear, and plib > source code as well as the base package, and I couldn't find anything > that looked like a reasonable candidate for an exception returning the > message "Success". > WAG - OpenAl? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
David Megginson wrote: On Mon, 10 Jan 2005 13:59:28 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: One issue to consider is that going to nil visibility (and not drawing the cloud plane) hides when you pass through the "cloud plane". When the cloud plane intersects the near clip plane you get some ugly artifacts. I don't know how you get around this if you go to only partial visibility. I don't know if I'm willing to live with that artifact. I'm not even going to only partial vis -- I'm not touching vis at all with under 50% cloud coverage. On my system, it doesn't look too bad -- FlightGear doesn't draw the cloud texture at all when you're (supposedly) inside the cloud layer. It does reappear when you get below it, but that sudden pop is not nearly so big a problem as not being able to use FlightGear to fly VFR in what should be VFR conditions. For an inexperienced user, especially, having everything go white when trying to descend past a few clouds (far away) is a far worse visual glitch than having a texture suddenly pop into view, and will probably cause the user to loose control and get frustrated. Should I tentatively commit it so that people can try it out? We can always revert if people hate it (and then I'll have to run it just as a local patch). David, Is it possible to fade the alpha value of the cloud layer to zero as you fade the visibility to 100 (or 50%)? Once the alpha is zero then you can stop drawing the layer. I'm not sure if this is possible by setting the alpha component of the base color of the cloud polygons? On the same subject of clouds. Is anyone still using the bump mapping code in the cloud layers. I thought this yielded interesting results for the middle of the day, but didn't do the correct thing as the sun got lower and lower in the sky. It adds a lot of complexity to the cloud code and if it's not really being used it would almost be nice to be able to remove it. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange FG crash.
On Mon, 10 Jan 2005 14:20:45 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: > I was just flying in the SFO area with the DHC2-F and flightgear crashed > with the following message: > > Unknown exception in the main loop. Aborting... > Possible cause: Success > > Anyone have any ideas? This is the first time I've seen anything like that. I did a find/grep through all of the FlightGear, SimGear, and plib source code as well as the base package, and I couldn't find anything that looked like a reasonable candidate for an exception returning the message "Success". All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
On Mon, 10 Jan 2005 13:59:28 -0600, Curtis L. Olson <[EMAIL PROTECTED]> wrote: > One issue to consider is that going to nil visibility (and not drawing > the cloud plane) hides when you pass through the "cloud plane". When > the cloud plane intersects the near clip plane you get some ugly > artifacts. I don't know how you get around this if you go to only > partial visibility. I don't know if I'm willing to live with that artifact. I'm not even going to only partial vis -- I'm not touching vis at all with under 50% cloud coverage. On my system, it doesn't look too bad -- FlightGear doesn't draw the cloud texture at all when you're (supposedly) inside the cloud layer. It does reappear when you get below it, but that sudden pop is not nearly so big a problem as not being able to use FlightGear to fly VFR in what should be VFR conditions. For an inexperienced user, especially, having everything go white when trying to descend past a few clouds (far away) is a far worse visual glitch than having a texture suddenly pop into view, and will probably cause the user to loose control and get frustrated. Should I tentatively commit it so that people can try it out? We can always revert if people hate it (and then I'll have to run it just as a local patch). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
On Mon, 10 Jan 2005 20:56:41 +0100, Erik Hofman <[EMAIL PROTECTED]> wrote: > This is due to a faulty SGSky::modify_vis() function. Actually it has > been broken since early 0.7.x as I recall it. I've never remembered to > look at it prior to a release, but I would recommend to fix that > function rather than to apply any kind of hack. I'm not sure I understand. The modify_vis() function isn't buggy as far as I can see, but it does have logic that makes FlightGear less useful -- that's what I'm proposing changing. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Strange FG crash.
I was just flying in the SFO area with the DHC2-F and flightgear crashed with the following message: Unknown exception in the main loop. Aborting... Possible cause: Success Anyone have any ideas? This is the first time I've seen anything like that. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
Erik Hofman wrote: This is due to a faulty SGSky::modify_vis() function. Actually it has been broken since early 0.7.x as I recall it. I've never remembered to look at it prior to a release, but I would recommend to fix that function rather than to apply any kind of hack. Erik, Can you explain in greater detail? What exactly is broken in the modify_vis() function? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
David Megginson wrote: Currently, FlightGear (SimGear, actually) always sets visibility to near-nil when the plane is inside a cloud layer -- obviously, the right and proper solution is 3D clouds, but until we have that working, or at least until we can detect whether the plane is actually near the cloudy part of a texture, I suggest that we do not limit the visibility when the cloud coverage is under 50% (i.e. scattered, few, or clear). This is due to a faulty SGSky::modify_vis() function. Actually it has been broken since early 0.7.x as I recall it. I've never remembered to look at it prior to a release, but I would recommend to fix that function rather than to apply any kind of hack. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposed change: visibility inside a cloud layer
David Megginson wrote: Currently, FlightGear (SimGear, actually) always sets visibility to near-nil when the plane is inside a cloud layer -- obviously, the right and proper solution is 3D clouds, but until we have that working, or at least until we can detect whether the plane is actually near the cloudy part of a texture, I suggest that we do not limit the visibility when the cloud coverage is under 50% (i.e. scattered, few, or clear). It's a bit of a hack, but it does make it possible to fly VFR under conditions that are legal VFR -- it's quite normal for VFR pilots to climb through a scattered cloud layer, for example (our scattered texture might be a little too busy for realism, though). You should have everything go white when there are only a few clouds in the sky. I'd like to commit this (very small) change. Are there any objections? It's especially useful with --enable-real-weather-fetch, where otherwise a low layer of few clouds gives you IMC right off the end of the runway. Here's the complete summay: clear: normal vis few: normal vis scattered: normal vis broken: low vis overcast: low vis cirrus: low vis Thanks, and all the best, David, One issue to consider is that going to nil visibility (and not drawing the cloud plane) hides when you pass through the "cloud plane". When the cloud plane intersects the near clip plane you get some ugly artifacts. I don't know how you get around this if you go to only partial visibility. I don't know if I'm willing to live with that artifact. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Proposed change: visibility inside a cloud layer
Currently, FlightGear (SimGear, actually) always sets visibility to near-nil when the plane is inside a cloud layer -- obviously, the right and proper solution is 3D clouds, but until we have that working, or at least until we can detect whether the plane is actually near the cloudy part of a texture, I suggest that we do not limit the visibility when the cloud coverage is under 50% (i.e. scattered, few, or clear). It's a bit of a hack, but it does make it possible to fly VFR under conditions that are legal VFR -- it's quite normal for VFR pilots to climb through a scattered cloud layer, for example (our scattered texture might be a little too busy for realism, though). You should have everything go white when there are only a few clouds in the sky. I'd like to commit this (very small) change. Are there any objections? It's especially useful with --enable-real-weather-fetch, where otherwise a low layer of few clouds gives you IMC right off the end of the runway. Here's the complete summay: clear: normal vis few: normal vis scattered: normal vis broken: low vis overcast: low vis cirrus: low vis Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hello Christian, > Probalby the easiest way would be to create an independant program > first, that communicates with FGFS via the network api. > The benefit is a very fast start on the rendering side - w/o much needed > internal FGFS knowledge and w/o the need to synchonize development at > the beginning. Thanks for the suggestion, but as the rendering engine is (mostly) finished, there will be not too much developemnt effort on this side (hopefully! :-)). Given the entangledness of the simulation with terrain handling, I don't think externalizing it via the network would be any easier... you would still have to set the same hooks, regardless if you couple via C++ API or the network. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hi Norman, > In the paper this appears to be based on a 'flat Earth' model > i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y > > Perhaps I am missing something or you have extended the engine > since this was written ? I don't remember if this was mentioned in the paper, but we use vertex shaders to simulate earth curvature (but could also be done on the CPU). The underlying datasets are projected; for whole earth visualisation, we split the earth into UTM zones (transverse mercator projection). This is important in order to limit map distortions and to retain valid error bounds for our elevation and texture data. I would have to look at the projection you mentioned, but I don't think it would be very well suited for our engine; because of its global nature there will inevitably be areas of high distortion. Additionally, the fact that a single landsat-textured UTM zone is a few 100 MB in size makes a monolithic global dataset unpractical. > Are you folks familiar with this work > http://globe.sintef.no/documentation/projection.html bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Mayer schrieb: > Jon Stockill schrieb: > I can look up a few positions of objects. What format do you need? Lat/Lon? >>> >>> >>>Just lat/lon, a heading (if appropriate) and the model you want inserted >>>at that point (obviously if it's not a standard one form the Models >>>directory then it'd be nice if you had the model too, so that everyone >>>else gets to see it). >>> >>>I'll archive the Objects tree and my models, and let you know when >>>they're available for download. > > > Argh. The Bayernviewer page doesn't give me the coordinates anymore (the > old, non-java version could do that). > I write an eMail and hope that they'll add that functionality. I got an answer. They told me that the ministry decided that it'll be a security problem if people could the the coordinates of objects and places easily and quickly from the BayernViewer. So the alternative would be that I buy the map-data CD-ROM at ebay. They are not expensive (they are made for tramping and bike tours) - but too expensive for looking up just a few locations :( CU, Christian PS: Does anybody know an online map service where you can get the coordniates? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4qyllhWtxOxWNFcRAp48AJ98gI8VphyCFeIFLDhFKAlqji6RlgCfWzLo Xva9iA5jbeUODksLKKX6jCU= =FLNU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Norman Vine wrote: > > Manuel Massing writes: > > > > > Is this methodology you want to integrate ? > > > http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf > > > > yes, that's it. > another interesting read from this project :-) http://cg.cs.uni-bonn.de/docs/publications/2004/harabasz-2004-out-of-core.pdf Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hi, > If my memory serves, previous "big" changes to the codebase have been > handled by having a conditional compilation option which switches on the > new code (and switches off some old code if needed) and putting all changes > in CVS HEAD. This allows people to try it if they want to, and avoids what > I understand is the main problem of CVS branches, which is reintegration > when it is complete. I don't exactly need to do "big" changes (as in many LOC), but some intrusive and scattered ones. Conditional compiles would be a _major_ hassle to this end. OTOH, I have never had any notable trouble merging branches... bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Norman Vine writes: > > In the paper this appears to be based on a 'flat Earth' model > i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y ooops ... i.e. lon lat are taken to be simple X, Y or Cos(medianY)*X,Y ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Manuel Massing writes: > > > I think an abstract Terrain API is a great idea however please > > keep in mind that FlightGear uses a round earth model and that > > this should be reflected in any FGFS Terrain API > > > Is this methodology you want to integrate ? > > http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf > > yes, that's it. In the paper this appears to be based on a 'flat Earth' model i.e. lon lat are taken to be simple X, Y or Cos(medianX)*X,Y Perhaps I am missing something or you have extended the engine since this was written ? Are you folks familiar with this work http://globe.sintef.no/documentation/projection.html Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Norman Vine schrieb: > Manuel Massing writes: > >>I want to start to integrate an alternative terrain engine >>with flightgear >>(http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) >> >>For this, I need to adapt flightgear to use an abstract terrain API, which >>will encapsulate the current and new terrain engine transparently. > > > < Apologies for my earlier empty msg > > > I think an abstract Terrain API is a great idea however please > keep in mind that FlightGear uses a round earth model and that > this should be reflected in any FGFS Terrain API Probalby the easiest way would be to create an independant program first, that communicates with FGFS via the network api. This works currently for multi monitor (=machine) setups. And when the new rendering engine is capable enough to work in such a situation we can integrate it. The benefit is a very fast start on the rendering side - w/o much needed internal FGFS knowledge and w/o the need to synchonize development at the beginning. CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB4ppglhWtxOxWNFcRAvA4AJ9TcDWEHcUCHRAvBGrSHQqyz91OsACgr2Vw PwkYmqngc8Qgy/4X9KOF32k= =7SGU -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
> > I think in this case a branch makes a lot of sense, because > otherwise the > modifications would greatly disturb the main-branch; or I > would be forced > to hold back a gigantic monolithic patch until coding&testing > has finished, > which would leave me without version control (and others > wouldn't be able to > test or contribute). > If my memory serves, previous "big" changes to the codebase have been handled by having a conditional compilation option which switches on the new code (and switches off some old code if needed) and putting all changes in CVS HEAD. This allows people to try it if they want to, and avoids what I understand is the main problem of CVS branches, which is reintegration when it is complete. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hello Norman, > I think an abstract Terrain API is a great idea however please > keep in mind that FlightGear uses a round earth model and that > this should be reflected in any FGFS Terrain API Yeah, there are a lot of things one has to keep in mind I guess, so this will be most probably an iterative process... that's why I'm begging for a branch :-) The API-sketch passes coordinates in lat/lon (via SGLocation), so there should be no problem regarding the roundness of the earth. Anyhow, the API will be as simple as possible; currently just elevation, ground type and collision queries and some sort of rendering interface. Maybe some methods for dynamic addition of airports. The APIs' initial task will be to encapsulate the existing ground code, any other fancy stuff comes in later if necessary :-) I'll post the intitial sketch later... > Is this methodology you want to integrate ? > http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf yes, that's it. bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Hello Erik, > That's great, I already wondered what happened to that project. This > would really be a great addition for FlightGear. Unfortunately I am studying and currently try to compensate for the tremendous lazyness of my past semesters :-) So that project had to wait for the christmas break. > As I understood you where using your own SceneGraph engine, what would > be the best way to handle this; > 1. Adding a SceneGraph API > 2. You change your code to use plib > 3. FlightGear starts to use your SceneGraph library I am not yet sure what the best solution will be, but I want to either: 1) Wrap it into a plib scenegraph node 2) Abstract out the scenegraph and only offer a render() method, which would just render to the current OpenGL context. I prefer the second method, because of the simplicity of the interface; implementation-wise the difference is small, it's more of a design question at what level the rendering should be encapsulated. IMO the earlier, the better (i.e. simpler). > Hmm, I've seen work on branches and they have their pro's and con's. I'm > not sure I like branches all that much. I think in this case a branch makes a lot of sense, because otherwise the modifications would greatly disturb the main-branch; or I would be forced to hold back a gigantic monolithic patch until coding&testing has finished, which would leave me without version control (and others wouldn't be able to test or contribute). bye, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Manuel Massing writes: > > I want to start to integrate an alternative terrain engine > with flightgear > (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) > > For this, I need to adapt flightgear to use an abstract terrain API, which > will encapsulate the current and new terrain engine transparently. < Apologies for my earlier empty msg > I think an abstract Terrain API is a great idea however please keep in mind that FlightGear uses a round earth model and that this should be reflected in any FGFS Terrain API Is this methodology you want to integrate ? http://cg.cs.uni-bonn.de/docs/publications/2004/wahl-2004-scalable.pdf Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] alternative terrain engine integration
Manuel Massing wwrites: > Sent: Monday, January 10, 2005 7:33 AM > To: flightgear-devel@flightgear.org > Subject: [Flightgear-devel] alternative terrain engine integration > > > Hi, > > I want to start to integrate an alternative terrain engine > with flightgear > (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) > > For this, I need to adapt flightgear to use an abstract terrain API, which > will encapsulate the current and new terrain engine transparently. > > As this will involve some (mostly small) changes all over the place, it would > be great if I could work on a CVS branch. > > Would that be possible? What is the policy for gainining > CVS write access to the fgfs repository? > > Of course, I will post planned changes on the mailing lists for > discussion, but I want to get the bureaucratic stuff sorted out first :-) > > cheers, > > Manuel > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] alternative terrain engine integration
Manuel Massing wrote: Hi, I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) That's great, I already wondered what happened to that project. This would really be a great addition for FlightGear. For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. As I understood you where using your own SceneGraph engine, what would be the best way to handle this; 1. Adding a SceneGraph API 2. You change your code to use plib 3. FlightGear starts to use your SceneGraph library As this will involve some (mostly small) changes all over the place, it would be great if I could work on a CVS branch. Hmm, I've seen work on branches and they have their pro's and con's. I'm not sure I like branches all that much. Would that be possible? What is the policy for gainining CVS write access to the fgfs repository? Curtis? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] alternative terrain engine integration
Hi, I want to start to integrate an alternative terrain engine with flightgear (http://baron.flightgear.org/pipermail/flightgear-devel/2004-September/030853.html) For this, I need to adapt flightgear to use an abstract terrain API, which will encapsulate the current and new terrain engine transparently. As this will involve some (mostly small) changes all over the place, it would be great if I could work on a CVS branch. Would that be possible? What is the policy for gainining CVS write access to the fgfs repository? Of course, I will post planned changes on the mailing lists for discussion, but I want to get the bureaucratic stuff sorted out first :-) cheers, Manuel ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
