Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
* [EMAIL PROTECTED] (Jon S Berndt) [2002.10.24 12:08]: > On Thu, 24 Oct 2002 09:30:29 -0700 > Andy Ross <[EMAIL PROTECTED]> wrote: > >Richard Bytheway wrote: > >>We really ought to sort out the ability to disable *any* > >>console > >>output after initialisation on Windows... > > > >Is it maybe time to revisit the priority of most of the log messages? > >I mean, the vast majority of these things are debugging output for > >code that is mature and stable. Even most developers > >don't care about tile cache behavior anymore. > > I agree with this. At the least, we ought to have > different levels of output for the released binaries on > the web site - those who download the binaries are (I > would think) users who could care less about the console > output - and indeed might find it confusing. The default > there should be for less console output. Also, I feel that > some things such as the solution and landing reports are > generally useful and of interest, but perhaps they could > be made optional as well. For instance the user, after > landing, requests a landing report from a "Reports" menu. > The information can be passed up into FlightGear easily > enough from JSBSim, at least. I mentioned in another thread that I thought the log levels where configurable at runtime, and I've confirmed that they are. The property is /sim/logging/priority. It defaults to "info", but you can change it to "warn" or "alert" to quell the verbose logging. We might want to set the log level to "warn" in the base package when we make a public release. Beyond that, I agree with Andy. There are a lot of messages that just don't seem like useful "info" to most of us, but fall more under the "debug" umbrella. We hardly use the "bulk" priority; maybe we can move the "debug" messages to "bulk" and move some of the "info" messages down to "debug". And when I say "we", I mean "someone else." :-) -- Cameron Moore [ If God was a perl hacker: ($child = 'grave') =~ s/v/c/; ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: setting the heading indicator froma GPS
Tony Peden writes: > > Hmm, curious. How can you get anything but ground track from a single > receiver with a single antenna? You can't, but ... your ground track is a 'heading' if ... you keep a steady course. This is not as hard as it sounds with a GPS because most units allow you to program in a waypoint and then will give you a 'cross track error' updated at every fix so you can adjust things. Yes this begs the question as to what about wind and drift so I guess I should qualify that as to be 'course made good' instead of 'heading' but in practical terms it is the 'course made good' that matters apologies for the 'nautical' terminology and reference but this is an excellent read and 'current' for a ship has the same effect as the wind on a 'plane' when considering heading http://www.irbs.com/bowditch/ wish I knew of a book that covered using a GPS as well as this does a sextant that I could point at Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > David Megginson writes: > > Maybe a middle ground approach would be to add a branch for each > fan/strip and then underneath that, add a branch for the objects from > each leaf. This is a **long** thread :-) (and I'm behind reading the list). I'm glad you found that Curt...that's something that was bugging me when messing with the changes to that for supporting tower view. A possibile angle might be to manage the caching a little better as well. It seems that part of the problem (the shallow structure with random objects is indeed a big issue) is that when switching views the tightness of the cache forces a lot of work to be done at once. I'm wondering if building in a good sized buffer so that deletions are scheduled earlier would help smooth things out, even if these other issues are addressed. In other words schedule deletions further ahead of when they become necessary to load new tiles always leaving a good sized buffer for new loads to continue while deletions are executed. This is a throw memory at it kind of solution, but we might need to optimize for speed from multiple angles given the requirements of some of the new stuff coming in to the project. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: setting the heading indicator froma GPS
On Thu, 2002-10-24 at 09:04, Norman Vine wrote: > David Megginson writes: > > > I little while ago, I made a posting asking how a pilot in the > > Canadian far north (where magnetic compass readings are not useful) > > could reset the heading indicator in flight using a single GPS > > receiver. > > > > The answer is actually fairly simple, if you don't mind a brief course > > excursion: turn the plane until the ground speed reading on the GPS > > receiver maximizes or minimizes, and then the GPS track will be almost > > identical to your heading since you'll have a pure headwind or > > tailwind. > > > > To allow for lags in the GPS, > > Nit -- to allow for lags in the GPS computer's track computation > Most GPS's have a 'track' and a 'heading' feature. Where the > 'heading' is usually determined from a piece of the 'track' This is > computed from the X most recent locations or after at least X distance > has been traveled. The 'X' values above are ususlly 'user tunable' > even in the cheapest of sets these days. > > Note that as someone who made a living relying on precise navigation > for many years the GPS 'heading' determined in this way is to be > trusted when autopilot is engaged ONLY after a considerable period > of time or distance was traversed and no course changes were made > > Also note in my experience that this reading is NOT to be trusted > when not under autopilot control unless you have a GOOD visual > target at a distant range to help manitain a constant course. > > Also note that the heading from a GPS I was refering to previously > is an entirely different beast and will give an instantaneous accurate > reading > > YMMV but the prudent navigator . Hmm, curious. How can you get anything but ground track from a single receiver with a single antenna? > > Cheers > > Norman > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes: > David Megginson writes: > > Norman Vine writes: > > > > > Also even though we probably would be drawing more objects > > > I wouldn't expect much of a hit in that there would be lot fewer > > > culling operations > > > > When I was initially experimenting, putting all objects under a > > fan-level branch gave quite a performance hit, as well as outstripping > > the (limited, hard-coded) limit of plib's internal d-list vector > > substitute thingies. Perhaps the other optimizations we've since made > > would change that. > > Maybe a middle ground approach would be to add a branch for each > fan/strip and then underneath that, add a branch for the objects from > each leaf. I think that is how it would have to be if we just moved the LOD nodes up to the 'leafs' branch'. ie we would still have the individual triangle transform branches FWIW - I did a half hearted attempt at doing this when I tweaked the mkTransform() but I got lazy in that this requires a substantial change in the data structure, but I think its worth trying in that we will end up saving a fair bit of memory too Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes: > However there is still an issue to worry about. The random ground > cover code can create thousands of objects which means a branch node > in our scene graph with thousands of kids. plib is not exactly > efficient at deleting kids and even if you know the index, it converts > this to a pointer and then later needs to do a linear search to find > the index again. I've submitted a patch to the plib list to help with > this, but I've never had good luck getting any plib code to change. How big is the hit if you simply delete a higher-level node and let plib delete all of the branches and leaves underneath automatically? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Erik Hofman writes: > Could we all *PLEASE* forget about std:: in the code and use > SG_USING_STD() at the beginning of the file instead. That way I don't > have to correct every file that contains debugging statements like this. I'll also recommend that all primary developers currently using G++ 2.95 on Posix systems switch to G++ 3.2. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes: > Curtis L. Olson writes: > > > However there is still an issue to worry about. The random ground > > cover code can create thousands of objects which means a branch node > > in our scene graph with thousands of kids. plib is not exactly > > efficient at deleting kids and even if you know the index, it converts > > this to a pointer and then later needs to do a linear search to find > > the index again. I've submitted a patch to the plib list to help with > > this, but I've never had good luck getting any plib code to change. > > How big is the hit if you simply delete a higher-level node and let > plib delete all of the branches and leaves underneath automatically? Big. This is the big hit people were reporting and we were discussing originally ... worst case scenario we are talking 10-20-30 second pauses on a 1 Ghz class machine ... very often when you finally get control back you find that in the last 20 seconds you have crashed into the ground. It's a disappointing way to end a flight, and this problem is quite often flight ending. I have fixed my bug so that the really long pauses are eliminated, but still when plib has to slog through a huge number of kids to remove one, I see my frame rates dropping to 10-15 fps while it's slogging through those nodes. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes: > Curtis L. Olson writes: > > > However there is still an issue to worry about. The random ground > > cover code can create thousands of objects which means a branch node > > in our scene graph with thousands of kids. plib is not exactly > > efficient at deleting kids and even if you know the index, it converts > > this to a pointer and then later needs to do a linear search to find > > the index again. I've submitted a patch to the plib list to help with > > this, but I've never had good luck getting any plib code to change. > > How big is the hit if you simply delete a higher-level node and let > plib delete all of the branches and leaves underneath automatically? My guess is that we would gain more by having the random objects connected to the leaf rather then to the individual triangles. This would mean that the culling would not be as fine grained but the bookeeping overhead would be a LOT less. Of course the actual result of this change would vary depending on processor speed and GFX card but as the GFX cards are always getting better I believe this would eventually always be a WIN as long as we stay with our 'tri-fan' vs a 'tri-strip' approach in that 'fans' are usually 'optimium' for culling etc. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Solution: setting the heading indicator from a GPS
I little while ago, I made a posting asking how a pilot in the Canadian far north (where magnetic compass readings are not useful) could reset the heading indicator in flight using a single GPS receiver. The answer is actually fairly simple, if you don't mind a brief course excursion: turn the plane until the ground speed reading on the GPS receiver maximizes or minimizes, and then the GPS track will be almost identical to your heading since you'll have a pure headwind or tailwind. To allow for lags in the GPS, you will probably need to follow some organized procedure, like turning in 30 or 60 deg chunks and waiting for the gs to stabilize, then making smaller turns to home in on the highest or lowest speed. Also, obviously, this will be more difficult gusting winds near the ground or in heavy turbulence. Still, it seems simple enough, and should give you your true heading within 5deg or so most of the time (about as well as you can do with a mag compass). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Norman Vine writes: > > How big is the hit if you simply delete a higher-level node and let > > plib delete all of the branches and leaves underneath automatically? > > My guess is that we would gain more by having the random objects > connected to the leaf rather then to the individual triangles. Well a leaf by definition is the end of the line. If there were more kids connected to a leaf, then it wouldn't be a leaf, it would be a branch. Only leaves can contain geomotry, and only branches can have kids attached to them. Ultimately, what we need to do is deepen the stucture. Rather than having 1 parent with 4000 kids, we need a parent with say 50-100 sub branches, and each of those sub branches has 50-100 leaf nodes. Each ground cover object needs to be placed an oriented so it needs an individual transform node above it. Things like trees are also rotated to face the viewer so they need an additional "cutout" node (i.e. billboard) to do this. This is a lot of additional work, but one idea would be to divide up a tile into 8x8 or 10x10 smaller chunks. Each chunk would have a branch node under the top level node (64-100 sub branches.) Then each random object would get tossed into the appropriate sub branch based on it's location in the tile. This would keep the kid list sizes from becoming insanely large and would also benefit things like view frustum culling. But it is additional work to set this up, and I don't know how this would factor into David's current scheme of creating and deleting the objects on the fly. By the way, I've been meaning to ask ... if we actually are deleting these on the fly, why are we ending up a huge list of them left over when we remove the tile from the cache? Is the on-the-fly random object deletere missing them under certain circumstances? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
Hi, Thanks for your reply. > This is a known problem - Win95/98/Me are absolutely hopeless at outputting > to the console - NT/2000/XT are much quicker, and Linux quicker still. I'm not very experienced here ... but are you sure that the problem is just writing to the "terminal window" ? >From what I can see ... when it happens ... there are about 20 lines of text written (something like "... Updating Sun position ..." is among them). That is not very much ! Moreover ... If I remember well the problem seems to exist also when the "terminal window" is minimized and when FGFS runs in "full screen mode" - in both cases the "terminal window" is invisible (writing to it should be fast). I tried to "set JSBSIM_DEBUG=0", but it does not seem to help much. In any case ... is there anywhere any option in Win98SE that I could try to activate in order to get it faster ? Best regards, Jacek. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: FlightGear 0.8.0 on Win98SE
Hi, Following my yesterday's mail I gained some more experience in my "joystick" problem. It seems that the problem is related to the fact that I have two USB RamblePads, instead of only one (yesterday I said I did not observe problems with the "rudder", but ... they are there). In the evening by a chance I took my "second" RamblePad into my hands and ... FGFS was reacting ... then I took my "first" (default one) and ... it was ALSO reacting. This means that FGFS mixes these two joysticks - it reads both of them and reacts to both of them - that is why it often jumps between the "actual" joystick position and the "neutral" position - the "actual" position is the one that I set on the joystick that I have in my hands, the "neutral" position comes from the other joystick that I currently do not use ... . There is one more thing about which I would like to ask you - the default screen resolution for my small son is 800x600 (a lot of his programs can only run up to this resolution), but he would also like to run FGFS and then it would be convenient if FGFS was automatically changing the screen resolution to 1600x1200 when entering the "full screen mode". I tried "--geometry=1600x1200", but it does not do the job. Is there any option that would allow me to force the screen resolution when entering the "full screen mode" ? Thanks in advance, Jacek. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Solution: setting the heading indicator from a GPS
David Megginson writes: > I little while ago, I made a posting asking how a pilot in the > Canadian far north (where magnetic compass readings are not useful) > could reset the heading indicator in flight using a single GPS > receiver. > > The answer is actually fairly simple, if you don't mind a brief course > excursion: turn the plane until the ground speed reading on the GPS > receiver maximizes or minimizes, and then the GPS track will be almost > identical to your heading since you'll have a pure headwind or > tailwind. > > To allow for lags in the GPS, Nit -- to allow for lags in the GPS computer's track computation Most GPS's have a 'track' and a 'heading' feature. Where the 'heading' is usually determined from a piece of the 'track' This is computed from the X most recent locations or after at least X distance has been traveled. The 'X' values above are ususlly 'user tunable' even in the cheapest of sets these days. Note that as someone who made a living relying on precise navigation for many years the GPS 'heading' determined in this way is to be trusted when autopilot is engaged ONLY after a considerable period of time or distance was traversed and no course changes were made Also note in my experience that this reading is NOT to be trusted when not under autopilot control unless you have a GOOD visual target at a distant range to help manitain a constant course. Also note that the heading from a GPS I was refering to previously is an entirely different beast and will give an instantaneous accurate reading YMMV but the prudent navigator . Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
* [EMAIL PROTECTED] (Jon Berndt) [2002.10.24 08:49]: > > quickest fix > > would be to fix the SG_LOG level of that output to be disabled with > > --without-logging. The best fix might be to enable full run-time > logging > > control. I have commented out all the sun position information > > stuff in my > > own build in the past and the pauses go away. As someone else has said, > > Does SimGear not have runtime control of logging!? > > Jon Yes, it does have runtime control of logging. You turn if off by using the --without-logging configure option. I believe David M. placed the log level control into the property tree in FG a while back, but I think it may be a bitmask, so you will need to know the bit values of the different log levels in order to set it properly. Don't quote me on that though -- I haven't looked at the code or property tree in forever. -- Cameron Moore / Just think how much deeper the ocean \ \ would be if sponges didn't live there / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson wrote: > How big is the hit if you simply delete a higher-level node and let > plib delete all of the branches and leaves underneath automatically? Probably equivalent. The overhead is usually in all the per-chunk bookeeping, not the function calls. We could try playing games with operator new, I suppose. We know for a fact that all these objects will be deleted at the same time, so we can in theory do much better than a general purpose allocator. The apache webserver has a similar issue -- they have lots of code that needs to do allocation from disparate areas, but they know for a fact that all of this stuff will be obsolete once the current request finishes. So they have a "pool" API where handlers can go for memory without all the bookeeping overhead. The request just doles it out as needed and frees it all at once. Code that needs "destructor" functionality can register a callback that will fire before the free is called. In our situation, this should work pretty well. It might need some hacking in plib to make it work cleanly, though. Lots of work, but with real performance benefits. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Michael Basler writes: > > > I'll also recommend that all primary developers currently using G++ > > 2.95 on Posix systems switch to G++ 3.2. > > While I am not a primary developer I would be interested if it is possible > to build under Cygwin's GCC 3.2 already? YES - but be prepared for some pain and you will need the VERY latest Cygwin All of your C++ libraries will need to be converted over to 3.2 as the C++ ABI < application binary interface > has changed in an incompatable way. So if you aren't comfortable hacking, I suggest waiting a bit yet Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ***long*** pauses after flying a while
> I'll also recommend that all primary developers currently using G++ > 2.95 on Posix systems switch to G++ 3.2. While I am not a primary developer I would be interested if it is possible to build under Cygwin's GCC 3.2 already? Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Andy Ross writes: > David Megginson wrote: > > How big is the hit if you simply delete a higher-level node and let > > plib delete all of the branches and leaves underneath automatically? > > Probably equivalent. The overhead is usually in all the per-chunk > bookeeping, not the function calls. > > We could try playing games with operator new, I suppose. We know for > a fact that all these objects will be deleted at the same time, so we > can in theory do much better than a general purpose allocator. FWIW - I started looking into this a while ago and was thinking of having a specialized 'Pool allocator' that never really deleted the random objects but placed them on a 'freelist' from which they could be doled out. I think that this would be a big gain but probably not worth the energy until we have stabalized on a 'better' chunked data structure Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
Richard Bytheway wrote: > We really ought to sort out the ability to disable *any* console > output after initialisation on Windows... Is it maybe time to revisit the priority of most of the log messages? I mean, the vast majority of these things are debugging output for code that is mature and stable. Even most developers don't care about tile cache behavior anymore. Some stuff is still useful, like the YASim solution report and the JSBSim landing report. Other stuff is harmless, like the material loading messages which aren't very useful but at least tell you the sim isn't hung on startup. But IMHO, almost everything after the initialization pass can be pushed down to the "print only when debugging" level. Alternative, a really cool eye-candy suggestion would be to maintain the console log internally and display it with a popup console or somesuch, a-la Quake. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
On Thu, 24 Oct 2002 09:30:29 -0700 Andy Ross <[EMAIL PROTECTED]> wrote: Richard Bytheway wrote: We really ought to sort out the ability to disable *any* console output after initialisation on Windows... Is it maybe time to revisit the priority of most of the log messages? I mean, the vast majority of these things are debugging output for code that is mature and stable. Even most developers don't care about tile cache behavior anymore. I agree with this. At the least, we ought to have different levels of output for the released binaries on the web site - those who download the binaries are (I would think) users who could care less about the console output - and indeed might find it confusing. The default there should be for less console output. Also, I feel that some things such as the solution and landing reports are generally useful and of interest, but perhaps they could be made optional as well. For instance the user, after landing, requests a landing report from a "Reports" menu. The information can be passed up into FlightGear easily enough from JSBSim, at least. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Andy Ross writes: > David Megginson wrote: > > How big is the hit if you simply delete a higher-level node and let > > plib delete all of the branches and leaves underneath automatically? > > Probably equivalent. The overhead is usually in all the per-chunk > bookeeping, not the function calls. Curt's problem, though, is that his deletion code has to do a linear search in the parent for each child node to remove it; I assume that plib's internal code just iterates. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes: > > How big is the hit if you simply delete a higher-level node and let > > plib delete all of the branches and leaves underneath automatically? > > Big. This is the big hit people were reporting and we were discussing > originally ... worst case scenario we are talking 10-20-30 second > pauses on a 1 Ghz class machine ... very often when you finally get > control back you find that in the last 20 seconds you have crashed > into the ground. It's a disappointing way to end a flight, and this > problem is quite often flight ending. What I meant is that you use your scheduler a little higher up the scene tree. The dynamic objects, for example, are under separate branches for each scenery triangle; just deleting the top-level triangle branch should be good enough, rather than recursing right to the bottom of the tree and picking off the individual leaf nodes. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson wrote: > Curt's problem, though, is that his deletion code has to do a linear > search in the parent for each child node to remove it; I assume that > plib's internal code just iterates. Ah, never mind then. :) Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no allocator hack is going to fix that for us. I'm with David now; plib might have trouble doing constant-time deletion of children, but it certainly should handle a plain old recursive destruction just fine. Does it not? Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
On Thursday 24 October 2002 8:02 am, Curtis L. Olson wrote: > John Check writes: > > On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote: > > > I just fixed a bug in the tile freeing code which accounted for the > > > very long pauses people were seeing after flying for a while. > > > > Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs > > std::cout > > You can just remove that line ... left over debugging output ... > > Curt. That was my humble non programmer way of nudging you on behalf of the 3.2 users. Subtle, I know. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes:
> What I meant is that you use your scheduler a little higher up the
> scene tree. The dynamic objects, for example, are under separate
> branches for each scenery triangle; just deleting the top-level
> triangle branch should be good enough, rather than recursing right to
> the bottom of the tree and picking off the individual leaf nodes.
Unfortunately, plib doesn't work quite as you'd hope/expect. If to
remove all kids it does:
void ssgBranch::removeAllKids (void)
{
ssgEntity *k ;
while ( ( k = getKid ( 0 ) ) != NULL )
removeKid ( k ) ;
}
This means that the code finds the pointer to the first kid and
removes it individual (requiring a linear search for each element.)
This is no more efficient than my manual code, except that my manual
code can bail out after "n" deletes and leave the rest for the next
frame.
Regards,
Curt.
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
On Thursday 24 October 2002 4:30 am, Erik Hofman wrote: > John Check wrote: > > On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote: > >>I just fixed a bug in the tile freeing code which accounted for the > >>very long pauses people were seeing after flying for a while. > > > > Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs > > std::cout > > Could we all *PLEASE* forget about std:: in the code and use > SG_USING_STD() at the beginning of the file instead. That way I don't > have to correct every file that contains debugging statements like this. > > Erik > SImmer down bud. I'm for whatever works. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Andy Ross writes: > Ah, never mind then. :) > > Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no > allocator hack is going to fix that for us. I'm with David now; plib > might have trouble doing constant-time deletion of children, but it > certainly should handle a plain old recursive destruction just fine. > Does it not? No, unfortunately, it does not handle a plain old recursive destruction without having to do a linear search to find each kid first. (Granted it's a short linear search since it should find it right at the beginning of the list, but still, a lot more overhead than it would need.) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes: > Andy Ross writes: > > > David Megginson wrote: > > > > How big is the hit if you simply delete a higher-level node and let > > > plib delete all of the branches and leaves underneath automatically? > > > > Probably equivalent. The overhead is usually in all the per-chunk > > bookeeping, not the function calls. > > Curt's problem, though, is that his deletion code has to do a linear > search in the parent for each child node to remove it; I assume that > plib's internal code just iterates. No, plib's internal code has to do the same linear searching because of the way it's written. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes:
> David Megginson writes:
> > What I meant is that you use your scheduler a little higher up the
> > scene tree. The dynamic objects, for example, are under separate
> > branches for each scenery triangle; just deleting the top-level
> > triangle branch should be good enough, rather than recursing right to
> > the bottom of the tree and picking off the individual leaf nodes.
>
> Unfortunately, plib doesn't work quite as you'd hope/expect. If to
> remove all kids it does:
>
> void ssgBranch::removeAllKids (void)
> {
> ssgEntity *k ;
>
> while ( ( k = getKid ( 0 ) ) != NULL )
> removeKid ( k ) ;
> }
>
> This means that the code finds the pointer to the first kid and
> removes it individual (requiring a linear search for each element.)
>
here is some experimental code I have been playing with
which I think works and should help a biit
maybe others could test, and improve it etc.
before I submit it to PLIB
PLIB / src / ssg / ssgList.cxx
#define NHV_TEST
#ifdef NHV_TEST
void ssgList::removeAllEntities ()
{
while ( total > 0 )
removeEntity ( (unsigned int) (total-1) ) ;
}
void ssgList::removeEntity ( unsigned int n )
{
--total;
if(total-n)
memmove ( &(entity_list[n]), &(entity_list[n+1]), sizeof(ssgEntity
*) * (total-n) ) ;
if ( next >= n )
next-- ;
}
#else
void ssgList::removeAllEntities ()
{
while ( total > 0 )
removeEntity ( (unsigned int) 0 ) ;
}
void ssgList::removeEntity ( unsigned int n )
{
memmove ( &(entity_list[n]), &(entity_list[n+1]), sizeof(ssgEntity *) *
(total-n-1) ) ;
total-- ;
if ( next >= n )
next-- ;
}
#endif
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Norman,
This seems like a sensible optimization. If you remove the last entry
you don't need to do a memmove ... just decrement the total count. We
don't worry about freeing the memory until the entire list goes away,
and we never shrink list memory allocation.
But ok, while we are optimizing how about something like:
#define CURT_TEST
#ifdef CURT_TEST
void ssgList::removeAllEntities ()
{
total = 0; // :-)
}
void ssgList::removeEntity ( unsigned int n )
{
--total;
if(total-n)
memmove ( &(entity_list[n]), &(entity_list[n+1]),
sizeof(ssgEntity *) * (total-n) ) ;
if ( next >= n )
next-- ;
}
#endif
We probably need to be careful though becuase there is a doubly linked
element to the scene graph where each kid maintains a parent list, so
we need to make sure that get's addressed at the ssgKidList level.
Regards,
Curt.
Norman Vine writes:
> here is some experimental code I have been playing with
> which I think works and should help a biit
>
> maybe others could test, and improve it etc.
> before I submit it to PLIB
>
> PLIB / src / ssg / ssgList.cxx
>
> #define NHV_TEST
> #ifdef NHV_TEST
> void ssgList::removeAllEntities ()
> {
> while ( total > 0 )
> removeEntity ( (unsigned int) (total-1) ) ;
> }
>
> void ssgList::removeEntity ( unsigned int n )
> {
> --total;
> if(total-n)
> memmove ( &(entity_list[n]), &(entity_list[n+1]), sizeof(ssgEntity
> *) * (total-n) ) ;
>
> if ( next >= n )
> next-- ;
> }
> #else
> void ssgList::removeAllEntities ()
> {
> while ( total > 0 )
> removeEntity ( (unsigned int) 0 ) ;
> }
>
> void ssgList::removeEntity ( unsigned int n )
> {
> memmove ( &(entity_list[n]), &(entity_list[n+1]), sizeof(ssgEntity *) *
> (total-n-1) ) ;
> total-- ;
>
> if ( next >= n )
> next-- ;
> }
> #endif
>
>
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ***long*** pauses after flying a while
> From: [EMAIL PROTECTED] > [mailto:flightgear-devel-admin@;flightgear.org]On Behalf Of Norman Vine > So if you aren't comfortable hacking, I suggest waiting a bit yet Thanks, Norman, so I'll prefer to wait. As a close watcher of the scene you might give a shout to the list when you think it's time to convert. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes: > Andy Ross writes: > > Ah, never mind then. :) > > > > Yeah, O(N^2) deletion behavior with thousands of nodes is bad, and no > > allocator hack is going to fix that for us. I'm with David now; plib > > might have trouble doing constant-time deletion of children, but it > > certainly should handle a plain old recursive destruction just fine. > > Does it not? > > No, unfortunately, it does not handle a plain old recursive > destruction without having to do a linear search to find each kid > first. (Granted it's a short linear search since it should find it > right at the beginning of the list, but still, a lot more overhead > than it would need.) That sounds like something we should fix in plib rather than in FlightGear. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Curtis L. Olson writes: > Norman Vine writes: > > > How big is the hit if you simply delete a higher-level node and let > > > plib delete all of the branches and leaves underneath automatically? > > > > My guess is that we would gain more by having the random objects > > connected to the leaf rather then to the individual triangles. > > Well a leaf by definition is the end of the line. If there were more > kids connected to a leaf, then it wouldn't be a leaf, it would be a > branch. Only leaves can contain geomotry, and only branches can have > kids attached to them. Sorry .. of course I meant the Leaf's branch :-) > > Ultimately, what we need to do is deepen the stucture. Rather than > having 1 parent with 4000 kids, we need a parent with say 50-100 sub > branches, and each of those sub branches has 50-100 leaf nodes. Each > ground cover object needs to be placed an oriented so it needs an > individual transform node above it. Things like trees are also > rotated to face the viewer so they need an additional "cutout" node > (i.e. billboard) to do this. > > This is a lot of additional work, but one idea would be to divide up a > tile into 8x8 or 10x10 smaller chunks. Each chunk would have a branch > node under the top level node (64-100 sub branches.) Then each random > object would get tossed into the appropriate sub branch based on it's > location in the tile. This would keep the kid list sizes from > becoming insanely large and would also benefit things like view > frustum culling. This is basically what I was suggesting Currently there is a LOD node for every material for every triangle :-( IMHO we should take advantage of our existing bucketing by fans and put the LOD nodes at the 'leaf's branch' level instead of the individual triangle level. Just doing this would save us LOTS of nodes and should speed things up a bit and not require YAN set of branches :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Norman Vine writes: > IMHO we should take advantage of our existing bucketing by fans > and put the LOD nodes at the 'leaf's branch' level instead of the individual > triangle level. Just doing this would save us LOTS of nodes and should > speed things up a bit and not require YAN set of branches :-) It's not a bad idea, but a single leaf can cover a very large area; using the individual triangles cuts out at least some of the popping effects. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes: > > No, unfortunately, it does not handle a plain old recursive > > destruction without having to do a linear search to find each kid > > first. (Granted it's a short linear search since it should find it > > right at the beginning of the list, but still, a lot more overhead > > than it would need.) > > That sounds like something we should fix in plib rather than in > FlightGear. Yes, definitely. I submitted a proposed patch last night, but usually my patches get ignored. I could commit it myself, but Norman cautioned that since this is in the core of ssg, it might be worth having Steve look through it and bless it first. Don't know when/if that will happen. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson > Norman Vine writes: > > > IMHO we should take advantage of our existing bucketing by fans > > and put the LOD nodes at the 'leaf's branch' level instead of the individual > > triangle level. Just doing this would save us LOTS of nodes and should > > speed things up a bit and not require YAN set of branches :-) > > It's not a bad idea, but a single leaf can cover a very large area; > using the individual triangles cuts out at least some of the popping > effects. If anything I would think that this would cause objects to be drawn earlier hence decreasing the popping effects Also even though we probably would be drawing more objects I wouldn't expect much of a hit in that there would be lot fewer culling operations Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
Norman Vine writes: > Also even though we probably would be drawing more objects > I wouldn't expect much of a hit in that there would be lot fewer > culling operations When I was initially experimenting, putting all objects under a fan-level branch gave quite a performance hit, as well as outstripping the (limited, hard-coded) limit of plib's internal d-list vector substitute thingies. Perhaps the other optimizations we've since made would change that. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
David Megginson writes: > Norman Vine writes: > > > Also even though we probably would be drawing more objects > > I wouldn't expect much of a hit in that there would be lot fewer > > culling operations > > When I was initially experimenting, putting all objects under a > fan-level branch gave quite a performance hit, as well as outstripping > the (limited, hard-coded) limit of plib's internal d-list vector > substitute thingies. Perhaps the other optimizations we've since made > would change that. Maybe a middle ground approach would be to add a branch for each fan/strip and then underneath that, add a branch for the objects from each leaf. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 pannel lights
Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Agreed. Instruments that test whether they are powered should default to "powered" if the aircraft does not provide a suitable electrical system. This could translate to "if the required power bus property is not present". A simple default electrical system that provides just a "main bus" would only satisfy instruments that connect _directly_ to the main bus. I know that David disagrees with me on some of this, but my view is that the electrical system should provide common named outputs. Hang on ... I don't think these are mutually exclusive options. Woudn't you agree that, as well as standardising on bus names as much as possible, it would be good to smooth the transition from always-on to having a proper electrical system, by making all instruments default to "on" if they have been modified to check whether power is provided but have been plugged into an aircraft which does not yet specify any electrical system? For instance, panel lights would always check /systems/electrical/outputs/panel-light-power or something like that. And the green navigation light would check /systems/electrical/outputs/nav-lights-power and the turbofan engines' fuel flow monitors would check /systems/electrical/outputs/engines/engine[n]/monitoring-power and ... The only way I can see of making a generic simple electrical system serve this scheme is if we can somehow make "/systems/electrical/*/*-power" return true - i.e. any unknown property under a given branch returns a default value. I don't think the property mechanism has this feature at the moment, but it might be possible to add it. However, I completely agree that, to the extent possible, it makes sense to standardise the names. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
> quickest fix > would be to fix the SG_LOG level of that output to be disabled with > --without-logging. The best fix might be to enable full run-time logging > control. I have commented out all the sun position information > stuff in my > own build in the past and the pauses go away. As someone else has said, Does SimGear not have runtime control of logging!? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
On 10/24/02 at 12:48 PM Jacek M. Holeczek wrote: >> This is a known problem - Win95/98/Me are absolutely hopeless at >outputting >> to the console - NT/2000/XT are much quicker, and Linux quicker still. > >I'm not very experienced here ... but are you sure that the problem is >just writing to the "terminal window" ? >>From what I can see ... when it happens ... there are about 20 lines of >text written (something like "... Updating Sun position ..." is among >them). That is not very much ! Moreover ... If I remember well the problem >seems to exist also when the "terminal window" is minimized and when FGFS >runs in "full screen mode" - in both cases the "terminal window" is >invisible (writing to it should be fast). >I tried to "set JSBSIM_DEBUG=0", but it does not seem to help much. >In any case ... is there anywhere any option in Win98SE that I could >try to activate in order to get it faster ? Yes, I'm absolutely sure, the problem *is* writing to the console window in Win9x/Me. I run Flightgear in 98SE, NT4 and Linux, and it is absolutely, definately the console output that causes the pauses. The whole Win9x/Me console API is inherently inefficient and broken - attempting to use a scroll buffer in the console also doesn't work properly with 9x but is fine with NT. The only way to get round it is to output nothing whilst running. Unfortunately console output is currently set at compile time in Flightgear (JSBSim has some runtime control but I'm not sure if the ground contact messages can currently be turned off), and even when compiled with --without-logging the sun update stuff still gets output. The quickest fix would be to fix the SG_LOG level of that output to be disabled with --without-logging. The best fix might be to enable full run-time logging control. I have commented out all the sun position information stuff in my own build in the past and the pauses go away. As someone else has said, minimising the console window can help, but some pauses still get through IME. Curt - can we change the SG_LOG level of the sun position stuff so it is disabled by configuring with --without-logging along with the rest of the output? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
Jacek M. Holeczek wrote: ... There are two problems with the joystick. First, there are two vertical "bars/arrows" in the cockpit for the "elevators", but only the "right" one is following the joystick (the "left" one always stays in the middle) - however, if I "view" the plane from "outside" I can see that both (left and right) are moving up/down. This is correct: the right-hand indicator is indicating elevator position, but the left-hand indicator is indicating elevator trim, which can be adjusted with numeric keypad 7 and 1 (or is it 9 and 3) and possibly with joystick buttons/hat switch if the joystick configuration file says so. Second - both the "aileron" and "elevator" quite often misbehave - what I observe is that when I move them then appropriate "bars/arrows" are also moving, but every now and then the "bars/arrows" suddenly jump to the "neutral" position (and so they quite often jump between the "actual" joystick position and the "neutral" position). This can also be seen when I "view" the plane from "outside" - indeed "ailerons" and "elevators" are jumping - this makes the steering quite difficult. I monitored the joystick with an external utility and this utility does not show such problems, so it must be the "software". I did not observe such problems with the "rudder", but ... maybe it is just the "lack of experience". That sounds like both the joystick and some other input device are trying to drive the controls at the same time. The other device might be the mouse, which has three modes, indicated by three different cursor shapes. Clicking the right-hand mouse button cyles around the three modes. When the cursor is a normal pointer, it is for pointing and clicking on menus and the panel controls. When it is a cross (+), it is in control of the elevators and ailerons - perhaps that is what you have. When it is a double arrow (<=>) it controls the view direction, for looking around. Hope this helps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] segfault
Michael Selig writes: > At 10/23/02, Curtis Olson wrote: > >I'm not coming up with any good ideas ... I *thought* that if you > >didn't specify --enable-clouds3d, then none of that code was executed, > >but perhaps that's not the case ... (?) > > > > >From gdb, it's dying in the 3d cloud setup/init but beyond that I'm > >not sure why. > > Ok, given that it's in the new 3D cloud code, maybe some mods could be made > so that none of that code gets executed w/ the default, which is 3D clouds off? > > I love to see those clouds ... but I'd be happy w/ the essentials for now. In src/Main/main.cxx, line #230 we have: SkySceneLoader *sgClouds3d; However, this is just a pointer, and I can't find any place where an instance of this object is created. It seems like it couldn't work without it on any system; am I missing something here? Should we #ifdef out all the 3d cloud support (so developers can still conditionally compiled it in) until everything get's fully fleshed out? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
John Check writes: > On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote: > > I just fixed a bug in the tile freeing code which accounted for the > > very long pauses people were seeing after flying for a while. > > > Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std::cout You can just remove that line ... left over debugging output ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RE: Wing warping mistake found
Dear Jim & Arnt, I found the mistake in my FEM model. The struts are coupled to the wing by means of hinges. In my model they were rigidly attached !!. I also corrected a wrong torsional stiffness for the spars. I now find atan(127/1180) = 6.14 degrees for 80 N at the tip. Thus this is more like the results from prof. Fred Culick. If we say the pilot is only able to deflect one wing (following the results from prof. culick), we can estimate the force the pilot had to apply. If the pilot wants to deflect the wing at a EAS of 42 fps = 12.8 m/sec, he has to oppose an additional lift force of about (0.5 * 1.225 * (12.8)^2 * (3.4) * 0.3 = 102 N.) where 3.4 = is the outboard wing surface and 0.3 the additional Cl due to 6 degrees wing deflection). If we suppose this force to be at a pressure point of 2/3 the length of the outboard wing and 0.5 times the chord length, we can estimate the extra force that has to be added to the 80 N. 102 * 0.5 *2/3 = 34 N. We have 2 wings thus the total force at the wing tip is 80+34+34= 148 N. Now the pulling wire is connected at an angle of about 61 degrees. Thus the tension in the wire is about Fw = 148/cos(60) = 296 N. At last the wire is connected at an angle of 24 deg to the hip saddle . Thus the tension in the wire is about Fw = 296/cos(24) = 324 N. Tot this value should be added some losses due to friction of coarse but it represents a maximum that could occur in full flight. kind regards Marcel Wittebrood ADSE _ ADSE Consultancy and Engineering B.V. Tel. +31 (0) 23 554 2255 Fax +31 (0) 23 557 1069 Email: [EMAIL PROTECTED] Website http://www.adse.nl P.O.Box 3083 2130 KB Hoofddorp Saturnusstraat 12 2132 HB Hoofddorp The Netherlands
RE: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
Minimize the console window to minimise the effect. Richard > -Original Message- > From: David Luff [mailto:David.Luff@;nottingham.ac.uk] > Sent: 24 October 2002 11:27 am > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE > > > On 10/23/02 at 11:58 AM Jacek M. Holeczek wrote: > >There is also another "annoying" problem. Basically, the > FGFS runs very > >smoothly on my machine except that every now and then (I > don't have my > >machine at hand now, but let's say it is about every 30 seconds) it > >"stops" for a moment - I can see that in these moments there > are always a > >couple of lines written on the "terminal window" - among > them there is > >"... recalculating the sun position ...". > > > > Hi Jacek, > > This is a known problem - Win95/98/Me are absolutely hopeless > at outputting > to the console - NT/2000/XT are much quicker, and Linux > quicker still. > > We really ought to sort out the ability to disable *any* > console output > after initialisation on Windows... > > Cheers - Dave > > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > > __ > __ > This e-mail has been scanned for all viruses by Star Internet. The > service is powered by MessageLabs. For more information on a proactive > anti-virus service working around the clock, around the globe, visit: > http://www.star.net.uk > __ > __ > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
On 10/23/02 at 11:58 AM Jacek M. Holeczek wrote: >There is also another "annoying" problem. Basically, the FGFS runs very >smoothly on my machine except that every now and then (I don't have my >machine at hand now, but let's say it is about every 30 seconds) it >"stops" for a moment - I can see that in these moments there are always a >couple of lines written on the "terminal window" - among them there is >"... recalculating the sun position ...". > Hi Jacek, This is a known problem - Win95/98/Me are absolutely hopeless at outputting to the console - NT/2000/XT are much quicker, and Linux quicker still. We really ought to sort out the ability to disable *any* console output after initialisation on Windows... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ***long*** pauses after flying a while
John Check wrote: On Wednesday 23 October 2002 11:48 pm, Curtis L. Olson wrote: I just fixed a bug in the tile freeing code which accounted for the very long pauses people were seeing after flying for a while. Cool, but it breaks for gcc3.2 line 704 of tileentry.cxx needs std::cout Could we all *PLEASE* forget about std:: in the code and use SG_USING_STD() at the beginning of the file instead. That way I don't have to correct every file that contains debugging statements like this. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
