Re: [Flightgear-devel] x++ The World's First XML-Based ProgrammingLanguage
Jonathan Polley wrote: > Jon Berndt wrote: > > Just because something *can* be done doesn't mean it *should* be! > > Actually, I was going to say that it was another solution in search of > a problem. I honestly thought it was a joke, but the website looks serious enough to believe. Good grief. But it's not the first -- XSLT is a full XML-based programming language, thankfully tailored to a much smaller problem area. And XSLT is still a horrific monster, IMHO. I still remain dumbfounded at the number of otherwise bright people in this world that believe that needlessly gluing together two useful technologies results in improvement. What happened to encapsulation? It's not just for programs anymore. :) 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] How to draw lines?
Martin Dressler wrote: > I wan to draw lines in instruments layer. I made a new subclass of > FGInstrumentLayer and in draw method I do > glDisable ( GL_TEXTURE_2D ); > glBegin(GL_LINES); > glVertex2f(-100,0); > glVertex2f(100,0); > glEnd(); > > but it doesn't draw anything. But when I draw something with GL_POLYGON it > draw fine. > > What I should to change, please? Is this on the 3D panel or 2D? In 3D, the texture layers are drawn with GL_POLYGON_OFFSET, which by default does not apply to lines. For reasons having to do with a metaphor collision (lines are "thick" in screenspace, while polygons aren't) lines don't work well with glPolygonOffset() -- you have to play with the factor argument. Try using glVertex3f() and specifying a Z coordinate of about 0.01 or so; that might work. But are you actually sure you want to be drawing lines? Lines are not the natural medium for 3D hardware -- they don't antialias well (if at all), don't have an easy way to associate their "size" with the world around them, and don't behave nicely under changes of perspective. Almost always, you'll get better results by using a 1D texture to draw your lines. Picture a 4x1 GL_LUMINANCE_ALPHA texture that looks like this: 0 0 0 255 255 0 0 0 Set your line color with glColor, and draw the line in world-space coordinates as a "thicker" (4x as wide as the intended line) quad modulated by the texture. Now, the line will be nicely antialiased, will look correct when viewed at funny angles, and will be less likely to excercise slow paths and funny behavior in the OpenGL driver. You'll send about twice as many vertices to the driver, but that's not likely to be significant when compared with the terrain complexity. 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] see-through instrument panel
Alex Romosan wrote: > just took a look at the outside view with the cessna and i noticed you > can see the instrument panel through the fuselage. this is on linux > with a geforce card. picture at: What size depth buffer are you using? The default is to use the same depth as the color bits, so if you're in 16 bit color mode, you're probably using a shallow depth buffer. You could try a depth of 24 in your XF86Config-4 file, and see if that fixes it -- I don't see this behavior under XFree with either a GeForce 2MX or GeForce 3. Right now, there's a very large offset placed between layers of the panel, which can bleed through on shallow depth buffers. When the jitterbug (which causes the panel layers to jitter "through" each other) is fixed, this can hopefully be reduced to a point where it is invisible on most hardware. 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] GS needle sensitivity.
Curtis L. Olson wrote: > I had someone recently comment that they thought the glide slope > needle was too sensitive in FG. Can anyone comment on this? I think the glideslope needle is too sensitive in FG. :) I don't have any harder evidence either, but I'll throw in my 2¢ anyway. I've been practicing constant AoA landings in the A-4 over the last week or so (getting really good at them now, gonna have to code up arrestor wires pretty soon...), and using the ILS receiver to train my eyes to recognize the right glideslope. It's definitely very touchy, even 2-3 miles out. My sense is that maximum deflection of our instrument is only a small fraction of a degree, when it should* be something more like 1° or so. Andy * Where "should" means "what other simulators seem to do" and not "what real equipment does". -- 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] A-4 "manual"
I've been doing really well recently with my A-4 landings, so I wrote up a putative "Flight Operations Manual" to record the stuff I've learned: http://www.plausible.org/a4-ops/ Obviously, I've never actually trained with the Navy, so lots of this is guesswork based on data points I've picked up from research and/or experience with the flight model. So it's not necessarily something you'd want to hand to a real pilot, but it should help to get FlightGear geeks up to speed on this stuff. If folks like it, it would be nice to put it up on the flightgear.org site. A set of operational manuals for all of our core models would be a really good thing to have. I need to write up something similar for the Harrier, which is even harder to land. :) 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] concave mirrors
Curtis L. Olson wrote: > My initial speculation is that the position of my eye is an important > factor that isn't addressed by the simple theory, but from the simple > theory, I don't see how that could be possible. One nit is that the simple theory only works for small mirrors (large curvature radius to diameter ratio) and for reflections that are close to the axis of the mirror. Large mirrors really need to be paraboloids and not spheres, and off-axis images will experience distortion (the focal "plane" is only flat in its middle). But these aren't issues here, and wouldn't explain what you saw. > If I move my eye point away from the mirror and watch myself, I seem > to hit the singularity at 40" which is the center of curvature, not > the focal point. Yes, I've verified that the radius is indeed 40" > and is most definitely not 80". This sounds right. At 40", your eye is in the center of the mirror. It is seeing its own reflection in every direction, which looks like a singularity. You should also see a singularity at 20", but that's a little different: At the focal point, your eye's reflection should be discernable, but everything else in the world will appear to be coming from all directions. If you didn't see one at 20" at all, then I'm confused too. :) Remember that your eye and the background are separate objects at separate distances. Objects at different distances have different focal planes (especially when those distances are already on the order of the focal length). Only objects that are infinitely far away will converge exactly at the focal point of the mirror. The mirror is not a pinhole camera. 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] MP what data to send
Christian Mayer wrote: > I don't know if zipped packages help much for the kind of data you are > sending. You can only compress redundant information Amen. He speaks the truth. But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like "zip" are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be "near" the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a "zone" coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. + Orientation can be very crude -- the eye has trouble telling degree differences less than 5 degrees or so. That means that the whole orientation can fit in something like 11 bits with creative packing (consider quantizing a 4D "sphere" of 2048 quaternion points and picking an 11 bit encoding for them). With a little extra work, you can transmit a "zone" as above, to get constant orientations (approach AoA's, for example, that the eye could tell are wrong if it looked carefully) exactly right. + Likewise, velocity needn't be terribly accurate so long as it is retransmitted regularly. No more than +/- 5 knots or so is fine for updating the position display. If you need more accuracy for ATC purposes or whatnot, that can be done with a different packet much less often. + Rotation rate, linear acceleration and rotational acceleration can be skipped entirely. These values are useful only to an FDM, or perhaps to a cockpit interface. Simply display them using a time-interpolation of the values you already have. The eye won't be able to see the errors unless the update rate is very slow. + If you really want to be macho, you could investigate fixed huffman encodings for the different values. Position changes are more likely to be horizontal than vertical. Typical velocities are very likely to be near the nominal cruise speed of the aircraft. Upright orientations are more common than inverted ones, etc... This could probably get you another few bits per value, on average. But usually this isn't worth it. It optimizes the common case, but often makes the "interesting" cases (say, a dogfight) perform worse. Most users are going to want better performance in the interesting situations. Most of this probably isn't worth it. But it's kinda fun stuff to think about if you really need to pack those bits in. 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] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
Victoria Welch wrote: > No jstest or jscal here and I have yet to track them down for > something other than SuSE or Debian (or a tarball that has be be > compiled into the kernel...) These are userspace test programs, not the kernel driver. They really should have been installed with your distribution. On my Red Hat 7.[23] boxes, they are in the "joystick" package. Definitely get these and try them first -- this is the best way to tell whether the problem lies in the hardware, driver, or plib/FlightGear. 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] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
Jim Wilson wrote: > Was in sound card hell myself a few nights ago, so I can relate. > Finally decided my time was worth something and went out to buy an > sblive You weren't by any chance trying to make the built-in sound on a KT333 motherboard work, were you? I got bit by exactly this problem. The answer turns out to be that the VIA 8233A south bridge dropped a feature from the 8233 used by the kernel driver (but, because it looks like a newer/compatible version, Red Hat detects and installs the original driver anyway). The newest ALSA pre-release drivers have support. I just installed them in OSS-compatibility mode, and things worked great. The sound quality is surprisingly high for an on-motherboard card. Also, if you do have one of these motherboards, definitely install a 2.4.19-rc1 kernel. The stock 2.4.18 code doesn't recognize the IDE DMA hardware (not VIA's fault this time -- the Linux IDE driver is just conservative about what hardware it *knows* is bug-free) and falls back to PIO mode for disk access. My machine would lock up for significant fractions of a second while doing big disk transfers. 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] New textures
Erik Hofman wrote: > Today I've sent some new textures to David (which he hopefully will > commit somewhere in the next weeks). But the result is such that I > want to let you know about it: Wow! This is magnificent. I've always hated the city texture (too yellow, too nondescript, maybe the scale was wrong?), but was too shy to criticise it for lack of ability to make a better one. :) I looked really hard, and couldn't find the texture seams. How did you manage to get this to tile so well? Where is the photo from, btw? Amazing, truly. 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] dc3.xml questions and suggestions
Dave Perry wrote: > I have continued to work with the dc3.xml for yasim and some of the > numbers in the original file seem inconsistent with the 3D model. > Here are my questions: The model and YASim description don't agree exactly. The biggest difference is (I think) the location of the origin. YASim puts it at the tip of the nose, whereas the model uses a nominal c.g. instead. This can be fixed by adding offsets to all the YASim coordinates. I did this for a copy of the A-4 (that, er, I haven't checked in), and it made the model animations much better. What I did for the A-4 was pull it up in ac3d, find the coordinates of the nose (note that the axis conventions are different), and subtract those values from all the coordinates in the YASim file with a perl script. > 1. Shouldn't the z value for the wing be -0.95 as the z for the wing > is for the root mid cord. This is a low wing. This matches the tank > and the engines better also. This looks like a typo. Uh, yup. That looks pretty wrong. I'll fix this tonight; I think I still have the sheet of paper with all of my original 3-view measurements. :) > 2. The z value for the tail wheel, z=-1.5, seems to leave the tail > off the ground at rest in the 3D model with compression="0.2". I have > tried increasing the compression to 0.3 to 0.5 or increasing z to > -1.0. I don't think the tail wheel compressed very much at all -- just the compression of the tires. My original 20cm value was almost certainly too high already (I made it so for numerics reasons -- very short compressions lead to correspondingly high spring constants, which increase the likelihood of the tail "bouncing" unphysically due to aliasing interactions with the 120 Hz integration interval. I figured that no one would notice an extra 20cm of "squish" in the tail on hard landings.). The best thing to tune is almost certainly the tail position. But only do this once the coordinate origins match. > Then the over-the-nose visibility is terrible. In a real dc3 it was > not so great until the tail came up in the takeoff roll. Visibility issues really need to be addressed using a 3D panel, which the DC-3 doesn't have yet. Right now, the panel lives at the same place on the screen regardless of what the resting orientation of the aircraft is. The Right Thing is to figure out a position for the panel inside the aircraft's coordinate frame, and fix the panel there. This then begs for a 3D-modeled cockpit environment, though, to avoid the "panel floating in space" effect. :) > 3. Is there a way to add damping or make the stiffness of the > compression for the main gear? It is very easy to get an oscillation > the feels like a pre-bounce while accellerating on the mains or while > rolling out from a wheel landing. Um, no, although there's no good reason for this. The spring constant is currently computed automatically as sufficient to support a landing at 3x the vertical velocity of a normal 3 degree approach. The damping is sufficient to critically damp a normal landing. This works surprisingly well for most aircraft, so I never added the ability to tune these parameters. You're the first one to really worry about ground handling in such detail. How would "spring" and "damp" attributes on the tag sound? These would be unitless numbers, so spring="2" would indicate a spring constant twice as high as the normally computed one, etc... > 4. Does yasim report an actual Center of Gravity? I know that it > checks to see if the approach config can be achieve with trim. This > would tell me if I was going overboard with the ballast. There's a C.G. line at the bottom of the solution report. I believe it's for the approach configuration. Thanks for all your work. I'll try to get you an origin-consistent model ready tonight, with support for the gear spring tuning. 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] MP what data to send
Frederic Bouvier wrote: > And what happens with deltas and positions when you will lose UDP > packets ? How will you restore the correct position or orientation ? > Perhaps, from time to time, it will be good to send absolute positions > to resynch. Yes, this is a requirement. Sending unreliable deltas requires that there be a reliable transport for the value that the deltas are computed from. That was the idea behind the "zone" suggestion I made. The "zone coordinate change" packet would be sent rarely, and would require and ACK from the client and retransmition on failure. Blindly relying on the packets to arrive correctly and in-order is not an option*. Andy * Except on a local network. On a single physical network, the ethernet standards handle retransmission on collision for you, so packet loss at the IP level can be ignored. I'm not sure if this is true for ethernet derivatives like WiFi, though. -- 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] ANN: a new dimension to FlightGear
Gouthas, Themie wrote: > I dont think the alpha sorting code was ever comitted, so currently > I dont beleive PLIB will alpha sort. I'm not sure this is a great idea in any case. There are a *lot* of these objects, and doing an NlogN sort of them (with attendant geometry processing to get the distances, not to mention the cache effects of doing an extra sweep over all of them) every frame is likely to be awfully slow. Hacking around the issue by diddling the rendering order (and maybe double-rendering problem objects like nearby clouds) sounds like the best idea to me. We could also investigate the use of destination alpha, which is available and fast on high end hardware these days. 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] Dynamic scenery notes
I got a chance to try the dynamic scenery last night (in lieu of implementing the gear bounce/damp tuning for Dave Perry -- sorry). Wow. Simply stunning. :) Abject praise out of the way, here are the nits: The cowbox is too small. At only 1m high, it's really a more appropiate size for a sheepcase. Cows (at least the big north american ones that match the texture) are 1.5-2m tall at the shoulder, and often 3m long. I doubled the size to 2x4, and found the results more satifactory. The slightly-too-large size is hidden by the sparseness of the scenery. At the other extreme the 8 story building, while scaled correctly, is too large. Buildings this large are very rare, and occur in large numbers only in downtown areas that are better handled by "real" static scenery. I'd suggest replacing the "urban" scenery object with something like a 2-3 story building, or perhaps a cluster of small buildings. Right now, you can look accross the bay from San Francisco and see a huge urban skyline stretching from Oakland to Fremont which isn't even close to what's there in real life. My reading of the code is that there is a separate ssgTransform node in front of every one of the objects. That's likely to be a performance bottleneck, if the OpenGL matrix state has to change every four vertices (most GPUs want to flush the stream when the matrix changes). Instead, why not "pre-compile" the scenery objects for each tile into a single vertex buffer at load time. This is really easy -- step through each object and add the appropriate offset to each model vertex as you copy it into the vertex array(s). Then you could draw them all at once with no state changes whatsoever (and even get fancy in the future with stuff like compiled vertex arrays, NV_vertex_array_range and whatnot if you like). Even better, you could get a very cheap "continuous LOD" by drawing a distance-dependent prefix of this vertex buffer. That is, draw only the first N objects based on your distance from the tile centroid. Writing a new ssgLeaf node type really isn't so hard -- take a look at the fgPanelNode implementation for a minimalist 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] Randomly-placed objects, take 2
David Megginson wrote: > Norman Vine wrote: > > Win2k PIII 733 256meg Geforce2 GTS 32 meg Latest certified WQL GFX > > drivers from NVIDIA at default startup location no HUD no Panel > > > > Latest changes~17fps > > your original code~32 fps > > no dynamic objects ~75fps > > Here's what I get sitting still at the default location, no panel or > hud, with a GeForce2Go, 32MB, 800x600x32, with the latest Linux > drivers (I'm using the latest plib CVS, but I assume you are as > well): > > no dynamic objects: ~40fps > dynamic objects (latest code): ~34fps > dynamic objects (old code): ~32fps I actually see numbers that are more in line with Norman's (Athlon 1800XP, Geforce 3 Ti200, 1280x1024 32bpp, current code as of last night): the ~70 fps I see without dynamic scenery at startup at SFO drops to 40 or so when I turn the dynamic object on. This effect isn't severe, but it's enough to be worrisom. Certainly the dynamic scenery is taking up a significant chunk of the current render time, which makes it a good candidate for optimization. This is something that I think we need to look at more generally: right now, FlightGear is making rather poor use of the graphics hardware on fast cards. There was a thread on plib recently that showed that the current tile renderer is rendering lots of tiny ssgLeafs instead of a single large buffer. This tickles a bad code path through ssg, which wants to render each ~10 vertex leaf from a separate vertex array (drivers don't optimize this case well -- the "fix" being discussed was to use plain old glVertex (!) calls, which turn out to be faster for such small objects). Almost everything we render (other than the cockpit and model animations) is static geometry. In principle, we should be able to ship this off to the card in a big chunk. In practice, though, we end up no better than 1990-era code, which sent each vertex across the bus in a separate transaction. As we start adding geometric complexity to the scene, we really should look hard about how it's done. I see some support in plib for using display lists, although it looks like it's #ifdef'd out. 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] FW: [Plib-devel] ssg vertex tables tuning
David Megginson wrote: > Norman Vine writes: > > I got a considerable boost in the frame rate from the following > > patch to PLib. < ~25% at default startup location > > > > > I am trying to determine if this also true for 'most' systems > > before advocating it's inclusion into PLib > > I saw a pretty-nice boost as well, for what it's worth. GeForce2Go > 32MB, Linux drivers, 1600x1200x32 LCD. I don't remember what it was, > because I've been using the patched plib now for over a week, but it > was at least 15-20%. I tried it too, and likewise saw a similar increase in framerate. Nonetheless, I think this is the Wrong Solution. What this patch does is test at render time whether or not the vertex array is "small" or not. If it is small, it renders the leaf with glVertex3f() calls instead of using the vertex arrays. Gack. Now, for plib as a library, this is a fine optimization that's probably worth including. I have no objections there. But for FlightGear as an application, the *real* performance bug is that we're generating really tiny ssgLeaf objects. Each tile is a single piece of static geometry. There's no reason that it couldn't live in just one vertex array (or maybe one per texture). Or be stored in a single display list, etc... But clearly the optimal performance solution we're looking for is not iterated glVertex() calls. :) 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] FW: [Plib-devel] ssg vertex tables tuning
Curtis L. Olson wrote: > I'm not claiming we are currently optimal, but you also need to > consider that by grouping your low level structures into larger > chunks, you reduce the ability of the scene graph to do an early cull > of non-visible stuff. Making larger chunks needs to be balanced > against the benefits of scene graph culling that smaller chunks bring. The majority (I'm guessing 70%) of tiles are either rendered in their entirety or culled in their entirety. The tile would seem, to me, to be just about the right granularity for doing culling. Certainly culling on tiny 10 vertex objects is too fine-grained, no? You can DMA a *lot* of vertices across the AGP bus in the time that it takes to do that cull. If my 70% guess is correct, then doing culling at a tile level will send 15% (the remaining 30% of tiles are on average half-invisible) too many vertices to the card for each frame. Rendering out of large vertex arrays instead of doing glVertex() calls has to be worth at *least* 15%. 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] Night lighting revisited
Norman Vine wrote: > For example the a4 behaves differently then the c172 in this > respect. Discover what is different and the lighting problem should > be 'illuminated'. Curtis L. Olson wrote: > People who understand the opengl lighting model better than I do > might notice that I haven't mentioned the specular lighting > compenent, which opengl supports as a way to emulate 'reflective' > surfaces. If we are seeing some strange lighting effects perhaps > the models have some kind of specular component that isn't getting > turned off properly at night? Good catch, both of you. All of the materials in the a4-blue.ac file have a 50% specular coefficient, the c172 file has 0. While some specular probably isn't wrong for the A-4 (the Blue Angel's used glossy paint, of course), 50% is certainly way to high. It's also used for stuff like the cockpit panel, which is clearly not specular. I think perhaps the original author misunderstood what specular means -- even the lights (which are, by definition, 100% emissive) are listed at 100% specular. I changed all the specular components to zero, and things look much saner in my copy. 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 dc3.xml edit
Dave Perry wrote: > I have continued to tweak the yasim dc3.xml. Attached is what I have > settled on. Sorry, I didn't get a chance to get to this over the weekend (wedding plans...). If anyone else has flown it and feels comfortable, feel free to check it in. I promise to get to it tonight, really I do. :) > The CG is at x=-8 meters (still 1 meter aft of the center of the root > cord) via negative ballast in the tail. I could not get to this CG > w/o increasing the length of the hstab to 3.5 meters, as the trim for > approach solution always failed. I got the lengths off of a 3-view diagram that may or may not have been correct. This sounds fine to me. > The hstab effectiveness="4.2" with a flap effectiveness="0.5". That sounds kinda high, but then we should expect to have a more effective surface in the absence of prop wash. If it doesn't cause any other weird effects, it should be fine. > I notice I am holding a little right aleron all the time. It may be > my imagination, but when I use the external view from the rear, it > looks to me like the right aleron is ever-so-slightly drooping and > the left aleron is slightly up when my yoke is neutral. And when I > add the right aleron to keep the wings level, this goes away. Has > anyone else seen this in yasim? Check the value of /controls/aileron-trim. In the past, I've seen this set at startup to a non-zero value (0.055, if I remember correctly). I believe this is a magic tuning value that was added to the JSBSim 172 at one point, but I was never able to track down where it is coming from. Setting it to zero at runtime, on the command line, or in the dc3-yasim-set.xml file should fix this. Anyone else have an idea of where this value 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
Re: [Flightgear-devel] Re: lighting
Melchior FRANZ wrote: > ... and given that Andy posted this on the 28th, the suspicious > changes could be these: > > | Log Message: 3D panel support from Andy Ross Could be. These changes moved the panel rendering into the main scene graph. If the panel code changes any OpenGL lighting state without setting it back, then this could cause symptoms like this. We just need to find out what's wrong and where it's being set. I'm fuzzy on what the exact problem is, though. Could you post a screenshot? 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: lighting
Curtis L. Olson wrote: > When you say moved panel rendering into the main scene graph, do you > mean [...] or do you mean the panel rendering code get's executed as > a call back from some ssg node [...] ? I mean that one. :) There's a tiny "FGPanelNode" ssgLeaf class that wraps an FGPanel object. It sets up the matrix stack appropriately and then calls the panel renderer as normal. Does anyone know off the top of their heads if the panel code changes the OpenGL lighting or material state? If it does, then this will be a really simple fix. 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] [PATCH] tdfx & fog
Melchior FRANZ wrote: > 1 would fix my problem. BUT: 40 only breaks the fog in the scenery, > while it works well for the instruments. So I suggest to let > POFF_UNITS be 40 but to reset the PolygonOffset to -1 or zero after > having drawn the instruments. This should also work for all other > cards. (Please verify and apply!) Is this not done already? I'm pretty sure that I reset the offset at the end of panel rendering. If I didn't, then this is quite obviously a bug. 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] defaults
Curtis L. Olson wrote:
> The preferences.xml file specifies the c172 as the default. It
> appears that even if you request a different aircraft as the default,
> the c172 config files get loaded first anyway, then the alternate
> config file is loaded with the correct aircraft.
THAT'S IT!
Dave Perry posted a few days back ("Pulling to the left trim?") that
he was seeing a out-of-roll-trim condition on all the YASim aircraft
that didn't have an explicit setting for /controls/aileron-trim. I've
looked at this in the past, and noticed that this property is always
set to (I think) 0.055 on startup.
I was never able to track it down; but that's it, clear as day. :)
[I'm back, by the way. Give me a few days to sort out the
post-wedding clean up and write thank-you notes (and read the 1000
messages in my flightgear folder), and I'll be able to start working
on things again. The top of the list currently is the jitterbug and
translating mouse clicks onto the existing "hybrid" 2D/3D virtual
panels.]
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] Help: Current Ground Elevation
Norman Vine wrote: > FWIW - I really don't understand why the FDM folks haven't been using > this as I wrote it several years ago so that one could get an > elevation per wheel Landing gear struts compress, so there isn't a single point of intersection. Worse, they don't always point down. Even worse, the ground isn't always flat, so a plumb bob won't always tell you the right point even for a vertical landing gear strut. Elevation is the wrong metaphor for this problem. As is being discussed on the plib list, what is really needed is a generic vector intersection test. That would clobber both the mouse click picking problem and the gear strut test in a single blow. 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] Internationalizing FlightGear.
Curtis L. Olson: > Well the difference is if you have one menu.xml for each languange, > then when someone adds a new option to the default menu.xml and > forgets to add it to all the other languange's menu.xml files you have > a problem and you are headed towards a big mess. This is true, but it's handlable. The way the Gnome i18n stuff works, the program is guaranteed to have american English text for everything. These strings are often hardcoded, and are used as the hash keys for translation lookups. So, in the worst case situation, a user of an internationalized program with incomplete translation sees the correct English text for the missing items. Since, sadly, this happens all the time with translated programs anyway, it's not a huge bug. :) Even better, since the translation tables are stored by themselves in (reasonably) non-threatening text files, non-technical users can go in there on their own, find the broken translation and fix it. The other big advantage to storing all the translations together per-language is that it better optimizes the work done. Typically, one person will do the translation for a single language, as Marcio has done for Portuguese. If you make them sift through all the translations for the the whole UI structure (which is probably split across many files), their task is more difficult and technical. Or stated another way: if you store the translations per-language in a single text file, the maintainer need only know English and the translation language and be able to edit an XML file. If you store it in the UI description too, then they need to understand the FlightGear UI structure as well. This shrinks the number of translators available, since they now have to be developers too. 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] Accelerations and Rates
David Megginson wrote: > In flight.hxx, some of the *dot* values are referred to as 'rates', > and some are referred to as 'accelerations' (i.e. rate of change in > rate of change). So, here are some specific questions: Strictly, the dot notataion refers to time derivative. So, if you have a variable X, "X dot" (written, unsurprisingly, as an X with a dot over it) is the same as dX/dt. "X dot dot" (two dots) is d^2X/dt^2, etc. If X refers to a position in meters, then X dot is the velocity in m/s, and X dot dot is the acceration in m/s^2, etc... This is presuming that the second is the canonical time unit (which it is). > 1. For those that represent angles (lat/lon/alpha/beta/phi/theta/psi), >what are the units? radians/sec (rate of change), radians/sec/sec >(acceleration), or something else? > > 2. For those that represent velecities (v-dot-local, v-dot-body), what >are the units? feet/sec, feet/sec/sec, or something else? > > 3. Wouldn't radius-dot just be a straight-velocity (i.e. rate of >change in the geocentric radius)? What's the unit in that case? Presumably the units are unchanged from the original. If lat/lon are in degrees, lat-dot will be in degrees per second. It's worth pointing out that there is a *lot* of duplication in the variables in flight.hxx. IMHO, the FDM's shouldn't be responsible for producing output in every coordinate system imaginable. We should just pick one and do the translations using a SimGear accessor library. For reference, YASim does all of its internal mechanics in a geocentric cartesian coordinate system. It never usees anglular measures except at the interface level. In these coordinates, the aircraft state is pleasingly simple: position: 3 doubles orientation: 9 floats (I use a matrix for simplicity; a quat would be smaller) velocity: 3 floats rotational velocity: 3 floats acceleration: 3 floats rotational acceleration: 3 floats All of the other flight.hxx output variables can be computed from these as needed. The only extra piece of information I can think of being necessary is the location of the cockpit, for the "pilot acceleration" values. But a good case could be made that the location of the cockpit is part of the 3D model, and not the FDM data 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] Internal compiler error
Richard Bytheway wrote:a > As mentioned in the Sig11 FAQ (link above), ensure that all the > hardware in the PC is the correct spec, and that nothing is > overclocked. Try underclocking as a possible workaround. If your RAM > is on more than one stick, try removing different parts of it. Oddly, that FAQ fails to mention the single best tool for detecting these problems: http://www.memtest86.com/ Get this and run it. It's a boot image, so if you don't have a Linux installation (LILO and GRUB can run it just like a kernel) or a floppy, you may have to do some gymnastics. Leave it running overnight and see what you find. You'd be amazed at the number of "working" machines in the world have slightly bad RAM. One of my boxes, which seems perfectly stable, gets about 1 error every 10 hours. If you see any more than that, consider replacing your memory or motherboard. 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] Internationalization
Frederic Bouvier wrote: > I made a french translation but unfortunately, accented characters ( e > acute or a grave for instance ) are not present in the current font. I > think the problem will show up for several languages. Should we have > to provide a specific accented font for languages like nordic or > french ? The current font is ASCII-only. Doing an ISO 8859-1 (or -15) version would be pretty simple, although visual quality might suffer if we have to stay at 256x256. The font file format works fine at bigger sizes, but Voodoo cards don't support textures larger than this. There is a fundamental 8 bit limitation in the file format (and I think in plib too), however. Doing unicode stuff will need surgery in plib to support a fancier font description. What is needed is a list of Postscript "glyph names" for the high 128 characters of the font (because ps fonts don't have a fixed encoding -- the only unique way to specify a desired character is as a symbolic glyph name). I'm sure this could be looked up somewhere... 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] STL and vectors
David Megginson wrote: > Frederic Bouvier wrote: > > I think your are making the too rapid assumption that > > an iterator is a pointer to an element. > > Don't iterators override the '+' operator if they're not just > pointers? Indeed. That's the whole genius (madness, whatever) behind the idea. Many useful algorithms work on pointers into arrays, so if you abstract that notion syntactically, then the algorithm writer can just write his quick sort as if it took pointers and the compiler will inline everything correctly at compile time. It's really very elegant. Of course, the cost of that elegance is a library that almost no one understands. Witness the length of the "how do I delete an element from a vector" discussion. I respect the STL, really. But in this case respect involves a healthy dose of fear. :) 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] STL and vectors
Bernie Bright wrote: > Only random access iterators support the '+' operator. Fortunately > std::vector and std::deque provide just such iterators. I thought there was a variant that supported incrementation but not decrementation. You don't need the full-on random access variant in this case. That's defined as supporting the '[]' operator; '+' is useful without random access (walking a linked list, for example). More fuel to the STL flames, I guess. :) 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] VASI
Jim Wilson wrote: > How do they work in real life? It seems that animation shouldn't be > necessary. I got to see a 2-light PAPI up close at Fishers Island*, NY once. It's an astonishingly simple device. Basically, it's a box with a bright white interior. At one end is a lens. At the other (on the focal plane of the lens) is a white card painted red on the top and white on the bottom. Along the sides of the box are flourescent light tubes. ++ Red#/\ # | | Lens ~ | | Wht~\/ +-- + ==light=== So when you look through the lens, you see a singularity image (i.e. infinite magnification) of whatever you're looking at on the back card. If you're below the centerline, you see the red side. If you're above, you see the white. The box is mounted on a pair of sturdy concrete poles, and is tilted up at the glideslope angle. Basically, Curt's approach seems exactly right. The image of the thing depends entirely on direction to the viewer. There are no moving parts at all. Andy * A really cute airport for anyone in the northeast. Fishers Island is a tiny spot off the tip of Long Island, just south of New London, CT. The demographic is similar to Martha's Vinyard or Nantucket -- a small contingent of locals and a larger group of very wealthy vacation home owners. My sister-in-law's parents were in the former group. I got there on a ferry, not an airplane. :) -- 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] Airport Database Model
David Megginson wrote: > Alex Perry writes: > > Why can't we stick it into the scenery directories, but one directory > > up from the tiles, so we have one file per 10degx10deg of planet. > > That should ensure that FGFS doesn't need to load all that many files, > > and just having the one file in the base package will allow initial use. > > It's not a bad idea, except that FlightGear needs to be able to search > all the airports at once to find the one the user wants to jump to. It seems to me like the airport database is only searched on two keys: location and ID. Storing an "index" on location is trivial, as Alex points out -- store it with the location-specific data structure that is already indexed. So all we need is an index on name. Not to be too glib, but the OS already provides a rather nice index on named objects -- the filesystem. So in Scenery/w130n30/airports.xml you will find a simple list of airport ID's: KSFO KOAK ... And look up the airport data itself under Airports/KSFO.xml: KSFO San Francisco Intl. ... ... ... 11 ... ... ... ... ... ... The astute will point out that not all filesystems actually store indices on filenames (ext2 and FAT among them, sadly -- NTFS and reiserfs do have indices). With only a few thousand files, this isn't likely to be a real performance problem. Nonetheless, storing them sorted into directories is possible. Use Airports/K/KSFO.xml, for example, or even Airports/K/S/F/O.xml if you really want. :) This strikes me as easy to implement and much easier to maintain than the current metakit stuff. 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] Airport Database Model
Curtis L. Olson wrote:
> Just a couple thoughts to consider. We are looking at 16-20,000
> airports so we couldn't stuff them all in a single directory. Even
> splitting them into subdirectories by first letter probably isn't
> enough.
There are 17073 airports in the current database. Splitting on first
letter only, the largest is (no surprise) 'K', with 2161 airports. On
a lark, I created such a directory containing all the US airports.
The creation process was relatively slow -- 20 seconds or so. But
once the files are there, access to them is very fast (a few tenths of
a second). This was true even after I was careful to flush the buffer
cache by cat'ing a different disk to /dev/null, if the stuff is in the
cache, of course, access is milliseconds at most. If you think about
it, 2000 is about the same number as the number of device files in
/dev, and no is complaining about performance issues there.
And remember, we can split on the first two bytes ("K/S/KSFO.xml")
without any more difficulty (one extra line of code) and the whole
problem goes away.
> Also, consider that with zillions of tiny files, much space
> is wasted on the file system which hits people in the windows land the
> hardest it seems because they often have a very large minimum file
> size.
This is a good point, actually. Almost all the Linux filesystems use
a 4k block as the minimum allocation unit*, and I presume NTFS is
similar. Still, though, 4k per airport is still a tiny fraction of
the size of the scenery. Remember that with a file per airport, there
is no need to have the whole airport database in the base package.
You can download the airports along with the scenery. Airports aren't
very useful without scenery, anyway.
[* Geeky aside: reiserfs doesn't. It has a unique "tail folding"
feature where the last sub-block of files gets folded into a single
block with the tails of other files, so small files take space
proportional to their actual size. Very cool, although apparently
not used much.]
The windows issue is, I think, true only on very old FAT32 variants.
I'm pretty sure the block size limitation went away at the same time
the 2G limit did, no? Everything from Win98SE on should be fine, I
believe. Any windows users want to comment? Certainly anyone running
XP won't have this problem.
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] Airport Database Model
Norman wrote: > [ ... indexing scheme involving spacial partitions and trees ... ] > > With such a scheme we should be able to access any airport and > determine which airports are within some sane distance in much > less then a few tenths of a second < order of manitude less at least True, but performance really isn't the goal here. The existing metakit stuff performs great. It's problem is that it's essentially unmaintainable without regenerating a megabyte of data*. Replacing one complicated binary data structure with another really doesn't address that need. My point was that a really simple one-file-per-airport scheme (you basically can't get any more maintainable than that) would work with adequate performance for typical usage. The airports in the current tile set could be kept in memory easily; arbitrary airports could be looked up quickly (under the UI definition of "quick") by their ID; and the set of all airports would still be trivially searchable in a linear walk (looking for a match by name, for example) for cases where that capability was needed. Andy * Well, and that it involves a 3rd party C++ library that insists on installing itself as a shared library. My guess is that metakit version skew is the single biggest FAQable problem with new developers. It's a very real, very significant barrier to people who want to run the cool new stuff in CVS. This is my peeve, anyway. -- 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] multiplayer / AI property tree - questions
David Megginson wrote: > I cannot say. One thing we're not modelling yet is nosewheel > shimmy: Does this really have to be modeled, per se? Until we get support for force-feedback rudder pedals and seat cushions, the only thing we can reasonably do is play a sound. That can be done already with some fancy thresholding (gating with /gear[0]/wow and groundspeed) using the existing sound mechanism. I have limited experience here, but the nosewheel shimmy I noticed in a friend's PA-180 was only a rumble. It didn't seem to effect the orientation or handling of the aircraft. 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] Some little bugs report from an enthusiastnew user...
Jim Wilson wrote: > The problem with the 2D panel mapped to the cockpit had been there > since Andy added that capability...but now I don't see it anymore. > I'm sure it was there fairly recently, within the last month anyway. > Are you seeing it with current code David? It's related to depth buffer precision. On my Geforce cards (2MX and 3), it never happens with the 24 bit depth buffer you get by default at 32bpp. At 16bpp, it picks a slimmer depth buffer (probably 16 bit) and the texture layers bleed through. The code is using a pretty big argument to glPolygonOffset, and I've never investigated how small it can be. If someone has a little time the next time they see this issue, try changing the value of POFF_UNITS at the top of Cockpit/panel.cxx. Decrease it until the textures *just* start to interfere with each other, and post the value that works for you. 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] Licensing issues
Alex Perry wrote: > I don't see a real benefit of changing FGFS from GPL to LGPL ... > * The people who don't like GPL probably aren't much happier about LGPL > * They (or we) can add a shared-memory tunnel in SimGear for properties > * Most proprietary extensions can simply coexist as separate programs I'm inclined to agree. The only real purpose behind the LGPL is to special case the situation of GNU versions of "system" libraries. Applying the GPL strictly to libraries like libc or libstdc++ means that proprietary software can't be run on free operating systems, since the act of linkage makes them a "derived work" according to the license. That's silly, so there's a special-purpose variant of the license that allows linkage (but *only* linkage) of proprietary code. The LGPL has since become popular for library projects that are designed to become standards, or at least widely shared. Projects like plib and SDL use it for that reason -- to keep development open while encouraging use of the library by anyone. FlightGear doesn't really fall into either category, since it's a one-of-a-kind codebase that is used only by other GPLed software. It strikes me that putting, say, the scenery engine under the LGPL isn't likely to encourage anyone to use it as the "standard" scenery engine for anything. Users who want the code are likely going to want to hack at it for their own purposes, which the LGPL forbids. Is there a use case here, or a particular proprietary application you have in mind? It might be simpler to do a custom release to that vendor under a separate license, rather than play with the license for the whole project. The LGPL is a little problematic for most proprietary users. They aren't, contrary to common belief, allowed to use the library any way they want. They have to link expressly against the library as shipped (no cutting and pasting of code), and have to ensure that future users can relink against newer versions of the library if they want (no static linkage, essentially). 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] TC ball
Curtis L. Olson wrote: > it seems to be more than a simple coordinate system difference, > unless JSBSim/YASim swap X/Y axes or something strange like that. Could be a bug, too. What exactly is the behavior you're seeing? The way the code in steam works is to look at the Y and Z "pilot acceleration" vectors and compute a "down" direction. Is it the direction that's wrong? * Not the same as coordinate acceleration, for the reasons discussed before. And it shouldn't use X, which is the longitudinal axis. The ball is constrained by its housing to the YZ plane. The steam.cxx code is the only place that uses these numbers, so a bug could easily have gone unnoticed. I haven't looked at the ball in a while, honestly, but I don't remember being surprised by anything looking wrong. 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] Licensing issues
Curtis L. Olson wrote: > Question: for a particular source file, if a person contributed a > minor patch or tweak to compile on a new platform, does that person > now have a "full" say in the future of that source, or are they giving > their changes to the author of that file to be placed under the > license terms chosen by the primary author. It goes by change, not by file. They contributed a patch under an existing license, not a new one. So you can't legally change their license without removing the patch; nothing gives you the right to their work. In practice, what this means is that you need to get "most" of the developers on board. If someone doesn't agree, you need to be prepared to remove their code and reimplement it. You don't necessarily need to remove every 2-line patch submitted on the assumption that the author doesn't agree. It's enough to announce the license change in the appropriate forum for FlightGear development (here, of course) and expect that people interested will notice and tell you about problems. IANAL, of course. But this is the way it's worked in other projects (Wine, especially) that have gone through license changes. But under no circumstances can you relicense someone else's code over their objections. If someone makes a stink, you have to snip it out. 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] Licensing issues
Alex Perry wrote: > There is a subtle distinction, which essentially means that, since > you do still have the copyright, people who retrieve the code also > have the right to sue you. It's even more subtle: the right to sue you doesn't go with the copyright. The copyright is a right that *you* have to restrict distribution. The right to sue for damages is someone else's, and is inherent (with lots of legislative exceptions). Basically, regardless of what you do with your copyright: if you wrote the code, it's your "fault". This is why the GPL has its warranty clause, and why commercial licenses always have the limitation of liability clause. 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] TC ball
Tony Peden wrote: > Well, I tried to compare the two, but got this for the yasim c172: > YASim SOLUTION FAILURE: Are you sure you have current code and base package? I haven't looked at the 172 in a good while, and not much has changed. Do the other YASim aircraft work for you? 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] TC ball
Curtis L. Olson wrote: > The JSBSim drives the ball in a reasonable way, as does this other FDM > I'm playing with. However, the scaling is about an order of magnitude > different between the two, even though they supposedly report the > accels in the same units and are modeling the same aircraft. YASim > seems to drive the ball yet another order of magnitude further. Hrm... yup, that sounds awfully wrong. Especially since units shouldn't matter. What the steam.cxx code is doing is taking the sideways acceleration and dividing it by the vertical acceleration to get a "down" direction. The units should drop out. I could be reporting accelerations in mph per year and it should still work. Could you stick some printfs in and get a feel for the numbers that are coming out? I mean, just print Ay and Az for each sim under broadly similar conditions and see if anything is obviously wrong. Unless you're doing aerobatics, Z should be very close to 32 and Y should be near zero. If this is happening in the air, it might not be the acceleration code at all, but the side-force-per-slip-angle behavior that is different. Try testing while doing constant rate turns on the ground to see if they behave the same there. 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] FG plane data in cartesian coordinates
David Garcia Moreno wrote: > I´m trying to communicate the Flight Gear with a 2D-map display, > which works with cartesian coordinates instead of geodetics as the > Flight Gear works. What i was able to get only was the position in > cartesians (absolute_view_pos). The only true cartesian coordinate system in FlightGear is the "global" coordinates, which is probably not what you want. This system is geocentric, with the X axis pointing out the equator at 0 longitude, the Y axis out +90 longitude, and the Z axis out the north pole. If you want to get 2D coordinates for a map display, you're going to need to do a map projection of some form, which is a complicated field. Can you be more specific about your needs? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [BUG][RFC] YASim + Bo105 + Rotation aroud origin (rather than CG)
Melchior FRANZ wrote: > As you can see, Integrator::l2gVector() does not access its parameter > orient, but the object variable _s.orient! > > Andy says that the code is correct. Andy was wrong. :) I misinterpreted the diff you posted in chat to indicate that the original code should use the parameter. Clearly that's the case. This looks to have been a cut-n-paste typo, where the line originally got snipped out of code that passed the object variable. I'm still alive, by the way. Just too busy with real life to actually participate. I'll come back soon. Can someone else verify and commit this? It's a pretty trivial change. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [BUG][RFC] YASim + Bo105 + Rotation aroud
Martin Spott wrote: > Andy Ross wrote: > > Can someone else verify and commit this? It's a pretty trivial > > change. > > Does this mean the past "the PA-28 rotates around its nose" irritations > have come to a final solution ? Honestly, I don't know because I haven't had time to actually test it. But the bug fix is clearly correct; the code as written doesn't make any sense. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI carrier
Matthias Froelich wrote: > This case kind of works for the arrester wires. The braking force is > just hacked into the gear code. But this is just to be able to test. What would probably be a better idea (at least for YASim) would be to model the braking force as a *distance* over which the aircraft will be stopped. In the real world, they have to calibrate the wires for the exact aircraft configuration that is going to be landing. You would figure out what constant acceleration would stop the aircraft in the distance available, and simply apply that force "at" the tailhook and "towards" the center of the arrestor wire. The catshot is actually harder: in real life, the force is at the bottom of the nosegear. But if you apply that to the dynamics model the aircraft will want to tilt backwards as it accelerates. Real aircraft don't do this because the nosegear is artificially compressed and held that way during the shot. Maybe the easiest way to simulate this would be to apply the force at the nose, or some other point forward of the c.g. and above the gear. I'm honestly looking for something to get me back into FlightGear development. I can do the YASim integration if you guys have an interface ready for the "ground velocity" and "arrestor wire position" values. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] When can we have roads like this
Lee Elliott wrote: > Just a thought... An alternative approach might be to make the > textures dynamic so that the roads could be overdrawn on them before > they're rendered. Way back in the day (maybe 3-4 years ago, when I was at NextBus) I wrote a parser for the TIGER database format, an intermediate binary format, and an interactive Java renderer. The idea was to have an interactive street map, not a photorealistic rendering. But the parser and intermediate format generator (in perl) might be useful to someone wanting to work on this. I put the applet binaries up at http://plausible.org/tiger/ but unfortunately modern Java plugins seem to have trouble with the older applet. You can still download the files (TestMap.jar and 06-075.nbm -- San Francisco County, CA) from that URL and run it off the command line with something like: java -cp TestMap.jar TestMap 06-075.nbm Use "z" to zoom in, "Z" to zoom out, and click the mouse on the map to recenter. NextBus never used this code, and I doubt they'd mind if I distributed it. Let me know if someone wants to look at it and I'll ask. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nasal?
Curtis L. Olson wrote: > Is there any documentation that explains how the nasal scripting > system is integrated into FlightGear? I looked a bit, and can't > find anything. Sure: http://plausible.org/nasal/flightgear.html This should probably move to the FlightGear site, I suppose. > If I decide I want to call a nasal script from someplace in the > code, how do I go about doing that? Do I create an entirely new > parser and call it? Is the global parser good enough, can I just > pass a script to it? What about the existing scripts, how are they > found and launched? I'm not seeing how it all goes together. This is pretty much covered on that page. The files in the Nasal directory of the base package are read and executed at the end of boot. Stuff in fg-command bindings is parsed and executed when the binding fires. Properties under /nasal are read during initialization and can contain either literal code or point to files to load. And there are C++ APIs from which you can turn a string into a "FGNasalScript" object with a call() method which can be invoked at runtime. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FGNetFDM etc.
Gerhard Wesp wrote: > 1. GNU C++ structure layout may _differ_ between different compiler > _minor_ versions. E.g., one sizeof() was 504 bytes on Linux with > g++ 3.3.3 and 520 bytes on Cygwin with g++ 3.3.1. Both on x86. Are you sure? Starting with the 3.2.x releases, g++ is supposed to have standardized on a single C++ ABI. Are you sure the two builds didn't have differing flags? The Cygwin headers, I know, have a bunch of win32-compatibility hacks that tend to muck with standards compliance. That said, basing a protocol on the idea of spitting raw structures onto the network is kind of a silly idea, for exactly the reasons you posit. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Solaris/GPU recommendations sought!
Gerhard Wesp wrote: > I thought about Solaris. Seems to be absolutely straightforward to > install. But I don't know anything about OpenGL and GPU support. > Linux: X11 installation (especially GPU drivers) were a pain last time > I checked (requires kernel compile!). Has this changed in the > meantime. Other options? FreeBSD perhaps? I'm not sure what trouble you had, but the NVidia drivers are almost idiot-proof these days. Install your Linux distribution (I use FC3 and can recommend it; others will work great too), then download the driver package and run it. One of the third party RPM distributors (livna.org maybe?) used to have it packaged automatically so you could just do something like "yum update nvidia" to download and install it automagically. The ATI drivers are not so pleasant, however (the last I checked, the still lacked support for the 2.6 kernel). Although the built-in DRI drivers for the ATI 8x00 and 9200 cards run flightgear very well and come standard with your X server. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New nasal features coming
Some people may notice that I just announced a new Nasal version on Freshmeat.net today. This release includes support for the oft-requested "recursive contexts" feature. It uses it internally to implement call() (a functional programming gadget that most people don't care about) and eval() (evaluates a string; might be useful to someone here). Eventually, it will also make possible recursive nasal invocations in FlightGear (i.e. scripts that fire command bindings that are themselves scripts) and will be used to implement a sleep() function that can be called from within a script. I still need to do the FlightGear integration for this release, so give me a few days. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New nasal features coming
Curtis L. Olson wrote:
> Finally, I get to realize my dream of re-implimenting all FG
> algorithms using recursion.
Not to ruin the joke, but you could do that already. Nasal has always
been a fully functional language, with recursion, lexical closures and
anonymous lambda expressions. :)
This feature allows for calling Nasal scripts (not functions)
recursively. That is, have a command binding that is a Nasal script,
that then calls another FGCommand object that is implemented in
Nasal. Before, this wasn't possible because there was only one
execution context for the scripting engine. Now you can have lots.
So you can, for example, stash one away on a timer while another one
runs. This allows for pseudo-multithreading of many scripts at once,
which run forever in loops like:
while(1) {
if(NeedToUpdate()) { DoSomethingUseful(); }
sleep(0.2);
}
This kind of programming can be simpler than running from a timer.
Although the context is fairly heavy-weight compared with a timer
entry, so we don't want thousands of them sitting around.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Parametric Tool
Ed Baker wrote: > Does anyone know if there is a parametric plane generator for FlightGear. > > I'd like to be able to play out "what if" simulations with a tool > like this. The YASim solver is a parametric plane generator, but probably not in the sense you want. You seem to want a tool where you can change design parameters and see how they affect the performance numbers. YASim takes performance number *as* parameters and generates an aircraft configuration to match them. Maybe the "aeromatic" generator for JSBSim aircraft could be evolved to do what you want? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] includes in brackets ?
Martin Spott wrote: > While I'm digging through the sources in the hope to find the cause > for some mislead header includes I wondered about notation of > several include statements. To my knowledge system includes should > be bordered by brackets: It's not really well specified. Usually: using angle brackets means to search the system standard directories, followed by directories specified on the compiler command line; using quotes means to search the directory containing the source file, followed by command line directories. There are two source code conventions I've seen: 1.) Use quotes for all "project-local" files, even those not in the same directory as the C files including them. Use angle brackets *only* for stuff expected to be installed globally on the system. This has the problem that a common name like config.h might exist in multiple directories and there's no easy way to say "I want the one in my own directory please". It makes it difficult to have a local namespace for your own headers in a big project. 2.) Use quotes *only* for things on the local directory, and angle brackets for everything else. I like this one, but I have seen build systems that complain about missing include files because they are specified with angle brackets but not in the "system" directories. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Speaking of always turning...
[bouncing replies to flightgear-devel] David Megginson wrote: > I don't know if we're modelling this or not, but with full power you > often need a lot of rudder to keep a plane straight during the > takeoff roll even when there is no crosswind. During the landing > roll, with no power, it is a lot easier. YASim is definitely not doing this right. This is because in a real plane the wheel casters a little, which has the effect of twisting the nosewheel away from the wind. On planes with a direct linkage between the nosewheel and the rudder, this is essentially the same as applying a control force. YASim doesn't model this kind of "castering torque" on the nosewheel. I know Curt was complaining to me once about an aircraft that would yaw violently in crosswinds once the nose came up -- I think this was the reason. When the nosewheel is on the ground, it isn't trying to "steer into the wind" like a real plane would be; so on rotation the pilot hasn't applied the right amount of correcting rudder. Modelling this would involve some complicated per-airplane configuration, I think. I guess we could start by defining a "castering distance" (distance from the wheel contact point to the rotation axis) and interpolate the force as linear across the full rudder travel to get a effecting "rudder trim" setting. Other planes (I know the 152, probably other Cessnas) have a spring connecting the nosewheel to the rudder cables, so they will see a similar but smaller effect. Then again, some planes have fully castering nosewheels with no rudder linkage and steer with braking. These get modelled correctly as-is. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] May I help with scenery?
Martin Spott wrote: > Does anyone have experiences with portable GPS recievers ? Do they > tend to increase the precision of their coordinate output if you > remain at a location for several minutes ? My wife have gotten into geocachine (www.geocaching.com) over the last two years, so we've played with these things quite a bit. Yes, almost all consumer devices will do averaging, although none of them tell you the algorithm they use. Given enough time, they will converge down to a value that is accurate to within the accuracy of the system (a few meters). I doubt a few minutes would be enough, I would give it several hours to ensure that a large number of satellites triplets get used in the solution. Averaging over a few minutes is only going to reduce sampling error, it probably won't be switching between its satellite signals, so systematic error of one satellites signal (due to ionosphere refraction, etc...) won't be caught. Honestly, there's a lot of voodoo in consumer GPS hardware. Sometimes the sky looks great, you see really strong signal from 8 satellites, and still get a fix that is off by 40m or more and need to reboot the unit to get it to see straight. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?
Wolfram Kuss wrote: > However, CFD programs need a "watertight" geometry. I would > guess that far in excess of 90% of models are not. For example, > each edge needs to have two neighbour faces. It's even worse than that. Real world aircraft performance is sensitive to all sorts of details that are simply unattainable for an amateur 3D model. Things like exact wing section shapes aren't available unless you have the original design plans and/or an actual aircraft to digitize. And I don't even want to think about the polygon counts involved in an accurate model. :) And remember that the aero modelling is still only part of the problem. You still need to get the mass distribution from somewhere, because it doesn't appear in the photographs. I'm not saying this stuff is impossible; people have been designing aircraft using CFD models for almost 20 years, and CPU cycles have never been cheaper. But it's a lot more work than just feeding c172.ac into a program and getting a working FDM configuration out the other side. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Google adwords?
Curtis L. Olson wrote: > Dumb question: do we want to investigate the possibility of adding > google adds to the FlightGear site? FWIW, it's fine with me. If the worst thing FlightGear does in this world is make Curt rich, I suspect I'll still be able to sleep at night. :) Seriously, having some extra cash available for FlightGear-specific stuff (hardware purchases, maybe, or conference travel/demo stuff) can't be a bad thing. I don't see any ethical problems here. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Is this usefull for flightgear/jsbsim?
Arnt Karlsen wrote: > ..well, all good jokes can't come up with a potential like the > http://gpgpu.org; your average recent GPU chews code 6 times > faster than your average CPU. So, we can use part of the GPU > to show pretty pictures, and the remainder, say "half", to say, > triple FG framerates? ;-) Well... it's not quite that great. If GPUs were better CPUs than CPUs, guess what we'd all be running for our performance-critical operations? Specifically, find me an implementation of string search (the fundamental operation in gene sequencing) that works on a GPU. Or index building (database stuff); or a big if()-tree based on complicated state (server-side business apps)... GPUs have dedicated hardware for the purpose of 3D rendering. Most importantly this includes: + Parallel, pipelined, single-precision 4D vector operations. A typical CPU has 2 or 3 floating point pipelines. A high end GPU can have dozens. + 1- 2- and 3D lookup tables (i.e. textures), with built-in interpolation/extrapolation (i.e. mipmapping & filtering). The memory bandwidth they can bring to bear on this stuff just crushes what a CPU can do. It also includes less generically useful stuff, like perspective-correct interpolation of vertex constants across a polygon. And it lacks a lot of stuff that CPU users take for granted: + High clock speeds. A CPU can dispatch single instructions 10x faster than the fastest GPU. This means that anything requiring quick decision making or iteration belong on the CPU. + Registers and cache. CPUs get special bonuses for iterating on the same data they were just using. GPUs get almost nothing (there's a little bit of caching that goes on within a single polygon's texture mapping, and a vertex cache of recently transformed vertices), and have to fetch it from main memory every single time it's used. + Turing completeness. Other than recent NVidia hardware, GPUs simply can't decide a lot of problems without CPU intervention anyway. + Double precision floating point math. Sometimes, single just ain't enough. And lots of others. Basically, this is all just a long winded way of saying "use the right tool for the job". Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib-1.8.4_RC
Martin Spott wrote: > I wonder how you ever managed to make them accept patches of obvious > necessity. If I were you I'd already have lost my countenance They're a little slow sometimes, but things get done eventually. I checked to see that my set of GUI rendering fixes from last May made it into the release. They did. In August. With no traffic on the mailing list to indicate it. But they did apply them. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C++ question
Christian Mayer wrote: > But I only want class A to be an interface that tells everybody what to > expect from it's derivated classes. And one of these things is, that > every child must have a member that is called "foo" and has one > parameter of the type of the child itself. > > How do I achieve that? With a template. But IMHO you really don't want to go there. :) Basically, you make a class template with a function parametrized on the type of the class. The problem is that this kind of template wizardry is confusing and hard. You had to ask how to do it, which means that most people who see it are going to have to look it up before understanding it. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
Curtis L. Olson wrote: > Bear in mind that one thing that is commonly done on many > aircraft is to pop up a spoiler on the wing that should drop. > This can be a lot more effective than just deflecting airflow > with the aileron. To my knowledge, YAsim doesn't model this > directly [...] Actually, it does. There is a "SPOILER" control that you can map on wing/hstab/vstab objects. I don't think anything has used it yet for roll control, but it ought to work. Remember to set split="1" to make it asymmetric. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D
Dave Martin wrote: > Something I noticed early on is that the mass needed distributing for things > like Engine+Gearbox sets and Maingear etc as Yasim just evenly places the dry > mass otherwise. Yeah. Evenly placing the mass is a great way to get the overall mass distribution (the inertia tensor, for those who like the jargon) correct. But it's basically *never* going to produce an acceptable result if that's all you use. Most of the aircraft I did would tip backwards on their gear with the default masses. The idea is to place point masses at locations where you know the heavy stuff is (engines & payload), and then let the solver come up with something plausible for wing & fuselage masses. I believe it weights them according to their surface area. And, of course, there is always a final tuning stage where you move ballast around madly trying to get the aircraft to sit stably on its gear and still be able to lift the nose for takeoff. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
Lee Elliott wrote: > I don't think it quite reaches it's altitude performance yet (I've > been thinking about a PR version sometime). However, I once got the > YF-23 > 200,000 ft (and still climbing at a fair lick). YASim's atmosphere model table stops at FL620. It doesn't try to extrapolate and just clamps the air density outside that range, so you were cheating badly by getting to that altitude. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
Curtis L. Olson wrote: > Let's not be too quick to stamp out people's ability to express > their faith. The tides of societal whimsy shift very quickly, and > if we tolerate stamping out opposing view points, all too soon you > could find yourself on the loosing end of that battle. Let's also be mindful of the sin of using other people's work to express a faith they don't hold. Now, I'm not one to get worked up over religious debates. As a garden-variety modern atheist, I'm generally happy to let other folks think whatever they want to. I don't argue against religion. I don't fear it or reject it. I don't mind attending weddings at churches, and even bow my head during prayer out of politeness. Many of my best friends and big chunks of my family are christians, and they're all great people. That said, knowing that someone downloading FlightGear gets this document dropped next to it gives me the willies. I'm fine if Arthur wants to spread The Word himself. I'm very much *not* fine with him stapling the pamphlet to a copy of YASim and Nasal. FlightGear belongs to all of us. It shouldn't be a vehicle for views that aren't shared by the community as a whole. While the GPL allows Arthur to distribute FlightGear any way he wants, including this file is neither polite nor appropriate. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > Here is my local config for the p51d yasim propeller. Most of these > values are pretty much on target according to actual specifications. > The problem is that it "appears" to not produce sufficient thrust. I did actually get started on this at one point. :) The first problem I ran into is that getting a manual pitch propeller tuned is REALLY hard. Because of the way the numbers work (pitch in YASim isn't an angle, it's a multiplier) it is very easy to move the propeller into a pitch range where the efficiency drops near zero. What I ultimately did was set the prop to have a standard variable pitch governor and hack a printf() into the YASim loop to tell me what settings the prop was actually using. Then, a few days later, my copy of the F-51D Mustang POH arrived. It turns out that this model (which I assume was identical to the wartime P-51D -- they were surplus items, not new construction) in fact had a standard RPM governor for its prop speed lever -- not a manual pitch system at all. What is the source for defining the Mustang's prop control as manual-pitch? If it's not needed, I can all but guarantee that solver tuning will be much easier without it. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > So, let's assume you got a good manual. How does this RPM governor > control work? And how can I implement that in YASim? Just set min-rpm and max-rpm properties to the RPMs in the handbook, basically. The propeller will automatically modify its pitch to seek to those values. There are examples of this in other YASim aircraft. I'll look again at the POH tonight and see if I can get you numbers. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > If you look at that manual the diagram in Section I that shows > the control box, indicates at #12 "Prop Control" (I've only got > about 6 pages from that manual). That's the blue knob with the > P on it in the model. The control box indicates "Max RPM" with > the blue knob all the way forward. > > What does the manual say about that control? Here's the relevant section: PROPELLER. The airplane is equipped with an 11-foot 2-inch diameter, four-bladed, constant-speed, Hamilton Standard Hydroatic propeller of the nonfeathering type. A propeller governor mechanically controleld from teh cockpit admits engine oil to the propeller dome for pitch changes necessary to maintain a constant engine sped. Engine oil pressure is used to aid th ecentrifugal twisting moment of the blades toward low pitch (increase rpm), an dboosted engine oil pressure through the governor moves the blades toward high pitch (decrease rpm). Propeller Control. A propeller control (12, figure 1-4) located on teh throttle quadrant, is mechanically linked to the governor. The control setting determines the engine rpm, which is maintained constant by the propeller governor. The propeller control may be positioned at INCREASE or DECREASE or to any intermediate position. The range of RPM settings I see in the performance tables is 1600-3000, so those are probably reasonable numbers to use for the min/max range. I'm sure real planes would vary due to calibration issues anyway. The manual itself is one of those annoying secure PDFs from www.eflightmanuals.com, and all I have handy is a printed copy. I think I need to get another key for it, as I've since reinstalled the windows machine I put it on originally. I played for a little while trying to figure out how to get it extracted, but eventually gave up. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > The min/max range, does that refer to engine RPM or propellor? Propeller. It's a setting for the governor. With the newer syntax, the engine and propeller are separate XML tags, so hopefully it should be clearer which is which. If an attribute on the propeller tag takes engine RPM, then that would be a bug. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How to convert from WGS84 coordinates?
> You're right, the picture shows a Projection field too. Complete infos are:
>
> Datum: WGS84
> Projection: NUTM33
>
> Coordinate top left
> x: 353620.2 y: 4225543.6
>
> Coordinate bottom right
> x: 354212.2 y: 4225976.1
Those are odd looking numbers. The WGS84 standard specifies a
"datum", which is a mapping of lat/lon/altitude coordinates to a 3D
cartisian coordinate system. Specifically, it calls the zero-altitude
surface ("sea level", sorta, although it doesn't always coincide with
actual MSL in all areas) a slightly flattened ellipsoid with an
exactly specified equation.
That said, WGS84 numbers are still plain looking latitude and
longitude values, usually written in degrees. They aren't ever called
"x" or "y" (which for obvious reasons is really confusing). My guess
is that those numbers are arbitrary 2D coordinates used by the
satellite photo software. Or maybe they're well-specified 2D
coordinates in the NUTM33 projection* about which I know nothing.
* A projection is not the same thing as a datum. It is a mapping of
2D (!) lat/lon values to a 2D cartesian surface. Becuase this
transformation is lossy, projections get really, really complicated.
Many are specified with giant lookup tables and/or curve fitting.
I'd hunt around in the documentation you have for the photo to try to
figure out what it's talking about.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > But those numbers you gave me seem to be engine RPM numbers. Sorry > for the confusion. The gear ratio is 0.479 and the merlin max rpm > is 3000 rpm. Ah, I get it. Sorry for the confusion. :) I guess the gauge in the cockpit shows engine speed, but the YASim file wants propeller RPMs in the propeller tag, so the proper range would be ~766-1437 or so. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Vivian Meazza wrote: > Yes - perhaps Andy will recall our long discussion of a year ago? Only vaguely, and I currently lack the time to crawl through the archives. You keep hinting that you want something done. Can you be more specific? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote:
> Now I'm finding that we're seeking the engine rpm instead of the
> prop-rpm.
Andy Ross wrote:
> If an attribute on the propeller tag takes engine RPM, then that
> would be a bug.
See? I was exactly right. :)
Can you try the following fix to PropEngine.cpp? That should fix it,
but I can't test right now.
Andy
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/PropEngine.cpp,v
retrieving revision 1.13
diff -u -r1.13 PropEngine.cpp
--- PropEngine.cpp 13 Dec 2004 23:48:43 - 1.13
+++ PropEngine.cpp 26 Jan 2005 00:58:52 -
@@ -216,7 +216,8 @@
// _current_ RPM. Seek to that. This is sort of a continuous
// Newton-Raphson, basically.
if(_variable) {
- float targetOmega = _minOmega + _advance*(_maxOmega-_minOmega);
+ float targetPropSpd = _minOmega + _advance*(_maxOmega-_minOmega);
+float targetOmega = targetPropSpd / _gearRatio; // -> "engine omega"
float ratio2 = (_omega*_omega)/(targetOmega*targetOmega);
float targetTorque = engTorque * ratio2;
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > Speaking of which, in the prop config, what exactly do the "cruise" > numbers do? If I'm not getting enough thrust still out of the prop, > what should I mess with first? This is the black magic part, and could really use a redesign. The "cruise" pitch (the RPM and an airspeed) defines the point of maximum propeller efficiency. Anything faster or slower will be less power-efficient according to a curve I reverse-engineered out of a textbook. The cruise-power then defines the engine power needed at that speed. But that's for a fixed-pitch prop. For a variable one, it's only for the "one" point of the pitch multipler (which is allowed to go from 0.25 - 4.0). Which is basically useless, because the second the governor starts it pulls the multiplier off of the default value. The end result is that it's pretty much impossible to predict which part of the efficiency curve a variable pitch propeller will be operating under in practice. That's not a huge issue, I don't think, as the efficiency curve is pretty flat. But it does make the solution very sensitive to input values. The idea of using an efficiency curve to define the prop (instead of, say, a pitch value and takeoff thrust/power) has some merit, but it ended up being difficult to tune -- David M. has had trouble with getting the windmilling speed to be correct, for example, because that number (which is basically the same thing as pitch) is a derived value, not a core tunable. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] can 'dynamic' textures be disabled ???
D Wysong wrote: > I'm using a custom texture that I created using OpenGL directly > (instead of via plib) and I'm getting HOSED when FG decides to go > load new textures Are you sure you aren't picking texture names that collide with the SSG loader? If you use glGenTextures(), you should be safe. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] YASim prop thrust
Jim Wilson wrote: > What should I look for then when mucking with the cruise numbers from > the prop definition? Or is there some way to just remove them? One thing to try would be to remove the variable pitch settings entirely and nail the prop down at your specified cruise setting (which should generally be low rpm, long range values). Verify that you get the desired performance in that configuration, then add the min/max settings back in to check that they don't break anything. Doing it this way, the variable pitch tuning shouldn't be far off from 1.0 in your cruise configuration. > I've tried to get a little more thrust of this prop and haven't had > much luck. One thing that just occurred to me, does this formula make > any assumption about the number of blades? The P51D prop has four > blades and I'm not clear on how that is accounted for. Doesn't matter. The big advantage to doing the modelling with an efficiency curve is that you don't worry about details like this. The engine provides input power, divide by current speed to get output thrust. Plausibly perfect performance in all conditions. But hard to tune. What thrust are you looking for, btw? You can get an actual value in pounds out of the property tree. With some unit conversions, you can multiply this by the true airspeed and divide by the engine power output to work backwards manually to an efficiency value (maybe a Nasal script would be good for this). If you are seeing something in the range of 75-85%, then your problem is more likely engine power than prop thrust. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against Sun's
Arnt Karlsen wrote: > ..riiight, we all can agree on that, now try keeep in mind _none_ of > us are IBM, and The SCO Group is still running its 2 yr old Â419 > scam in the 9'th Circuit Court before Judge Kimball in SLC, Utah. Relax. Under no circumstances will we be any more exposed than if we ported to *commercial* Solaris, where we have no rights to any Sun IP at all. This is a non-issue. The complaint is that the Sun patent grant is unfair and incompatible with the GPL, so free software developers should not attempt to use the Sun patents. We aren't, so we don't care. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Curtis L. Olson wrote: > If he has all these things, then that's wonderful, he has done an > impressive piece of work. I'm not trying to be critical here, I'm > just pointing out that this is *very* difficult stuff. It's one > thing to do a nice little demo, it's something else entirely to > tackle all the issues of doing this in a full sim where you are > trying to model the world seamlessly. Let me just chime in to agree with Curt. Some of the long-timers here will remember that one of the first things I wanted to do when I discovered FlightGear was write a "modern" terrain engine to replace the tile system we're currently using. Since then, I've contributed an FDM and an extension language. No terrain. I spent the spring of 2003 working on my own project full time and produce a ton of working code. Until I got to the terrain engine, which I got partially working, then burned out. No terrain. It's hard, really. It's not impossibly hard, but the distance between something that works well as a demo and something that ships well as a product is very long. As with everything, really, the key here is integration. Make it work with FlightGear so we can test. Saying "here is code, can we use it?" just isn't enough. It needs to be "here is a patch, try it and tell me what breaks". Until we get that far, there really isn't much to argue about. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Christian Mayer wrote: > Manual Massing wrote: > > Yes, textures and geometry are paged and decompressed > > asynchronously in the background (seperate thread). The engine > > supports image compression to save IO (and possibly bus) > > bandwith, e.g. JPEG and S3TC compression. The first maybe quite > > taxing on the CPU, so we usually only use JPEG for the finest > > detail level textures, which account for most of the data, and > > S3TC for the lower detail levels. > > Do you know: > > http://www.sjbaker.org/steve/omniv/jpegs_are_evil_too.html Honestly, Steve is just wrong on this one. Lossy compression works just fine in moderation. The S3TC format itself is a lossy algorithm that is inferior in quality to JPEG in basically every conceivable way, and it's supported navtively by the texture hardware for goodness sake. Yes, using JPEG as an intermediate format during content creation is a dumb idea due to progressive data loss. Refusing to use it for final/shipping textures based on this advice is just dumb. Real-world 3D applications and games ship their images compressed with lossy algorithms. Has anyone actually looked at how much of the base package is taken up by SGI+ format image files? (Which have absolutely abysmal compression ratios, but that's a different argument.) I wrote a quick script at one point to recursively convert all these to default-quality JPEGs, and the savings was staggering. Something like a 75% reduction. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Frederic Bourvier wrote: > It is still true that JPEG have no alpha channel, so not all > textures could be converted. Yes. Although the loader could play tricks like storing the alpha channel in a separate grayscale image. And I believe the already-mentioned jpeg2000 format does support 4-channel images. Many of the alpha images are actually poor choices for jpeg anyway, as the cutouts often have fine detail / high frequency shapes. But the point wasn't that jpeg was perfect for everything, just that refusing to use it where appropriate was silly. Especially for the terrain textures, it works really, really well. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
Christian Mayer wrote: > For our case that compressor must not rely on special optical > tricks (because these get destroyed when they are used as an > texture). All lossy compressors rely on special optical tricks, that's the point. If all the data was equally important, you couldn't "lose" any of it without damaging the image. This is where Steve is overgeneralizing. Simply using an image as a texture (which is just a picture intended for viewing) does *not* destroy anything important. Yes, jpeg has artifacts that you need to be aware of. No, 3D texturing doesn't do anything magical to them other than stretch/shrink and downsample them. This is painfully simple to test. Take the terrain textures, convert them to jpeg, re-convert them to sgi+, fire up fgfs and take a screenshot. If you can see a difference, post a screenshot pair pointing out how awful jpeg is. I give 100:1 odds that no one can come up with such a situation. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
Innis Cunningham wrote: > I dont think there is a total fuel onboard or fuel remaining > property. I asked about this a couple of weeks back and got no > reply(I think). Each tank has its own value, under /consumables/fuel/tank[n] you will find "level-gal_us" and "level-lbs" properties. I don't think there is a standard fuel consumption rate output property across the FDMs right now. But if there were, you would fine it under /engines/engine[n]/... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
Jon S. Berndt wrote: > I haven't been following this thread very closely. Can someone > concisely recap what is wanted, here? It's most likely a very simple > addition for us if it's something we don't now model. Actually, YASim uses a Nasal-based fuel system that was designed to be FDM-independent. It doesn't handle the stuff internally at all. Instead, each engine sets an /engine/engines[n]/fuel-consumed-lbs property. Each iteration, it adds its newly consumed fuel (that is, just flow rate * timestep) to this property. The Nasal script then comes around in a polling loop, sucks this stuff out and subtracts it from the tanks according to the fuel selector properties. YASim then just uses each tanks level-lbs property as a pure input property to set weights on the tank objects. There are some comments at the top of fuel.nas that try to explain things. The big advantage here is that you get to use the fancy fuel dialog (which works entirely in the property system) to twiddle fuel tank amounts and selection states at runtime. You can bounce an aircraft up and down on its gear by filling and emptying its tanks. It's kinda cool, but then I'm biased because I wrote it. :) FWIW, another cool thing this dialog gets you is automatic weight management. You can assign "named" weight objects in your -set.xml file and use sliders to control their sizes at runtime. Not many of the YASim aircraft are doing this yet (I did the pa28-161 and a4, I know). It's a much cleaner interface than having separate FDM configurations for each aircraft loadout. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
Jon S. Berndt wrote: > This is good for YASim. However, the Nasal approach won't apply for > other applications which use JSBSim, and JSBSim also needs its own > fuel management for batch runs (standalone operation) outside of > FlightGear. Well, it's certainly fgfs-specific, although there's really not much YASim-ness in there. Basically, we want things like fuel state to be settable by the "user" using the property system. That's really not an escapable requirement if we want the users to configure this subsystem at runtime. IMHO, the easiest way to implement that is to "disengage" the FDM's internal fuel management code (I actually deleted YASim's) and simply make it take the property stuff as input. The weights work the same way: the YASim configuration simply associates a property name (e.g. /sim/weight[0]/weight-lb) with a specific location on the airframe. Then the GUI code reads the metadata under /sim/weight[n] to pop up a dialog with sliders for each named weight. With JSBSim, you could write a "property interface manager" for these guys that replaces the "internal" internal fuel/weight managers you have right now. If you wanted, you could actually write property listeners to override the current property nodes and wire their get/set operations directly into your internal get/set calls. But that seems like more work, IMHO. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
I found time this afternoon to refresh my memory about how the fuel stuff works. The FDM reads these properties to determine the amount of fuel in each tank. YASim uses this only for computing the inertia tensor and total aircraft mass, it doesn't care about "fuel" per se. /consumables/fuel/tank[n]/level-lbs The FDM reads the following boolean property to determine whether to kill an engine: /engines/engine[n]/out-of-fuel The FDM *adds* to this property to contain a running total of fuel consumed for each engine. If it currently has a value of 7, and this timestep 4.2 lbs of fuel were consumed by this engine, then it should be set to 11.2. /engines/engine[n]/fuel-consumed-lbs And that's it. Everything else related to fuel, including user-configurability of tank selection and/or filling, is handled by the nasal script/gui for you. IMHO, it's really about as simple for the FDM as is possible. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Curiosity about antialiasing
Ampere K. Hardraade wrote:
> At the moment, is antialiasing applied to textures themselves?
Sort of. This is the purpose behind mipmapping and filtering --
avoiding aliasing effects in texture ("texel") space.
> If so, what will happen if antialiasing is applied to the final
> render/output instead?
Nothing. The FSAA mechanisms on modern cards work in screen (pixel)
space, for scene elements (triangle edges) that cannot be helped by
the mipmapping mechanisms. Different tricks for slightly different
purposes. Inside of a polygon, the FSAA tricks are mostly a noop and
mipmapping is what you want.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] normal maps for flightgear
Erik Hofman wrote: > Frederic once wrote a plib patch to add multitexturing by someone > thought it was an ancient technology and everything should be done by > shaders in the future. First I don't think we ;live in the future end > secondly I don't think shaders will be fast enough to do _everything_ > using shaders. There's no inherent magic to shaders. Normal maps on terrain can be lit at load time (or once every minute or so -- the sun doesn't move that fast) and applied as a second stage multitexture or even as a second pass to the terrain rendering. The more interesting question is how we generate the normal maps. It could be done with a high frequency noice perturbation of the polygon normals, or even generated from the original high resolution input terrain data. But I agree with Erik: we want to avoid specifying features as "shader" stuff. Shaders are the mechanism you use to render it. As always, the hard part is getting the data representation right. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument headaches
Giles Robertson wrote: > Working out gravitational and kinetic energy is trivial; accounting > for energy in the fuel not hard - but I don't think you'll be able > to account for elastic energy stored in the airframe. It's a pilot's tool, not a design thing. It's designed for glider pilots to show them rate of climb/descent information corrected for dynamic conditions like a zoom climb or accelerating dive. The airframe energy is essentially miniscule compared to this. Gliders, last I checked, were decidedly incapable of flapping their way to a safe landing. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] how to find remaining fuel
Seamus Thomas Carroll wrote: > The fuel levels seem to retrieve correctly. > I then added the following code to set the fuel levels for when the c172 aircraft starts: > fgSetDouble( "/consumables/fuel/tank[0]/level-gal_us", tank1 ); > fgSetDouble( "/consumables/fuel/tank[1]/level-gal_us", tank2 ); The 172 is a JSBSim aircraft, so Jon or one of the JSB crew will have to provide specifics about this particular situation. But for YASim aircraft (really: users of the Nasal fuel system), this will not work. You can set the current fuel only using the level-lbs properties. The -gal_us and -norm are output-only convenience properties that may be useful to panel code. Setting them is a noop; their values will be clobbered by the FDM. If I remember correctly, JSBSim does not currently support setting fuel state through the property system. Instead, since you are in C++, you should be able to find an interface there. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Placing an aircraft model in FlightGear
Don Oliver wrote: > fgfs --prop:/sim/model/path=Models/my-cessna.wrl" > > There are no .wrl files in my FlightGear installation, so where do I > find this information? FlightGear's model loader (part of plib) supports many different file formats. The best supported is currently AC3D (.ac) format, which is native to that shareware modeller (www.ac3d.org) and well-supported in Blender by a Python export script. This particular extension, .wrl, indicates a VRML file. Maybe we should fix the docs to use .ac instead. > Next, there are detailled instructions for how to animate rudder, > throttle, etc., but how does the program know what part of my model is > the rudder, throttle, etc., and what makes the part move? Almost all 3D modelling programs allow you to associate "names" with object sub-parts. These names then appear in the XML content that describes the animation. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Curtis L. Olson wrote: > Frederic Bouvier wrote: > > There is the property /sim/frame-rate-throttle-hz that could be > > used to limit the framerate but the source should be modified > > to call a system sleep method ( with a fine resolution, for > > example pthread_cond_timedwait ) instead of looping wildly. > > I know this is hard to do with standard system level calls. For > instance setitimer() in unix allows you to specify a very fine > resolution sleep/wakeup time. However, the OS only checks the > thread during a kernel interrupt which happens at 100hz. So you > can only get divisers of 100hz resolution with this approach. Indeed. For what it's worth, almost all full screen 3D apps end up spinning on the CPU, for exactly this reason. Trying to sleep for tiny amounts of time really isn't doable in a portable way. Under linux, the real time clock device can be programmed to provide an I/O wakeup to a process at fine intervale (and because it is I/O bound, it is at high priority and generally gets the CPU immediately). But that's not even portable to other Unix kernels, much less windows. Really, the best thing you can do is to turn on sync-to-vblank in the OpenGL driver. This will throttle the process* to the monitor refresh rate, at least. Andy * Hopefully in a CPU-friendly way. I know that older versions of the NVidia drivers did this by spinning in a polling loop inside the driver. I'm not sure if this has been fixed or not. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Making FlightGear more deterministic
Frederic Bouvier wrote: > Quoting Andy Ross: > > * Hopefully in a CPU-friendly way. I know that older versions of > > the NVidia drivers did this by spinning in a polling loop > > inside the driver. I'm not sure if this has been fixed or not. > > From my experience, the latest non-beta Windows NVidia driver seems to > eat CPU even with sync to vblank enabled. The CPU usage is always > 100%. This made me curious, so I checked. In fact this bug *has* been fixed in the current NVidia linux drivers. Running a plain "glxgears" causes the CPU load to jump immediately to 100% and stay there as it reports 1500 fps on my laptop. Running it with __GL_SYNC_TO_VBLANK set to 1 causes it to report 55 Hz, and CPU usage just barely gets above zero. Nice. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] calctile.nas
Melchior FRANZ wrote: > Some of the digits after the comma may be stripped. Nasal doesn't > seem to support that. Indeed, there is no formatted text mechanism in Nasal right now. Everything is printed to the precision of a full double. Doing this the "right way" (say, a printf-like format string) is really hard, short term hacks (like format(fldwid, precision, num)) are really ugly, and the price of doing it wrong (inserting formatting operators into the output stream!?!?) is pretty high. I'm willing to listen to suggestions, though. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: calctile.nas
Melchior FRANZ wrote:
> Unfortunately, I can't avoid the silly double-0. No idea why.
As you pointed out on the IRC channel (which more folks should be on,
it's kinda fun sometimes), this is a Nasal bug. Or two, actually.
The simple bug is that the string "-" converts to a numerical zero due
to the way the number parser works. That should be easy to fix.
But it exposes a nastier issue in the code generator. Nasal's binary
format uses a table of scalar constants ("foo", 1.234, etc...) that
appear in each code block. To save space, it uses a hash table to
eliminate duplicated constants. But to a Nasal hash table, all
"equal" constants look alike. So in fact if you write a source with
something like:
a = "0"; b = "0.0"; c = 0; d = "-";
... then these four constants (three strings and one number) will all
turn into exactly the *same* *thing* in the generated code (which one
in particular gets chosen depends on which one the code generator
spits out first). Most of the time, that's benign and invisible,
except where string conversions are an issue.
Anyway, I need to fix this to use a true identity test instead of a
standard nasal hash table in the code generator. Gimme a while to
play with it. Fun bug, though.
For now, the workaround is what you already discovered: don't use a
constant in the code with a numerical value of zero. Use something
like "a-" instead, and strip off the leading "a" at runtime.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Curtis L. Olson wrote: > Maybe we need separate options, such as > --cpu-friendly-inaccurate-throttle-with-sleep-hz= and > --frame-rate-accurate-throttle= > > Thoughts? I think we need to tread a bit more carefully on this one, > especially since I have a side project that employs this option (well, > used to employ this option) :-( to achieve accurate frame rate timing > and smooth animation. What was the original bug report? Currently, FlightGear will look CPU-limited to the OS, which means that short running or I/O bound processes will get priority anyway. What is the application that needs extra CPU, and are we sure that it's not being performance limited in some other way? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
I asked: > What is the application that needs extra CPU, and are we sure that > it's not being performance limited in some other way? Aha! Drew wrote: > In Windows, adding this code did absolutely nothing to the > processing time...it remains at 99% usage whether I throttle back to > 60, 30, or 1 Hz. [...] Once iit was compiled in 'debug' mode, the > throttle_frame_rate actually yielded some processing ttime for other > processes. It runs better, but still not ideal. Wait, that's not a bug report about processing time available for other proceses at all. That's a bug report about the total CPU usage being at 99%, which is irrelevant. If the CPU is available, then of course FlightGear should use it all; you can't save up cycles -- either use them now or let them go to waste. Which app are you running that is going too slow, and how much CPU do you think it needs? Those are the important questions. Your OS (yes, even windows) has an elaborate scheduler which is designed to make sure that all processes get the CPU they need to do their job. Sometimes you need to tweak things, but those circumstances are rare. I strongly suspect we're chasing a ghost on this one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote: > The program runs great, it's just that FlightGear gets interrupted > easily by other programs, and is jumpy in my particular application. > If you open and close a window, you can see how FlightGear freezes > momentarily. I don't wonder, though, if that isn't due to locking inside GDI (or VM swap -- how much memory do you have?) and not CPU usage. Applications doing 3D rendering don't coexist well with things that need to draw to the screen. Can you try something "purely" CPU intensive (like a perl script that counts to a few million) and see if you can notice the same behavior? My guess is that tuning FlightGear's CPU usage isn't going to get us much. Conversely, can you compare FlightGear to other "spin on the cpu" 3D applications like games? Do they exhibit the same issues? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS: FlightGear/src/Main main.cxx,1.193,1.194
Drew wrote:
> I'm not really interested in how other 3D apps, including games,
> work...I have a specific application, and I want to optimize the
> code for this purpose, regardless of what the status quo is.
And the proper way to do that optimization is to figure out what the
actual symptom is. Which requires testing a hypothesis ("is it due to
CPU usage?") by changing one parameter ("open a window" vs. "run a
looping perl script") at a time in order to isolate the symptom
("complicated window system interaction" vs. "pure CPU usage").
It seems to me that you have gone backwards: you picked a favorite
"fix" before knowing what the problem is. The bottom line is that
performance analysis is really complicated. You can't cook it down to
a single number like CPU usage (or "load" -- a equally flawed Unix
favorite) if you really want to fix a problem.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Help with B-29
Josh Babcock wrote: > My problem is that I apparently am genetically incapable of > getting a YASim config to converge. XML file? Output? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airspeed (indicated vs. calibrated) question.
Curtis L. Olson wrote: > 1. FlightGear has a property called /velocities/airspeed-kt; does anyone > know if this was originally intended to be VCAS, VIAS, VTAS, or what? > > 2. The pitot system uses /velocities/airspeed-kt as it's input (and > seems to assume this value is VIAS.) This value looks like IAS to me. It's set from YASim via the FGInterface::_set_V_calibrated_kts() function. Note that the difference between IAS and CAS are due solely to gauge/pitot system issues. As far as the FDMs are concerned, they mean exactly the same thing. There is also an "equivalent airspeed" value that comes out, which is CAS without the mach corrections. I have no idea if this ever makes it to the property system, but FGInterface has a slot for it. A true TAS value* comes out via _set_V_rel_wind(), but I'm not sure where this ends up in properties. * Er... sorta. This is total airspeed velocity magnitude, whereas the pitot would really only measure velocity along its axis... If your suggestion is that we chuck all of this stuff and just pick some standard output props for the FDMs to fill out, then I agree. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
