Re: [Flightgear-devel] SeaHawk
Erik Hofman wrote: I try to get it working when on the ground only by adding the following tho the YASim configuration file: control-input axis=/gear/gear[0]/wow control=EXTEND/ which checks for weight on the nosegear, but it seems to work inverted. Andy? You can play with the src0/src1/dst0/dst1 attributes to get any linear mapping you want. YASim will map the input property range [src0,src1] to the output (wing angle, in this case) range [dst0,dst1]. Input values beyond the edge get clamped to the src range. A few of the existing aircraft use this to invert axes, and the Harrier uses it more elaborately for autostabilization in hover. As for which direction the property *should* go, I dunno. :) Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SeaHawk
Erik Hofman wrote: Andy Ross wrote: You can play with the src0/src1/dst0/dst1 attributes to get any linear mapping you want. Hmm, Im not sure I can do what I want then. What is needed is a switch that says, hey if this property is false then ignore this input. Is this possible at all? Sort of. The summation of the inputs happens before final clamping. So add a mapping that takes the wow property range [0:1] to [-1:0]. The -1 that gets added in when wow is false saturates any contribution from the gear object and ensures that the final value is zero. It's a hack, but a reasonably elegant one. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
David Megginson wrote: 2. Turbulence does a linear fade-out within two wingspans of the ground. The second item is there merely to annoy Jon into implementing something more realistic. Actually, that sounds pretty good to me. Doing realistic turbulence models near the ground is essentially impossible, for all the same reasons that doing realtime fluid dynamics doesn't work. The only augmentation I can think about is that you might consider fading out only the turbulence component perpendicular to the ground. Horizontal turbulence (wind gusts) can and does happen in reality. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Turbulence redux
David Megginson wrote: As long as I have you on the line, Andy, how hard would it be for you to adapt the FGAtmosphere::Turbulence() function (in src/FDM/JSBSim/FGAtmosphere.cpp) for YASim? It looks like it should be fairly clean. You would take the per-iteration turbulence vector and add it to the wind at setup time. This happens in YASim.cxx, lines 235-237. Just move the turbulence value to somewhere accessible from the YASim FDM object (properties or whatnot) and add it in. The value gets converted into YASim's internal coordinate system later on; this part is in NED coordinates and should accept Jon's output without change (well, units might need twiddling). Really the only significant code that would have to be written is a patch to get FGAtmosphere::Turbulence() to export the velocity vector. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] cygwin problems linking fgfs.exe
Norman Vine wrote: -lopengl is there in the link line *but* it is in the wrong place i.e Win32 linkage is quite different then Unix linkage and the order of the libraries *is* important ie sybols must be resolved *after* they are used. Actually, Unix-style compilers are sensitive to link order issues too. The only thing that makes it seems simpler under Linux is that shared libraries (unlike DLL's) can export their dependency information to the linker and automatically pull in the needed libraries in the proper order. For example, many OpenGL test programs link correctly if you simply specify -lglut on the command line. All the other libraries (GLU/GL/Xext/X11/m, off the top of my head) will get pulled in automagically. Something tells me that recent versions of GCC had some new features in this area, but I can't remember what they were. Maybe the link order isn't a problem any more? I was playing with this last week while writing an automatic dependency build tool for C/C++ projects. plug mode=shameless It's actually working pretty well, if anyone wants to see it. You just drop code into a local ./src directory and it all gets compiled magically into program files that have a prog- prefix. Saves a lot of annoying Makefile/autoconf drudgery; I got a little spoiled these past four years doing Java stuff at NextBus./plug Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Viewer suggestion: acceleration effects
[Chiming in because the subject is cool, and because I'm currently stuck debugging a parser that is giving me fits and need a break.] David Megginson wrote: For the cockpit view, it might be interested to add optional acceleration effects to make up for the lack of full motion -- I think I first noticed this trick in Battle of Britain. The FDMs already publish the required information in the property tree: Why not just model the head as a highly damped spring? You'd need to fiddle with the constants a little to make it look right, but once it's fixed up it should work right for all heads. :) Almost exactly the same thing technique can be used for orientation. I distinicly remember from my few flights in light planes that turbulence (especially yaw oscillations) felt more like the plane was rotating around me. It would be (I think) really cool for the view direction to lag the planes reference frame a little in the same way that the view position lags the real position. I'd give this more general idea a shot first, before trying axis-specific code. Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
Jumping in here, just to prove to folks that I'm still alive. :) James Turner wrote: I'm pretty adamant that's the wrong way to do this, we're reduced to polling. Being anal for a second, SGPropertyNode is an interface, and therefore is supposed to make some guarantees about it's behavior. One of these is that changeListeners are correctly invoked. Sure the property picker dialog can do polling, but that's wasteful for infrequently changing values. Your heart is in the right place, but you are grossly over-optimizing. If the property picker is on the screen at all, that means it is being drawn: property by property, character by character, quad by quad and pixel by pixel every time the frame is drawn. The extra work involved in querying out the property values pales into ridiculous insignificance compared to the rest of the task. A property read involves at most a few indirections and a printf. Plib's text render (just to pick an example) needs to stitch together every byte of that string into a set of OpenGL calls which then get batched and DMA's to the video card. Noise. This is, however, a truly righteous feature. :) Andy -- Andrew J. RossBeyond the OrdinaryPlausibility Productions Sole Proprietor Beneath the Infinite Hillsboro, OR Experience... the Plausible? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance analysis
Michael Pujos wrote: Yes but there are techniques to sustain high poly count, none of which would be easy to integrate in flightgear. One great demo of high poly count terrain rendering with LOD is the chunked LOD demo from Thatcher Ulrich (http://sourceforge.net/projects/tu-testbed). This demo is optimized to death for NVIDIA cards though and is well worth checking if you have one. Woo hoo! The LOD war is back. :) My feelings: Static geometry is good enough for almost everything these days, including flight sims. The only exception is getting the all the way to the horizon rendering correct for high altitudes, where visibility can be infinite and mountains 200nm away should be visible. Continuous LOD schemes are the only ones that make sense. Chunked LOD is optimizing the wrong thing -- Thatcher gets very high polygon throughput, which admittedly make for good flame bait. But real users can't count polygons on modern hardware, and only care that the screen looks right and the animation is smooth. For a LOD scheme the only correct metrics are (1) screen space error and (2) lack of visible pops or geometry discontinuities. Chunked LOD does no better than ROAM variants in error (despite using far more polygons to acheive that error), and shows significantly worse discontinuity behavior (whole chunks go in and out at once). Split-only ROAM is my choice, FWIW. You can push the per-triangle CPU overhead down to 2-300 cycles, which on modern processors is easily sufficient for tens of thousands of triangles per scenery tesselation. For real-world terrain, that's less than a pixel of screen space error. 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] compile warning
Curtis L. Olson wrote:
For the C++ experts, I'm starting to see a lot of these sorts of
warnings? Other than trying to avoid and clean up warning litter, is
this dangerous? What's the best fix for this?
warning: `class FGGlobals' has virtual functions but non-virtual destructor
If you have virtual functions, then the assumption has to be that you
will be using the class polymorphically. If you are using it
polymorphically, you might be expected to delete objects using a pointer to
the base class instead of the real class. If you do this with a
non-virtual destructor, bad things ensue. :)
More tersely, if you have:
class SubClass : public ParentClass { ... };
ParentClass * p = new SubClass(...);
delete p;
If ParentClass has a *non* virtual destructor, then this code will
call only ParentClass's destructor. The SubClass destructor will
never be invoked on this SubClass object, and you will leak memory, or
resources, or leave dangling pointers, or worse.
A virtual destructor works by first calling the SubClass destructor,
and then automatically chaining in calls to the superclass destructors
in order to make sure that everything is cleaned up.
So basically, put a virtual in front of the destructor declaration
for any classes whose subclasses can be deleted through pointers to
the base class. It's easy and safe and the Right Thing. The compiler
warning doesn't necessarily indicate a problem; but there really
aren't any downsides do heeding it anyway.
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
Men go crazy in conflagrations. They only get better one by one.
- Sting (misquoted)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft updates in CVS
Curtis L. Olson wrote: I've just commited some aircraft updates from Lee Elliott to the base package cvs. This is a neat aircraft to fly and is crying for someone to add textures to the beautifly done 3d model. Indeed, Lee rocks. But seriously, someone needs to come to his home, tie him down and teach him Blender so that we can get some colors on these things. And make him do something non-british while you're at it. :) I finally started playing with Blender a little last week. It's an awfully slow start, but after the first few hours you really do get the hang of it. The CVS version is building via autoconf now, by the way. I haven't looked at the code, but the build process is simple and painless. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Moving [was: Trip Report: Roads and Rivers]
Curtis L. Olson wrote: One that I have enjoyed is following the Columbia river. If you start from Portland, OR (KPDX) the airport is right next to the river. For those who haven't seen it, the Colombia River gorge is even better in reality, too. And while we're on the subject of Portland, I should mention my near-future plans. :) My wife, Alison, has just completed her graduate work in chemistry and accepted a position with Intel in Hillsboro, just outside of Portland. We will be closing on our new house and moving in three weeks. I don't have GPS coordinates handy, but the property sits about 0.6nm mile from the threshold of KHIO runway 2, maybe 200 feet from the centerline. This is the short runway at Hillsboro airport; unfortunately all we saw last week were planes in the pattern for runway 30. Hopefully we'll get the occasional overflight on short final. :) This is obviously going to interrupt my email availability during the move. My nextbus account should remain active for the near term, but I may not be able to check it. The plausible.org domain needs to wait for a DSL/cable installation before it comes back. Basically, expect me to be unreachable for the last week in January. Longer term, I may be fairly invisible as well. Obviously, I'm terminating my current employment when I leave. The cost of living in the Portland area is amazingly low when compared to the San Francisco Bay area; we can easily support ourselves on Alison's salary alone. And since the job market for programmers is very soft at the moment anyway, I managed to convince her to let me spend two months working on a game project of my own that has been bouncing around in my head for the past few years. Enough of the code-level design is clear to me (in my head, anyway) that I'm hopeful I can get something playable/demoable put together in that time frame if I can maintain focus. We'll see, sometimes sitting down and cranking away at code works great for me, sometimes not. I give myself perhaps 1 in 10 odds of ever getting payed for this. But if things go well (from my perspective), I won't have time available for leisure pursuits like FlightGear in the near term. I'm not leaving forever, but the idea of working full time on something that is 100% mine is just too attractive. If it doesn't pan out after two months, I'll get a real job and come back to the fold, I promise. I'll try to get a few items off of David's wish list ticked off before then. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 segfault
Matthew Johnson wrote: Major A wrote: does the 747-yasim segfault fgfs on everyone's computer? Yes I get a segfault too I can't reproduce this with the command line solver (and can't run fgfs from work). Crashes in YASim are (well, have been) almost always in the parser, and happen due to unhandled syntax errors. Are you sure you have the proper base package and an unmodified 747.xml file? Can one of you get a stack trace in gdb to see where it's crashing? 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] Problem: unrealistic YASim stalls
[Sorry for the delay. This one was hard, and had to wait for the weekend for an investigation.] David Megginson wrote: Andy: unfortunately, none of your suggestions helped (details below). How are you modelling washout in YASim? From the violent roll that comes with every stall, it looks like all of the wing is stalling simultaneously, so the plane loses roll control from the ailerons at the same time as it loses lift from the wings. Wow, good call. The lack of washout modelling is indeed the problem. And the details turn out to be great fun, to boot: What happens in the current (no washout) implementation is that the aircraft nears a stall some (just a tiny bit) non-zero roll rate. The wing going down therefore experiences a higher AoA than the upward wing. In normal flight modes, this has a pro-stability effect. The asymmetric lift distribution opposes the roll rate. Once the wings are beyond the stall point, however, increasing AoA's decrease lift and this causes a pro *roll* moment. That's a divergence, and the aircraft very rapidly rolls off into a wild departure. I've always understood washout the way you explained it. It's there to keep the ailerons unstalled and the plane controllable at high AoAs. I figured this was something that could be modelled away by simply increasing the stall width to reflect the fact that the whole wing stalls gradually at different AoA's. But that is a demonstrably minor effect; you can pump the aileron effectiveness up to ridiculous magnitudes in YASim and you will still be doing snap rolls. The real reason for washout (or at least a better physical explanation) is this: the washout that maintains the tips below stall AoA keeps as much of the stable derivative as possible out on the wing tips where the moment arm is long. If the early stall happens near the fuselage on a short moment arm, then the overall behavior will still be stable, not divergent, even past the peak of the whole aircraft lift curve. It also explains why aircraft which are normally stable in the stall can sometimes do divergent snap rolls (c.f. Luke and Ryan's anecdotes). If you pull the AoA high enough to put the tips in the stall too, then the divergent mode reasserts itself. You can do this with an accelerated maneuver, for instance. Also, flying at aft c.g. configurations results in more relative elevator authority which could plausibly overwhelm the washout at the tips. Cool. I learned something this weekend. A snap roll is a physically well-defined thing: it is a roll executed in a post-stall environment where the roll-moment-due-to-roll-rate coefficient is divergent. So anyway, YASim needs to model washout. In principle, this should be pretty easy. Each wing segment (Surface object, as currently implemented) gets its own orientation already. We just need to decide on a way to specify it to the solver. Would a linear interpolation between base and tip incidences work? I don't know much about washout design as implemented on typical aircraft. A fancier mechanism would allow you to specify washout as an interpolated curve per-station curve along the span, but that sounds like it might be overkill to me. Does anyone have a preference? 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] Problem: unrealistic YASim stalls
Arnt Karlsen wrote: ..some planes use distinctly different airfoils, leading edge cuffs, slots etc, towash out. Some different-airfoil wings transform gradually towards the tip, and not neccesarily in a linear fashion, some of these can get really weird. Actually, this is supported already, for those who have the patience to work with such minutia. You can chop the wing up into as many separate vstab objects as you like, each with an independant configuration. The point of handling washout as a separate concept is that (counter to my original thought) it turns out to be important for all aircraft with high aspect wings, not only those with hyper-realist authors. :) In fact, adding a tip section to the cessna wing with a different incidence value would be an immediately useful way to test washout effects. 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] Problem: unrealistic YASim stalls
David Megginson wrote: I found it easier simply to picture different 2D sections of the wing stalling at different times, but I can see how your explanation might lead to a programmatic solution faster. Right, but what is it about different secions of the wing stalling at different times that causes the aircraft to snap roll? That's the part that was non-obvious to me. You get the snap roll effect even when there is no dihedral or sweep, in situations where the wing should be stalling symettrically. It happens because when the aircraft is rolling (even a little bit), one wing is going down and the other up. This causes a difference in AoA at the tips. If the wing tips are stalled, then the wing going down is pushed farther into the stall, while the one going up sees a lift recovery. So the net effect is that the aircraft tries to roll *into* the existing roll direction. That's an unstable situation (like a ball sitting at the top of a hill), and it will diverge if the roll rate has any non-zero value. The more common explanation for washout (that the ailerons are masked by the tip stall) is incorrect. The snap roll doesn't happen because of aileron authority, it happens because the aircraft is literally unstable in roll. Aileron authority can obviously help to recover, but the tendency to roll off into a divergent snap roll is the real effect, and it is a different behavior from the normal roll stability of the aircraft in typical conditions. Isn't the snap roll usually uncoordinated? I've never done aerobatics myself. If it is, then I wonder what the role of the uncoordination is. If there is any wing sweep or dihedral, then a non-zero yaw angle also changes the relative AoA of the wings to produce the same effect. If you apply full rudder on such an aircraft, then you don't need to pull up the nose as far to get the down wing tip stalled. There might be a yaw rate effect too. When the aircraft is yawing, the wingtip going back also sees a higher AoA and will drop if it is past the stall. Same deal. The snap roll needs a stalled down wingtip to get the divergence, in any case. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 segfault
Major A wrote: #0 ssgSGIHeader::getRow() at ssgLoadSGI.cxx:211 #1 ssgSGIHeader::ssgSGIHeader(... /usr/local/FlightGear/lib/FlightGear/Aircraft/747/Models/boeing747-400-jw-08.rgb, ...) at ssgLoadSGI.cxx:328 This is plib crashing while trying to load a texture file. My guess is that something is wrong with this texture. Either it doesn't exist, or is corrupt. Try updating your base package. 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] build identification
Bernie Bright wrote: The very first thing FG displays is its version number and compiler info: [...] It would be trivial to add a timestamp. A much better idea would be to store a time in the CVS archive. Relying on a compilation date can bite you in very strange ways. Who knows when the user last did a CVS update. For a while at NextBus, we had a scheme like this where a checkin hook would automatically increment the value stored a version file. There was some Rube-Goldberg-style magic that had to be done to get one checkin to run recursively inside another (we used a cron job that checked a temporary log file, as I remember), but it worked and had the advantage of exactly capturing the archive state in a single value. It got chucked in favor of a much simpler manual release stamp system that fits our deployment model better. But it was awfully cool. 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] Another question (udp sockets/broadcast)
Curtis L. Olson wrote: However, I can only open one receiving server on my machine. Subsequent processes fail to open the socket returning Address already in use. Are you sure you're using the broadcast address configured for your ethernet device? I might be wrong on this, but I believe the kernel should let you bind multiple sockets to the same port on this IP. If you're using a normal UDP port, then this is correct behavior. The kernel won't deliver the same packet to more than one socket. 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] Question on YASim ....
Gene Buckle wrote: Andy, is it technically possible to fiddle with the model parameters in real-time? Not easily. Changing the parameters requires a re-solution, which can take a second or two for aircraft with lots of elements like the 747. So it would have to be done a little bit at a time over many frames, and probably involve a throttler gadget to keep the frame rate high enough. On an SMP system, you could just spawn a thread to do it and it would work great, of course. But on a uniprocessor, even threading would take half the CPU and performance would drop by 50% for a few seconds while the solution popped out. Is there something in particular you want to control at runtime? Support could probably be added per-device. 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] Question on YASim ....
Gene Buckle wrote: My thought is that a real-time model wrench might make it easier for people to develop or improve aircraft models. I imagine it would save a _lot_ of time if the edit parameter file, run fgfs, test, re-edit cycle could be reduced to run fgfs, tweak in-flight, dump new parameter file. Ah, got it. Actually, that feature could be expressed as simply as make YASim load its configuration out of the property tree like everything else does. Then you'd just change the properties using whatever interface you want and select reset from the menu. This is definitely the way it should work. I've been slow to do it only out of laziness. Re-writing the existing aircraft definitions in property XML would be a pain. You're right, the N second pause for the solver would be just fine for this application. I was thinking you wanted to do something like variable-camber wings or whatnot and needed realtime control over things that are currently constants to the solver. Although it's worth pointing out that the command line yasim program goes a long way toward reducing the tedium involved with getting an aircraft in the air. Most of the big configuration bugs can be found and fixed before you ever run fgfs, although admittedly interpreting the solution report takes a little practice. 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] What's in the job jar?
Michael Bonar wrote: MSVC6 has a Visio add-on that allows you to reverse engineer C code into UML diagrams. Anybody have experience with it? I was thinking of giving that a try to see what it looks like. It probably looks a lot like UML generated automatically from C code. :) I've never been able to understand the appeal of CASE tools like this. How on earth is a machine going to read your code for you and tell you how the design works? The whole point behind overview documentation is that it captures the *intent* behind the code -- that is exactly the part of the design that is not actually found in the code. By its very definition, it can't be automatically extracted. It has to be either written down by the designer or intuited by the reader. At best, a tool like this could make source navigation easier. Having tools to answer questions like who calls this? or where are these made? is useful. But that's best done at the level of C syntax, IMHO, not in a separate diagramming language. A lot of this, to be quite honest, is just me being a luddite or an elitist. It's been my experience that elaborate documentation schemes really aren't worth it. There seems to be an inverse relationship between a programmer's penchant for fancy design tools/methodologies and their ability to understand a design presented to them. The really productive coders I have known are happy with a one page README file for documentation, and tend to be able to dive into existing undocumented code and figure stuff out very well. The folks who insist on having pick your jargon available tend to struggle whether they get it or not. All in my experience, of course. None of this is to say that documentation is a bad thing. But elaborate documentation and design work is, IMHO, largely useless or self-defeating. In the professional world it tends to hamstring the best workers for the benefit of the worst, thus running afoul of Fred Brook's (The Mythical Man Month) observations about productivity. Really good examples of sane documentation can be found in the Documentation directory of the Linux kernel. The files there tend to tell you exactly what you need to know, and give you enough hints to discover the rest on your own and/or clue you in on what questions to ask of the people who know. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 crash fixed
Curtis L. Olson wrote: actually my guess is that due to the gear problem, it probably crashes instantly so nothing will work at all with it. Yup, that was it. Sorry, I've been ignoring this one. I recently changed the default gear spring strength. But taildraggers have different c.g. configurations, and the aircraft was falling through the ground on initialization. Fixed. And of course, in air starts don't work for YAsim models, so... :-) Andy, I'd be happy if we were forced to specify velocity in kts (and then maybe mach for the faster aircraft.) The units don't really matter. I can convert between them just fine. What I'm confused by is the API for how to tell which units are being used. JSBSim does this in FGInitialConditions, but I got a little lost trying to figure out where the information there comes from. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Render-to-texture for the panel
Norman Vine wrote: This method should also be *considerably* faster then the current Panel code in that the actual updating of the instruments can be done on a round robin basis I'm not sure this will work as well as you think. The only way to reduce the amount of work done is to re-render panel instruments something less than once per frame. Once that multiplier becomes more than 2 or 3, you end up with the same chunky, awful panel animations that MSFS is (in)famous for. Ick. Remember that this only matters for low frame rate situations -- people who are already getting 60 fps don't care about getting to 90. But people at 15 Hz might not be willing to go to 25 if it means that their panel instruments update at only a stuttering 8 Hz. The panel update rate is, IMHO, more important than the overall frame rate. This is my #1 biggest peeve about MSFS. And remember that fast render-to-texture requires support for pbuffers/render_texture extensions (I believe only NVidia's windows drivers currently have this). Doing it with glCopyTexSubImage involves at least one extra blit and buffer clear per frame, which is (I suspect) likely going to cost more fill rate than you save in panel rendering. 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] Render-to-texture for the panel
Norman Vine wrote: This used to be true but not with the current cards or on any NVIDIA card with a current driver glCopyTexSubImage is FAST even without using pbuffers It's not all that fast. You still have to clear the back buffer and you still need to do the memory blit into the texture. It's not slow, and it makes fun techniques like impostering and dynamic cube map generation possible. But compared with traditional rendering it still costs significant fill rate. Remember that the slow thing your trying to fix is the fill rate penalty of rendering all the panel layers; the panel layers don't have significant geometry to speak of, they're slow because of all the texture reads. Fixing that problem with a fill-rate-intensive algorithm won't give you quite as much of a speed up as you think. Again, I'm not saying that it won't be faster. I'm saying that it might not be quite as fast as you imagine, and that it involves significant tradeoffs in panel fidelity that I'd be really hesitant to make on systems that are already getting slow frame rates. 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] Re: [Plib-devel] Texture border (ATI performanceissue)
Whee, here we go. :)
Steve wrote:
I think you have it wrong.
EVERY card implements GL_CLAMP because all that it requires is that
the texture coordinates are clamped to the range 0..1.
No. Check the spec, or the recent discussion on the DRI list. I
thought this must be the case, too, but I was wrong. Attached is a
simple glut program. Run it against software mesa and compare against
the NVidia drivers and the specification. NVidia gets it wrong.
Very few cards implement GL_CLAMP_TO_EDGE - it was added to OpenGL
because it does a better visual job of stitching together the edges
of textures.
No, this is backwards. CLAMP_TO_EDGE does a *poorer* job of stitching
the edges together when compared with OpenGL 1.0 texture border. It
was added to the spec because that is all that consumer cards support.
I don't believe that ATI don't have an efficient implementation of
GL_CLAMP mode...nearly every software package out there uses it.
Buy one and try it. They don't. In their defense, however, they have
a compliant implementation of GL_CLAMP. No one else does.
Running FlightGear under software Mesa creates dark lines in the
runways where the default black border is sampled between the
tiled textures.
That doesn't happen with GL_CLAMP unless you ask for a texture
border and PLIB doesn't do that. None of my games exhibit that
problem under software Mesa.
Again, read the specification. The texture border (or border color,
if there is no border) is *always* supposed to be sampled at the
texture edges when using GL_CLAMP.
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)
#include stdio.h
#include GL/gl.h
#include GL/glu.h
#include GL/glut.h
#define TSZ 32
unsigned char tex[TSZ*TSZ*3];
int state = 0;
/* Tile the texture using four exactly adjacent quads */
void display()
{
glClear(GL_COLOR_BUFFER_BIT);
glBegin(GL_QUADS);
glTexCoord2f(0, 0); glVertex2f(-0.5, -0.5);
glTexCoord2f(0, 1); glVertex2f(-0.5, 0.0);
glTexCoord2f(1, 1); glVertex2f( 0.0, 0.0);
glTexCoord2f(1, 0); glVertex2f( 0.0, -0.5);
glTexCoord2f(0, 0); glVertex2f(-0.5, 0.0);
glTexCoord2f(0, 1); glVertex2f(-0.5, 0.5);
glTexCoord2f(1, 1); glVertex2f( 0.0, 0.5);
glTexCoord2f(1, 0); glVertex2f( 0.0, 0.0);
glTexCoord2f(0, 0); glVertex2f( 0.0, 0.0);
glTexCoord2f(0, 1); glVertex2f( 0.0, 0.5);
glTexCoord2f(1, 1); glVertex2f( 0.5, 0.5);
glTexCoord2f(1, 0); glVertex2f( 0.5, 0.0);
glTexCoord2f(0, 0); glVertex2f( 0.0, -0.5);
glTexCoord2f(0, 1); glVertex2f( 0.0, 0.0);
glTexCoord2f(1, 1); glVertex2f( 0.5, 0.0);
glTexCoord2f(1, 0); glVertex2f( 0.5, -0.5);
glEnd();
glutSwapBuffers();
}
/* Cycle the texture border mode when the user presses a key */
void keyboard(unsigned char k, int mx, int my)
{
if(state == 0) {
printf(GL_CLAMP_TO_EDGE\n);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
} else if(state == 1) {
printf(GL_CLAMP\n);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);
} else if(state == 2) {
printf(GL_REPEAT\n);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
}
if(++state = 3)
state = 0;
glutPostRedisplay();
}
/* Generate a 33%/66% gray mipmapped checkerboard. */
void init()
{
int i, j;
for(i=0; iTSZ; i++) {
for(j=0; jTSZ; j++) {
unsigned char* pix = tex + 3*(i*TSZ + j);
pix[0] = pix[1] = pix[2] = (i+j)1 ? 170 : 85;
}
}
gluBuild2DMipmaps(GL_TEXTURE_2D, GL_RGB, TSZ, TSZ, GL_RGB,
GL_UNSIGNED_BYTE, tex);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glEnable(GL_TEXTURE_2D);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_DECAL);
}
int main(int argc, char** argv)
{
glutInit(argc, argv);
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGB);
glutInitWindowSize(512, 512);
glutCreateWindow(Texture Border Test);
glutDisplayFunc(display);
glutKeyboardFunc(keyboard);
init();
glutMainLoop();
}
[Flightgear-devel] procmail trivia (OT)
David Megginson wrote: On my system, I use procmail to sort messages into separate lists. When someone crossposts to flightgear-devel and plib-devel (for example), both messages end up in the flightgear-devel folder, because that rule fires first, so it just looks like a duplicate posting. Yup, user error. :) David gets the cookie. I do indeed use procmail to filter my mail, but normally this isn't a problem. We use postfix as a MTA, which delivers multiple copies of messages when expanding aliases. So I typically do see one delivery for each list. But I have this recipe in my .procmailrc: :0 Wh: .msgid.lock | formail -D 16384 .msgid.cache Which (for those who aren't fluent in procmail) removes messages with a duplicate ID tag. For messages that arrive from elsewhere, this is apparently rarely true. But for messages that I send, it is. Odd. 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] perl scripting
David Megginson wrote:
Last time I looked at swig, it was for creating bindings for native
libraries from include files.
Try
perldoc -f pack
perldoc -f unpack
Perl has excellent support for this kind of thing, once you get your
head around it.
BIG WARNING: The pack/unpack facilities have been pretty thoroughly
cuisinarted by the recent UTF8 support. I got smacked hard by this a
few months back.
Attached is a little mind bender that I wrote while trying to figure
this out. All it does is take a number (255), and try to pack that as
a single-byte number into a one character string. It verifies that
the length is one; writes that single byte out to a file, reads that
single byte back in from the file, and then verifies that the strings
are equal.
When run under Red Hat 8.0, the strings are *not* equal. When run on
the same machine via an ssh -c command, the strings *are* equal.
What happened is that perl honors the LANG attribute when doing file
I/O, and LANG is set to en_US.UTF-8 by default for login shells in
Red Hat. So it writes out the (UCS-2) character 255 as a two byte
(!) UTF8 string.
This is sane behavior for perl in text contexts (UTF8 files turn into
character arrays magically when read, and re-stream themselves
magically when written), but it completely breaks the pack function,
which is based on the idea of packing numbers into strings and
interpreting those strings as arrays of bytes, not characters.
This is trivially fixable by clearing $ENV{LANG} in scripts where you
want to call pack/unpack, but it is very non-obvious if you aren't
prepared for it.
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)
#!/usr/bin/perl -w
use strict;
use bytes;
my $s0 = pack C, 255;
print Length: , length($s0), \n;
print Bytes: , join(, , unpack(C*, $s0)), \n;
open FOO, foo.out or die;
print FOO $s0;
close FOO;
my $s1;
open FOO, foo.out or die;
read(FOO, $s1, 1) == 1 or die;
close FOO;
print Length: , length($s1), \n;
print Bytes: , join(, , unpack(C*, $s1)), \n;
if($s0 eq $s1) { print Strings are equal\n; }
else { print Strings are NOT equal\n; }
[Flightgear-devel] Texture border (ATI performance issue)
I've been playing with the new ATI linux drivers recently. It turns out that they have a performance problem that gets tickled by plib. Plib allows you to pick wrapped or clamped texture borders when you create your ssgTexture. To get the clamping, it uses the original GL_CLAMP mode, instead of OpenGL 1.2+ GL_CLAMP_TO_EDGE. The problem is that the original OpenGL texture border behavior, as specified, isn't implemented by any consumer hardware. It requires that the border color (or texture border) be sampled at the edge of the texture. Most drivers (at least NVidia's and DRI) actually cheat, and treat GL_CLAMP as a synonym for GL_CLAMP_TO_EDGE. Since Plib doesn't provide control over the texture border, existing plib applications (at least FlightGear) actually *depend* on this misinterpretation. Running FlightGear under software Mesa creates dark lines in the runways where the default black border is sampled between the tiled textures. As it happens, ATI complicated things with a 100% correct implementation of texture wrap modes. Running under ATI's drivers, you see lines like this: http://www.plausible.org/andy/ati-texture-border.jpg And it gets worse. While the drivers support this mode, the hardware actually does not. So it's falling back to a slow path and is really slow. By default, FlightGear under ATI's drivers is much slower than under DRI. Changing plib to use GL_CLAMP_TO_EDGE got almost a 3x performance boost when there are a large number of runway pixels on the screen (hardly an uncommon occurrence) Since this is actually correct behavior per the spec, we can't ask that they fix it in the drivers (even if it would be nice for them to mimick everybody else's behavior). The attached patch causes Plib to ask for the mode that the hardware supports, at least when compiled against OpenGL 1.2 or newer. Really, that's what we want anyway. The old 1.0 texture border behavior is problematic and confusing unless you understand it very well. Andy Index: ssgTexture.cxx === RCS file: /cvsroot/plib/plib/src/ssg/ssgTexture.cxx,v retrieving revision 1.22 diff -u -w -r1.22 ssgTexture.cxx --- ssgTexture.cxx 2 Sep 2002 06:05:49 - 1.22 +++ ssgTexture.cxx 18 Dec 2002 22:53:09 - @@ -58,10 +58,17 @@ glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR ) ; glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, mipmap ? GL_LINEAR_MIPMAP_LINEAR : GL_LINEAR ) ; + +#ifdef GL_VERSION_1_2 +# define PLIB_CLAMP_MODE GL_CLAMP_TO_EDGE +#else +# define PLIB_CLAMP_MODE GL_CLAMP +#endif + glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, -wrapu ? GL_REPEAT : GL_CLAMP ) ; +wrapu ? GL_REPEAT : PLIB_CLAMP_MODE ) ; glTexParameteri ( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, -wrapv ? GL_REPEAT : GL_CLAMP ) ; +wrapv ? GL_REPEAT : PLIB_CLAMP_MODE ) ; #ifdef GL_VERSION_1_1 glBindTexture ( GL_TEXTURE_2D, 0 ) ; ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Texture border (ATI performance issue)
I wrote: [snipped] Can someone forward this to the plib list? For whatever reason, none of my posts seem to get through there. Dunno if that's a sourceforge thing or what... 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] 3D model origin proposal
Jon Berndt wrote: Also, Andy: which point does YASim provide to FGFS? Is it the CG, or some other point? It provides the coordinates of the origin, be that the nose or centroid or FAA reference point or whatever. Going back into hiding now; wake me up if you need me to move the origins. :) 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] 3D model origin proposal
Erik Hofman wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. Even when in motion? It seems to me there would otherwise be no need for a refference point. That's exactly the point. The reference point is a completely arbitrary choice; it could be 4 light years away (well, with infinite precision floating point) and the math would still work just fine. The FDMs do the dynamics for you; if you draw the aircraft where they tell you it is, then you will always be drawing physically correct rotations. It is true that there is an *illusion* that happens when you look at a point far from the aircraft's c.g. which makes the airplane look like it is not rotating correctly. But this is an illusion; what is really happening is that the *viewpoint* is moving. The aircraft motion is correct in all cases. The fix for this issue is either to pick an origin near the c.g. (hard to enforce between FDM(s) and 3D model) or to have the view code explicitly look at the c.g. point instead of the origin (my preference, although it does complicate things a little). 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] 3D model origin proposal
David Luff wrote: Jon Berndt wrote: Well, to rotate the aircraft realistically the refference point should be known by the 3D modellers, but that aside. The rigid body rotates about the CG, not the aero ref. pt. What about rotation (the taking-off one)? Surely in that case it rotates about the axles? You're both right. Any point can be used as an origin, and any motion of a rigid body can be decomposed into a set of translations through space and rotations about that origin. There's really nothing magic about the center of gravity. It's just another point in the body's coordinate system. It's useful as a teaching aid because, in the absence (!) of any interaction, continuous (!) unaccelerated (!) motion of a rigid body can be captured by a constant velocity and a constant rotation speed. That's not true of other reference points (where unacclerated motion requires changing speeds and rotations). In the real world, bodies interact and accelerate, so the c.g. isn't quite as useful as a magic reference point (although it still simplifies the math internally). Here's a really quick thought experiment to make the point: Even if the aircraft is motionless on the ground, it's still rotating with a period of 24 hours about the center of the earth. The center of the Earth is most certainly *not* the c.g. of the aircraft. :) [This is not to say that current FDMs bother to model coriolis effects. I know for a fact that YASim doesn't.] 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] c310 origin
David Megginson wrote: 1. Put the X axis origin at the published weight-and-balance reference datum. 2. Put the Y axis origin at the centreline of the plane. 3. Put the Z axis origin [where? the ground?]. I'll just state my opinion again, and then keep my head down until someone tells me where to move the origin. :) Whatever convention we pick should be an easily explainable and identifiable from the *shape* of the airframe only. Not everyone has a POH handy, very few people have WB or C.G. numbers, and even things like the centerline are subject to argument on some aircraft. Referencing the ground plane is especially bad, since the gear are going to compress differently depending on load. Remember that many/most 3D model authors aren't particularly interested in aerodynamics, and may very well be working from photographs and 3-views only. Forcing these people to look up a reference datum from an unfamiliar source is only going to discourage them. I continue to like the origin is at the tip of the nose. You'd have to look really, really hard to find an aircraft without an identifiable nose. And finding an aircraft author who doesn't understand the concept is literally impossible. And, quite honestly, what's the actual advantage to using a reference datum anyway? No one does weight and balance calculations in Blender. :) 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] Grey panel with Radeon 7500 and dri driversstill there.
Fabien ILLIDE wrote: David Luff wrote: FWIW, the grey panel with the Radeon 7500 and the DRI drivers still persists despite the patch to fix this behaviour with the ATI binary drivers. I jump onto this post to say that I've just see that I've got the same problem with my new Dell Latitude C610, which have a Radeon Mobility LY. I hereby call not it and point you guys to the DRI list. This just looks like a driver bug to me, sorry. I don't have a Radeon 7500 to test against. https://lists.sourceforge.net/lists/listinfo/dri-devel It's worth pointing out that the DRI driver the current distributions are shipping is rather old. I've seen lots of work checked in and discussed (I'm a lurker on the list) over the past few months. You might very well see better results with current code, although sadly building an entire X server isn't terribly easy. If someone can come up with a good test case and screenshot and is willing to test fixes for them, I'll happily chime in with remarks about how the code works. 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] Grey panel with Radeon 7500 and dri driversstill there.
Jim Wilson wrote: FWIW I'm also seeing a significant degree of what appears to be z-buffer fighting with geforce2 at 24bpp. The c310-3d panel goes grey at certain angles and the c172-3d and a4-yasim panels display a lot of instability in the rendering (problems between layers in the instruments), although they do not go grey. The fighting is more pronounced with instruments at an increased angle from the camera vector. I see this too. I think (maybe) that it's due to the cockpit jitter issue, though. The loss of precision issue will result in different depth slopes for polygons that should mathematically be on the same plane. Thus the problem is worse for the near cockpit geometry (A-4), and with off-angle viewing. I need to work on the jitter bug, but keep getting distracted by more interesting things. The problem, if anyone forgets, is that the matrix the cockpit draws into has a translation component that looks like: eyepoint-to-origin + origin-to-aircraft-body Since the origin can be kilometers away, and the math is done in 32 bit floats, you end up with millimeter scale (several pixels or so) imprecision in the resulting positions. What needs to happen is for the model code to calculate a eyepoint-to-aircraft transformation on its own (in double precision) and not simply push a translation onto the matrix. 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] Grey panel with Radeon 7500 and dri driversstill there.
Jim Wilson wrote: Right, the polygon offsets that I thought I rememebered Andy had been adjusting for this issue seem to have introduced some other problems though. The way it worked was that the original code I submitted used a very high offset number (because I'm using NVidia hardware too, and needed it to prevent fighting between layers -- I didn't understand the jitter issue yet at the time). But this caused the infamous panel visible through the aircraft bug with 16 bit Z buffers. David experimented and found a much smaller number that worked well for him at 16 bit, in the process re-introducing the Z fighting bug on NVidia hardware with a 24 bit depth buffer. But again, the Z fighting issue is (I'm pretty sure) related to the matrix precision issues. It's not a PolygonOffset issue per se. 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] Fwd: Re: preferences.xml change
Jim Wilson wrote: Michael would like to add an additional default view (a third, closer tower) to the base package preferences.xml. I'm against it since we offer the ability to add custom views and there's already too many default views for my taste. I'd argue that this is a UI limitation. Having a fixed set of views works fine for N=3 or so, but forcing the user to cycle through 6 is just too much. Even explaining the difference between some of them is a chore. Why not add an extra menu where the user can select from a list, instead? Then the v key can toggle between cockpit mode (by convention always view 0) and whatever the last selection was (the default could be external view, currently view 1). This should remain easy to use up to N=10 or so. 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] [OT] BA-609, V-22 derivative aircraft
Carsten.Hoefer wrote: Forgetting about all 'unsafe' situations in helicopters, do we have one in flightgear? Is it possible to model one with the existing flight models we use? Not without a lot of code work. Helicopters have a bunch of effects that don't exist in the current FDMs. Things like asymmetric lift effects would need to be revisited. Both YASim and JSBSim model P factor, which is what the same effect is called on a fixed wing propeller aircraft, via a hack that isn't general enough to handle ~90 degree AoAs. Other stuff, like blade flapping and precession of the main rotor just don't exist and would need to be done from scratch. For myself, I don't find PC simulation of helicopters very interesting. Existing throttles don't have anywhere near enough precision to simulate a collective, IMHO. Helicopter pilots maintain altitude by feeling for very slight changes in vertical acceleration and adjusting with tiny movements of the collective. There's no way we can simulate that well. We could do it with an autopilot like device, of course, but where's the fun in that? You might as well just install Commanche MCMXIV or whatnot to get same level of simulation realism. :) If you want to try hovering in FlightGear, try the Harrier. That thing is really difficult to hover, for all the same reasons that the real aircraft is difficult to hover. 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] SimGear configure problem (metakit)
David Megginson wrote: configure:8649: checking for ftime configure:8699: gcc-3.2 -o conftest -g -O1 -finline-limit=6 -finline-functions -D_REENTRANT -I/usr/X11R6/include -L/usr/X11R6/lib conftest.c -lm -ljpeg -lmk4 5 /usr/local/lib/libmk4.so: undefined reference to `operator new[](unsigned)' It looks to me like a gcc invocation (as opposed to g++) is being used to compile a C program, but linking against a C++ library (metakit). So whatever library operator new is in isn't there. Using gcc to compile C++ does work, but I suspect you have to pass it a .cxx or .cpp or .cc file to get support. My guess is that metakit shouldn't be there. It certainly isn't needed to test for the presence of ftime. Maybe it got added to the wrong library list? 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] J3 Cub won't converge
Curtis L. Olson wrote: With the latest YASim changes, the J3 Cub won't converge for me (and others.) Confirmed. Sorry, I didn't test this one. Any ideas? No, sadly. A quick spot check shows that it fails for pretty much all sane configuration changes. And the thing that *should* return it to the same behavior it had before the recent update (setting idrag to 1.429) doesn't work either. Odd. I honestly haven't a clue. I'll tear things apart and watch the solution step by step and see what I come up with. Hopefully it's something simple. 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] J3 Cub won't converge
I wrote: Curtis L. Olson wrote: With the latest YASim changes, the J3 Cub won't converge for me (and others.) Confirmed. Sorry, I didn't test this one. OK, fixed. The model was almost converging, but wasn't getting close enough to the threshold. It was oscillating around the right values, but each iteration moved to far to be considered done. This is a problem with this kind of heuristic. Just moving the solution precision targets a tiny bit was sufficient to fix the problem. I should probably make this number settable in the configuration file, for aircraft that run into problems. It affected the Cub because it's small and light -- relative changes in performance per-AoA and per-knot (i.e. the first derivatives of the solution functions) are higher. The problem is therefore stiff, in the lingo of computation differential equations. One exacerbating factor that I noticed is that the Cub we model has a *monster* elevator. Holding the aircraft at its stall AoA requires only 35% back stick. Is that really correct? I changed the lift parameter on the hstab from 1.7 to 1.3 and seemed to get better results. I've never flown one, though, so I hesitate to check the change in. As above, this makes the moment per elevator derivative bigger and the problem stiffer. 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] Re: J3 Cub won't converge
Curtis L. Olson wrote: Alex Romosan wrote: after updating to the latest cvs, i can't fly the a4-yasim anymore: For what it's worth, I can reproduce this. Oddly, I couldn't; the A-4 worked fine. But I did notice a newly induced failure of the (rarely used) Cessna 310 model. I gave it some more thought, and changed the mechanism a little to make the solution converge more slowly. This is checked in now, and I can verify that (at least on my machine) it produces a valid solution for every YASim aircraft in CVS. It is a little slower at the solution, though. The long-wing aircraft (which have more elements) like the 747 take as much as 2 seconds to solve now. 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] Auto Pilot probs in 0.9.1
Curtis L. Olson wrote: Heading hold seems to fail on YASim planes ... something seems to be missing, or not quite happening right. I thing this was introduced about the same time David implimented the vacuum driven AI and DG ... Hrm... did a property name change, perhaps? Or maybe something that I've never set correctly got promoted into use? I'll take a look tonight, although someone more familiar with the autopilot would probably have more luck; just tell me which output property is garbage. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] Segmentation fault ?
[bouncing discussion to flightgear-devel] Adam wrote: Andy Ross wrote: Adam wrote: As soon as I run ./fgfs I immediately get segmentation fault - with no other errors. John S. Coomler wrote: I am also using Mandrake 9 and I too get the same segmentation fault error on FlightGear 9 startup. Let me know what you find out. Can one of you post a backtrace from the debugger so we can see where it's crashing? Also, do an ldd on the binary and make sure that the plib and SimGear libraries it is using are the right ones. Thanks for that - here it is: Bingo. Cleaning things up a bit, your stack looks like this: glGetIntegerv () from /usr/X11R6/lib/libGL.so.1 SkyTextureState() at SkyTextureState.cpp:49 SkyMaterial() at SkyMaterial.cpp:60 SkyLight()at SkyLight.cpp:67 __static_initialization_and_destruction_0() at vec4f.hpp:37 _GLOBAL__I__sky_ssgLights() at /usr/include/c++/3.2/bits/stl_multimap.h:123 __do_global_ctors_aux() _init () __libc_start_main () from /lib/i686/libc.so.6 I can see two things wrong immediately. The first is that this code is part of the clouds3d stuff, which (I thought) should be disabled by default. It really isn't ready yet. Is is possible that this got turned on by accident in the release? If you enabled it yourself, turn it off before sending bug reports in the future. :) The second is that the code above can't possibly work. The call to glGetInteger() will produce undefined behavior unless there is a current OpenGL context. But there can't be an OpenGL context yet -- we're still running under _init() doing static initialization. The main() routine hasn't even been called, and we won't have a context until after we connect to the X server. It looks like there is a static SkyLight object somewhere. That's a no-no, if it has dependencies on OpenGL. Actually, this might work (or at least not crash) on some platforms; the behavior is just undefined. It might even give you a sane answer, depending on which enumerant you ask for. 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] Re: ld: Undefined symbols error linking fgfs0.9.1
David Drum wrote: I am compiling FG 0.9.1 on Mac OS X. ld: Undefined symbols: _CPSEnableForegroundOperation _CPSGetCurrentProcess _CPSSetFrontProcess _CPSSetProcessName [...] I sent this to flightgear-users a couple days ago when 0.9.0 was out. No response. Unfortunately, the OS X port is still very new and not very stable. None of the core team have Mac's. It's not that we're ignoring you, it's that we really aren't equipped to answer the question. Quite honestly, you may need to do some of the debugging yourself. Some of the missing symbols (slScheduler et. al.) should be found in the Plib sl library, which for some reason doesn't appear on your linker command line. The other four (above) I don't recognize at all. Maybe they are Mac API functions that you need to link in via a non-default library? 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] panel on Radeon 8500
Major A wrote: There is another issue with the A4 though -- pressing shift-KP8 gives a default view which is nicely out of the window, but the instruments are no longer on the screen. You mean that the view is looking too far up, above the level of the instruments, right? Not that there's a rendering error preventing them from being drawn? This is probably a simple bug in the xml files, but I don't have the time to dig into it and fix it. It's actually a little deeper than that. The keypad 8 view control sets the view straight ahead. But that's too high for a typical fighter panel. For visibility reasons, military jets essentially put the panel in the pilots lap. The a4-set.xml file defines the default configuration for view 0 as looking down by 17° to give a better default view. But it's only a default startup setting -- the keypad bindings change the current values. There's no return to default binding anywhere. This can be fixed in XML; but it requires defining a place to put default settings for the view, getting all the aircraft to adhere to them and rebinding a key or button to copy these values. That kind of consensus is hard to come by, so no one's done it. :) FWIW, I have a joystick hat mapped to pan the view and use that exclusively. Once you get used to the 3D cockpit, you really don't mind the lack of a default. If I want to look down, I just look down. 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] terrasync
Norman Vine wrote: Andy Ross writes: I think you have to give serious thought to enabling this by default, Great idea, got a URL for a native WIN32 version of rsync ?? Doing a google on rsync cygwin pulled up this post that claims that it works normally out of the box. You have to build it yourself, or did as of a year ago anyway. http://www.cygwin.com/ml/cygwin-apps/2001-01/msg00021.html The rsync distribution is tiny -- less than half the size of metakit. And it has zero meaningful dependencies (file system access and the sockets API). I don't see any particular reason we can't require it as part of the SimGear build. Even so, there's still no reason fgfs can't try to spawn an rsync on the assumption that it exists on the users path. If it fails it fails; having no scenery is a non-fatal error condition that the user would have had to deal with anyway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] terrasync
Norman Vine wrote: But in any case I don't appreciate programs that automatically connect to the NET and I still want to have the default behaviour NO networking without explicit authorization ! That's a fair point, although as long as we aren't transmitting any data I don't see any ethical problems. Some users on per-minute dialup might not want FlightGear to fire up their modem. But certainly we want this to be as easy as possible. To us, it's only a major convenience. But to a casual user, it turns FlightGear from a bay-area only demo into a whole-world flight simulator. That's a huge win. So if it's not the raw default, it needs to be a trivially simple switch that any user can throw. I'd be happy with something like a --auto-scenery argument (or better yet, a runtime menu option). But having to run terragear manually and specify an atlas argument to fgfs is too much complexity for the casual downloader. These are the people that can most benefit from this feature; and they get a *lot* of benefit from it. 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] terrasync
Michael Basler wrote: One ugly solution might be to provide just the rsync.exe, but I don't know if this works (it would require the cygwin dll, at least). Plus this might cause licensing troubles. Why not? I can't speak to whether it works with (only) the cygwin DLL, but there's nothing wrong IMHO with shipping required binaries in a binary distribution. Does the windows binary currently ship a metakit DLL, or link it statically? This isn't much different. Again, rsync is a very small program. 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] panel on Radeon 8500
Major A wrote: May I suggest a straight-forward solution: - For 2D panels, disable GL_DEPTH_TEST altogether. No objections here. It wouldn't even complicate the code much at all. The only downside is that the traditional 2D panels are essentially legacy features. All current development happens in 3D mode. - For 3D panels, they should be made real 3D panels -- needles should be some 2mm closer to the viewer than the scale. Opinions differ on this one. While some instruments (like the A-4 attitude ball) pretty much have to be 3D, I don't think this is the right model for typical flat panel instruments. The first problem is of course that having to figure out 3D offsets is a pain. It's too easy to get offsets wrong, the numbers are all magic (does anyone really know how far a GS needle is off of the backplate?), transformation math is all 3D instead of 2D, etc... The other biggie is that 3D objects don't give you control over rendering order. Many of the panel instruments make good use of the alpha to cut curvy holes, etc... In 3D, this would all have to be geometry. The nice circular holes in the panel gauge faceplates would have to be approximated with 10-20 vertices, which is significantly chunkier. And finally, in the real world cockpit designers compose panels in 2D anyway. I honestly find it more intuitive to think about a panel in flat isolation and then paste it onto cockpit geometry. Moving individual instruments around in a 3D editor is a little scary -- how do you get them all onto the same plane? 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] Cygwin + gcc 3.2 Issues
Curtis L. Olson wrote: Do we know which source files are having problems with min/max under cygwin? My impression (watching from the peanut gallery) is that min and max are useful functions that simply can't be used portably, not unlike alloca or snprintf. But in this case, is this such a loss? Why not just define something like fgmin and fgmax instead? 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] panel on Radeon 8500
Major A wrote: Sorry, I only said 747 because that was the only one I could run in the broken build I used. I now fixed that one, it happens with all 2D panels, 172, 182, 747 (press P), etc. I can confirm this. Layers on the 2D panels (but oddly, only the 2D panels) aren't drawing over the background with the current ATI drivers. I vaguely remember other reports of this kind of symptom. Does anyone remember? I'll take a look. Another ATI bug I've noticed is that they seem to have trouble with texture border. It's sampling the border color even when there is no border width defined, with the result that the runway tiles have dark shadows between them. Screenshot at: http://www.plausible.org/andy/ati-texture-border.jpg I actually had to get out the OpenGL spec on this one. It's not actually clear what happens at the edge of a texture when border==0. Some sentences seem to imply that the the border color should *always* be sampled, but that's contrary to what all the other drivers I know of do. Has anyone else dealt with this? 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] panel on Radeon 8500
I wrote: I can confirm this. Layers on the 2D panels (but oddly, only the 2D panels) aren't drawing over the background with the current ATI drivers. OK, this turns out to be a trivial fix, although I still think it's a driver bug. There are two calls to glPolygonOffset in the panel rendering code (shared by both 2D and 3D panels). One is called per-layer, and sets up a layer-specific offset. The other is called for drawing the background textures, to lift them off of any underlying cockpit geometry. I was using different factor values for each, incorrectly. Patch attached. It was affecting only 2D panels because the 3D ones don't use background images. Problem is, by my reading of the specification the bug should have had the effect of pushing the background texture *farther* behind the instruments, instead of pulling it on top of them. Either I'm reading the spec incorrectly or ATI has inverted the sense of the factor argument. Dunno, I'll submit a bug report to them and see what happens. Andy RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.cxx,v retrieving revision 1.6 diff -u -r1.6 panel.cxx --- src/Cockpit/panel.cxx 17 Nov 2002 00:04:57 - 1.6 +++ src/Cockpit/panel.cxx 1 Dec 2002 22:23:42 - @@ -370,7 +370,7 @@ // of an existing polygon. Use an offset to prevent z-fighting. In // 2D mode, this is a no-op. glEnable(GL_POLYGON_OFFSET_FILL); - glPolygonOffset(0, -POFF_UNITS); + glPolygonOffset(-1, -POFF_UNITS); // save some state glPushAttrib( GL_COLOR_BUFFER_BIT | GL_ENABLE_BIT | GL_LIGHTING_BIT -- 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] panel on Radeon 8500
Curtis L. Olson wrote: I could easily be wrong since I've never messed with glPolygonOffset myself, but it's my understanding that one of the problems with this function is that the values you need to assign to the parameters can be different across platforms to accomplish the same thing. It's actually supposed to be consistent across platforms. The parameters are units for this reason. It's historically been a compatibility problem, as many drivers have had bugs here. But the actual numbers are as portable as anything else -- the displacements you would need to achieve the same offsets in geometry will change between platforms too. But in this case, the driver seems to be interpreting the *sign* of the value incorrectly. The wrong factor argument should have pushed the background away from the viewer, but it pulled it toward the camera instead. 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] heading: magnetic or not?
David Megginson wrote: Major A writes: - The autopilot in the 172 tries to keep the orange heading bug at the top of the directional gyro, period. If you set the DG to the true heading (as you would in the Arctic), then the autopilot uses true Ever flown a (real) 172 across the North Pole? :-) No, but the Arctic starts a long way from the North Pole. Many people in Canada fly 172's in Northern Domestic Airspace (roughly north of 60, but it zigzags a lot), where you use true rather than magentic headings. The same may apply to parts of Alaska. It's worth pointing out that a DG will work fine in the polar regions. Other than precession (which has a 24 hour period -- hardly a huge source of error), there's no way for it to know that it's over the pole. It will even work fine on the pole itself, in the sense that it will always point toward the same meridian. It won't tumble or do anything silly. Only floating point euler angle computations have trouble at the poles; real hardware is a little more robust. :) 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] YASim: yasim
Erik Hofman wrote: Now that your five minutes of fame are over, I'd like to ask you to remove the creation of the yasim program in a default build, because it has a lot of dependancy problems for me (IRIX/MipsPro). First it needs all objects files from src/Main and libFlight.a from src/FDM but also libssg, which requires -lGL -lplubul and -lplibsg and so on. I'll try to see if I can illiminate most of them by only adding the YASim object files required by yasim-test instead of including libYASim as a whole. Hrm... libYASim.a is a static library. It doesn't (well, shouldn't) have dependency information in it. Some of the files reference the rest of FlightGear, but none are linked into the yasim executable. Are you sure about this error? It sounds like the Irix linker is getting itself into a weird mode. The whole point of a static library is that you put a bunch of code into it without regard for who needs what and sort it all out at link time. What does your ar command look like to link the library? I'm wondering if this is a bug in autoconf or libtool on Irix. I mostly copied this stuff from the Input directory, and don't see any obvious differences. The libInput files also reference the rest of FlightGear, SimGear, plib and GL. I'm wondering why don't you get the same errors with js_demo and fgjs? Certainly using only object files will work to remove the libYASim dependencies. But you'll also need the sgmisc, sgdebug and sgxml libraries. If these also have dependencies on plib or GL, then you're still going to have the same problem with pulling in unrelated libraries. 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] Error from latest CVS
William Earnest wrote: js_demo.cxx:21: undefined reference to `jsJoystick::jsJoystick(int)' js_demo.cxx:84: undefined reference to `jsJoystick::read(int *, float *)' Recent plib changes have turned the joystick routines from an inlined header file into a real library. You need to add a -lplibjs to the _LDADD lines in src/Input/Makefile.am and src/Main/Makefile.am. Looking at this, by the way, was what got me to add the command line YASim compiler to the default build. Normally I fear automake/autoconf. :) Responding to a later note: Stuck that lib in the Makefile, and those 2 errors vanished. The new one is: Progress in small increments... The order is important. The -lplibjs must come before -lplibul to get the dependencies correct. Remember to do the same thing to your src/Main/Makefile.am, or else the fgfs binary will get the same error. 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] YASim: yasim
Erik Hofman wrote: I'll try to see if I can illiminate most of them by only adding the YASim object files required by yasim-test instead of including libYASim as a whole. OK, I've checked in a Makefile.am that does exactly that. It still works for me; is Irix happier? 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] YASim: yasim
Erik Hofman wrote: I propose a small change in the Makefile which might make life a little easier in the future, by defining SHARED_SOURCES wich hold (indeed) all the files that are shared between the library and the stand alone interpreter. Indeed. I actually tried that first, but gave up when it died in automake. Apparently I was trying to use shell syntax for the variable instead of make syntax. Or should it be m4? Silly me. :) 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] Today's new segfault
William Earnest wrote: With the compile problems resolved, still getting a consistent segfault just after Done reading panel instruments. The other repeatable clue is that the fgfs window never appears. I'm not aware of any current crashing bugs. Can you run it in gdb and get a stack trace? If you're not used to the debugger, just get into the FlightGear source directory and do gdb src/Main/fgfs. Then type run at the gdb prompt and let the program do its thing. When it dies, backtrace can be used to get a stack trace. Post the results. :) 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] ATI vs. Linux
Martin Spott wrote: Andy Ross wrote: Probably most of you noticed last week that ATI has released a unified linux driver package for all of their 8x00/9x00 cards. [...] Wohoo, you made it into /. with this article. I would not wonder if this boosts FlightGear popularity :-) Yikes. My wife saw this first* and called me in this morning. Good grief. I hadn't planned on using up my 15 minutes of fame so soon, nor for such a silly purpose. * Yes, I have a wife who reads slashdot. Phear me! No wait, this is a post to flightgear-devel. Never mind. :) I was hoping to see some interest in FlightGear in all the responses, but most of it was the standard slashdot nonsense**. Curt will have to tell us if he sees any new mailing list subscriptions. The statistics at http://seneca.me.umn.edu show a little peak over the past few days and about 6000 hits on the slashdot link, but not a whole lot of change. ** Linux vs. Windows (no! FreeDOS!). NVidia vs. ATI (no! Matrox!). More than a few people called me an idiot. More than a few of those hadn't bothered to read the link. Whee. But let it not be said that all was in vain. I just received the following from Terry Makedon at ATI. These guys understood the problem and fixed it withing a day after the slashdot article appeared. It looks like it really was just an honest mistake. Now I feel guilty for the frothing mess remark. :) Andy Hi there, Last week we posted a set of unified Linux drivers. These drivers were only loading up on Built by ATI cards. Through our various feedback mechanisms we have determined that there is a large community of Powered by ATI Linux users that did not benefit from our Linux drivers. At this point we are happy to announce an update to our Linux driver (ver. 2.5.1) which will work on both Powered by and Built by. ATI's driver and software strategy is firmly based on responsiveness and we greatly appreciate the feedback our Linux users have provided. Please use http://apps.ati.com/linuxDfeedback/ for a direct feedback line to ATI. Thanks again for the feedback, Terry Makedon Sr. Product Manager - Software ATI Technologies -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New YASim stuff
I had some time today to play with YASim stuff. New things in CVS: Fuel consumption has finally been implemented. It's pretty simplistic and doesn't support stuff like tank selection, engine-specific fuel feeds, inter-tank feeds (or fuel dumping), etc... But it seems to work. It probably also exposed a bunch of bugs in the engine fuel flow calculations, too. A spot check looks reasonable to me. The out-of-fuel behavior is pretty cheezy too. The engines just act as if the throttle was at zero. For the piston engines this is fine, but for jets throttle==0 means ground idle. Oh well. And Curt: this should also fix the tile loader bug where the data gets corrupted if you fly the A-4 for 3600km. I don't thinkg it can't get that far anymore. :) There is now a per-wing tunable induced drag number. One of the things that the YASim solver doesn't constrain is the drag-due-to-AoA coefficient. As a result, all aircraft were getting essentially the same behavior, and this turns out to be really draggy. The jets, and the A-4 in particular, were flying their approaches way behind the power curve. I found a throttle setting mentioned in an A-4E NATOPS manual that didn't jive with what the YASim model was requiring. So I put a hacked parameter in, and set the default to something more reasonable. The straight-winged aircraft won't notice any difference. It's only the high-AoA regime that changed. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 flight deck
Martin Dressler wrote: It was me, but unfortunetly I wasn't succesfull. The one problem is in drawing lines. Cause we use polygon offset you must use polygons instead of lines. This isn't entirely a showstopper. Polygon offset works for lines, but you have to enable it explicitly and there are some confusing rules regarding wide lines. The second is that OpenGC use changing of projection in each Gauge component to clip out the stuff which doesn't belong to gauge. Hrm. That's nastier. David is right, that clip planes can be very slow on some hardware, and cause interactions on others. NVidia cards actually use one of the texture units to do user clip planes (which is awfully elegant, but really weird). If it's entirely 2D rendering, though, and all that it's drawing is lines, then doing the clipping yourself is really easy and probably not too slow. But maybe you're right, that a custom-built FlightGear EFIS would be simpler. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ATI vs. Linux
Probably most of you noticed last week that ATI has released a unified linux driver package for all of their 8x00/9x00 cards. I've been wanting to try one of these for a long time, but have been a little scared of the DRI drivers which are still maturing. This was a good excuse to buy a cheap ($70) Radeon 8500LE and try it. The short report is that it works and seems to run FlightGear very well, but I wouldn't recommend buying one purely for their Linux drivers. Stay with NVidia for now. Continue reading for the story of compatibility hell. Background: ATI's business model differs from NVidia in that they manufacture and market their own circuit boards, not just the graphics chips. Mostly. They actually *do* sell the chips to OEMs, who market third party Radeon-compatible boards. In their marketing parlance, their own boards are Built by ATI, while third parties sell Powered by ATI hardware. Most of the low end mail order cards are of this type; ATI's hardware seems to be sold mostly off of store shelves. In practice, this doesn't make much difference. While some OEMs might skimp on parts or use cheap memory, most don't, and the hardware is 100% software compatible. ATI's windows drivers have always worked equally well for OEM hardware and Built by ATI cards. Except their Linux drivers. For reasons unknown, the recently released drivers do an explicit check to see that they are running on built by hardware, and exit if they find a powered by card. Guess which one I bought? Not that I could tell -- I ordered a ATI Radeon 8500LE 64MB card from a mail order vendor. There is no information in the distribution channel to indicate what you are getting. Nor is there any documentation on ATI's site that the linux drivers only work on pure hardware. So I'm SOL. ATI clearly says on their website that Radeon 8500's are supported, but in reality most Radeon 8500 cards are *not* supported. Someone lied to me. But nothing is ever unfixable. Remember that the hardware really is software compatible (the DRI drivers and Windows drivers don't care what they are running on). It turns out that the OEMness of the card is stored in the PCI subsystem ID, and that value is defined in the card's BIOS code. And the BIOS can be flashed. So I'm off to the realm of the hardware modder and overclocker. It turns out that utilities are available to put a retail BIOS into an OEM card, which will defeat the stupid version check. I found one at http://www.xcl-clan.com/ -- woo hoo. Except that it's a DOS program. Remember that I'm a Linux guy. I have no DOS, nor FAT partition, nor even a floppy drive in this machine. So after a few hours finding and burning a FreeDOS CD and figuring out how to get a ramdisk working, I'm golden. The card has new BIOS, and it works, and the steam coming out of my ears hadn't yet caused any major burns. Yay. Apparently some people enjoy this stuff... In summary: unless you are 100% sure that your card is a built by variant (which basically means that you have to have purchased it in a dark red ATI box at a retail store), are happy with gray market stuff like BIOS reflashing, or absolutely *must* have one of the super-high-end super-expensive 9700 cards (for which no alternatives exist), stay away from Radeon cards for Linux. The technical decision to cut off perfectly working hardware is pure idiocy, and the marketing scheme that makes it impossible for a consumer to tell the difference between supported and unsupported products is downright dishonest. It's not that the drivers themselves are poor quality, or that I think ATI is actually trying to abuse its customers. But this driver release is just not good. Between them, the ATI marketing, engineering and manufacturing people have turned a fairly standard software release into a bloody, frothing mess. Give them another release to fix the release stupidities (or at least document their hardware limitations) and hopefully things will get better. And the competition isn't even close, anyway. Except at the very high end, the NVidia hardware and drivers are just as fast, just as cheap, and (most importantly) just work. I'm going to give the DRI stuff a whirl tonight. It lacks a lot of the fancier hardware features (programmable shaders), but FlightGear doesn't use them anyway. After last night's experience, I'd honestly give up 10-20% in performance to not have to use the ATI dreck. 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] heads up ...
Curtis L. Olson wrote: Recently a very kind person donated some hardware to upgrade the flightgear web/cvs/ftp/rsync/cvs server. I am respecting their wishes to remain anonymous which is why I've avoided any hoopla. Aw, c'mon. Can't we have just a little hoopla? I hate anonymous donations. :( Seriously, many, many thanks to whoever this was. With the terrasync tool on its way to a release version sometime in the near future, have you given any thought to soliciting bandwidth donations? :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 flight deck
Jim Wilson wrote: Well this probably isn't very impressive. But here it is. First view from the pilot's seat. Things are very rough at this point. Oh, baby. Someone get some instruments in that thing. :) One nit that occurs to me: looking at the horizon, it looks like the view down over the nose is only about 5° or so. This means that the runway will be hidden under the nose at a typical approach AoA of 8°. I think, anyway. That's the AoA that the YASim model likes to use for approaches (i.e. solves for), in any case. If anyone has better figures on approach AoA or cockpit geometry/visibility, speak up and I can fix the flight model. Maybe the viewpoint needs to be moved up a few cm or so? A few months back someone was looking at trying to integrate the OpenGC stuff into FlightGear as a panel-like object. Did anything come of that? 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] Presets menu
Curtis L. Olson wrote: BTW, Andy, how hard would it be to accept an initial airspeed for the YASim models so we can do in-air starts with those? Not hard at all. The only reason it doesn't is that, heh, I got really confused about how to figure out the units and precedence rules. Speed can be set in about a zillion ways (roll/pitch/heading vs. x/y/z vs. north/east/down coordinates, IAS, TAS, knots, m/s, mach, etc...), and it seemed like the FDM is responsible for figuring out what goes where. If you can point me at a property to read for an authoritative velocity source, I'm there. :) A slightly harder problem is getting the aircraft trimmed for the selected environment. A really annoying property of most (all?) sims is that they start you out at the right point, but way out of trim and you wreck the setup trying to get stabilized. I can probably canibalize some of the solver code for that. 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] gear compression
Jim Wilson wrote: What do the gear/compression-norm values in YASim represent? Is it a distance or travel range fraction or something else? It's a normalized value -- a fraction. A value of 0 represents full extension, 1 is full compression. The actual length numbers can be gotten from the aircraft configuration. If you like, exporting a compression-m wouldn't be hard at all. The problem is that not all gear compress linearly; think of the spring steel gear on light planes, or the weird bending gear on the Hornet. The advantage of a normalized value is that you can interpolate any bizzare animations you want and know that it won't break when someone changes the gear compression in the YASim configuration (this just happened for the 747, for example). 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] Bug-Report for FGFS v0.8.0
Roland Häder wrote: But what about fixing-out some compiler warnings? Most of those appeared with gcc 3.2, I believe. They don't look too scary to me -- mostly C++ standardization stuff. I'm sure they'll be fixed soon. Scanning through it quickly, it looks like mostly David's code. Sloppy bum; we oughta fire that guy. :) 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] Bug-Report for FGFS v0.8.0
Roland Häder wrote: fgfs: relocation error: fgfs: undefined symbol: __10c4_StoragePCci Very complete bug report. Unfortunately, it's a FAQ. :) The metakit library you linked when compiling against isn't the one that is getting picked up by the shared linker at runtime. Try an ldd fgfs to find out which one is getting chosen, and delete that one if possible. Better yet, link against metakit statically. C++ library have no business being shared. 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] Latest CVS Crashes
Jonathan Polley wrote: I updated plib, SimGear, and FlightGear before rebuilding. I cleaned everything on Windows because there were some changes to plib headers (MSVC isn't always smart enough to properly handle header changes if they are not in YOUR project). I haven't cleaned the MacOS build because gcc hasn't had such problems. I just got bitten by this too after a CVS update. Your diagnosis was correct; it's a plib bug. Changes that Steve made two days ago introduced an new variable without a default initialization. Here's the note I just sent to the plib list: The most recent changes have an uninitialized data bug. The new ssgContext member ovState is never assigned to a default value in the constructor, but is nonetheless tested against NULL at runtime. Trivial patch follows. Andy diff -u -r1.19 ssgContext.cxx --- ssgContext.cxx 10 Nov 2002 17:12:13 - 1.19 +++ ssgContext.cxx 12 Nov 2002 21:14:07 - @@ -48,6 +48,7 @@ cullFace = TRUE ; ovTexture= FALSE ; ovCullface = FALSE ; + ovState = NULL ; sgCopyMat4 ( cameraMatrix, _ssgOpenGLAxisSwapMatrix ) ; 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] tail scraping the 747
Jim Wilson wrote: The origin location on the 747 and a4 were fixed (Andy?) as of yesterday. Yeah, that was me. I still say that the origin should be on the airframe instead of inside the plane, but a promise is a promise. :) Random note: how hard would it be to get the checkin account added to the base package CVS emails, like is done for FlightGear and SimGear? Sometimes you can tell who made the modifications by context, but often it's no so clear. Other good stuff, for people who haven't flown the 747 recently, is that the recent ground effect fix makes landing behavior much nicer. When flown in on a 3° glideslope*, the aircraft just barely levels out in ground effect. You have to decrease power (or push the nose down) very gently to get it on the ground; it's very easy to miss the touchdown point and land long. This sorta feels right to me, based solely on passenger seat observations. * I find that about 8° of AoA for approach is about right. At the default weight, this results in about a 150 knot approach; dunno if that's right or not. I haven't been able to find a good reference for approach numbers for the 747. I'd be happy to tune it for different numbers if someone has them. Now you will note that the B747-400 on take off, rather than yanking back on the stick you need to just bring the nose up a bit and let it lift off, lest the aft section of the fuselage scrapes on the pavement...just like the real thing. Hmmm...anyone have a sound effect for that? :-) To be fair, the tail has always been scraping inside the FDM. It's just obvious now that's what is happening. Before, it looked like you were running out of elevator authority. And I agree, a scraping sound would be really nice ear candy, and very easy to implement. I can just set a /sim/fuselage-contact boolean whenever one of the non-gear contact points is touching the ground. 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] tail scraping the 747
Erik Hofman wrote: To be honnest, I don't think anyone would even notice if the Boeing were tail scraping over the runway. For example, it is very comon for F-16 to hit the runway with their ventral fins on startup or touchdown. This is usually only noticed afterwards by the groud crew. True enough. But certainly some airframe touch situations are easily noticeable. Hauling back on the yoke of a 747 at 100 knots during a takeoff roll is guaranteed to be noticed, for example. :) I think, on the whole, a scraping sound would add more to the simulation experience than it takes away. Right now, it's very much non-obvious to the user when they've clipped a wing tip or tail. I think there's a training benefit to the sound, even at the expense of pure realism. On a side note, it would be nice to make a distinction between locations that would crash the aircraft (nose, wing tips) and part that just cause the aircraft to clip to the ground (belly, ventral fins). This is already done, in a sense. A crash is something that's able to force a gear or contact point through the ground plane. If this doesn't happen, then the contact was light enough not to bend the airframe (for some only vaguely plausible definition of bend, of course). There's really nothing special about the nose, for example. Light contact to the nose isn't going to kill the aircraft. The only reason it looks special is that, aerodynamically, you can't put the aircraft into a situation where a nose touch is light. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 question
Curtis L. Olson wrote: Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) This looks odd from an external view standpoint. It seems like we'd want a slight amount of positive alpha, but I couldn't find alpha in the property tree? The angle of attack property is available as /velocities/alpha-deg. No, I don't know why it's under velocities, either. :) One thing to point out is that FL180 is a very low cruise altitude, and 490 knots indicated (you are quoting IAS off the HUD, right?) is a very high indicated airspeed. At this speed, the aircraft will be producing significantly more lift than it would at a normal cruise altitude of FL360. In order to keep the lift at 1G, the nose needs to point down more. Remember also that angle of attack is an arbitrary number. Zero AoA is almost never the same as the AoA of zero lift. In YASim's case, zero AoA is defined as the X axis direction. The point of zero lift depends on several factors, most importantly including the camber and incidence of the wing. So basically, you have the plane in an unusual flight environment. Real planes are almost never flying this fast at this altitude; they'll be at ~300 KIAS or so and using the extra available thrust for climbing. I really don't know what attitude real jet would have under these conditions. You can try playing with the camber attribute of the main wing (which defines the zero-AoA lift of the wing). If you reduce it, you'll get less lift at low angles of attack and thus require less nose-down attitude to get the same lift. This can have nasty interactions with the drag computation, though. I can at least say that YASim solves for a cruise AoA as part of initialization and prints it along with the rest of the report. In the solution cruise environment, it is flying with a slightly positive AoA: something like 2-3 degrees if I remember correctly. 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] Sound vol/pitch transforms are like panelx/y/r transforms
Julian Foad wrote: Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: If you guys are thinking of changing the way we do linear function of a property value definitions in configurations, let me argue for a slightly different way to do it: The problem with specifying a multiplier (e.g. scaling or rotation) and an offset is that these two opperations don't commute. Especially when coupled with a syntax that is order-independant (you can *specify* the scaling last, but it still happens first, or vice versa) it's a constant confusion for the user as to what the final result will be, with the end result that the generated configurations are hacked up balls of goo. Be honest everyone: how many people have ended up typing random values into things like this trying to get the results they expect? I know I have. Instead, why not specify a range mapping. That is, input values in the range [a,b] get mapped linearly to output values in the range [c,d]. Input values outside of [a,b] can be clamped to that range before computation. This has a few advantages: + Out of bounds values are eliminated by the clamping step. This is especially useful for sounds, where beyond-maximum scaling factors cause distortion. + The offset and multiplier are specified simultaneously and implicitly, so the user doesn't need to remember any precedence rules. + No need to handle the mind-bending gymnastics involved in negative scaling factors if you want something to scale in the reverse direction. (Negative scaling factors invert the direction of the offset only if the offset comes last; no wait... you get the idea). This is the way that YASim handles its property input and output specifiers*, and it's worked pretty well. Take a look at the reaction jet definitions for the harrier for an example of how much complexity this can eliminate. Andy * albeit not in a standard way -- YASim doesn't use the property tree parser, since I didn't know about it. It uses the lower-level XML callback API. -- 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] Keyboard braking power
Julian Foad wrote: It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? This issue came up about a year ago. There really isn't any good resolution. Sometimes you really do want full brakes (short runway landings in the A-4, for example), and sometimes you want to brake gently. And IMHO asymmetric braking is more likely to be gentle, as it's used for steering. The only control input that makes sense for those requirements is an analog axis from a brake pedal. Anything else is basically a hack. My favorite hack, FWIW, was to have the on/off input affect the braking power slowly -- over a second or two. That way you could modulate the brakes yourself by changing the frequency with which you toggled the button. You can try this out right now with YASim, by adding a control-speed tag for the braking inputs. But it's still a hack -- sometimes you want to release the brakes right now, as with short takeoffs. 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] Yasim origin and model offsets
Jim Wilson wrote: After moving the AC3D model origin to where Yasim wants it (at the nose) the aircraft rotates fine. (Note that it appears the gear still compresses abit too much as when doing Curt's throw on the breaks at 40kts test, the nose comes very close to the ground). Yeah, the nose gear compresses by 2m, which is too far. I got better results by changing to compression=1 in the nose gear definition. But with that change it ends up too stiff, and tends to end up in an undamped oscillatory bounce on its nose gear. I need to get per-gear tunable spring constants and damping coefficients working; the automatically generated ones are almost, but not quite, good enough for all cases. Anyway, what I now remember is this: the camera position as configured for the chase view is always in relation to the FDM location. And in the case of Yasim that location is always the nose. Oh, good point. This will create problems for view direction too -- the viewer will expect to rotate around the center of the aircraft instead of the nose. But there are other places in the code that make assumptions about the location of the aircraft, too, and they have different requirements. The tile rendering and navigation stuff obviously doesn't care about a few tens of meters, but the altitude computation in the HUD (which is different from the agl property) does, and it uses aircraft origin as well. Or consider an ILS receiver, which really wants to use the location of the antenna on the 747, not the cockpit, c.g., or center. (I have no idea where this is, but I suspect it's closer to the tail, so that the main gear are what travel down the exact glidepath). Maybe we need separate origin offsets for all of these applications? Actually, wouldn't a sane default for the view code be to *always* pick a center point for the offset? That is, just pick the center of a bounding box computed from the model (or the FDM). This will match more closely to what the user expects in all cases I can think of. That being said, I'd be happy to put this to rest right now by moving the YASim origin for the 747 and A-4. :) 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] Yasim origin and model offsets
I wrote: I need to get per-gear tunable spring constants and damping coefficients working; the automatically generated ones are almost, but not quite, good enough for all cases. Well, that was easy enough. You can now use spring and damp attributes on gear objects to modify the default ones you get out of the solver. These are unitless scalars, specify 0.5 if you want half the damping coeffient, etc... I've checked this in, as well as a change to the 747 nose gear that fixes the wobble and bounce issues. Someone with more experience than I should try the result to see that I got it right. The nose gear now just barely bottoms out when you whip the nose down from a tail dragging situation with full braking and full down elevator, comes up but doesn't leave the ground, and oscillates once or twice. That seems like it would be the design goal for the real thing, but I dunno. Maybe it should have more bounce? Some of the other YASim planes could probably use some gear treatment too. The default damping is probably too stiff for the 172 and Cub, which have spring steel gear. 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] glass panel instruments
Jason Viloria wrote: Can anyone please tell me the state(or existence) of development on glass panel cockpit instruments on flightgear please. There's nothing working inside of FlightGear for this yet, but the OpenGC project (www.opengc.org) is available as a stand-alone app. You run it on a separate display, and it hooks to FlightGear over a socket. It's a little heavyweight for a direct port into FlightGear (right now, anyway, give the hardware a year or so to catch up), but would certainly be something you'd want to look at. I know I'd like to see something available for use in panel. Maybe not the full-on EFIS deck, but a digital AI or HSI would be great. 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] Engine models: start-up and commonality betweenFDMs
Julian Foad wrote: David Megginson wrote: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. Well, for the record, I think this is a great idea. It really wouldn't be hard at all to wire up an interface between YASim's Thruster class and an external engine/propeller representation. What's that bit about the separate output mp? An engine doesn't produce zero thrust at idle, just a low thrust. And manifold pressure isn't supposed to be related to thrust in a simple way, is it? I should have written power instead of thrust, of course. The real point is that the output power of an ideal engine at peak mixture is proportional to the mass input, which is proportional to the product of RPM and manifold pressure. So an ideal engine will produce zero power only at zero MP. ...which is ridiculous, of course. In the real world, engines have a minimum MP when the throttle is at idle, and produce near-zero usable power at that MP. This is because of all kinds of complicated internal losses (pressure drop across the intake valves, internal friction, you name it...). I couldn't simply assume that an engine that produced 200 HP at 29 inches of MP would produce 41 HP (6/29 of 200) at idle; nor could I come up with a good/broad/general thermodynamic argument for what those losses should be. However, I had an empirical number from Dave Luff that engines idle at about 6 inches. So I cheated and interpolated from that point instead. :) When I'm running this at idle, _egt comes out at 80 (kelvin); presumably this should be added to ambient temp (which is 288) rather than clamped to it: That sounds like a bug. I'd have to look more carefully at the physics to be sure. But adding the temperature to ambient is almost guaranteed to be wrong. There are exactly zero adiabatic processes that are symmetric with change of temperature; that's what the second law of thermodynamics is all about. More likely, I'm converting the units incorrectly or using a miscalibrated value for power due to the hack above. 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. One issue is that the moment of inertia for the Cub looks too big. The current value is the same as the one for the 172, which has a larger prop. All other things being equal, it should scale with the mass of the propeller; I'd try a value about half of the Cessna's. This will result in too much stored energy in the prop that has to be dissipated, and thus a longer run-down (and run-up) time. You could also try increasing the 10% of cruise torque value that gets used for internal friction. I don't have any good numbers for what is appropriate, so I guessed. This is the kind of value that could/should be made tunable via configuration. I'd *love* to see good numbers for propeller acceleration, however. If one of the Real Pilots out there could go out with a stopwatch and get us graphs of RPM vs. time for full throttle acceleration and cut-power deceleration I'd be eternally grateful. :) 4. That negative torque: Interpolate it away as we approach cruise RPMs, though, to prevent interaction with the power computations. Ugly. Actually, the only way the variable power is used after that point is to compute the EGT, and that wants to know thermally developed power anyway (i.e. excluding the starter motor contribution and the friction reduction) so that should be fine. The engine power numbers are also used to handle the propeller solution too. My thinking here appears to have been that I didn't want an extra value interfering with the solver in funny ways. It's possible that all the changes cancel out later; just realize that the numbers get used outside the function, too. By the way, the experimental values here were with j3cub-yasim because c172-yasim gives a solution failure for elevator. Oh dear, is there another solver issue? This works fine for me. Are you absolutely sure you have current YASim code and base package? Platform/compiler? This is the solution result that I see: YASim solution results: Iterations: 362 Drag Coefficient: 18.0245 Lift Ratio: 90.6643 Cruise AoA: -0.131865 Tail Incidence: 0.582091 Approach Elevator: -0.920007 CG: -2.404, -0.033, 0.218 For all this, my original aim was just to get simple things like a realistic cranking speed of about 100 RPM, and some rotation sound while the engine is spinning down after being switched off! The sound issue is trivial -- just have one sound for the propeller noise that scales with RPM, and another for engine noise that is gated on /engines[0]/running. The realistic cranking speed is just a
Re: [Flightgear-devel] multitex investigation
Roman Grigoriev wrote: ok it's done at startup but if we want to have landing lights moves we have generate second texture coordinates in realtime please give me hint where in flightgear it can be done? in tileentry? I'm not the right person to answer questions about the scenery tile subsystem, but you are aware of OpenGL's texgen features for doing realtime texture coordinates, right? If you set things up right, texgen will generate the texture coordinates for you dynamically from the vertex coordinates on the GPU, with no significant loss of performance. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Tony Peden wrote: BTW, you will rarely see the c.g. used as a reference point for dimensions on aircraft. First of all, it moves in flight. Second of all, it's very difficult to actually point to its location. That's my intuition too. David is correct, though, that most lightplane POH's use a nominal center of gravity as the origin for their weight balance tables. The front seat is N meters in front, the fuel tank is M meters behind, etc... But still, the goal here is to make communication between 3D artists and aero modellers easy, not necessarily to adhere to pre-existing conventions. An artist using Blender is much more likely to be working from a 3-view or a photograph; the c.g. isn't marked on these. Picking an easily recognized spot on the airframe seems like the best convention. Whether that be the nose or not, I don't much care. Other good choices would be the nose gear base, wing root, tail, top of the vertical stabilizer, etc... The nose seemed straightforward to me. In this case, the simplest solution is to bring up the 747 model in a (registered) copy of AC3D, drag it around so the nose tip lies exactly on the origin, and save it. I can do all but the last step. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson wrote: When the 3D model origin is set at the nose or cockpit, the aircraft is too far back on the runway at startup. So far back that the main gear is not on the pavement. It looks stupid. Ah, now I think I understand what you mean. I agree, the model placement looks dumb. But it's correctly dumb. If we were modeling off-runway ground handling, the aircraft would be bouncing (or sinking!) because YASim really *does* think the aircraft is off the runway. Moving the model origin only fixes the problem on the screen. The bug you are trying to fix is in the runway placement initialization code, not the model geometry. Right now it puts the origin just barely past the threshold, which is fine for light planes but not for jumbo jets. Even if you were going to try to do the Right Thing, you would have to deal with aircraft geometry. Real aircraft pull onto the runway with their nosegear on the taxi lines, and have to pull forward by different amounts depending on their gear geometry. Just moving the aircraft origin will never be sufficient. I agree, we need a per-aircraft runway startup offset (which would basically be the length of the fuselage). Alternatively, we could pick the *tail* of the aircraft as the coordinate origin. That would behave correctly under these conditions. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Burrito Jack wrote: Is fuel consumption modeled in yasim, or will it ever be? Someday. :) Right now, you can use --prop:/sim/fuel-fraction=0.2 to get an appropriate landing weight. Really, this would be very simple. Like I've said, I'm lazy. To be honest, I don't usually fly cross country in FlightGear. I'll set up the aircraft for whatever I want to practice (vertical landings in the Harrier are my most recent addiction) and just do the interesting parts. Fuel consumption ends up being superfluous under those circumstances. Lots of fuel in the tanks could also cause problems with landing right? I have tried landing several times but always bounce off the runway. Lots of fuel will cause fast approach speeds, which are more difficult and could result in bounced landings. But there's an honest bug with ground effect that is probably causing your real problem. I (literally) just checked a fix for this into CVS. Can you try that and see if it fixes things for you? Also, sometimes setting the flaps around 20-30 degs can cause the plane to shoot thousands of feet into the air. Has anyone else noticed this? Which version are you using? There were sporadic reports of this sort of behavior about six months ago, and I thought it was due to a flap drag bug that has since been fixed (maybe in 0.7.8 or 0.7.9). The way to exercise it was to (1) be going very fast (300+ kts); (2) be at a significant negative AoA; and (3) pop the flaps. The flap drag could end up pointing in the wrong direction and producing thrust proportional to speed; the aircraft would then speed up and produce more thrust, and the airspeed would diverge. Like I said, I think this has been fixed. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
I wrote:
Jim Wilson wrote:
How hard would it be to have a property that toggles hotspot
visibility? It'd be nice to be able to turn it on and have yellow
rectangles show up on the hotspots...
That's not a bad idea.
It's actually an astoundingly good idea, and implementable over lunch
to boot. :)
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property. I mapped a toggle event on this to a
spare joystick button, and had fun. :)
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)
Index: panel.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.hxx,v
retrieving revision 1.2
diff -u -r1.2 panel.hxx
--- panel.hxx 29 Oct 2002 19:44:03 - 1.2
+++ panel.hxx 5 Nov 2002 21:38:59 -
@@ -370,6 +370,7 @@
virtual ~FGPanelInstrument ();
virtual void draw () = 0;
+ virtual void drawHotspots();
virtual void setPosition(int x, int y);
virtual void setSize(int w, int h);
Index: panel.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.3
diff -u -r1.3 panel.cxx
--- panel.cxx 29 Oct 2002 19:44:03 - 1.3
+++ panel.cxx 5 Nov 2002 21:38:59 -
@@ -436,6 +436,21 @@
glPopMatrix();
}
+ // Draw yellow hotspots if directed to. This is a panel authoring
+ // feature; not intended to be high performance or to look good.
+ if(fgGetBool(/sim/panel-hotspots)) {
+glPushAttrib(GL_ALL_ATTRIB_BITS);
+glDisable(GL_DEPTH_TEST);
+glDisable(GL_TEXTURE_2D);
+glColor3f(1, 1, 0);
+
+for(int i=0; i_instruments.size(); i++)
+ _instruments[i]-drawHotspots();
+
+glPopAttrib();
+ }
+
+
// restore some original state
glPopAttrib();
glPolygonOffset(0, 0);
@@ -647,6 +662,25 @@
it++) {
delete *it;
*it = 0;
+ }
+}
+
+void
+FGPanelInstrument::drawHotspots()
+{
+ for(int i=0; i_actions.size(); i++) {
+FGPanelAction* a = _actions[i];
+float x1 = getXPos() + a-getX();
+float x2 = x1 + a-getWidth();
+float y1 = getYPos() + a-getY();
+float y2 = y1 + a-getHeight();
+
+glBegin(GL_LINE_LOOP);
+glVertex2f(x1, y1);
+glVertex2f(x1, y2);
+glVertex2f(x2, y2);
+glVertex2f(x2, y1);
+glEnd();
}
}
Re: [Flightgear-devel] Clickable 3D panel
Michael Basler wrote: Andy Ross wrote: Try the attached patch, which predicates the boxes on the /sim/panel-hotspots property. I mapped a toggle event on this to a spare joystick button, and had fun. :) Up until we'll have that pretty menu system soon ;-) would it be hard to bind a spare key to this by default? The toggling bit was mostly a joke. :) This is really only useful to people designing and debugging panels, and they're not likely to decide to do that in the middle of a long flight. They'll start up fgfs with a --prop:/sim/panel-hotspots=1 on the command line, edit their panels, and do a reset to see their changes. Unless there are applications for this feature that I don't see, they'll never want to turn the feature on and off interactively. There are a limited number of keys available. IMHO, panel hotspots aren't important enough to a general user to justify getting a key assigned to them by default. As you said, a menu option would make a lot more sense. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Manuel Bessler wrote: BTW: What is the difference between Speedbrakes and Spoilers? Typically spoilers refer only to flaps on the top of a wing. They spoil the lift generated and allow the plane to fly at a higher angle of attack for the same lift, and thus descend more steeply (or remain on the ground after landing). They also create a little drag of their own, but that is not their primary purpose. A speedbrake, on the other hand, is a pure drag device. Most of them are just flat plates that pop up when deployed. The A-4 has one on either side of the tail, and the Harrier has one on its underbelly. These things don't do anything but create drag. In the context of jetliners, I've seen the terms used interchangably to mean what I'm calling spoilers. Part of this is due to a blindingly stupid bug with ground effect that I discovered this weekend. Is there a way I could apply this to 0.8.0 which I currently have? Only by bugging Curt to make a new release. :) To be fair, building FlightGear from CVS really is no harder than building the source tarballs. 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] KJFK at night
Jim Wilson wrote: That's a little too small to resolve differences at 16bpp. Try the patch below. It decreases the lifting substantially. You will see a slight increase in z-buffer flickering but it isn't bad. Has anyone tried offsetting the lights in the direction of the viewer? While this might look weird for off-axis lights (they would appear to move a little bit as you turned or changed the view), it would (might?) require far less offset to get the same effect. Shouldn't be too difficult to try, anyway. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Cool, someone's playing with the 747. This model hasn't had a lot of tweaking yet beyond the engine thrust bugs that Jim Wilson dealt with a few months back. Manual Bessler wrote: Here are a few things I wanted to ask about the 747-yasim: Does it model the thrust reversers ? What about Speedbrakes/Spoilers ? No, no, yes. The spoilers control is mapped to the /controls/spoilers property, which doesn't have a default input binding. I have it wired to one of the thumbwheels on my Saitek throttle. Thrust reversers and speedbrakes wouldn't be hard to support, I've just been lazy. The Boeing obviously doesn't have a speedbrake, but the A-4 and Harrier should. There are still some (much harder) issues with drag scaling that I'd like to get fixed first. None of the planes need a brake right now, since they all sit way behind the power curve during approach and dump speed really fast. Bouncing: * Landing is relatively hard, esp. since it bounces much. Part of this is due to a blindingly stupid bug with ground effect that I discovered this weekend. It should interpolate the effect from zero at one span height to one at ground level, but it did the opposite. You got full effect instantly at about 200 ft, and the aircraft sorta bounced in midair, spoiling the approach. I don't have this checked into CVS yet, but it'll be there today or thereabouts. Another factor is the lack of automatic wing spoiler deployment, which helps a lot to keep the airplane from getting airborne again after a hard landing. This would require just a tiny amount of C++ code right now: watch the /gear[n]/wow properties and set the /controls/spoilers to 1.0 when they transition from false to true. This would be a great application for interactive scripting from the aircraft definition; a feature that has been long talked about but not yet moved on. And finally, I agree. The default gear damping is a little too light. YASim computes a default damping coefficient automatically, based on the weight of the plane and the placement of the gear. But it's not going to work perfectly for all aircraft. There needs to be a per-gear tunable for spring and damping coefficients, but there isn't yet. This is like the reversers/speedbrakes issue -- something unimplemented only due to my laziness. * Prior to takeoff, if I keep pressing 'b' and let the engines spool up to full throttle (or less), the front gear starts bouncing quit a bit after I release the brake. Well, pumping the brakes during the takeoff is hardly standard procedure; I'm not sure what the real aircraft would do. :) The joystick trigger is mapped to the wheel brakes, by the way. You can use this to get constant braking instead of pounding on your keyboard. The wheel bounce issue is real, though. In my copy, I got better results by changing the compression distance of the nose wheel strut from 2m to 1m in the Aircraft-yasim/747.xml file. This has the effect of making the nose gear much stiffer, reducing the pitch change from gear oscillations. Try this, and see if it feels better. I have no idea what the compressibility of the real thing is -- I made the 2m number up too. (BTW: the parking brake doesn't seem to work w/ the 747) Uh, true. This is trivial to fix, just add a mapping from the parking brake property in the 747.xml file. Everywhere you see: control-input axis=/controls/brakes[n] control=BRAKE/ add a: control-input axis=/controls/parking-brake control=BRAKE/ I don't know why this wasn't done to begin with. Maybe it's because I'm not sure how the parking brake functionality is handled on a 747; I'm sure it's more complicated than this, but this is a start. Another thing: It does not seem possible to start fgfs with the 747's engines off. This is true. The YASim jet model doesn't handle starting and stopping behavior. Unlike piston engines, starting procedures and behavior for turbines are very complicated, and vary widely from engine to engine. The idea behind YASim is to provide good and sane behavior for all aircraft, or at least as many as practical. I suppose I could wire up an eye candy starter, which spooled the engine up and down from zero while diddling the temperature and fuel flow variables in a vaguely plausible way. But features like realistic engine start aren't possible for this code; they'll need to wait for someone with the patience and dedication to model one specific engine (and electrical system, and APU, and...). :) Why are the four engines mapped to two thrust[n] properties instead of four ? Would it work if I map them to 4 throttles ? There are only default input bindings for two throttles. While I was happy leaving spoilers out of the default configuration, a 747 with its two starboard engines fixed at idle is kind of a showstopper. :) It will work just fine to map them to as many properties as you like. You can map any joystick/keyboard input to any property, and any property to any single YASim
Re: [Flightgear-devel] 747-yasim Questions
Curtis L. Olson wrote: Speaking of gear modeling in the 747-yasim, have you tried getting the aircraft up to say 40kts. taxiing and then hit the brakes ... there is clearly something going on with the 747 gear modeling that is not physically possible ... best seen when viewed from the chase view. Without having tried it, I assume you mean that the nose dives straight through the ground when the aircraft pitches down during hard braking? That's actually not a gear issue. What you're seeing is a difference in coordinate origin between the YASim description and the AC3D model file. The YASim origin is at the nose of the plane, while the model places it closer to a nominal c.g. at the back of the hump. So the nose of the plane drawn on the screen is actually ~25m in front of the real nose as modeled by YASim, and therefore moves more due to orientation changes. You can see a similar effect with the A-4 model. This is tedious to fix, so no one has bothered. There's also the question of whether it should be fixed in the YASim file or the model file. I contend that the nose is a much better origin, since a c.g. value is meaningless unless you have the mass distribution handy. YASim recomputes the c.g. dynamically anyway based on fuel load and cargo and whatnot. The FDM configurer and the model author might not be expected to have the same c.g. numbers (in fact, they probably never will -- most 3D artists aren't aero geeks), but hopefully they can always agree on the position of important parts of the airframe. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Curtis L. Olson wrote: Speaking of gear modeling in the 747-yasim, have you tried getting the aircraft up to say 40kts. taxiing and then hit the brakes ... there is clearly something going on with the 747 gear modeling that is not physically possible ... best seen when viewed from the chase view. Without having tried it, I assume you mean that the nose dives straight through the ground when the aircraft pitches down during hard braking? That's actually not a gear issue. What you're seeing is a difference in coordinate origin between the YASim description and the AC3D model file. The YASim origin is at the nose of the plane, while the model places it closer to a nominal c.g. at the back of the hump. So the nose of the plane drawn on the screen is actually ~25m in front of the real nose as modeled by YASim, and therefore moves more due to orientation changes. You can see a similar effect with the A-4 model. This is tedious to fix (for me, anyway -- I don't have a registered AC3D copy that can save), so no one has bothered. There's also the question of whether it should be fixed in the YASim file or the model file. I contend that the nose is a much better origin, since a c.g. value is meaningless unless you have the mass distribution handy. YASim recomputes the c.g. dynamically anyway based on fuel load and cargo and whatnot. The FDM configurer and the model author might not be expected to have the same c.g. numbers (in fact, they probably never will -- most 3D artists aren't aero geeks), but hopefully they can always agree on the position of important parts of the airframe. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Julian Foad wrote: For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). Are you sure? I thought this might be it too, and tried tracking it down. The 3D panels are loaded through the model code, and never get a chance to register themselves as the current_panel object in globals. Is there an invisible 2D panel loaded from somewhere else? FWIW, I still haven't been able to duplicate the rogue mouse click problem. If you're right, though, good catch. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Julian Foad wrote: Well, I'll put it this way: If I turn the 2D panel on and off with P while flying --aircraft=c172-3d, and note where a particular button is, and then turn it off so that only the 3D panel is visible, I can still click where the 2D button was as well as where the 3D button is visible. Heh, hard to argue with that. Indeed, there was no check for panel visibility in the input code. I guess we've never noticed because nothing was fighting for the same real estate in the past. This one-liner appears to fix the problem. And, since you were right, good catch. :) Andy RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Input/input.cxx,v retrieving revision 1.4 diff -u -r1.4 input.cxx --- src/Input/input.cxx 29 Oct 2002 19:44:03 - 1.4 +++ src/Input/input.cxx 5 Nov 2002 01:38:23 - @@ -379,6 +379,7 @@ if (puMouse(b, updown, x, y)) return; else if ((current_panel != 0) + current_panel-getVisibility() current_panel-doMouseAction(b, updown, x, y)) return; else if (fgHandle3DPanelMouseEvent(b, updown, x, y)) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson wrote: It isn't tedious at all, we can offset the origin to where we want without messing with the ac file *and* it won't affect the animation. Cool. Uh, how? :) Having the FDM origin at the center of gravity should improve the appearance of the 3D modeling since pitching of the model would appear more realistic. It wouldn't matter. The FDMs do the dynamics for you. You could put the origin of the model on Mars* and the model would rotate correctly on the screen so long as the origins agreed. The aircraft rotates about its real c.g., which has nothing to do with either the 3D model coordinate conventions or the YASim coordinate origin. * Well, not on Mars due to precision issues. Maybe Sri Lanka. It could be that the brakes are too good. If you locked the wheels up at 40kts the 747 _maybe_ would stop that quickly...not sure. It is quite a mass, as you know. I think the tires get a 0.6 dynamic friction coefficient. The way the physics works, the mass doesn't matter. Anything (aircraft, trucks, bicycles, roller blades) sitting in 1G of gravity on a flat surface decelerates by the same amount. The reason the real aircraft can't stop via wheel braking alone is because the brakes would melt. The tires could stop it just fine if you could put all the kinetic energy somewhere. The reason the pitch changes so much when braking is because the nose gear travels too far. Try the gear compression fix I mentioned earlier. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Jim Wilson wrote: How hard would it be to have a property that toggles hotspot visibility? It'd be nice to be able to turn it on and have yellow rectangles show up on the hotspots...or something like that. Thinking about making hotspots to control some of the 3D instrumentation. That's not a bad idea. It shouldn't be that hard, actually. Just draw a final layer around the hotspots with some OpenGL lines. The existing layer offset code would insure it gets drawn on top of the rest of the panel, and the matrix environment is already set up so you can draw 2D panel coordinates directly. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] One down, two patches left
I give up; I withdraw the HUD patch. Too many people want the code to stay the same to make it a good basis for doing 3D cockpit work, even with the compatibility hook in place. (Although I suspect that if people tried it, they might change their minds). I'll maintain it for my personal use, of course. Folks can ask for it if they want it. Has anyone looked at the other two? One of them just makes three FDM values available from the property tree, is required for some cool stuff I've been doing with the Harrier, is harmless, and really shouldn't generate any objections at all. The other, which makes mouse clicks work in a 3D environment sounds like a win to me. I know for a fact that people have asked for it multiple times. Who hates this one? :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Norman Vine wrote: Andy Ross writes: Sure there is. But the ladder will only work at 1024x768 with the default view direction and field of view. The current HUD ladder works fine at all resolutions with all view directions once you accept the fact that it is a 2D Overlay instrument that is designed to have a fixed layout We're arguing from different definitions. I want the horizon line to line up along the horizon, the N degree lines to be N degrees from the horizon, the glide path indicator to lie along the right glide path, and the velocity vector to point where the aircraft is travelling. The existing HUD can only do this at one resolution, one field of view, and one aspect ratio. Since these aren't the values that I use (well, except aspect ratio -- I have a 4:3 monitor like everybody else), the existing code doesn't work for me. This isn't because I'm wrong or right, but because I want the code to do different things. I'm sorry you don't like my requirements. I honestly did try to accomodate yours. Really. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable panel and zooming
David Megginson wrote: To simplify things, I've just committed a base-package patch to bind zoom-in to '+', zoom-out to '-', and return to default zoom to '='. Ooh, this brings up a good point. Is there a place to store a default zoom, or are you just hardcoding the normal default? I have a button on my joystick mapped to mean recenter view. But the problem is that recentered means different things in different contexts. The A-4 needs to look down by 17 degrees, and I use a 65 degree FOV to keep the whole panel on the screen. The 172 is mostly straight ahead, as is the Harrier. It would be nice to store a per-aircraft (or per view?) default view configuration somewhere and have my button and the '=' key binding copy that onto the current view. Does a convention like this exist? 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] DEM, sigh
David Megginson wrote: I have a feeling that we won't have good, free geodata for the rest of the world until the U.S. decides to provide it for us, Actually, wasn't there a shuttle mission about two years ago which did a high-resolution radar survey of the whole planet? I remember reading somewhere (maybe here) that the intent was to make the data publically available after some number of years. Does anyone remember this project? 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] DEM, sigh
I wrote: Actually, wasn't there a shuttle mission about two years ago which did a high-resolution radar survey of the whole planet? Duh, that's what the SRTM link is about on the page Norman sent. I followed through to the project webpage at JPL (http://www.jpl.nasa.gov/srtm). In their words: 1. Systematic processing of the global data set on a continent-by-continent basis, with North America first. As each continent is completed, the data will be delivered to NIMA where it will be edited, verified, and brought into conformance with National Map Accuracy Standards. These 'finished' data will then be returned to NASA for distribution to the public through the United States Geological Survey. Current plans call for the first continental data to be available by Summer, 2002, with the whole job completed by the end of 2002. They appear to have gotten the Continental US on their site by September, so it actually looks like their on schedule. Just a few months more? This sounds great. 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
