Re: [Flightgear-devel] YASim twist/incidence fix
On Thursday 01 Dec 2005 21:08, Andy Ross wrote: > I've been short of time recently, but Curt is keen on getting > the twist/incidence fix into YASim in time for the next > release. So I've committed it more or less blind. :) > > A quick grep through the source code gives a list of affected > aircraft configurations that I've attached below. The fix is > *supposed* to either do nothing or improve handling of each of > these aircraft, but problems do happen. If anyone is > interested in QA work, could you load up and play with > some/all of these aircraft to validate that nothing weird has > happened? Just make sure that (1) it solves and (2) doesn't > have handling bugs like odd stalling, snap rolls, etc... (or > at least handling bugs that weren't present before). > > The one exception is (I think) the Citation, which had its > twist and incidence numbers negated in CVS prior to the 0.9.9 > release. That one will have to be re-negated now that the fix > is in code. > > Planes affected: > > MiG-15/MiG-15bis-yasim.xml > B-52F/B-52F-yasim.xml > b29/b29-yasim.xml > Hurricane/hurricaneIIb.xml > Citation-Bravo/Citation-Bravo-yasim.xml > dhc2/dhc2F.xml > dc3/dc3.xml > Hunter/hunter-yasim-2t.xml > Hunter/hunter-yasim.xml > YF-23/YF-23-yasim.xml > pa28-161/pa28-161.xml > tu154/tu154.xml > seahawk/seahawk-3d-yasim.xml > seahawk/seahawk-yasim.xml > Citation/Citation-II-yasim.xml > j22/j22-yasim.xml > 747/747.xml > p51d/p51d.xml > AN-225/AN-225-yasim.xml > j3cub/j3cub.xml > Spitfire/spitfireIIa.xml > Spitfire/seafireIIIc.xml > A-10/A-10-yasim.xml > TU-114/TU-114-yasim.xml > b1900d/b1900d.xml > > Thanks, > Andy I'm expecting several of the ones I've done to break, in fact I'm surprised some of them fly at all in view of the -ve incidence they've apparently had but it's better to have the s/w right. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RocketCam / PlaneCam
On Saturday 19 Nov 2005 15:46, Jon Berndt wrote: > Does FlightGear have the capability to specify a camera > viewpoint ON the aircraft. For instance, could a "camera" be > mounted on the vertical stabilizer, pointing forward? It would > be nice to see the aerosurface movements. > > Jon Yes - I've added extra on-board views for the B-52F (Tail gunner), BAC-TSR2 - navigator position), TU-114 & Canberra (Nose nav position). You can place them anywhere you want. You need to increase /sim/number-views by the number of new views you want to add and then define the new views by specifying it all up in the aircraft 'set' file. In the aircraft I've mentioned above I've added two new views so you could have a look at those. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft for v0.9.9
On Friday 18 Nov 2005 15:25, Curtis L. Olson wrote: > Aircraft authors (or other interested parties.) > > Take a look at the latest aircraft download page: > > http://www.flightgear.org/Downloads/aircraft/ > > There are quite a few aircraft with no thumbnail.jpg created > for the web page. We need a 171x128 pixel image for each > aircraft that has a 3d model. This needs to be saved as > "thumbnail.jpg" in the aircrafts top level directory ... you > can look at other aircraft for examples. > > It would be great if we could have pictures for everything > before we spam the world with our v0.9.9 release. > > Thanks! > > Curt. Josh has been doing some nice work on the Canberra model so I'll leave the thumbnail and author details to him - ok Josh? The TU-114 status should be set to something like 'development' or 'pre-alpha' because of the fundamental problems with the prop pitch control. I can do an update for the status change and a thumbnail if you wish. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] mi_cmd_stack_list_frames: Not enough frames in stack.
On Friday 11 Nov 2005 17:35, Erik Hofman wrote: > Arthur Wiebe wrote: > > OK, > > > > But then why when I select the A-10 or f16 fgfs crashes? But > > when selecting the c172p and j3cub there is no problem? > > The only commonality between the A-10 and f-16 is the turbine > sound file?? > > Erik Agreed - I used the generic sound files for the A-10 but the engine related ones are probably the only ones common to the F-16 and A-10 but not used by the C-172 or j3 cub. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Citation "pitch down" divergence. Fixed?
On Friday 11 Nov 2005 02:47, Josh Babcock wrote: > Lee Elliott wrote: > > On Thursday 10 Nov 2005 20:20, Andy Ross wrote: > >>After some prodding from Curt, I finally spent a few hours > >>yesterday tracking down the "pitch down" discontinuity in > >> the Citation. > >> > >>Well, I didn't find a discontinuity. I can now graph the > >> lift curve from a Surface (a real one, part of the real > >> aircraft, not an isolated test instance) and verify that > >> it's valid and correct looking through the entire AoA > >> regime. > >> > >>But I think I *did* find the problem: it seems that I, er, > >>"misdocumented" the incidence and twist parameters in the > >>YASim configuration. The README.yasim file states that > >> these numbers are positive for positive AoA (i.e. a > >> positive incidence on a wing generates extra lift, and a > >> negative twist causes the wing tips to stall after the > >> root). But the code was interpreting the number as a > >> rotation about the YASim Y axis, which points out the left > >> wing and therefore is positive *down*. Oops. > >> > >>The reason the citation exhibited this especially is just > >>luck: the file lists an incidence of 3.0 (which is > >> relatively high, and the inversion bug therefore puts the > >> wing 3 degrees closer to a negative stall) the solver > >> happens to generate a nose-down cruise configuration of > >> about 1.5 degrees, and the elevator authority is actually > >> quite high (which causes higher pitch rates under autopilot > >> control). > >> > >>So the bottom line is that Curt was right: it *was* the > >>negative AoA stall (probably the tail's, not the wing's) > >>happening too soon. :) > >> > >>I'm a little leery of changing this in code this close to a > >>release -- the risk of breaking working aircraft is too > >> high. For the short term, this can be fixed in the > >> Citation-II.xml file by simply negating the incidence and > >> twist values on the wing. I did this and tried the > >> autopilot in a maximum speed cruise at low level (which > >> should produce the highest nose-down AoA) without any odd > >> behavior. > >> > >>Curt, can you try that and see if it appears to fix the > >>handling issues? Likewise, anyone with a YASim aircraft > >> that makes use of incidence or twist values is encouraged > >> to try the same modification and report any problems. We > >> can go back after the release and fix the code and all the > >> aircraft files. > >> > >>Andy > > > > I'll try to check the ones I've done over the weekend. The > > one that concerns me most is the B-52F. The wing incidence > > is set to 6 and the twist to -4 and I'm starting to wonder > > how it manages to fly at all. > > Nose down. The fuselage is about 5 deg down when in level > flight. > > > I got some good info on the B-52F from someone who flew > > around 3000 hrs in that model and around 6000 hrs total in > > all models, apart from the A/B, and it was flying to within > > around 10 kts or so of what it should have been doing and > > was climbing at about the right rate. > > > > LeeE Depending on weight, alt and speed, 5 deg nose-down could be correct. The incidence of +6 degrees is correct but I had to estimate the twist. I should be able to have a look at it sometime this weekend. Ta for having a look. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Citation "pitch down" divergence. Fixed?
On Thursday 10 Nov 2005 20:20, Andy Ross wrote: > After some prodding from Curt, I finally spent a few hours > yesterday tracking down the "pitch down" discontinuity in the > Citation. > > Well, I didn't find a discontinuity. I can now graph the lift > curve from a Surface (a real one, part of the real aircraft, > not an isolated test instance) and verify that it's valid and > correct looking through the entire AoA regime. > > But I think I *did* find the problem: it seems that I, er, > "misdocumented" the incidence and twist parameters in the > YASim configuration. The README.yasim file states that these > numbers are positive for positive AoA (i.e. a positive > incidence on a wing generates extra lift, and a negative twist > causes the wing tips to stall after the root). But the code > was interpreting the number as a rotation about the YASim Y > axis, which points out the left wing and therefore is positive > *down*. Oops. > > The reason the citation exhibited this especially is just > luck: the file lists an incidence of 3.0 (which is relatively > high, and the inversion bug therefore puts the wing 3 degrees > closer to a negative stall) the solver happens to generate a > nose-down cruise configuration of about 1.5 degrees, and the > elevator authority is actually quite high (which causes higher > pitch rates under autopilot control). > > So the bottom line is that Curt was right: it *was* the > negative AoA stall (probably the tail's, not the wing's) > happening too soon. :) > > I'm a little leery of changing this in code this close to a > release -- the risk of breaking working aircraft is too high. > For the short term, this can be fixed in the Citation-II.xml > file by simply negating the incidence and twist values on the > wing. I did this and tried the autopilot in a maximum speed > cruise at low level (which should produce the highest > nose-down AoA) without any odd behavior. > > Curt, can you try that and see if it appears to fix the > handling issues? Likewise, anyone with a YASim aircraft that > makes use of incidence or twist values is encouraged to try > the same modification and report any problems. We can go back > after the release and fix the code and all the aircraft files. > > Andy I'll try to check the ones I've done over the weekend. The one that concerns me most is the B-52F. The wing incidence is set to 6 and the twist to -4 and I'm starting to wonder how it manages to fly at all. I got some good info on the B-52F from someone who flew around 3000 hrs in that model and around 6000 hrs total in all models, apart from the A/B, and it was flying to within around 10 kts or so of what it should have been doing and was climbing at about the right rate. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange colors in spash screen
On Thursday 10 Nov 2005 18:01, Arthur Wiebe wrote: > http://artooro.spymac.com/pub/fg_spash_screen.png > > This is a screenshot of some very interesting colors I get in > the splash screen when launching FlightGear 0.9.9-pre2. > > Any idea what could be wrong? It all works fine once > everything has been initiated. > > -- > > - http://sourceforge.net/users/artooro/ > - http://artooro.blogspot.com That looks like a corrupted splash screen image. Does it happen with all the aircraft you've tried? Some aircraft have their own splash image but those that don't get one of the default splash images. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] waypoints, waypoint loops, route manger
On Wednesday 09 Nov 2005 22:02, Craig E. Staples wrote: > Hello all, > > I'm trying certain senarios via waypoints and varying > altitudes by using flightplan/.fgfsrc file. I plan on > implementing a data input change for route manger code to read > a file with my data, but in the mean time I was wondering if > there's a reason why [EMAIL PROTECTED] has issues maintaining the > wanted altitude. I have alts at 15k, but the craft drifts to > 20 k, etc... I also want to maintain a senario for a certain > amount of time, so go to waypoint 1 and 2 looping for 10 mins, > etc... then hit waypoints 3, 4 and 5... If anyone has a better > way to approach this please give me ur ideas. Thanks a lot.. > > Regards, > Craig E. I don't know the straight answer to this problem but there are a couple of factors that need to be considered in using flightplan data, like the [EMAIL PROTECTED] info in a flightplan file, or supplied on the console/termninal at start-up. The first is that if you want any altitude hold there will have to be a controller, or more likely a cascade of controllers set up in the autopilot to do it. The reference or target altitude that the autopilot altitude controller tries to achieve needs to be available in the property tree, so that it can read it. If the altitudes supplied in the flightplan aren't transferred to the right place in the property tree then the a/p controllers can't use them. The second factor is that just setting a target altitude will not mean that an a/c will fly properly to that altitude. Climbing to a new, higher altitude that's a lot different to the current altitude isn't a simple matter and must be done at the correct speed and may need to be done in steps. The fuel state and payload will also have a great influence on how the climb is achieved. I guess a simple list of [EMAIL PROTECTED] waypoints is inadequate because it lacks the climb info/requirements. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CPU usage issue
Hmm... the puzzling thing is that you don't seem to be getting 100% utilisation when running FG. As Andy R explained, you should expect to see 100% utilisation. If you had been running on a multi-processor/core system then it might have made more snese. LeeE On Monday 31 Oct 2005 15:16, Drew wrote: > No, single processor. > > On 10/29/05, Lee Elliott <[EMAIL PROTECTED]> wrote: > > Are you running on a dual processor/core system? > > > > LeeE > > > > On Friday 28 Oct 2005 01:41, Drew wrote: > > > If you can throttle the frame rate when the window is > > > open, can't it be throttled when it's minimized? When I > > > have the window open, it runs at about 60% utilization, > > > not 100. > > > > > > On 10/27/05, Andy Ross <[EMAIL PROTECTED]> wrote: > > > > Drew wrote: > > > > > I have a Windows build of FlightGear, and have > > > > > recently discovered when the FlightGear window is > > > > > minimized, the CPU usage jumps up to 100%. Does anyone > > > > > have any idea why this happens? What can be done to > > > > > fix this? > > > > > > > > Didn't this subject come up before? Note that "CPU usage > > > > is at 100%" is neither a bug nor a problem by itself. Do > > > > you need more CPU for calculating something else? Are > > > > your other applications unresponsive? > > > > > > > > FlightGear, like most games or real-time simulations, > > > > has a frame-based main loop. It calculates a frame, > > > > renders it, and then immediately goes back to the start > > > > of the loop to render the next one. That keeps the frame > > > > rate as high as possible given the resources available. > > > > > > > > There is currently no provision for "throttling" the > > > > frame rate in situations where the window is minimized, > > > > although I suppose that could be done. > > > > > > > > Andy > > > > > > > > ___ > > > > Flightgear-devel mailing list > > > > Flightgear-devel@flightgear.org > > > > http://mail.flightgear.org/mailman/listinfo/flightgear-d > > > >evel 2f585eeea02e2c79d7b1d8c4963bae2d > > > > ___ > > 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] CPU usage issue
Are you running on a dual processor/core system? LeeE On Friday 28 Oct 2005 01:41, Drew wrote: > If you can throttle the frame rate when the window is open, > can't it be throttled when it's minimized? When I have the > window open, it runs at about 60% utilization, not 100. > > On 10/27/05, Andy Ross <[EMAIL PROTECTED]> wrote: > > Drew wrote: > > > I have a Windows build of FlightGear, and have recently > > > discovered when the FlightGear window is minimized, the > > > CPU usage jumps up to 100%. Does anyone have any idea why > > > this happens? What can be done to fix this? > > > > Didn't this subject come up before? Note that "CPU usage is > > at 100%" is neither a bug nor a problem by itself. Do you > > need more CPU for calculating something else? Are your other > > applications unresponsive? > > > > FlightGear, like most games or real-time simulations, has a > > frame-based main loop. It calculates a frame, renders it, > > and then immediately goes back to the start of the loop to > > render the next one. That keeps the frame rate as high as > > possible given the resources available. > > > > There is currently no provision for "throttling" the frame > > rate in situations where the window is minimized, although I > > suppose that could be done. > > > > Andy > > > > ___ > > 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] CPU usage issue
On Thursday 27 Oct 2005 20:28, Drew wrote: > Hey all, > > I have a Windows build of FlightGear, and have recently > discovered when the FlightGear window is minimized, the CPU > usage jumps up to 100%. Does anyone have any idea why this > happens? What can be done to fix this? > > Thanks, > Drew Hmm.. when running FG my CPU usage is always at 100% although the total usage is split between user and system utilisation, with user taking the vast majority. I've noticed that if I bump up the anti-aliasing settings to high values I see a much higher system utilisation and lower frame rates, so I could imagine that minimising the FG window could do funny things to the frame rate and skew the user/system ratio. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] recent 737 autopilot change
On Thursday 27 Oct 2005 20:20, Vassilii Khachaturov wrote: > In the recent 737 autopilot change, > we see that the only improvement is the change of the target > speet. > > diff -u -2 -r1.15 -r1.16 > --- 737-set.xml 18 Oct 2005 16:32:23 - 1.15 > +++ 737-set.xml 27 Oct 2005 08:34:40 - 1.16 > @@ -110,5 +110,5 @@ > type="double">4000.0 type="double">283.0 - type="double">200.0 + type="double">165.0 > > > However, I am surprised to see that the target speed is > hardwired here. AFAIK, the heavies use different target speeds > dependant on the density altitude and aircraft landing weight. > I don't know how big the difference can be within the possible > range of the allowed landing weights. Can a 737 specialist > sched some more light, please? > > V. Hello Vassilii, these aren't 'hardwired' values but defaults. The values declared here, in the aircraft 'set' file create the corresponding nodes in the property tree and their values can be changed using panel instruments, GUIs, the property browser, nasal scripts and the telnet and http interfaces. The file that defines the characteristics of the autopilot is Aircraft/737/Systems/737-autopilot.xml If you have a look at this you'll see that the relevant autopilot PID controllers read their reference values from the property tree nodes holding the values declared in the aircraft 'set' file. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
On Saturday 22 Oct 2005 18:53, Oliver C. wrote: > On Saturday 22 October 2005 19:09, Lee Elliott wrote: > > Hello Geoff, > > > > just tried fgfs --fog-disable --visibility=12 and it > > seemed to start ok. Didn't try flying as I'm just off out. > > This is on a Debian Linux system. > > > > LeeE > > I tried it too. > It works okay running at about 7-11 fps on an Athlon 2000+, 1 > GB Ram and Geforce 4200 Ti 64 MB on a Linux Slackware 10.0 > machine. > > But the lightning is wrong, it is too dark in the far distance > at midday. See screenshot: > http://img460.imageshack.us/my.php?image=fgfsdark3xu.jpg > > Best Regards, > Oliver C. Do you mean that the sky colour is wrong? That's a bit of a difficult one to assess because at low altitudes we always see through a lot of atmosphere. Setting no fog is a bit like removing _all_haze from the view, which is something you'll never see in real life, except perhaps at very high altitudes. Removing the fog is a bit like elevating your altitude. It may not be perfect but you'd be hard pressed to do much better with a fully featured ray-traced renderer, let alone OpenGL. Don't get me wrong, with ray-tracing you could account for variable refractive index and scattering based on altitude and wavelength but it would take a long time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Two problems - 1 easy and 1 hard! - in XP using MSVC7
On Saturday 22 Oct 2005 16:43, Geoff Air wrote: > Hi, > > I guess I should write MSVC7.1 ;=)) I am using the 2003, > version 7.1.3088 ... Have downloaded beta 2005, but still > to try this ... > > Thanks for the heads up about the 120km limit of the > renderer, Harald ... I will keep that in mind ... I > presume this is a constant defined in FG/SG/PLIB/?? > somewhere ... > > And thanks Andy, for the pointer - > > http://www.microsoft.com/whdc/system/platform/server/PAE/PAEme >m.mspx This explains it all ... a maximum of 2GB of process > memory, and 2GB for system memory, unless > you add /3GB to boot.ini *AND* reset the exe image using > Editbin.exe to set IMAGE_FILE_LARGE_ADDRESS_AWARE ... > which seems quite a lot of effort ... to gain an > extra GB ... but worth keeping in mind ... > > I had already experimented a little with the virtual > memory settings and discovered the 4GB LIMIT! And perhaps > now see why FG did NOT allow me to use my 20, or > even 12 ... even though windows had memory for > starting other memory hungry processes ... Word for > example ... > > It also perhaps explains why Word will also politely > reject say a paste operation, when copying in a large > site from IE ... by large here, I mean a site that > takes lots of memory to contain ... > > I can get a MEMORY ABORT ... it is a shame it does not > seem to set a memory error message that perror(...) sees ... > by just be removing the fog (--fog-disable), even with > the default visibility ... which is? > > So while the renderer might have a 120km (~75 miles) limit, > it is further reduced by the FOG ... at present, through > repeated experiments, the most I can push the fog > back is 45 miles (72420m) ... 50 miles produced an ABORT > after quite a number of minutes of flying ... aka tile > loading ... > > We could attack the tile manager ... but not suggesting > this literally, since it already does a good job ... it > could encase its 'new' in an exception handler, and > 'know' it is requesting too much memory ... and if a > distant tile, that it 'knows' can not really be rendered, > forget it, output a warning, or, remove (free) some of > the non-visible behind tiles ... but I agree, this is, > perhaps, way too complicated ... > > Also, if as Harald reports, the renderer has a hard > coded limit of 120km, then, at least, IGNORE a user > request for more ... what would be the use in loading > tiles out-of-range of the renderer, if there is such > a limit? > > The whole aim here is to produce an application that > withstands ALL user parameters entered ... especially > --fog-disable ... If I do not want REALISM, I want > to 'see' as far as possible ... then the application > should try to oblige ... IMHO ... > > Simply, I would prefer FG fly on, and not ABORT, just > because it passed the 2GB of process memory, in > WIN32. It is further assumed unix systems do not have > these constraints ... or a different set of memory > problems ... > > I would certainly be pleased if a *nix system user > could try - > --fog-disable > --visibility=12 > Is no one else interested in 'seeing' as much of the > world as possible, as clear as possible, without > fog-blur? aka realism ... > > Anyway, I am happy, now I know the LIMITS, and will > try to work, quietly, within these constraints ;=)) > > Regards, > > Geoff. > > PS: I only get board messages in digest (batch) mode, > so may be behind what has been subsequently posted ;=() Hello Geoff, just tried fgfs --fog-disable --visibility=12 and it seemed to start ok. Didn't try flying as I'm just off out. This is on a Debian Linux system. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures - screenshot
On Saturday 22 Oct 2005 10:12, Erik Hofman wrote: > Dave Culp wrote: > > screenshot: > > http://home.comcast.net/~davidculp2/PC7-winter.jpg > > Here are two more: > > http://www.a1.nl/~ehofman/fgfs/gallery/T38-snow.jpg > http://www.a1.nl/~ehofman/fgfs/gallery/Mig15-snow.jpg > > Erik Got the textures but haven't tried them yet - the screen shots look really nice:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with 'V' (backwards view) on Mac os X
On Thursday 20 Oct 2005 03:31, Ima Sudonim wrote: > > On Thursday 20 Oct 2005 01:10, Ima Sudonim wrote: > > > Hi, > > > > > > Someone else had mentioned something similar recently, but > > > I can't find the post in flightgear-devel. > > > > > > I noticed that with latest CVS on mac os x, I can scroll > > > thru views (forward) with 'v' as many times as I like, but > > > that 'V' (reverse) only works 1-3 times until I reach the > > > view that has a name ending in 'w/o yaw'. > > > > > > 'V' will no longer work, until I move forward in the views > > > with 'v' at least once. Then the 'V' cycle works (or fails > > > to work) as mentioned above. > > > > > > Thanks! > > > > > > Ima > > Have you found this with several different aircraft or have > > you only tried a single type so far? If it only happens > > with a specific aircraft, which one is it? > > > > LeeE > > > I was using the default cessna (didn't give --aircraft= > option) (it's the chase view w/o yaw option, where the problem > occurs in all instances with reverse view). > > DOES happen with default cessna, sopwithCamel, spitfireIIa, > 747-100, ufo, Citation-II, A380, shuttle (gave a 'failed to > load aircraft from, falling back to glider.ac' message, > ornithopter (BTW, the ornithopter is already moving forward > when fg starts, unlike the other airplane models), bell206 > > DOESN'T happen with A-10cl (my personal favorite) 8-) or > A-10fl (there is no chase view w/o yaw option) > > Hope this helps! > > Thanks! > > Ima Heh ;) I don't mind top or bottom replies but sticking them in the middle throws me a bit. Anyway... I can't find any problems here - cvs a day or two old - I tried just calling fgfs with no params, to get the C-172, and could scroll backwards and forwards through the views ok. Cycled forward to chase w/o yaw, cycled backwards from it - no problems. Then tried both the A-10s, because you mention that they had no chase view w/o view and had no problems there either, including the chase view w/o yaw. Do you get a 'Drop View' with the A-10s? The Drop view should be the 'last' view on the A-10s, before you end up back in the Cockpit and should come after the chase view w/o yaw. Do you get both the chase view w/o yaw and drop view on the A-10s? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with 'V' (backwards view) on Mac os X
On Thursday 20 Oct 2005 01:10, Ima Sudonim wrote: > Hi, > > Someone else had mentioned something similar recently, but I > can't find the post in flightgear-devel. > > I noticed that with latest CVS on mac os x, I can scroll thru > views (forward) with 'v' as many times as I like, but that 'V' > (reverse) only works 1-3 times until I reach the view that has > a name ending in 'w/o yaw'. > > 'V' will no longer work, until I move forward in the views > with 'v' at least once. Then the 'V' cycle works (or fails to > work) as mentioned above. > > Thanks! > > Ima Have you found this with several different aircraft or have you only tried a single type so far? If it only happens with a specific aircraft, which one is it? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] TU114-set.xml help/spelling in comments
On Wednesday 19 Oct 2005 02:13, Vassilii Khachaturov wrote: > Index: ../data/Aircraft/TU-114/TU-114-set.xml > == >= RCS file: > /var/cvs/FlightGear-0.9/data/Aircraft/TU-114/TU-114-set.xml,v > retrieving revision 1.1 > diff -u -r1.1 TU-114-set.xml > --- ../data/Aircraft/TU-114/TU-114-set.xml5 Oct 2005 15:59:17 > - 1.1 +++ ../data/Aircraft/TU-114/TU-114-set.xml 19 Oct > 2005 01:11:34 - @@ -9,6 +9,16 @@ > > > > + > + > + K > + Toggle trajectory markers > + > + > +L/U > +Update Tower/Drop View position > + > + > > + > > > > @@ -181,7 +191,7 @@ > > > > -U > +L > Update Tower View position > >nasal Hello Vassilii, there are some fundamental problems with the TU-114 props and engines and it's really only in cvs so that other people can have a look into it. This doesn't mean you can't or shouldn't (try) to fly it or fix bits that you notice are wrong but you should bear in mind that in it's present state it's incomplete and badly flawed. The problems with the props & engines concern controlling the prop pitch and I don't have a clear/good enough understanding of how it should work to fix it. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible MP Server problem
On Monday 10 Oct 2005 10:04, Oliver Schroeder wrote: > Hi, > > Am Monday 10 October 2005 00:28 schrieb Lee Elliott: > > I had problems at first with FGMultiplayRxMgr not being able > > to bind the receive socket but I was still able to see > > myself on the web map display at pigeond.net > > That normally means, that another process is already using the > port. Note that you can use any port you want. > > > Once I seemed to get connected properly, and saw a message > > about Vivian being 'initialised' on my terminal I then found > > that I couldn't start the engine on any of the _single_ > > engined YASim a/c I tried. Multi-engined a/c would start ok > > but I don't know yet if they caused Vivian any problems. > > That is strange. Can you verify that everything is working if > you are not connecting to the server? Yes - the a/c works ok when I'm not connected to the server and also worked ok before I got the port forwarding problem sorted out i.e. when I could see myself on the map but was getting the FGMultiplayRxMgr message. When I tried again, a little later, with the correct params and when no one else was connected I had no problems. Once I realised that there was some sort of problem I only tried a few very quick checks because I didn't want to interfere with what Vivian was trying to do. I tried both the MiG-15bis, which I'm currently working on and the Comper Swift - one jet and one prop - and couldn't get any power out of either of them. The internal properties looked ok in both but the throttle simply had no effect in the Mig-15bis and although I could spin the Swift prop on the starter the engine wouldn't fire. Both checked ok 'off-line' or with an intentionally 'bad' --multiplay=in param. I only checked one multi-engined type - the TU-114 - but all of the engines were reporting the right o/p. Because of the risk of interfering with what Vivian was doing I didn't try any more tests. > > The message "initializing USER..." means, that you are > correctly connected to the server and receive data for the > remote user. > > > I'm still not sure if I was connecting properly because it > > was displaying me as [EMAIL PROTECTED] instead of showing my IP > > address, which I suspect has something do with IP > > masquerading. > > The map shows what the server sees. "[EMAIL PROTECTED]" means, that > the user Lee is connected to the server you are querying. On > pigeons map you can select which server you want to observe. > If you switch to "o-schroeder.de" while connected to pigeons > server, you will see "[EMAIL PROTECTED]" (the IP of pigeons > server). That is because my and pigeons server exchange their > user data, so that both servers see "one world". > That is possibly changing in the future, but that's the way it > is atm. > > regards, > Oliver I figured that the 'initialising user' message was a good sign;) I had a reply from Vivian saying that I didn't appear to affect his session, which is significant. On that basis i.e.my problems weren't causing other folk problems, I'll try some more tests in the next few days. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Possible MP Server problem
Hello all, I thought I'd try connecting to the MP server at pigeond.net and noticed that Vivian was connected at the time. I had problems at first with FGMultiplayRxMgr not being able to bind the receive socket but I was still able to see myself on the web map display at pigeond.net Once I seemed to get connected properly, and saw a message about Vivian being 'initialised' on my terminal I then found that I couldn't start the engine on any of the _single_ engined YASim a/c I tried. Multi-engined a/c would start ok but I don't know yet if they caused Vivian any problems. I'm still not sure if I was connecting properly because it was displaying me as [EMAIL PROTECTED] instead of showing my IP address, which I suspect has something do with IP masquerading. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On Friday 07 Oct 2005 01:25, Ampere K. Hardraade wrote: > Hello, > > As some of you may know, I have been working on the A380's > cockpit for the past few months. Since my work has been > commited to the CVS, I decided to show you guys a screenshot > of my progress so far: > http://www.students.yorku.ca/~ampere/fgfs-screen-005.jpg > > As you can see, a few components are still missing, so there > is quite a bit of work ahead before the cockpit can be > considered as finished. Notably, the sidesticks are missing; > as do the throttles, some instruments on the front panel, the > seats for the pilots... and the textures (glow, no glow, and > in-between). > > Since I have been quite busy lately, I want to concentrate my > work on the scripting aspect of the A380. Thus, it would be > nice if people can volunteer to fill in the missing pieces. > AJ has already been working on the sidesticks, but it will be > nice if there are a few more volunteers. =P > > Thank you, > Ampere I'll try modelling a few bits and bobs if that'll help. Texturing isn't really my forte and I've still got to do the MiG-15... LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] HUD AGL ladder/Elevation display problem
Hello all, I'm really replying to Curt's posting on the cvs-logs list re the HUD AGL problem that recently appeared. This problem only seems to affect the agl ladder on the primary HUD and the Elevation value displayed on the reduced HUD. The /position/altitude-agl-ft property is still being updated correctly and controllers that use this property still work ok. The agl ladder/elevation values seem to be initialised correctly at start-up but then appear to synch with the altitude ladder, as though the code treats the agl as an offset and then updates from the altitude. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Odd beige lines
On Sunday 02 Oct 2005 20:51, Alex Perry wrote: > In the southern california deserts, there are beige lines > wandering around the countryside that randomly cross the brown > road lines. The road layout makes sense, but I can't figure > out what the beige lines are supposed to be; their paths don't > match obvious landscape features. If they're supposed to be > streambeds, they're extremely conspicuous compared to real > life and sometimes go up hillsides. > I'm pretty sure that they're railway lines. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2 Questions: Terrain data? Flight Sim
On Thursday 29 Sep 2005 15:05, Mike Kopack wrote: > > Gosh I don't know, a Piper Cub UAV would be pretty > > impressive. :-) Michael Selig has a screenshot of one on his > > web page, so he might know where you can get yourself a UAV > > 3D model. Google "uiuc selig flightgear" > > > > Best, > > > > Jim > > Jim, > > I did as you suggested, and it appears he has a UAV on there, > but all of the aircraft are for a VERY old version of FG > (0.7.2) and examination of the files shows that they're not > even close to the same sort of format that the 0.9.8 codebase > uses. Bummer! > > Anyone else have any ideas or could they tell me how to get > the predator model from flightsim.com 's file library > converted over to work on FG. Heck, at this point, if somebody > could do the conversion for me I might even be able to get my > company to kick some $$$ your way (although we'd really prefer > an even smaller UAV model, like a Raven or a Silverfox or > Hunter or something like that.) > > --Mike How soon do you need a model? I found a small basic 3-view of a Raven and it doesn't look as though it would be too difficult to knock a simple model up. A lot depends on how much detail you need. There's not a lot of detail in the 3-view I found and there wasn't many detail photos on Google either. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Sunday 25 Sep 2005 09:12, Roy Vegard Ovesen wrote: > On Wednesday 21 September 2005 15:23, Lee Elliott wrote: > > The agl data can be pretty spiky due to terrain/scenery > > artifacts and 3d buildings/structures and using a moving > > average filter here reduces the influence of the spikes they > > produce.. > > Have you tried the noise-spike filter? Yep - that was the first thing that came to mind but I still had problems when flying over buildings and the occasional terrain intersection. It's mostly because I wanted to use high gains and output values and while the noise-spike filter seems to clip the value at the set limit the initial rate of change in the data is unaffected and the following 2nd stage PID controller still seems to see a spike. I also hit a problem using a moving-average filter on the nav1 heading error data and found that there seemed to be a permanent offset in the output. Re-loading the autopilot seemed to fix the offset and the filter then worked normally. I guessed that the problem might have been been due to the filter starting to run before the nav1 data was ready so I stuck a simple noise-spike filter in front of the moving-average filter and this seemed to cure it. This is in the MiG-15bis that I've just e-mailed to Curt. I've also tried a couple of other things in the MiG15's A/P - I've used common 2nd stage controllers for most of the altitude and heading mode 1st stage controllers. Apart from reducing the number of controllers, it seems to improve the transitions between different modes. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 Sep 2005 16:28, Curtis L. Olson wrote: > This is somewhat off topic, but in the spirit of open source > I'd like to share the tragedies as well as the triumphs ... > > http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ > > This is part of a university project I'm helping out with. We > have a backup plane and our expensive instrumentation survived > intact, so this shouldn't be a severe setback to us. > > Very high on my todo list is to build some glue code that can > take live IMU/INS/GPS data from the airplane (sent over radio > modem) to the ground station and display a live synthetic view > of the airplane using FlightGear. If I'm successful with > building the link, then the next obvious thing to try is to > fly the airplane looking only at the real time FlightGear > view, not looking at the real airplane. Beyond just being a > fun thing to try, you could imagine putting some > representation of restricted airspace in the synthetic view, > or other objects that are important to your mission ... > whether that be monitoring traffic, wild fires, surveying > damage after a storm, etc. > > Curt. Hmm... I'm getting a 504 - gateway time-out when I try to look at www.flightgear.org. (Hmm... wonders if this e-mail will get through...) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Saturday 17 Sep 2005 15:43, Paul Kahler wrote:
> On Fri, 2005-09-16 at 04:41 +0100, Lee Elliott wrote:
> > Hello List,
> >
> > I think there's a small bug in the moving-average filter in
>
> ...
>
> > xmlauto.cxx
> > else if (filterType == movingAverage)
> > {
> > output.push_front(output[0] +
> > (input[0] - input.back()) /
> > (samples - 1));
> > unsigned int i;
> > for ( i = 0; i < output_list.size(); ++i ) {
> > output_list[i]->setDoubleValue( output[0] );
> > }
> > output.resize(1);
> > }
>
> I'm not trying to flame, but why would you be using a moving
> average filter? That's the most complicated filter I've ever
> seen - it calls other functions! I always liked the simplicity
> of a low pass filter:
>
> output += (measurement - output) * gain;
>
> Using floats, doubles, or fixed point of course.
>
> No need to call a function either, just in-line it where you
> need it. Want fast convergence on startup? Just sweep the gain
> from 1.0 down to whatever the steady state value needs to be.
> I bet this is nothing new - it's probably in the code under
> "else if (filterType == IIRfilter)" or something.
>
> So why do people use moving average filters? Why does FGFS?
>
> Thanks,
> Paul
I'm trying them to smooth the input data for agl and nav1 holds.
The agl data can be pretty spiky due to terrain/scenery
artifacts and 3d buildings/structures and using a moving average
filter here reduces the influence of the spikes they produce..
I'm also trying a moving-average filter to smooth the nav1 data
at extreme range where the 'signal' is intermittent.
...and talking of agl... I've noticed that the default keyboard
command for engaging terrain-following (Ctrl-t)
sets /autopilot/locks/altitude to 'terrain-follow' but the
autopilot settings dialogue sets it to 'agl-hold'
Either one is fine... ;)
I also noticed that the agl ladder in the hud now seems to start
with the correct offset, so that it reads zero ft at the
starting airport, but then tracks the altitude ladder - starting
at zero feet alt results in them reading identically. I haven't
checked this with different aircraft yet but I'm just going to
do a quick check through my cvs archives.
LeeE
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in moving-average filter?
On Friday 16 Sep 2005 21:11, Roy Vegard Ovesen wrote: > Lee Elliot: > > Hello List, > > > > I think there's a small bug in the moving-average filter in > > xmlauto.cxx > > > > I noticed that the output from it was always out a bit and > > checking with a calculator showed that it seemed to be > > dividing by the number of samples + 1 instead of just the > > number of samples. > > > > subtracting 1 from 'samples' in line 702 seems to fix the > > problem and as 'samples' doesn't seem to be used elsewhere I > > think it's safe. Possibly implies that the number of > > samples may be one less than specified but I'm not familiar > > enough with c++ to spot it. > > You are right. I would suggest resizing input[] to (samples + > 1) instead. Change lines 654 and 661 to: > > input.resize(samples + 1, 0.0); > > That way we average over the number of samples as configured. > > Can anyone commit this?! the 'fix' in line 702 didn't feel right to me... ...better fixed up-stream. :) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bug in moving-average filter?
Hello List,
I think there's a small bug in the moving-average filter in
xmlauto.cxx
I noticed that the output from it was always out a bit and
checking with a calculator showed that it seemed to be dividing
by the number of samples + 1 instead of just the number of
samples.
subtracting 1 from 'samples' in line 702 seems to fix the problem
and as 'samples' doesn't seem to be used elsewhere I think it's
safe. Possibly implies that the number of samples may be one
less than specified but I'm not familiar enough with c++ to spot
it. The amended code segment is pasted below.
else if (filterType == movingAverage)
{
output.push_front(output[0] +
(input[0] - input.back()) /
(samples - 1));
unsigned int i;
for ( i = 0; i < output_list.size(); ++i ) {
output_list[i]->setDoubleValue( output[0] );
}
output.resize(1);
}
note the line break due to wrap just in front the amended code.
LeeE
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Segfaults with real weather fetch
On Thursday 15 Sep 2005 18:36, Vivian Meazza wrote: > Lee Elliott > > > since updating from cvs yesterday I now seem to get > > segfaults whenever I try to use real-weather-fetch. > > > > Anyone else? > > Everybody else: it's a known bug in 3dClouds which causes > YASim to fail. > > We await a fix from Harald. > > Just don't use real-weather-fetch until the fix is available. > > Regards > > Vivian Ta - and AJ. That one didn't register when I must have seen it in earlier posts. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Segfaults with real weather fetch
Hello all, since updating from cvs yesterday I now seem to get segfaults whenever I try to use real-weather-fetch. Anyone else? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
On Wednesday 14 Sep 2005 18:03, Curtis L. Olson wrote: > I have a question I'd like to toss out to the group for > discussion/comment. > > What would people think of abandoning our mailing lists and > converting over to online/web-based forums? > > - People would only have to subscribe once and they could > access all the *Gear forums. > > - I'm getting really sick of spam. I think we do a pretty > good job of protecting the list members themselves, but the > list admins get continually pummeled with spam rates measured > in messages per hour and sometimes messages per minute ... > > If we would like to move towards using forums instead of > mailing lists: > > - Should we manage the forums ourselves on our own FG servers? > > - Should we use some other forum hosting service? > > - Should we piggy-back off of a place like avsim.com (which > already has one general FG forum.) > > - I generally favor the idea of local admin control so we can > set up the various sub forums exactly how we like, but that > means additional setup and maintenance efforts on this end. > > - If we run our own forum software, does anyone have any > recommendations. (Bearing in mind that right now, mysql is > hopelessly hosed on our FG servers and a complete purge and > reinstall has not fixed it.) Are there any mainstream, > quality forum packages that don't require mysql? > > Curt. I've used a 'beehive' based forum that was flexible and nice to use. Needs mysql tho... However, I personally find that forums invariably end up with too much graphics in them and take too much time to go through. I find mailing lists much quicker to deal with and certainly a lot easier to search but spam is a real pain in the posterior - I get a couple of hundred spam e-mails per day. Nearly all of them use spoofed sender ids, so a large percentage are bounces (doh! - when will mail admins stop forwarding this crap and just dump it). Trouble is, if you want to be contactable your address is going to be 'harvested' and spam-bombed. Hmm... not much help here really:( LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Turbine Engine(Concorde, Hunter and Citation Information Needed)
On Sunday 04 Sep 2005 04:03, Jim Alberico wrote: > > > Would it be a first if FlightGear implemented a real-time > > > AI flocking bird hazard? ;) > > > > > > Dave Martin > > > > Anyone got any bird 3-views? > > > > ;) > > > > LeeE > > Not exactly a 3-view, but there is a well-done open source > game called Scorched3d that has 3D flocking objects amusingly > called "boids". Boid types are bat, seagull, AH-64, and F-18. > Go figure! Each has a 3D mesh and a bitmap skin. > > These flocking objects have no role other than eye candy, but > they are cool. The whole game has lots of great eye candy and > fun physics. > > Jim A > > (p.s., it's long evolved from the old Scorched Tanks game I > used to play on my Amigas years ago!!) I'll have a butchers at it. I thought about trying to do some birds a while ago and figured that even a simple 3d model was probably unnecessary - a few rectangles, suitably textured and animated, should do. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter and Citation Information Needed)
On Saturday 03 Sep 2005 19:02, Dave Martin wrote: > On Saturday 03 September 2005 17:43, Vivian Meazza wrote: > the deal? :) > > > No idea. I suppose flameouts and relights could enliven a > > dull "mission". Then we could do compressor surge, and bird > > strikes ... nah, forget it :-) > > > > Vivian > > Would it be a first if FlightGear implemented a real-time AI > flocking bird hazard? ;) > > Dave Martin Anyone got any bird 3-views? ;) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Real weather fetch stops FG from starting
On Monday 15 Aug 2005 08:55, Erik Hofman wrote: > Lee Elliott wrote: > > I've just been having a problem with FG failing to start > > when real-weather-fetch is enabled and the "METAR data is > > too old" > > This problem has been reported before. > I (or someone else) still need(s) to take a look at it. I > don't think it's that much of a problem to solve though, > probably just a matter of incrementing the error counter it > the right location. > > Erik I sort of got around it by increasing the entry in preferences.xml from 2 to 4 hours. I figured that this would let FG accept out of date reports but still use up to date ones where available. Seemed to work. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Real weather fetch stops FG from starting
Hello all, I've just been having a problem with FG failing to start when real-weather-fetch is enabled and the "METAR data is too old" At least, that's the message I'm getting when I set the log-level to warn. I thought FG would try for a while and then start with real-weather-fetch disabled if it hit any problems with it. I left it running for several minutes, waiting for it to start but all I could see were the error messages scrolling up in the terminal window and the repeated attempts by FG to get the data across my network. Would it be possible for FG to ask the user what it should do at this point? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D Cockpit view, L410 Turbolet
On Thursday 11 Aug 2005 15:38, Dave Martin wrote: > On Thursday 11 August 2005 14:23, Jon Berndt wrote: > > The red and green/blue images could be registered better in > > the post-processing phase. However, had I done that, I would > > have had to crop the images more horizontally. I didn't feel > > like doing that at the time. It was sort of a > > quick-and-dirty post-processing effort. I agree, though, > > that it would be cool to have a stereo flight simulator. > > I've got no idea on the mechanics of the visuals though - > > how that could be implemented. > > > > Jon > > I was looking into driving a stereo HMD thru FlightGear a > while back (all theory - nothing practical yet). > > One idea I had was to produce the offset visuals using a > dual-cpu system with 2 instances of FlightGear's > 'out-the-window' engine running as if the cpus were 2 > networked systems doing the same. The advantage (I presumed) > would be that the video frames would be closer to being synced > than if 2 seperate machines were used. Either 2 video cards or > one very-high performance one running 1 display per > framebuffer could be used. > > The FDM and everything else could be run a networked machine > or you could maybe step up your main system to quad cpus and > use the same 'locally-networked' trick. > > Dave Martin. If you have a high enough frame rate it might be easier to simply multiplex the views from a single instance of FG, switching the viewpoint between each eye on an alternate frame basis. You'd then need to feed the alternate frames to the left and right eyepieces in the 3d glasses and I dunno how they work - if they need two simultaneous signals you might have to buffer one frame from each pair within FG to be able to output both at the same time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
On Friday 05 Aug 2005 22:10, Curtis L. Olson wrote: > Lee Elliott wrote: > >Liked the 3 engine 747 :) > > > >The Draken is an interesting a/c - I saw the one at Duxford, > > here in the UK, and was surprised at how close to the ground > > the wing trailing edge was. When looked at from the back I > > rather thought it looked like a huge moth. > > I don't know how much more work I'll do with the National Test > Pilot School (pending the results of the current small > project) :-) but if things go well, there may be some modeling > work that needs to get done at some point. Any interest in > that sort of thing, or do you keep busy enough with your day > job and hobbies? > > The Draken is a really impressive bird, especially considering > the era in which it was designed. The US is pretty cocky > about stuff invented over here, but the Draken had some really > impressive specs for it's day. > > To be honest, I stared and squinted at the real scene for the > longest time trying to figure out if my eyes were playing > tricks on me or what. It wasn't until I got to see the full > digital picture that I figured out the 747 hump was behind the > DC-10/MD-11. :-) > > Curt. Just about all of the Swedish jets from the Tunnen onwards have been pretty interesting and capable aircraft for their day. Almost surprisingly so for such a relatively small nation. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Mojave, CA
On Tuesday 02 Aug 2005 17:09, Curtis L. Olson wrote: > In case anyone is interested in looking at airplane pictures, > I just returned from a trip to Mojave, CA (KMHV) where I got > to see a bunch of neat aviation stuff. I took some pictures > and posted them here: > > http://www.flightgear.org/~curt/Photos/KMHV/ > > Mojave is home to a lot of wind mills on the ridge overlooking > town, home to Scaled Composites (Burt Rutan/Space Ship One), > Orbital Dynamics, the Rotary Rocket (tm), an aircraft > boneyard, and the National Test Pilot School ... lots of neat > toys, aircraft restoration, research, development, and other > projects going on out there. There's also a lot of heat, > desert, tumbleweeds, and a whole lot of nothing once you get > off the airport property. > > Curt. Liked the 3 engine 747 :) The Draken is an interesting a/c - I saw the one at Duxford, here in the UK, and was surprised at how close to the ground the wing trailing edge was. When looked at from the back I rather thought it looked like a huge moth. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Tuesday 02 Aug 2005 00:01, Arnt Karlsen wrote: > On Mon, 01 Aug 2005 18:14:16 -0400, Josh wrote in message > > <[EMAIL PROTECTED]>: > > Arnt Karlsen wrote: > > > ..pass, what I learned from my own research on gpu's > > > before buying an ATI 9250 clone, is ATI are "native 24bpp" > > > and "24bpp only", where Nvidia is "1x32bpp or 2x16bpp", > > > suggesting "ATI would suck at 16bpp doing less than > > > 3x8bpp" and "at 32bpp not being able to see or make any > > > use of the top 8 bits." > > > My understanding of Nvidea is "their cards should work > > > better at 32bpp and 16bpp than at 24bpp, because 24bpp > > > wastes half a 16bpp engine." > > > > > > > > > > > >From what I understand, 24bpp is the same amount of data as > > > 32bpp. It > > > > just signifies that there is a separate alpha channel. Since > > this is not strictly 'color' the last 8 alpha bits are not > > counted in the color depth. > > ..yes, but does this impact 32bpp performance relative to > 24bpp and "not" 24bpp relative to 16bpp like it "should" on > ATI's and "should not" on Nvidea and vice versa? > > > Still, each pixel takes up 32 bits of memory. > > ..my understanding is ATI cannot do 32bpp math at all, their > gpus are "24bpp only", while Nvidea gpus does both 16bpp and > 32bpp "but not 24bpp." > Strategic gpu HW design choises made a decade or so back. > > > ATI cards do 16bpp just the same as all the other cards, 16 > > bits of color and nothing else. (red and blue get 5bpp, > > green I think is the one that gets 6bpp) > > ..true, at the same speed as they will do 24bpp, 15bpp and > possibly also 8bpp, I doubt ATI gpu's has a 3x8bpp mode, > Nvidea however talks about a 2x16bpp and an 1x32bpp mode. As Josh said, in a 32 bpp mode 8 bits are used for an alpha channel so there isn't really any 32 bpp maths to worry about. It probably makes more sense to think in terms of 3x8 bpp for 24 bit modes or 4x8 bpp for 32 bit display modes, with each 8 bit channel giving 256 levels of intensity (brightness). 8 bit and lower colour modes work differently and use an indexed palette and a look-up table of absolute rgb values. The actual colours in the palette can have any value but you're limited to a total of 256 of 'em. An 8 bit greyscale mode is essentially the same as one of the 24 bit colour modes channels except you're only dealing with absolute brightness - all colour info is ignored. 24 bpp data can be displayed on a 15 or 16 bit mode simply by discarding the least significant bits of each channel. This can produce some colour banding and other undesired artifacts but it's economical as the data requires no conversion. After 24 bpp the next commonly used colour mode is 36 bpp - 3x12 bpp. This is mainly used for print stuff. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
On Thursday 28 Jul 2005 15:15, Vivian Meazza wrote: > Dave Culp > > ... snip ... > > > The present system makes smoke/contrails by releasing AI > > objects rapidly. There are three problems with it now: > > > > 1) Orienting the objects properly. Only applies for long > > (i.e. cylindrical, > > rectangular) models. > > > > 2) Matching the release rate to the airplane's speed. > > > > 3) Making a smoke model that merges well with the others. > > I've heard (on this list) that this may be a plib > > limitation. It may require the use of a > > different visual model, like billboards or particle fields. > > > > > > On the other hand, maybe a whole new tactic is needed. > > I think Harald is working on this as an offshoot of his 3d > clouds. I'm quite sure we can't do better with the AI > ballistic approach as it stands. > > Vivian I've been wondering if Harald's clouds could be adapted for smoke, contrails, gun-puffs and touch-down smoke... It started me thinking when I saw a 'tower' of 3d clouds over some high ground and it looked like a pretty good volcano plume, and it occurred to me that it could be possible to add pretty good volcano hazards to FG. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Debian Installation
On Tuesday 26 Jul 2005 12:43, [EMAIL PROTECTED] wrote: > Hi, > > I have been trying to install the FGFS on my PC but I am > having problem to configure the DEBIAN packages on the proper > order before I start the FGFS packages installation. > > Is there a quick setup that I could use? > > I am doing the installation thru network, I downloaded the > newest Minimal Debian CD and there are not many options. > > I use a Nvidia board and it was recognized by the LINUX. > > Regards, > > FS Are you trying to install the debian packages for PLib, Simgear & FlightGear or do you want to use the cvs versions? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
On Sunday 24 Jul 2005 17:30, Erik Hofman wrote: > Lee Elliott wrote: > > p.s. Erik: someone on the user list wants to stop the > > YASim legacy engine definition message from your pa28. I > > can have a look at it if you want but I know it's really > > your baby:) > > Eh, no, It's David Meggison's model. > I have not yet created an airplane with a YASim FDM. > > Erik Oops - pardon me. Hmm... the last posting from Mr M that I have was way back in January when he said he was taking a break from FG for a while. As he also said he wanted to devote some time to the Warrior (and J3) I guess he'll sort it out at some point. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] yasim and modelling noob started to make ASK 21 Mi for flightgear
On Sunday 24 Jul 2005 00:31, [EMAIL PROTECTED]> wrote: > hello all. > > this is my first post to this mailing list. (some people might > know me from the irc channel, which i joined about a week ago > for the first time, not counting a brief visit a year ago.) i > have been following the development of flightgear for some > time now with interest. great work, folks! however as a glider > pilot (in training), i really miss (a decent FDM support for) > gliders. all right, there is the asw20 and the FDM doesn't > seem too bad either, but the thing i really missed here were > speed brakes. how are you supposed to land this thing on > target without speed brakes? > > anyway, i got more and more tempted to try and build my own > glider for flightgear. i had dreamt to model the glider i > learnt flying on for flightgear. > (http://www.alexander-schleicher.de/englisch/produkte/ask21/e_ >ask21_main.htm) someone on irc (i think it was andy) suggested > that i should take yasim for the FDM. i realized that an > essential part of yasim's solving process is the plane's > engine. the manufacturer of that glider happened to have > recently developed a powered version of it, so i went for that > instead. > (http://www.alexander-schleicher.de/englisch/produkte/ask21mi/ >e_ask21mi_main.htm) at the end of day one, i hat adapted the > j3cub FDM to represent very roughly the flight characteristics > of what i imagined a powered version of that plane would have. > as i recently had looked into blender, i took the next two > days to slap together a rough low poly model of the (still) > engine-less version of that plane as a first serious attempt > in blender modelling. > > the last few days, i fell on everybodys nerves on irc while > trying to get the FDM the way i wanted. the major thing i > tried and obviously failed to do is to get the stall behaviour > right. the thing with the ask21 is, that it never stalls > completely, part of the wing has always lift and "unstalled > airflow", so that it is impossible to get into a spin for > instance. this is optained by using a slightly different > airfoil at the wingroot than at the tip. those airfoils merge > into each other and with speed reaching "stall" speed, a small > part of the wing stalls first and the stall slowly expands > over the rest of the wing until you are not able to keep the > "nose" up any longer (that is, with fully pulled elevator) and > it just tilts gently downward again. the thing is: i can't > reproduce that behavior with a single wing definiton in yasim. > what i tried then was splitting the wing in half and adding an > mstab as the outer part of the wing. after some position > calculations (trigonometry now quite present again) i clipped > the wing to about half it's length and added mstabs with > exactly the same aerodynamic properties, just to look if it > had worked. well, it hadn't. i am experiencing the most > peculiar flightgear crashes or hangs, all occuring when the > speed of the aircraft exceeds 50 kts. i don't know where i > went wrong, but i definitely did. > > i've uploaded a package containing my aircraft FDM and 3d > model along with some documentation (README). the xml files > are commented, but mainly for my own use. could be rubbish in > there. note that i am a messie, too. i often lack > concentration, so there could be slips of the pen anywhere: > http://www.thorben-mit-th.de/files/ask21-mi-0.0.01.tar.gz > (just noticed: does anybody want a *.zip file? bug me.) > > would be glad if you could post your comments. > > thorben Have you tried playing with the subelements of the wing definition? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
On Saturday 23 Jul 2005 22:16, Erik Hofman wrote: > Lee Elliott wrote: > > How much detail do they want in the external model? > > > > It looks like a fairly clean design that shouldn't take too > > long > > > > to do. > > I just committed an early version of the SR-20 3d model > (including external hatches). I plan on improving it further > and add a 3d cockpit. > > It would be nice if someone would do the FDM and/or 2d and 3d > panel, which I won't be doing anyway. > > Erik Hi Erik & Roy I don't mind having a go at a 3d cockpit model I can get good drawings and dimensions for it. What I've been thinking recently about 3d models is that it might be best to make the panel and interior first, and then model the exterior to fit it. I say this because after making an external model that appears to fit the 3-views, if there's any real curvature to the cockpit region, it's very easy to find that you haven't enough room. I figure it should also make the cockpit view more accurate. For any aircraft that we have access to it's possible to get very accurate dimensions for the panels quite easily and without having to take many measurements - all that's really needed are some basic measured dimensions i.e. width & height plus some photographs of the panel, taken as straight-on as possible, with a reference (say two short measured lengths of thin, stiff wire at right-angles) laid against the panel. It shouldn't be too difficult to work out accurate instrument placement from that. The only problem with doing the interior this way might mean that it won't fit well into the existing model very well. LeeE p.s. Erik: someone on the user list wants to stop the YASim legacy engine definition message from your pa28. I can have a look at it if you want but I know it's really your baby:) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
On Friday 22 Jul 2005 00:49, Jim Wilson wrote: > > From: "Curtis L. Olson" [snip...] > > Apparently no one is interested in doing a Cirrus model for > > FlightGear at this time, which is fine, I was just asking, > > and just presenting a couple different options for getting > > it done. > > If no one steps up then I might take a stab at it next year. > It does look like a great project and would encourage anyone > interested in 3D modeling to give it a go. > > Best, > > Jim How much detail do they want in the external model? It looks like a fairly clean design that shouldn't take too long to do. They _don't_ want the parachute as well, do they? ;) I could probably do an external model, including the cabin space, in a couple of weeks. I still haven't got around to doing any panels yet but was planning to do one for the MiG-15 I've just started so I guess I'd have a go at one for an sr20. Would anyone else be able to collaborate on the panel? (external model and panel gpl'd for FG) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
On Tuesday 19 Jul 2005 02:02, Peter Stickney wrote: [snip...] > > But that's not the only way to do it. I've been preparing a > series of articles on supercharging reciprocating engines. > Is there any interest for me to pull some of it out and > present it here? Here may not be the best place for articles or essays but I'd certainly be interested in reading about this topic. If you can put some stuff on-line somewhere and post a url I'd love to read it. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] One bug with multiplayer...
On Saturday 16 Jul 2005 22:56, Paul Kahler wrote: > On Sat, 2005-07-16 at 22:44 +0300, Vassilii Khachaturov wrote: > > > On a side note, while testing the multiplay mode, > > > robitabu on #flightgear irc and I have discovered the > > > "Instant Replay" is also sent to all other players. Kind > > > of a nice "feature" when you want to show people stuff, > > > but also probably something you don't want all the time... > > > > > > :) > > > > That's pretty cool! it's pretty harmless though, isn't it? > > also, when people want to see others' action a lot, and one > > is lazy to do takeoffs/landings all the time, this can be a > > nice alternative to the boring AIs in single-player --- fly > > a nice circuit one time, and loop it via the network to the > > others. > > Is it possible to run FGFS as a screen saver? I think > prerecorded flights would make a really interesting screen > saver. At our local EAA meetings (chapter13) they sometimes do > slide shows before the meeting and I always thought having > FGFS up there might be cool. Either a screen saver mode or a > really long recorded demo would fit the bill. > > Paul There's not a screen-saver mode, as such, but you could script an entire flight using nasal. It would be possible to set up an aircraft so that once FG was started with that particular aircraft, the a/c would take-off, fly around, manuevour and then land, without you having to touch anything. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rutan and Scaled Composites [was code optimization]
On Saturday 09 Jul 2005 17:51, Andy Ross wrote: > Paul Kahler wrote: > > I once downloaded a Velocity and a Starship for MSFS and > > they were really fun to fly - not sure if the dynamics were > > correct at all because they really wanted to fly in a way > > thats hard to describe. OTOH I have read that canards really > > do like to fly compared to other aircraft. > > The trick of the canard is that you can arrange things such > that the canard surface stalls before the main wing. Because > it is forward of the c.g., this causes a downward pitch, thus > "saving" the pilot from a main wing stall. It's not quite > "stall proof", because it only applies to near-steady-state > changes, but it will save a dumb pilot who pulls back too hard > on the yoke. > > This would be perfectly doable in YASim, if anyone wants to > try it. Just put the hstab where it belongs and set the stall > angle appropriately. > > Andy I've had a longeze on my list for quite a while now and have been planning to do it just as you suggest re the hstab. I couldn't see any real problems with it. It'll be a while before I do anything on it though, so if anyone else wants to do one - go to it:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] UAV / FlightGear
On Friday 01 Jul 2005 21:51, Curtis L. Olson wrote: > I had an interesting day today. As I've mentioned before, I'm > helping out with a University of MN UAV project. My main > capacity was to assemble the airframe, and now I am the > primary test pilot. We are just now starting to add > instrumentation to our airplane. Today we flew (manually) > with a simple gps and radio modem on board and captured the > gps output on our ground station. We had a couple very > successful flights and captured a lot of good data. > > Right now the gps data can be stuffed into a running copy of > FG and FG will show a virtual rendition of what is going on. > That sounds really cool (and it is), however, our cheap gps > outputs data at 0.5hz (once every 2 seconds) which is very > coarse. We captured our data to a file so I can visualize > that with something like: > > fgfs --nmea=file,in,10,/home/curt/Flight4_3.txt --fdm=null > > However, position updates for an RC model at 0.5hz gives an > almost unusable display for typical manaul flying because you > can fly an entire turn and be going the opposite direction > before the next gps report comes in. > > I recall a while back, someone was working on a program to > take a 0.5 hz gps data stream and interpolate data to make > smoother visualization in FG. Is that code still floating > around and available any place? > > I have some early pictures and info about our project here: > > http://www.flightgear.org/~curt/Models/Construction/Rascal110/ > > Thanks, > > Curt. Hello Curt, The update rate for the basic e-trex should be 1Hz, though I doubt that this would be fast enough for you anyway. You're not operating the e-trex in battery-save mode are you? Battery-save mode lowers the update rate. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Sunday 26 Jun 2005 23:03, Vivian Meazza wrote: > Frederic Bouvier > > > Vivian Meazza a écrit : > > >I've just seen the new volumetric shadows. Brilliant!!! On > > > a Nvidia > > > > gForce > > > > >5200, the frame rate hit is about 10 in external view (I > > > can live with > > > > it) > > > > >and no noticeable effect in internal - perhaps 1 or 2. > > > > Yes, it is very nice. I have a drop of 10 fps ( 50 -> 40 ) > > when I enable all ( ac + ai + to ) > > > > >There's a bit of a funny with the interaction between the > > > Hurricane propeller disk and the ac shadow: it makes the > > > shadow disappear, and > > > > there's > > > > >something throwing a shadow on to the disk, which I've not > > > seen in real life, although I might not have noticed it. > > > Is there anything I can do within the ac model to tidy > > > this up? > > > > 2 stranges things that I know are inherent to the shadow > > volume technique > > > > 1. even when surfaces are smoothed, the shadows are hard and > > apply to a whole quad when a fuselage shadows itself ( try > > the A320, look at the airframe and press t to see what I > > mean ). > > 2. transparent surfaces ( the suspension chains of the > > bridges, or the metallic structures ) produce filled > > shadows. > > Yes, I can see that. The markings on the Hunter are on > separate transparent object: these throw a shadow. It seems as > if I'm going to abandon that method if shadows are to be > usable with that model. Pity; it saves a huge amount of > artwork and texture. The edges of the shadows are a bit too > hard; a little penumbra would be good > > > Let wait the hardware to catch up a hit, and we could have > > clouds and mountains casting shadows ;-) > > Nice if aircraft could throw shadow on cloud. > > Altogether it's a nice enhancement. > > V. Yep - I've used the same texturing technique on a few a/c as well:( Then again, I've already stopped using it:) It did save a lot of texture space though. Re the 1st problem Fred referred to, it seems to happen when an object puts itself in shadow. Shadows cast by other objects seem to be ok. Generally, the old shading code did a good enough job of shading each individual object in a model, according to the sun pos, so I wonder if the new shadows might work better if they were only applied to other objects, and let the old code shade each individual object... LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Sunday 26 Jun 2005 21:53, Frederic Bouvier wrote: > Vivian Meazza a écrit : > >I've just seen the new volumetric shadows. Brilliant!!! On a > > Nvidia gForce 5200, the frame rate hit is about 10 in > > external view (I can live with it) and no noticeable effect > > in internal - perhaps 1 or 2. > > Yes, it is very nice. I have a drop of 10 fps ( 50 -> 40 ) > when I enable all ( ac + ai + to ) > > >There's a bit of a funny with the interaction between the > > Hurricane propeller disk and the ac shadow: it makes the > > shadow disappear, and there's something throwing a shadow on > > to the disk, which I've not seen in real life, although I > > might not have noticed it. Is there anything I can do within > > the ac model to tidy this up? > > 2 stranges things that I know are inherent to the shadow > volume technique : 1. even when surfaces are smoothed, the > shadows are hard and apply to a whole quad when a fuselage > shadows itself ( try the A320, look at the airframe and press > t to see what I mean ). > 2. transparent surfaces ( the suspension chains of the > bridges, or the metallic structures ) produce filled shadows. > > Let wait the hardware to catch up a hit, and we could have > clouds and mountains casting shadows ;-) > > Good job again. > -Fred Yes, very nice work. I notice a little frame-rate drop but not as much as I expected (nVidia 6600 based card). I noticed problems with prop disks too. I'm fading both the props and prop disks in and out, depending on their rpm and even when the prop disk is completely faded out a shadow from the spinners is cast on them. As the disks are faded in the shadow density upon the prop disk seems to remain constant. I imagine that varying the shadow density based on the alpha channel of the texture of the object that the shadow is cast upon would not be trivial. I also noticed that the props, before being faded out, also cast a shadow upon the still faded out prop disks but don't once they're de-selected. I noticed a few 'artifacts' in the shadows cast upon the aircraft itself but I think most of these were due to tiny irregularities in the model geometry that are normally not noticed due to smoothing i.e. tiny concavities in the model which may not be obvious but which cast shadows. The shadow of the tailfin moving across the tailplanes is fine though, as was the shadow of the wing trailing edge upon the partially deployed flaps. I don't think I've seen the problem Fred reported of entire quads being shadowed incorrectly (hmm - Fred, are you referring to four-sided polys here? Any polys with > 3 sides appear to be triangulated before rendering. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Last Driver NVIDIA 7667:==>approach lighting "rabbit" DO NOT Conflict with Graphic Card
On Friday 24 Jun 2005 18:23, Gerard Robin wrote: > Le vendredi 24 juin 2005 à 18:53 +0200, Gerard Robin a écrit : > > Le mercredi 22 juin 2005 à 17:55 +0200, Gerard Robin a écrit : > > > > A better fix might be to use point lights for VASI/PAPI > > > > rather than commenting them out entirely. > > > > > > > > Here's my theory. VASI/PAPI and the get > > > > drawn with larger antialiased points. These are > > > > "unaccelerated" for the > > > > > > > > > > > > > > > > I suspect that they are intentionally making antialiased > > > > points artificially slow in their latest drivers to > > > > prevent people like us from getting away with using just > > > > a few here and there without upgrading to really high > > > > priced Quadro cards. > > > > > > > > I could be wrong ... maybe there's a valid technical > > > > reason, but this sounds more like a "marketing" thing > > > > than a driver bug from my perspective. > > > > > > > > Curt. > > > > > > Thank Curt > > > that explanation , is the good one. > > > Gerard > > > > I am Just Ending the test of the last NVIDIA driver 7667 > > june-22 The slowness in FG with VASI as vanished. > > That new driver seems right when working with existing > > OpenGL functionalities used by FG. > > I just notice a global speed a bit less than before (7664, > > without VASI). > > Good NEWS. > > I forgot to say, that message is only dedicated to FG users, > Others 3D textured applications are less good with that new > driver. I'll echo Curt - thanks for checking it out and passing the info onwards. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Wind and Turbulence
On Sunday 19 Jun 2005 15:22, Jon Berndt wrote: > What does FlightGear do in the way of wind and turbulence? I > assume that winds are set in FlightGear in NED coordinates and > that those change slowly? Turbulence is modeled in the FDMs, > but parameters are passed in? FlightGear does not model > turbulence itself, does it? > > I am debugging the gear jittering in JSBSim and I am seeing > windNED spike every so often and I have commented out > turbulence code in JSBSim, so I am wondering if these wind > spikes are coming from FlightGear. > > Jon It's possible that you're seeing the same problem I have here where the wind (and visibility) gets set incorrectly on an apparently random basis. I've reported it a few times now but no-one else seems to be experiencing, or perhaps noticing it. In one or two of the more recent a/c I've done I've included a simple 2d instrument to show the wind speed and direction and this makes it clearly apparent when the wind (and visibility) setting are incorrect. does anything happen if you open the weather settings dialogue and repeatedly apply the settings? (you don't need to change any of the settings for the conditions to change) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
On Friday 17 Jun 2005 20:02, Harald JOHNSEN wrote: > I have started to add some volumetric shadows in Flightgear. > It uses the standard stencil method to count shadow volume > (let me know if you want an implementation > without stencil, it can also be done with the alpha buffer). > A few days ago I thought that it would be overkill for the > processor or the graphic card to add this effect, but with > a few optimisations the impact on frame rate - while still > noticeable - is acceptable. > I can render the Concorde with a debug build so all is not > lost if your computer is not 10 years old. > Some screenshots here : > http://sites.estvideo.net/tipunch/flightgear/lab/shadows.html > Let me know what you think of that. > > nb: only the AC is casting shadows atm, I still need to verify > how are handled other objects in the scene graph > (tile objects, AI objects, etc). > > Harald. That looks very very good:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] need help for convertion(importing) fron MS FS into Flightgear
On Friday 17 Jun 2005 15:24, Andy Ross wrote: > Clifford Yue wrote: > > Andy Ross wrote: > > > Re: Re: FW: Re: Fwd: FW: Re: Re: Re : Re: Re : Re: > > > > > > What was the subject again? Someone's mail client is > > > obviously very angry... > > > > any one can give me some hint about how to run the MS FS > > models under flightgear? > > Of all the messages to reply to to create a new thread, you > picked this one? ... > LOL:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re : Re: [Flightgear-devel] getting the best perfo with FG
On Friday 17 Jun 2005 09:43, Harald JOHNSEN wrote: > BONNEVILLE David wrote: > >>From the Quadro FX 3000 : > > > >* 60 Hz refresh > >* vertical synchro forced > >* no AntiAlias > >* no Anisotropic filtering > >* 1280*1024 > >* 32 bpp > >* visibility 5 meters > > > > > >--- Message d'origine --- > > > >>De : "Ampere K. Hardraade" <[EMAIL PROTECTED]> > >>À : FlightGear developers discussions > >> Sujet : Re: > >> [Flightgear-devel] getting the best perfo with FG Date : > >> ven 17 jun 2005 10:11:46 CEST > >> > >>On June 17, 2005 03:17 am, BONNEVILLE David wrote: > >>>Hi again people, > >>> > >>>problem solved ! :D > >>> > >>>I've just recompiled the latest cvs of plib, simgear and > >>> FlightGear, > >> > >>turned > >> > >>>on the threads flags, and now I have a FG running up to 60 > >>> fps (i have forced the synchro with the vertical refresh). > >>> > >>>Cuold somebody explain me the way to tune FG options to get > >>> the best perfo ? visibility, threads, dynamic terrain > >>> loading ... > >>> > >>>Thanks > >>> > >>>David > >> > >>Well, 30 fps isn't that bad in my opinion, considering I > >> only have 15 fps if I > >>am lucky. > >> > >>What other options did you use beside vertical > >> synchronization? > >> > >> > >> > >>Ampere > >> > >>___ > >>Flightgear-devel mailing list > >>Flightgear-devel@flightgear.org > >>http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >>2f585eeea02e2c79d7b1d8c4963bae2d > > Your 60 Hz refresh seems too low, you should try 80-85, it > will be more confortable for your eyes. > But now that your fps is maxed you want to know how to lower > it ? ;) > > Harald. I wonder if it's running non-interlaced at that refresh... LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Opengl rendering
On Friday 17 Jun 2005 00:12, Gerard Robin wrote: > Le jeudi 16 juin 2005 à 23:01 +0200, Oliver C. a écrit : > > On Thursday 16 June 2005 20:34, Harald JOHNSEN wrote: > > > I was thinking of using some pixel shader for one or two > > > effects. This would be with the arbvp1 & arbfp1 type > > > shader. Of course I won't write them in assembler by would > > > use Cg to produce the assembler source. > > > The use or arb type program should limit the dependencies > > > on standard opengl driver. > > > > The GLSL is part of OpenGL 2.0 and NVidia has allready > > OpenGL 2.0 compliant drivers for Linux and Windows. So > > OpenGL 2.0 with GLSL is IMHO the way to go. > > > > > But before starting anything like that I first want to > > > know if : 1) people have program shader capable cards (ie > > > FX5200+ or ati9500+) No need to code lot of things if only > > > 5% of the user can see them. Normaly a good percentage > > > should have correct > > > cards (or will have in the next 6 month) but I feel that > > > some still use olders cards. > > > > I have a Geforce 4 Ti but that's not a problem, i can > > upgrade later when it makes sense. :) > > The only thing that is important for me now, is an option to > > turn it off and it must stay vendor neutral and > > crossplatform compatible. So, please don't use specific > > OpenGL Extensions that only run on specific hardware. > > Instead use only what OpenGL 2.0 offers in a neutral way. > > > > > No need to code lot of things if only 5% of the user can > > > see them. > > > > You can be sure, that i will be able to see it some day (in > > a couple of months -> next videocard is allready planned). > > So this shouldn't hinder you. > > > > > 2) you think it's a good idea to enhance a bit some visual > > > aspect of Flightgear or you think that only simulation > > > count and all the rest is useless eye candy ;) > > > > No, i like eye candy very much and see it as an important > > factor for flightgear beside the physic code and other > > things. So when you can improve it, then please, improve it. > > :) > > > > > > > > Best Regards, > > Oliver C. > > Whe must pay attention about the New OpenGL 2.0. > You probably remember, recently i have been fighting with my > new NVidia GT6600 (OpenGL 2.0) and the last Linux driver > (OpenGL 2.0), those are perfectly working. > BUT An Exception FG, does not. > I have found in FG itself a functionality about lighting > animation which makes the problem. > It was working with the older drivers (OpenGL 1.5). > I had to patch FG, because i need a hight speed graphic card, > I don't hope any come back from NVidia. > The graphics card suplyer, don't take care with the old > releases, they answer to the instant mass request. > With FG Beware OpenGL 2.0. There is/was definite problem with the 7xxx nVidia drivers & FG. Reverting back to the 69xx drivers works ok. There is a patch to the nVidia supplied source code that will enable it to be compiled on 2.6.11 kernels. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Opengl rendering
On Thursday 16 Jun 2005 21:52, Vivian Meazza wrote: > Harald JOHNSEN > > > I was thinking of using some pixel shader for one or two > > effects. This would be with the arbvp1 & arbfp1 type shader. > > Of course I won't write them in assembler by would > > use Cg to produce the assembler source. > > The use or arb type program should limit the dependencies on > > standard opengl driver. > > > > But before starting anything like that I first want to know > > if : 1) people have program shader capable cards (ie FX5200+ > > or ati9500+) No need to code lot of things if only 5% of the > > user can see them. Normaly a good percentage should have > > correct > > cards (or will have in the next 6 month) but I feel that > > some still use olders cards. > > 2) you think it's a good idea to enhance a bit some visual > > aspect of Flightgear or you think that only simulation count > > and all the rest is useless eye candy ;) > > We should have the most realism that we can collectively > produce, that's what sets us apart from other sims. (and being > open of course). > > The advice I received here when I built demanding aircraft > models was go right ahead: the hardware will soon catch up. It > has. > > Just ensure that whatever you do can be switched off or > degrades gracefully (preferably). > > V. I think that a design philosophy that incorporates backwards compatibility is A Very Good Thing. It's harder to start with but makes things much easier and more flexible in the longer term. I guess I'm thinking about how FG is pretty monolithic and wondering how much of an over-head there might be in making it more modular. Might also be worth thinking about parallelism aspects. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
On Saturday 11 Jun 2005 16:35, Andy Ross wrote: > Lee Elliott wrote: > > One problem with using YASim for sea planes is that the > > fuselage mustn't contact the surface as this equates to a > > crash. While I was experimenting with the SR45 I found that > > I had to omit the lower fuselage deck to achieve this, which > > must then affect the flying accuracy. > > I suspect the real problem is that there weren't enough "gear" > objects. On a seaplane, anything that contacts the water is a > landing gear. Something with a realistic gear compression > should be touching the surface before the automatically > generated fuselage contact point does; this requirement isn't > any different from any other aircraft. > > FWIW, adding special behavior for contact points when they > touch water (relaxed "crash" distance and spring constant, I > guess) wouldn't be hard, provided the hard part is done: > telling the FDM when the intersection point is with "water". > > Andy Hello Andy, I didn't really have a problem with the number of gear objects - I used a soft sprung tandem layout for the main gear with firm sprung out-riggers for the floats, which were retractable. It actually seemed to work quite well, with the a/c leaning a little to one side on the float that was in the water. As the a/c accelerated for take-off it rose up out of the 'water' quite nicely:) The main problem was that one of the fuselage entries had to be omitted - I originally tried to use three entries as this matched the SR45 fuselage well. As to how much difference this made to what was largely a guess-work fdm is anyone's guess. I figured that it should be possible to model a set of wash waves and spray that could be linked to the compression too. Lot of work though. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll (more complex than at first appears?)
On Friday 10 Jun 2005 22:41, Andy Ross wrote: > theoreticle wrote: > > Let's say someone comes up with a model for the old Pan Am > > Clipper, that wants to land fully loaded with passengers and > > half loaded with fuel. The actual aircraft will sink it's > > fuselage as far as 5 feet into the water, perhaps more if > > landing in 'seas'. There absolutely must be some code to > > support sea planes landing in the water. > > The water interaction really isn't so difficult (it's just > like landing gear compression, but with an extra term for drag > due to water flow). > > The harder part is hacking the scenery subsystem to understand > which polygons are "water" and propagate this information out > through the groundcache to the FDMs. That will likely require > touching a ton of code all over the simulator; it's always the > data modelling issues that cause the problems. Algorithms are > easy. > > Andy One problem with using YASim for sea planes is that the fuselage mustn't contact the surface as this equates to a crash. While I was experimenting with the SR45 I found that I had to omit the lower fuselage deck to achieve this, which must then affect the flying accuracy. I sort of got around it by using a non-retractable gear, which at least added some drag back. one of the last things I tried was to link the brakes of this gear to the gear compression so that the braking effect reduced or increased as the hull rose or sank into the water. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
On Friday 10 Jun 2005 21:20, Ampere K. Hardraade wrote: > hmm... flying undersea. Isn't that what submarines do? > > > > Ampere That's an interesting idea:) Relative viscosity of water must be a bit like super/hyper-sonic in air but the relative speed-of-sound for the mediums won't match at all. Is there any close analogue to cavitation with propellers? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Source of aircraft info
Hello all, just found this site while looking for some aircraft info... http://www.vectorsite.net/index.html Select the 'Air Vectors' link for the aircraft articles. I've only checked a couple of aircraft but it seems like good quality stuff. I haven't looked at any of the other sections. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cannot put character with ascii code 0 into the property tree
On Thursday 02 Jun 2005 20:18, Curtis L. Olson wrote: > Ampere K. Hardraade wrote: > >On June 1, 2005 07:02 pm, Andy Ross wrote: > >>This isn't fixable without relatively major surgery, so for > >> now I think you're stuck. Maybe Melchior's suggestion of > >> storing your data in Nasal space is the best one for the > >> moment. > > > >Okay. I think I came up with something using Nasal. =) > > > >Objects in Nasal seems to get passed/assigned by reference. > > So I wrote myself a medium object, passed two I/O buffers to > > it, and have the buffers swap by the medium periodically by > > calling the function settimer(medium.update, 0). It seems to > > work, and seems to be better than using the property tree as > > well. > > Hehe, when is your first release of NasalOS? :-) > > Curt. How about calling the shell (g)nash? :) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
On Tuesday 31 May 2005 18:24, Lee Elliott wrote: > On Tuesday 31 May 2005 00:44, Curtis L. Olson wrote: > > Lee Elliott wrote: > > >Can anyone confirm that terrasynch is currently working? > > > > Hmmm, the master scenery server looks like it may have gone > > down ... I can't ping it or log into it right now. It's > > going to have to wait until tomorrow am before I'll be near > > the machine to look at it though. > > > > Curt. > > Hello Curt, > thanks for checking. I think I've got everything right at my > end but I'll not know for sure until it works:) > > LeeE Yep - seems fine now - thanks. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
On Tuesday 31 May 2005 00:44, Curtis L. Olson wrote: > Lee Elliott wrote: > >Can anyone confirm that terrasynch is currently working? > > Hmmm, the master scenery server looks like it may have gone > down ... I can't ping it or log into it right now. It's going > to have to wait until tomorrow am before I'll be near the > machine to look at it though. > > Curt. Hello Curt, thanks for checking. I think I've got everything right at my end but I'll not know for sure until it works:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
On Monday 30 May 2005 00:03, Lee Elliott wrote: > On Sunday 29 May 2005 17:27, Lee Elliott wrote: > > Hello all, > > > > I've just tried to use terrasynch for the first time but I'm > > getting connection time-outs. > > > > I _think_ I've got it set up and running correctly at this > > end but I don't know how to test that the repository I'm > > trying to connect to is ok. > > > > (I'm using --nmea entries here - one for Atlas and the other > > for terrasynch, using different ports of course, and I can > > see the rsynch commands being issued for the correct > > locations) > > > > Can anyone confirm that scenery.flightgear.org is working > > ok? > > > > TIA > > > > LeeE > > Still no-go using the default rsynch source compiled into > terrasynch. > > I've been looking for alternate sources but haven't found any > yet - are there any? and if so, how do I specify them? > > Thanks again. > > LeeE Can anyone confirm that terrasynch is currently working? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel]Re:[Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
On Monday 30 May 2005 13:21, Jon Stockill wrote: > Jon Berndt wrote: > >>>Is the "ground cache" for the benefit of the FDM? > >> > >>The FDMs are currently the only users of the groundcache, > >> and yes, they benefit from it. A lot. > >> Per-wheel/contact-point ground awareness hadn't been done > >> before Mathias implemented the ground cache. And probably > >> it would have been a big performance problem to constantly > >> do intersection test with the whole tile. Still, I didn't > >> mean to blame the problems on the FDMs. I just > > > > What I was curious about was if per-wheel contact point > > checking was being done when it doesn't need to be done - > > that is, when the aircraft isn't even close to the ground? > > I'm not certain the area that the ground cache covers, but I > suspect it has applications beyond just contact points. ISTR > Lee was wanting to know ground elevation a distance ahead of > the aircraft for the terrain following mode of the TSR2s > autopilot - could this be used? > > Jon Hello Jon, well remembered:) I did give some thought to look-ahead algorithms and I think it would be possible to come up with a rolling max/min type algorithm that would only need one look-ahead sample per frame to get a good straight-line TF target agl. Gets much more complicated if turning, of course:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RC aircraft + ground view
On Monday 30 May 2005 01:02, Sam Heyman wrote: > I have finished implementing an RC UAV (2.2m span) and am now > trying to create a new view, that corresponds to the guy > standing next to the runway, near the plane. > Is there an existing view I can use and edit, or do I have to > start from scratch? I have read through quite a lot of the > past threads and didn't get much information. > > Thanks for your help, > Sam Curious - I replied to this on the FDM list - just checked the msg in my 'Sent' box but it's not come back to me yet. Oh well, computers eh? Anyway... The A-10s have what I've called a 'Drop' view. It's an additional lookat view where the view location can be 'dropped' behind the aircraft. Look in the A-10cl-set.xml or A-10fl-set.xml files for the setup. I also played with a similar Ground Observer view by using the altitude and altitude-agl values in the property tree, together with some basic Nasal, to position the view position 2m above the ground immediately below the aircraft. However, I had some problems with the near-plane clipping and didn't progress with it. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with Terrasynch
On Sunday 29 May 2005 17:27, Lee Elliott wrote: > Hello all, > > I've just tried to use terrasynch for the first time but I'm > getting connection time-outs. > > I _think_ I've got it set up and running correctly at this end > but I don't know how to test that the repository I'm trying to > connect to is ok. > > (I'm using --nmea entries here - one for Atlas and the other > for terrasynch, using different ports of course, and I can see > the rsynch commands being issued for the correct locations) > > Can anyone confirm that scenery.flightgear.org is working ok? > > TIA > > LeeE Still no-go using the default rsynch source compiled into terrasynch. I've been looking for alternate sources but haven't found any yet - are there any? and if so, how do I specify them? Thanks again. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problems with Terrasynch
Hello all, I've just tried to use terrasynch for the first time but I'm getting connection time-outs. I _think_ I've got it set up and running correctly at this end but I don't know how to test that the repository I'm trying to connect to is ok. (I'm using --nmea entries here - one for Atlas and the other for terrasynch, using different ports of course, and I can see the rsynch commands being issued for the correct locations) Can anyone confirm that scenery.flightgear.org is working ok? TIA LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Saturday 28 May 2005 12:54, Jim Wilson wrote: > >That's correct. See: >http://baron.flightgear.org/pipermail/flightgear-users/2004-July/008234.html > >I applied that patch or something just like that to 2.6.8 and it >worked fine. There is a risk that something else usb will stop >working since this patch undoes an earlier usb fix, but I >haven't had a problem. > >Best, > >Jim Thanks, I'll look into it. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Saturday 28 May 2005 11:23, Lee Elliott wrote: > > I'll try the the patches. Thanks. > Worked. Thanks to all concerned. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Saturday 28 May 2005 11:17, Gerard ROBIN wrote: > Le samedi 28 mai 2005 à 10:30 +0100, Lee Elliott a écrit : > > On Thursday 26 May 2005 21:35, Gerard ROBIN wrote: > > > > I > > > > > > > > > > get about 1 frame every five seconds. Same result at > > > > > > KEMT. > > > > > > > > > > > > Have looked through the nvidia forums but haven't > > > > > > seen anyone complain of problems like this. > > > > > > > > > > > > Geoff > > > > > > > > > > Thanks for that Geoff. I've already got a couple of > > > > > older drivers and I believe that all the old drivers > > > > > can still be downloaded from the archive at nVidia. > > > > > > > > > > I'll give it a go here and report back. > > > > > > > > > > LeeE > > > > > > > > I have three version here 7174, 7167 & 6629. Both of > > > > the 7nnn exhibit the same problem and 6629 won't compile > > > > here. Drat! > > > > > > > > Which kernel version are you using? I'm on 2.6.11 here. > > > > > > > > LeeE > > > > > > As far as i remember 6629 does not compile on Linux > > > greater than 2.9. > > > > Thanks, I was wondering if this might be the problem. I > > also have no joystick under 2.6.11 but I this version fixed > > a samba problem I had. Sigh... :) > > > > I know I've got some earlier 2.6 kernels where everything > > seems to work - just a question of progressively working > > backwards I guess. > > > > LeeE > > Looking at my old notes: > I can be more precise 6629 does not compile SINCE 2.6.9 > because off modification in Linux itself ===> > new__VMALLOC_RESERVE symbol it is said that you can compile > again with patch. I'll try the the patches. Thanks. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Thursday 26 May 2005 21:35, Gerard ROBIN wrote: > > I > > > > > > get about 1 frame every five seconds. Same result at > > > > KEMT. > > > > > > > > Have looked through the nvidia forums but haven't seen > > > > anyone complain of problems like this. > > > > > > > > Geoff > > > > > > Thanks for that Geoff. I've already got a couple of older > > > drivers and I believe that all the old drivers can still > > > be downloaded from the archive at nVidia. > > > > > > I'll give it a go here and report back. > > > > > > LeeE > > > > I have three version here 7174, 7167 & 6629. Both of the > > 7nnn exhibit the same problem and 6629 won't compile here. > > Drat! > > > > Which kernel version are you using? I'm on 2.6.11 here. > > > > LeeE > > As far as i remember 6629 does not compile on Linux greater > than 2.9. Thanks, I was wondering if this might be the problem. I also have no joystick under 2.6.11 but I this version fixed a samba problem I had. Sigh... :) I know I've got some earlier 2.6 kernels where everything seems to work - just a question of progressively working backwards I guess. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Thursday 26 May 2005 22:36, Geoff Reidy wrote: [snip...] > > 2.6.11 and also can't build the older drivers, as I since > found out :( Just updated from 2.6.9 where only <= 6629 worked > properly with fgfs. Debian unstable. > > Geoff Yeah, Debian unstable here too. Our systems are probably in a near identical state. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Thursday 26 May 2005 19:56, Lee Elliott wrote: > On Thursday 26 May 2005 02:50, Geoff Reidy wrote: > > Lee Elliott wrote: > > > I'm having a strange problem that may be linked to this. > > > > > > Now when I start at KSFO, looking forward, I'm getting < > > > 1fps. Same with the heli & chase views. If I switch to > > > the tower it's the same until I start zooming in. At > > > around 15 deg fov the frame rate jumps up to around 25-30 > > > fps. Switch back to the chase view and it's back down to > > > < 1 fps. > > > > > > Incidentally, the a/c I'm checking with has slowly > > > revolving props so I can see the changes in frame rate > > > very clearly. > > > > > > Anyway, back to the chase view and rotate the view around > > > using shift and the num-pad. Shift-9 is fine - > 20 fps, > > > shift-6 < 1 fps, shift-3 > 20 fps. From 2 through to 8 > > > are all < 1 fps. > > > > > > Try KJFK. Here only one view gives problems (can't > > > remember exactly which one now though). It's also > > > apparent while using the mouse to change the view. > > > > > > Back to KSFO, tower view and try a take off - > 20 fps. > > > Try chase view and < 1 fps until just after the last of > > > the white blocks on the runway (sorry, don't know their > > > proper name) when it jumps to > 20 fps. > > > > > > It'll also happen while I'm flying - I flew out over > > > downtown SFO and was heading back to KSFO at > 20 fps but > > > then it dropped back down to < 1fps. > > > > > > I'm guessing that it's due to a scenery or random object > > > problem, as it also happened at KJFK where there're no > > > custom scenery objects, but I can't identify what it can > > > be. > > > > > > Any ideas anyone? FG is pretty unusable for me atm. > > > > > > FWIW, glxgears gives > 3900 fps here. > > > > > > LeeE > > > > I get this problem also with any of the Nvidia Linux 7xxx > > drivers. Other programs like torcs still run fine, only fgfs > > seems to be affected. > > > > I used to get 30 to 40 fps at KSFO. If I look down at the > > cockpit (still at KSFO) or up at the sky or I look to the > > right more than about 15 degrees or to the left at about 90 > > degrees it runs at normal speed. Look straight ahead and I > > get about 1 frame every five seconds. Same result at KEMT. > > > > Have looked through the nvidia forums but haven't seen > > anyone complain of problems like this. > > > > Geoff > > Thanks for that Geoff. I've already got a couple of older > drivers and I believe that all the old drivers can still be > downloaded from the archive at nVidia. > > I'll give it a go here and report back. > > LeeE I have three version here 7174, 7167 & 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Thursday 26 May 2005 02:50, Geoff Reidy wrote: > Lee Elliott wrote: > > I'm having a strange problem that may be linked to this. > > > > Now when I start at KSFO, looking forward, I'm getting < > > 1fps. Same with the heli & chase views. If I switch to the > > tower it's the same until I start zooming in. At around 15 > > deg fov the frame rate jumps up to around 25-30 fps. Switch > > back to the chase view and it's back down to < 1 fps. > > > > Incidentally, the a/c I'm checking with has slowly revolving > > props so I can see the changes in frame rate very clearly. > > > > Anyway, back to the chase view and rotate the view around > > using shift and the num-pad. Shift-9 is fine - > 20 fps, > > shift-6 < 1 fps, shift-3 > 20 fps. From 2 through to 8 are > > all < 1 fps. > > > > Try KJFK. Here only one view gives problems (can't remember > > exactly which one now though). It's also apparent while > > using the mouse to change the view. > > > > Back to KSFO, tower view and try a take off - > 20 fps. Try > > chase view and < 1 fps until just after the last of the > > white blocks on the runway (sorry, don't know their proper > > name) when it jumps to > 20 fps. > > > > It'll also happen while I'm flying - I flew out over > > downtown SFO and was heading back to KSFO at > 20 fps but > > then it dropped back down to < 1fps. > > > > I'm guessing that it's due to a scenery or random object > > problem, as it also happened at KJFK where there're no > > custom scenery objects, but I can't identify what it can be. > > > > Any ideas anyone? FG is pretty unusable for me atm. > > > > FWIW, glxgears gives > 3900 fps here. > > > > LeeE > > I get this problem also with any of the Nvidia Linux 7xxx > drivers. Other programs like torcs still run fine, only fgfs > seems to be affected. > > I used to get 30 to 40 fps at KSFO. If I look down at the > cockpit (still at KSFO) or up at the sky or I look to the > right more than about 15 degrees or to the left at about 90 > degrees it runs at normal speed. Look straight ahead and I get > about 1 frame every five seconds. Same result at KEMT. > > Have looked through the nvidia forums but haven't seen anyone > complain of problems like this. > > Geoff Thanks for that Geoff. I've already got a couple of older drivers and I believe that all the old drivers can still be downloaded from the archive at nVidia. I'll give it a go here and report back. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Tuesday 24 May 2005 22:14, Martin Spott wrote: > Wesley Alden Pegden wrote: > > glxgears gives me 700fps (as good as it's ever given me), > > [...] > > With a working OpenGL/DRI setup you typically get far more > than 1000 fps with 'glxgears'. Please run 'glxinfo' or > 'gl-info' - whatever you have on your machine - and have a > closer look at the OpenGL 'vendor', > > Martin. I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting < 1fps. Same with the heli & chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to < 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - > 20 fps, shift-6 < 1 fps, shift-3 > 20 fps. From 2 through to 8 are all < 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - > 20 fps. Try chase view and < 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to > 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at > 20 fps but then it dropped back down to < 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives > 3900 fps here. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Monday 23 May 2005 14:47, Arnt Karlsen wrote: > On Sun, 22 May 2005 23:23:49 +0100, Lee wrote in message > > <[EMAIL PROTECTED]>: > > On Saturday 21 May 2005 17:33, Arnt Karlsen wrote: > > > On Sat, 21 May 2005 10:54:30 +0100, Lee wrote in message > > > > > > <[EMAIL PROTECTED]>: > > > > The system that has the problem is fitted with an ATI > > > > 9200 256MB card and I've had to use some drivers that I > > > > got via the developers of the 3d s/w I use for their s/w > > > > to work correctly (apparently there was a problem with > > > > GL threading in the standard drivers). > > > > > > .._which_ "standard" drivers? ATI's, XFree86's or > > > X.org's? > > > > ATI's > > ..try X.org latest (or Debian Sid's XFree86 4.3.0.dfsg.1-13) > radeon driver, with DRI turned on, it should perform better > than ATI's. Now that I've moved the card out of my main W/S I can afford to try some of the other options... ...that is, once I've figured out why my frame rate now varies between 30+ fps & < 1fps ...sigh LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Saturday 21 May 2005 17:33, Arnt Karlsen wrote: > On Sat, 21 May 2005 10:54:30 +0100, Lee wrote in message > > <[EMAIL PROTECTED]>: > > On Monday 16 May 2005 23:47, Lee Elliott wrote: > > > On Monday 16 May 2005 13:42, Curtis L. Olson wrote: > > > > Dave Culp wrote: > > > > >>>>MenuBar->View->Rendering->Enable 3d clouds > > > > >> > > > > >>I can't get the new 3d clouds to appear here either. > > > > > > > > > >Same here. I don't get 3D clouds. Using CVS from ten > > > > > minutes ago. > > > > > > > > > >I set the weather scenario to "thunderstorm" and I get > > > > > rain. I select "Enable 3d clouds" in the Rendering > > > > > options dialog and nothing happens. > > > > > > > > I'm pretty sure the new clouds don't work in 16 bit > > > > graphics mode. I have a laptop here I get to use once > > > > in a while and that has to run at 16bit graphics ... no > > > > clouds. I go down to my desktop with 24/32 bit graphics > > > > and I have clouds. > > > > > > > > Regards, > > > > > > > > Curt. > > > > > > Most definitely in 24 bpp here but still no go. > > > > > > I'll be able to test more systematically tomorrow. > > > > > > LeeE > > > > I just got everything running on a different m/c, with plib, > > SimGear & FlightGear compiled from the same cvs state as the > > m/c with the problem and the latest 3d clouds work ok. > > > > It looks like the problem is due to the graphics card & > > drivers. > > > > The system that has the problem is fitted with an ATI 9200 > > 256MB card and I've had to use some drivers that I got via > > the developers of the 3d s/w I use for their s/w to work > > correctly (apparently there was a problem with GL threading > > in the standard drivers). > > .._which_ "standard" drivers? ATI's, XFree86's or X.org's? ATI's LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Monday 16 May 2005 23:47, Lee Elliott wrote: > On Monday 16 May 2005 13:42, Curtis L. Olson wrote: > > Dave Culp wrote: > > >>>>MenuBar->View->Rendering->Enable 3d clouds > > >> > > >>I can't get the new 3d clouds to appear here either. > > > > > >Same here. I don't get 3D clouds. Using CVS from ten > > > minutes ago. > > > > > >I set the weather scenario to "thunderstorm" and I get > > > rain. I select "Enable 3d clouds" in the Rendering options > > > dialog and nothing happens. > > > > I'm pretty sure the new clouds don't work in 16 bit graphics > > mode. I have a laptop here I get to use once in a while and > > that has to run at 16bit graphics ... no clouds. I go down > > to my desktop with 24/32 bit graphics and I have clouds. > > > > Regards, > > > > Curt. > > Most definitely in 24 bpp here but still no go. > > I'll be able to test more systematically tomorrow. > > LeeE I just got everything running on a different m/c, with plib, SimGear & FlightGear compiled from the same cvs state as the m/c with the problem and the latest 3d clouds work ok. It looks like the problem is due to the graphics card & drivers. The system that has the problem is fitted with an ATI 9200 256MB card and I've had to use some drivers that I got via the developers of the 3d s/w I use for their s/w to work correctly (apparently there was a problem with GL threading in the standard drivers). As it took quite a lot of effort to get it running and stable I've been reluctant to update so it's still using pretty old s/w, albeit with current cvs stuff. The system that works ok is fitted with a new nVidia 6600 256MB card that I've just got to replace the ATI one. Once I've replaced the ATI card on my main system I'll put it in a backup W/S as it'll be less critical to run the 3d modeller on it and I can afford to mess about with it more. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Monday 16 May 2005 13:42, Curtis L. Olson wrote: > Dave Culp wrote: > MenuBar->View->Rendering->Enable 3d clouds > >> > >>I can't get the new 3d clouds to appear here either. > > > >Same here. I don't get 3D clouds. Using CVS from ten > > minutes ago. > > > >I set the weather scenario to "thunderstorm" and I get rain. > > I select "Enable 3d clouds" in the Rendering options dialog > > and nothing happens. > > I'm pretty sure the new clouds don't work in 16 bit graphics > mode. I have a laptop here I get to use once in a while and > that has to run at 16bit graphics ... no clouds. I go down to > my desktop with 24/32 bit graphics and I have clouds. > > Regards, > > Curt. Most definitely in 24 bpp here but still no go. I'll be able to test more systematically tomorrow. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] today's 3d clouds commit
On Sunday 15 May 2005 15:50, Curtis L. Olson wrote: > Erik Hofman wrote: > > Curtis L. Olson wrote: > >> Is there something special that needs to be done to > >> activate the new 3d clouds? Before this commit I got them > >> automatically, now I am just getting the original textured > >> layer clouds. I don't see anything promising in > >> preferences.xml ... ? > > > > MenuBar->View->Rendering->Enable 3d clouds > > > > This is done because the code isn't perfect yet. > > Hmmm, does this not work with 16bit visuals depth? > > Curt. I can't get the new 3d clouds to appear here either. They used to work ok (except for the problem I posted about) but enabling them in the rendering options dialogue didn't have any effect. I also found that the rendering options dialogue became unusable if it was closed and then re-opened: it seemed to be centered on the bottom left of the screen and was transparent, except for the value/data boxes and the close button:( Checked everything in the property browser but couldn't see anything wrong. Log-level=warn didn't show anything. The 2d clouds seemed fine. I also noted that, both with and without real-weather fetch, and with each of the scenarios I tried, I was still frequently getting the incorrect wind and visibility settings for the alt & agl that I was flying at. Or even sitting on the runway, for that matter. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
On Saturday 07 May 2005 15:14, Harald JOHNSEN wrote: > Lee Elliott wrote: > >On Saturday 07 May 2005 10:04, Harald JOHNSEN wrote: > >>Lee Elliott wrote: > >>>On Friday 06 May 2005 17:29, Ampere K. Hardraade wrote: > >>>>On May 6, 2005 10:06 am, Karsten Krispin wrote: > >>>>>If you bank your plane the clouds will move in the > >>>>> opposite direction as you turn > >>>>>to - They move to the right or to the left depending > >>>>>whether you turn left or right. (And I'am not talking > >>>>> about the movements through the wind ;)). It is strange > >>>>> to discribe this - The easiest way would be you try it > >>>>> your self :) - You'll immediatly recognize what I mean. > >>>>> - Just do some hard and fast turns. Also it looks like > >>>>> if they get zoomed in or zoomed out... > >> > >>You are right there is a strange movement. It's perhaps the > >>rotation axes of the clouds that are a bit off. > >> > >>>>I know what you mean. It seems you can never go inside > >>>> the cloud. > >>>> > >>>>Perhaps visibility should be decreased to a few meters > >>>> when one is inside the clouds? > >>>> > >>>> > >>>> > >>>>Ampere > >> > >>I think that you have that effect if you fly to the border > >> of a cloud. The quads are rotated to face the camera and > >> when the quads are very near on the left or the right the > >> rotation is too big and the quad go out of sight. This will > >> be corrected. > >> > >>>Hmm... I've flown inside them pretty convincingly but I'm > >>>seeing a darkened region within the clouds, even when I'm > >>>outside them, between the horizon and what I presume to be > >>>the bottom of the sky-sphere. > >>> > >>>I can post some screen shots of inside the clouds or of the > >>>horizon problem if anyone wants. > >>> > >>>LeeE > >>> > >>>___ > >>>Flightgear-devel mailing list > >>>Flightgear-devel@flightgear.org > >>>http://mail.flightgear.org/mailman/listinfo/flightgear-deve > >>>l 2f585eeea02e2c79d7b1d8c4963bae2d > >> > >>Can you post screen shots of the darkened clouds problem ? > >> > >>Harald. > > > >Hello Harald, > > > >there's a screen-grab (425k) at > > > >http://www.overthetop.freeserve.co.uk/fgfs-screen-009.jpg > > > >I've got the weather visibility set to 3m at this > > altitude. > > > >LeeE > > > >___ > >Flightgear-devel mailing list > >Flightgear-devel@flightgear.org > >http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >2f585eeea02e2c79d7b1d8c4963bae2d > > I'm affraid I can't reproduce the problem, but I have allready > changed a few things in the rendering order of clouds to > correct the problem of scenario objects visible in front of > clouds, I changed the transparency of clouds too, they now > appear totaly transparent at the horizon. > > 3 screen shots, visibility set to 3, clouds visibility > set at 3 different ranges : > http://sites.estvideo.net/tipunch/flightgear/images/fgfs-scree >n-025.jpg > http://sites.estvideo.net/tipunch/flightgear/images/fgfs-scree >n-026.jpg > http://sites.estvideo.net/tipunch/flightgear/images/fgfs-scree >n-027.jpg > > another screen shot from another view : > http://sites.estvideo.net/tipunch/flightgear/images/fgfs-scree >n-029.jpg > > Harald. I think you may be a bit too far away in the first three shots but I'd expect to have seen the problem in the last one, on the left hand side. The region that's getting darkened on my system is definitely outlined by the horizon, along the bottom, but I'm not sure what matches with the top. There just seems to be a 'gap' between the top of the horizon and the bottom of the sky. Incidentally, I was wrong about the visibility setting I have for that altitude - it is actually 2m. This could just be a problem with the video card driver sigh... LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
On Saturday 07 May 2005 10:04, Harald JOHNSEN wrote: > Lee Elliott wrote: > >On Friday 06 May 2005 17:29, Ampere K. Hardraade wrote: > >>On May 6, 2005 10:06 am, Karsten Krispin wrote: > >>>If you bank your plane the clouds will move in the opposite > >>>direction as you turn > >>>to - They move to the right or to the left depending > >>>whether you turn left or right. (And I'am not talking about > >>>the movements through the wind ;)). It is strange to > >>>discribe this - The easiest way would be you try it your > >>>self :) - You'll immediatly recognize what I mean. - Just > >>> do some hard and fast turns. Also it looks like if they > >>> get zoomed in or zoomed out... > > You are right there is a strange movement. It's perhaps the > rotation axes of the clouds that are a bit off. > > >>I know what you mean. It seems you can never go inside the > >>cloud. > >> > >>Perhaps visibility should be decreased to a few meters when > >>one is inside the clouds? > >> > >> > >> > >>Ampere > > I think that you have that effect if you fly to the border of > a cloud. The quads are rotated to face the camera and when the > quads are very near on the left or the right the rotation is > too big and the quad go out of sight. This will be corrected. > > >Hmm... I've flown inside them pretty convincingly but I'm > > seeing a darkened region within the clouds, even when I'm > > outside them, between the horizon and what I presume to be > > the bottom of the sky-sphere. > > > >I can post some screen shots of inside the clouds or of the > >horizon problem if anyone wants. > > > >LeeE > > > >___ > >Flightgear-devel mailing list > >Flightgear-devel@flightgear.org > >http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >2f585eeea02e2c79d7b1d8c4963bae2d > > Can you post screen shots of the darkened clouds problem ? > > Harald. Hello Harald, there's a screen-grab (425k) at http://www.overthetop.freeserve.co.uk/fgfs-screen-009.jpg I've got the weather visibility set to 3m at this altitude. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] new 3d clouds - strange movement
On Friday 06 May 2005 17:29, Ampere K. Hardraade wrote: > On May 6, 2005 10:06 am, Karsten Krispin wrote: > > If you bank your plane the clouds will move in the opposite > > direction as you turn > > to - They move to the right or to the left depending > > whether you turn left or right. (And I'am not talking about > > the movements through the wind ;)). It is strange to > > discribe this - The easiest way would be you try it your > > self :) - You'll immediatly recognize what I mean. - Just do > > some hard and fast turns. Also it looks like if they get > > zoomed in or zoomed out... > > I know what you mean. It seems you can never go inside the > cloud. > > Perhaps visibility should be decreased to a few meters when > one is inside the clouds? > > > > Ampere Hmm... I've flown inside them pretty convincingly but I'm seeing a darkened region within the clouds, even when I'm outside them, between the horizon and what I presume to be the bottom of the sky-sphere. I can post some screen shots of inside the clouds or of the horizon problem if anyone wants. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with steering plane o WinXP
On Friday 06 May 2005 02:12, Tymoteusz "Puciek" Paul wrote: > Well i got problem with flight gear on win xp, (amd athlon xp > 2600, 1,9ghz, 512 mb ram, ati radeon 9550, no joystick > installed or plugged). > When i start fly (after choosing plain, airport, setting that > i use keyboard) the plain is going forward it self, and, > usualy it rotate left or right (on helicoprtes he can even > make more han 360 degre rotate without aking off ground.) it > happends on all plains. When i start a plain, i need to manu > all time to steer formward, other way adter some meters i'm > out of starting road +_+ > I don't know why this happend, and this make me less happy :( What aircraft have you tried? Could you try an automatic take-off in the B-52F? Select the B-52F and the default airport settings. When FG has started press Shift-P and then 's' to get the 'mini-panel'. Either use Ctrl-b on the keyboard or click on the 'BRAKES' indicator on the panel (to release the parking brake) and then click on 'TO' on the 'AP Mode' instrument. Does the B-52F start a take-off roll along the runway? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Weather settings problems
Hello all, I'm experiencing some problems with the weather behaviour. Specifically, the problems are with the wind and visibility settings. Without using real-weather fetch, when I start on the runway, eg. at KSFO, the wind speed is frequently 6 kts i.e. second boundary layer instead of the first boundary layer of 3 kts. The visibility also matches that for the second boundary layer too. If I use the weather settings gui and (re) apply the existing settings the weather _may_ be corrected, or it may not. Repeated clicking on 'Apply' can often result in toggling between the two settings. Anyway, after taking off the wind and visibility effects are interpolated but frequently it's to the wrong target. For example it's possible to end up with 30 kt winds and the corresponding visibility for the 9000ft level while around 800 ft asl. It's possible to get the weather corrected again by using the weather settings gui but it usually takes a lot of clicks on Apply to get it right. Even more annoying is that very often, clicking on 'Ok' to close the gui results in the weather being set incorrectly again. You can probably imagine how annoying this is :) I think I've already reported this before, when I first experienced it on my systems, but I've now seen it on two windows systems, running from the pre-compiled binary and also when using the real-weather fetch. Has anyone else seen this problem? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Bump-mapping ground textures
Hello all, just curious - are the ground textures bump-mapped? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
On Wednesday 20 April 2005 19:41, Dave Culp wrote: > > What happens if you: start FG, display the hud, put the > > mouse into control mode, make a half deflection of the > > control surfaces, so that none of them hit their end-stops, > > and then hit F3? Do the controls move back to their > > centered position or do they end up randomly placed? > > When I hit F3 the cursor goes to the bottom-left of the > screen. The ailerons and elevator are displaced. If I find > the new neutral position and right-click three times to > re-enter control mode, then the cursor re-centers. > > So, F3 causes the cursor to displace very far. When the > screen capture is complete the model has already started > tumbling. > > Dave Couple of points to bear in mind: 1. I've only tried with the a/c stationary on the ground and this may make a difference. 2. when I looked at the screen shot I noticed that the controls were in the deflected position, so the pointer, and therefore the controls were re-centered after the screen shot data had been collected. What happens after the screen shot data is collected? The save dialogue pops up. But if your pointer isn't being re-centered but moved to the bottom left corner... Hmm... Well, they're both candidate locations for re-setting the pointer. P.S. Just spotted Curt's and Norman's messages. I didn't notice if the pointer was visible when I tested earlier so I just did another screen shot while the mouse was in control mode and found that the pointer wasn't visible at all. Guessing: The pointer is temporarily disabled when a screen capture is done, and is then reset afterwards. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
On Wednesday 20 April 2005 19:41, Dave Culp wrote: > > What happens if you: start FG, display the hud, put the > > mouse into control mode, make a half deflection of the > > control surfaces, so that none of them hit their end-stops, > > and then hit F3? Do the controls move back to their > > centered position or do they end up randomly placed? > > When I hit F3 the cursor goes to the bottom-left of the > screen. The ailerons and elevator are displaced. If I find > the new neutral position and right-click three times to > re-enter control mode, then the cursor re-centers. > > So, F3 causes the cursor to displace very far. When the > screen capture is complete the model has already started > tumbling. > > Dave Hmm... Where does the cursor move in 'normal' mode when you hit F3? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
On Wednesday 20 April 2005 18:56, Lee Elliott wrote: > On Wednesday 20 April 2005 15:39, Dave Culp wrote: > > > >It only happens when the mouse is in "flight control > > > > mode", indicated by the cursor having a crosshairs > > > > shape. If I first right-click to put the mouse into > > > > "pointer mode", indicated by the standard arrow cursor, > > > > then the screen capture has no effect on the fdm. > > > > > > Perhaps something relating to the screen capture is > > > "reseting" the mouse position? Sounds like you might be > > > onto a subtle bug under these specific circumstances. > > > You could also turn on the HUD and instantly see what > > > happens to the control positions. > > > > Yes, the controls slew very far. I was able to recover the > > airplane by finding a new neutral position and then > > right-clicking three times to re-enter "flight control > > mode". > > > > Dave > > Hmm... (bearing in mind that I'm about a week or so behind > current cvs) with the mouse in 'normal' mode i.e. using > joystick control input, hitting F3 moves the mouse pointer to > the center of the screen. > > However, when I put the mouse into control mode, deflect the > flight control surfaces and then hit F3 the mouse pointer is > not moved, the controls stay where they were and continue to > respond correctly to subsequent mouse movements. > > I'm updating now and I'll try again after I've re-compiled. > > I tried all this with the a/c just sitting at the start-up > position on the ground. > > The way that the mouse pointer is centered when in normal mode > seemed sort of suggestive. > > What happens if you: start FG, display the hud, put the mouse > into control mode, make a half deflection of the control > surfaces, so that none of them hit their end-stops, and then > hit F3? Do the controls move back to their centered position > or do they end up randomly placed? > > LeeE Right! Just updated my cvs, recompiled and when I now hit F3, even while the mouse is in control mode, the mouse pointer is re-centered on the screen. I tried what I suggested just above and found that the controls were re-centered, along with the mouse pointer. If you've moved the mouse around quite a bit before hitting F3 then it's likely that you'll have hit the control limits at some point and then, when the pointer is re-centered, the controls will have an offset. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] screen capture causes loss of control
On Wednesday 20 April 2005 15:39, Dave Culp wrote: > > >It only happens when the mouse is in "flight control mode", > > > indicated by the cursor having a crosshairs shape. If I > > > first right-click to put the mouse into "pointer mode", > > > indicated by the standard arrow cursor, then the screen > > > capture has no effect on the fdm. > > > > Perhaps something relating to the screen capture is > > "reseting" the mouse position? Sounds like you might be > > onto a subtle bug under these specific circumstances. You > > could also turn on the HUD and instantly see what happens to > > the control positions. > > Yes, the controls slew very far. I was able to recover the > airplane by finding a new neutral position and then > right-clicking three times to re-enter "flight control mode". > > Dave Hmm... (bearing in mind that I'm about a week or so behind current cvs) with the mouse in 'normal' mode i.e. using joystick control input, hitting F3 moves the mouse pointer to the center of the screen. However, when I put the mouse into control mode, deflect the flight control surfaces and then hit F3 the mouse pointer is not moved, the controls stay where they were and continue to respond correctly to subsequent mouse movements. I'm updating now and I'll try again after I've re-compiled. I tried all this with the a/c just sitting at the start-up position on the ground. The way that the mouse pointer is centered when in normal mode seemed sort of suggestive. What happens if you: start FG, display the hud, put the mouse into control mode, make a half deflection of the control surfaces, so that none of them hit their end-stops, and then hit F3? Do the controls move back to their centered position or do they end up randomly placed? LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..any estimates on SW rendering?, was: World Wind as moving map display
On Tuesday 19 April 2005 02:23, Arnt Karlsen wrote: > ..so, I wanna know what kinky things I can get done in a 4 > hour run on a 320,000 BogoMips rig with 25.6GB ram, 2 TB of > swap an/or /tmp disk space, on "a 170GHz Celeron" openmosix > type single image cluster. ;o) Distributed 3d rendering:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with YASim turbine engines
On Wednesday 13 April 2005 20:44, Andy Ross wrote: > Lee Elliott wrote: > > I've got two flight models in development that use the YASim > > turbine engine and [...] the fuel flow figures are of the > > order of several hundred million gallons/hour. > > There was a units bug with the default (and currently > untunable) BSFC number. Try it now and see if that makes more > sense. > > Andy Thanks - that seems to have done the trick. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with YASim turbine engines
On Wednesday 13 April 2005 19:34, Lee Elliott wrote: > Hello all, [snip..] also ignore the remark about the fuel tanks being empty on start-up - that only happens if your throttle is even only slightly open. However, with the throttles fully closed I now notice that the fuel-flow rate is negative and is over-filling the tanks:) Did I mention that I haven't done much propeller stuff? :) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with YASim turbine engines
On Wednesday 13 April 2005 19:34, Lee Elliott wrote: > Hello all, > > This is probably one for Andy R. > > I've got two flight models in development that use the YASim > turbine engine and although they both solve and fly reasonably > (bearing in mind that they are both pre-alpha and I've done > less than 15 minutes on each) the fuel flow figures are of the > order of several hundred million gallons/hour. No - that's > not a typo - several hundred millions of gallons per hour. > > Heh - although I said that they flew reasonably well for first > attempts I should have added that this was with empty fuel > tanks - as soon as the sim starts the tanks are drained:) > > There's a .tar.gz of the TU-114 YASim config on-line at > > http://www.overthetop.freeserve.co.uk/TU-114-yasim.tar.gz > > While there's certainly a lot of guesswork in the config I > can't see, or even imagine, anything that would lead to these > fuel-flow rates. > > The second 'problem' may not be a problem at all but just a > mis-configuration in the same TU-114 config. Although I've > included contra="1" tags I still appear to be getting prop > induced roll. > > I've also included moment tags but these are un-calculated > place holder figures until I can work some proper numbers out > but I thought that these were effectively ignored if > contra="1" was included. > > LeeE Oops - ignore the prop induced roll problem - the Right Outer engine needs a crucial '-' inserted in front of the propeller y loc - doh. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Problems with YASim turbine engines
Hello all, This is probably one for Andy R. I've got two flight models in development that use the YASim turbine engine and although they both solve and fly reasonably (bearing in mind that they are both pre-alpha and I've done less than 15 minutes on each) the fuel flow figures are of the order of several hundred million gallons/hour. No - that's not a typo - several hundred millions of gallons per hour. Heh - although I said that they flew reasonably well for first attempts I should have added that this was with empty fuel tanks - as soon as the sim starts the tanks are drained:) There's a .tar.gz of the TU-114 YASim config on-line at http://www.overthetop.freeserve.co.uk/TU-114-yasim.tar.gz While there's certainly a lot of guesswork in the config I can't see, or even imagine, anything that would lead to these fuel-flow rates. The second 'problem' may not be a problem at all but just a mis-configuration in the same TU-114 config. Although I've included contra="1" tags I still appear to be getting prop induced roll. I've also included moment tags but these are un-calculated place holder figures until I can work some proper numbers out but I thought that these were effectively ignored if contra="1" was included. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Help with B-29
On Saturday 19 March 2005 23:55, Josh Babcock wrote: [snip...] > > Is the sweep supposed to be the LE or the .25% chord? > > Josh The sweep in YASim is measured at the chord mid-point. At least that's what I've been using:) It corresponds with the wing location definition and I vaguely remember this topic coming up a long time ago. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
