[Flightgear-devel] Re: Remove .cvsignore?
* David Megginson -- Wednesday 26 June 2002 03:10: I now think that was a mistake, since people probably want their own, local, customized .cvsignore files if they want any at all. Huh?? You think that everybody should maintain his own .cvsignore files now? They are supposed to list all files that are not globally excluded and generated during the normal build process. I don't see where there is room for personal preferences. If I'm not happy with some, I can still provide a patch or change them locally. But in general they belong into CVS. They are in the repositories of Alsa, Wine, ImageMagick, XFree, Mesa, KDE, ... I couldn't name a single project where they are =not= in the repository. m. :-/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut font format
Andy Ross writes: Norman Vine wrote: I think that you will find that inorder to get 'high quality' fonts one needs to use a vector based font directly. The only problem in doing this is that the polygon count goes up considerably. Have you tried the antialiased fonts in KDE, WinXP or recent versions of Gtk+? They look *fantastic*, and are generated with exactly the method I propose -- a very high resolution bitmap is generated and then downsampled into a grayscale image that is alpha composited onto the screen. The plib TXF loader already does the second part, there simply aren't any tools to do the rendering and downsampling. Andy I saw a lot about this technique when MSoft first announced it and the Fonts do look great but aren't the fonts created when they are first requested for each requested size ?? Plib is using standard OpenGL texture mapping todo the scaling from a 'base' raster. I also think that there would probably need to be a 'special' rendering for each 'rotation' used. but I may be mistaken. FWIW I can't find it right now but I remember seeing a 'utility' that will convert any truetype font into an XFont somewhere which migh be useful too Please don't let me discourage you from making the fonts 'prettier' but IMHO the 'easiest' best looking fonts for the Panel will be Vector based. I don't think the 'polygon' budget will be excessive if we are careful about it as on GeForce2 or equivalant cards as I believe we are currently 'fill limited' when drawing the panel. To clear a possible misinterpratation up. The Fonts that are distributed with PLib were created by SteveB on a Linux machine, I have however created ny own on a Cygwin system without an XServer but you had to provide a XLib library. I use a 'slightly' modified version of the one that comes with the Cygwin RXVT source package. Of course if you gave X installed you don't need this font-rendering-best-left-to-the-likes-of-Knuth'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Remove .cvsignore?
I don't mind either way. I have found it generally useful to have them provided, and have wished the plib would do the same (for .deps directories, in particular). However, I have only ever worked on small patches, never adding files, so I have never needed to take note of the ? and unknown file messages that CVS prints. Even with the .cvsignore files, I still get a whole bunch of these messages, many of which are from local back-up files etc., but some of which I think should be added to the checked-in .cvsignore files (I can't check at the moment). I now always filter out lines starting with a question mark from the output of cvs update and cvs diff. If I was adding files I probably would want correct and complete .cvsignore lists. (I could add one in my home directory to describe most of my local back-up files.) While these files are in CVS people must occasionally update them. Not a very big deal, but in general the fewer files the better. About 22 of the 32 Flight Gear .cvsignore files contain just Makefile, Makefile.in and .deps. These could perhaps be replaced with a per-repository list in `$CVSROOT/CVSROOT/cvsignore'. - Julian David Megginson wrote: A while ago, I added .cvsignore files to the FlightGear, SimGear, and TerraGear CVS repositories to let CVS know to ignore generated files like executables and scripts, and cut down on the noise in CVS sessions. I now think that was a mistake, since people probably want their own, local, customized .cvsignore files if they want any at all. Would anyone object to my removing them from the repositories? Does anyone else care? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Remove .cvsignore?
[EMAIL PROTECTED] wwrites: I have found it generally useful to have them provided, and have wished the plib would do the same (for .deps directories, in particular). FYI the FlightGear 'configure' is designed to be able to be run in a directory other then then the CVS source tree. This has several advantages amongst them keeping the source tree MUCH cleaner :-) To use this feature: 1) run autogen.sh inside the CVS tree 2) create a new directory outside of the CVS tree 3) cd to the new directory 4) execute $PATH_TO_CVS_SOURCE_TREE/configure; make All of the compiler produced files should now be in your new directory .o .deps ect and the CVS tree should be 'clean' except for the files that autogen.sh created ie aclocal automake and autoconf created files IMHO these autogen.sh created files should be reflected in the .cvsignore(s) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Remove .cvsignore?
FYI the FlightGear 'configure' is designed to be able to be run in a directory other then then the CVS source tree. That sounds well worth a try. Thanks. This has several advantages amongst them keeping the source tree MUCH cleaner :-) And being able to keep a debug build and a release build without doing a make clean every time. - Julian To use this feature: 1) run autogen.sh inside the CVS tree 2) create a new directory outside of the CVS tree 3) cd to the new directory 4) execute $PATH_TO_CVS_SOURCE_TREE/configure; make All of the compiler produced files should now be in your new directory .o .deps ect and the CVS tree should be 'clean' except for the files that autogen.sh created ie aclocal automake and autoconf created files IMHO these autogen.sh created files should be reflected in the .cvsignore(s) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Remove .cvsignore?
Personally, I agree with Fred. The number of people who will actually be using a custom cvsignore will be far fewer than those of us who will not. Can you make your custom cvsignore read-only so cvs can't stomp on it? * [EMAIL PROTECTED] (Frederic BOUVIER) [2002.06.26 07:09]: Yes, but people can always modify their own version, even if they are already in CVS. I still don't see the benefit of having all those ? lines. If you want to remove the burden of maintaining per-directory .cvsignore, put one in /CVSROOT and you're set for the whole tree. Cheers, -Fred Messsage du 26/06/2002 13:07 De : [EMAIL PROTECTED] A : [EMAIL PROTECTED] Copie ? : Objet : Re: [Flightgear-devel] Remove .cvsignore? Frederic Bouvier writes: What is the rational of doing that ? To let people create their own, local, customized .cvsignore files instead (those who care, that is). David -- Cameron Moore [ When sign makers go on strike, what do they picket with? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Remove .cvsignore?
Cameron Moore writes: Personally, I agree with Fred. The number of people who will actually be using a custom cvsignore will be far fewer than those of us who will not. That seems to be the consensus -- I won't remove them. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
Andy Ross writes: * For safety. The A-4 had automatic slats that were retracted by aerodynamic force -- they dropped automatically at low airspeeds and high AoA's. On the ground, they just hung open. This was a great idea for maintenance purposes, but left open the possibility that they might get stuck and deploy asymmetrically. That's a recoverable situation normally, but not when there's another plane a few feet under or above your wing tip. :) The helio courier also has this feature. The leading edge slats are split so you have two per wing ... four total acting independently of each other. Depending on a variety of factors, each of the four could deploy/retract at a different time. They made a bit of a bang coming down so if you weren't expecting them, an unwary passenger might be a little surprised and wonder what just fell off. :-) It's a neat idea that is simple and effective. I've always thought it would be kind of fun to impliment something like this on an R/C model, not that the typical R/C model would need them ... Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
that is simple and effective. I've always thought it would be kind of fun to impliment something like this on an R/C model, not that the typical R/C model would need them ... I once saw an F-4 with controllable slats - they weren't automagic though. The Bf-109 and Me-110 has aerodynamic slats like the A4 does. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spiffy new panel gadget
Andy Ross writes: I should explain the problem a little better. What's happening is that there is no place to put a normal vector in the .ac file. The plib loader thus has to generate its own normals by averaging the normals of each polygon attached to a vertex. For vertices that are inside an object/texture, this works fine. But ones on the edge can't average in the normal of the polgon(s) that are on the other texture, as those are part of a different object in the .ac file. So what happens is that a vertex on one texture has a normal vector that is *different* from the normal of the same point on a different texture. This makes that polygon edge look sharp when lit. What's especially frustrating is that (1) I'm generating this file automatically, so I could export the normals explicitly if I wanted to, but the file format won't let me; and (2) it's a sphere! Generating normals is a ridiculously trivial operation -- they're just the coordinate of the vertex. Somewhere in simgear there is code to generate a plib sphere. It's adapted from the glu sphere code, but this code builds a sphere in a plib scene graph. We use it to build the moon and the sun I believe. That doesn't help you directly, but maybe if we extended the instrument xml so you can specify a primative and a texture and a placement and the animation variable hooks ... might not be too hard (?) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
On Wed, 2002-06-26 at 14:08, Curtis L. Olson wrote: Andy Ross writes: * For safety. The A-4 had automatic slats that were retracted by aerodynamic force -- they dropped automatically at low airspeeds and high AoA's. On the ground, they just hung open. This was a great idea for maintenance purposes, but left open the possibility that they might get stuck and deploy asymmetrically. That's a recoverable situation normally, but not when there's another plane a few feet under or above your wing tip. :) The helio courier also has this feature. The leading edge slats are split so you have two per wing ... four total acting independently of each other. Depending on a variety of factors, each of the four could deploy/retract at a different time. They made a bit of a bang coming down so if you weren't expecting them, an unwary passenger might be a little surprised and wonder what just fell off. :-) It's a neat idea that is simple and effective. I've always thought it would be kind of fun to impliment something like this on an R/C model, not that the typical R/C model would need them ... Two per wing, all independent? Sounds like a lot of potential for lateral control hell Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
On Wed, 2002-06-26 at 14:08, Curtis L. Olson wrote: The helio courier also has this feature. The leading edge slats are split so you have two per wing ... four total acting independently of each other. Depending on a variety of factors, each of the four could deploy/retract at a different time. They made a bit of a bang coming down so if you weren't expecting them, an unwary passenger might be a little surprised and wonder what just fell off. :-) It's a neat idea that is simple and effective. I've always thought it would be kind of fun to impliment something like this on an R/C model, not that the typical R/C model would need them ... Tony Peden writes: Two per wing, all independent? Sounds like a lot of potential for lateral control hell Didn't seem to be too much of a problem in practice. The transition period is relatively short and you are moving fairly slow (less than 80 kts or so?) when they deploy. I don't think deploying them significantly changes lift or drag, but it does introduce a slat on the leading edge to help keep the airflow stuck to the wing in extremely high angle of attack situations. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: C172P Hi-Res Panel Photos
Ryan Larson writes: I can get hires photos of a Warrior, Archer, Arrow, Grumman Tiger, Beechcraft Sierra, C182, C172R, C172RG, Mooney 201, Saratoga II and possibly an Aztec F. I love my new flying club! What do we have and what do we need? Would it also be helpful to get hires photos of the outsides of planes and maybe the moving parts (gear, alerons, rudder, flaps, elevator and the prop)? Admittedly this is for somewhat selfish reasons (I'm working on a side project where the primary instruments will fill an entire display and the out-the-window visuals will be on a second display.) So I vote for someone to create instruments where each instrument is about 256x256 resolution. And beyond this particular project, it would allow anyone with two machines to set up a similar arrangement. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
On Wed, 2002-06-26 at 15:15, Curtis L. Olson wrote: On Wed, 2002-06-26 at 14:08, Curtis L. Olson wrote: The helio courier also has this feature. The leading edge slats are split so you have two per wing ... four total acting independently of each other. Depending on a variety of factors, each of the four could deploy/retract at a different time. They made a bit of a bang coming down so if you weren't expecting them, an unwary passenger might be a little surprised and wonder what just fell off. :-) It's a neat idea that is simple and effective. I've always thought it would be kind of fun to impliment something like this on an R/C model, not that the typical R/C model would need them ... Tony Peden writes: Two per wing, all independent? Sounds like a lot of potential for lateral control hell Didn't seem to be too much of a problem in practice. The transition period is relatively short and you are moving fairly slow (less than 80 kts or so?) when they deploy. I don't think deploying them significantly changes lift or drag, They typically don't at deploy/retract airspeeds. At lower airspeeds, however, the wing will make quite a bit more lift with them deployed. Should one segment jam, however, some *very* serious lateral control problems can develop. It can, of course, also happen with a fully powered system as well, but at least there you've got half a chance of detecting the asymmetry and stopping the deploy/retract sequence. but it does introduce a slat on the leading edge to help keep the airflow stuck to the wing in extremely high angle of attack situations. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] jitters testing
Setting all the view offsets to 0 I was able to prove that the position/rotation matrices generated on the model and the camera are numerically identical. Here's a sample from the dump: POS Aircraft 0.823776 -0.150286 -0.546632 0.00 0.468893 0.722572 0.507965 0.00 0.318641 -0.674762 0.665706 0.00 5064.624023 590.030945 -1211.297729 1.00 VIEW From 0.468893 0.722572 0.507965 0.00 -0.823776 0.150286 0.546632 0.00 0.318641 -0.674762 0.665706 0.00 5064.624023 590.030945 -1211.297729 1.00 POS Aircraft 0.823778 -0.150284 -0.546631 0.00 0.468911 0.722528 0.508011 0.00 0.318610 -0.674809 0.665673 0.00 5064.621582 590.031433 -1211.296509 1.00 VIEW From 0.468911 0.722528 0.508011 0.00 -0.823778 0.150284 0.546631 0.00 0.318610 -0.674809 0.665673 0.00 5064.621582 590.031433 -1211.296509 1.00 Note that one is applied to the object and the other the camera. If you look closely you'll see that the numbers in sync. This is only a couple of iterations, but the values don't diverge over time either. With no offsets what so ever to either the model or the camera the jitters are still there (I modified a model in order to observe the jitters at 0,0,0 offset). The jitters are also there in Chase View so it has nothing to do with rendering the cockpit in a seperate ssg root. This tells me the problem is most likely in plib, or at least plib is where we send these numbers. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson writes: Setting all the view offsets to 0 I was able to prove that the position/rotation matrices generated on the model and the camera are numerically identical. Here's a sample from the dump: POS Aircraft 0.823776 -0.150286 -0.546632 0.00 0.468893 0.722572 0.507965 0.00 0.318641 -0.674762 0.665706 0.00 5064.624023 590.030945 -1211.297729 1.00 VIEW From 0.468893 0.722572 0.507965 0.00 -0.823776 0.150286 0.546632 0.00 0.318641 -0.674762 0.665706 0.00 5064.624023 590.030945 -1211.297729 1.00 POS Aircraft 0.823778 -0.150284 -0.546631 0.00 0.468911 0.722528 0.508011 0.00 0.318610 -0.674809 0.665673 0.00 5064.621582 590.031433 -1211.296509 1.00 VIEW From 0.468911 0.722528 0.508011 0.00 -0.823778 0.150284 0.546631 0.00 0.318610 -0.674809 0.665673 0.00 5064.621582 590.031433 -1211.296509 1.00 Note that one is applied to the object and the other the camera. If you look closely you'll see that the numbers in sync. This is only a couple of iterations, but the values don't diverge over time either. With no offsets what so ever to either the model or the camera the jitters are still there (I modified a model in order to observe the jitters at 0,0,0 offset). The jitters are also there in Chase View so it has nothing to do with rendering the cockpit in a seperate ssg root. This tells me the problem is most likely in plib, or at least plib is where we send these numbers. Plib for the most part is a very thin layer on top of opengl so these matricies are probably getting sent directly to opengl so most likely we are achieving some sort of numerical precision problem that is affecting opengl. This sort of thing probably isn't a bug with plib. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson [EMAIL PROTECTED] said: This tells me the problem is most likely in plib, or at least plib is where we send these numbers. On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. The variations are probably correct, but the way 3D rendering works you get what appears to be a jump when a pixel boundry is crossed. This is clearest when testing with the magic carpet fdm. Maybe anti-aliasing would fix the problem, but it seems that the only reasonable way to get rid of this is to make the cockpit a special case model and overlay it after all the scenery, etc. is rendered (without the position/orientation transformations). On the other hand I'm not sure that this is a good idea as a perfectly stable cockpit that does not jitter at all wouldn't be realistic either. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Engine project started
ace project writes: In my previous mail (Multplayer efforts ?) We asked for the status on multiplayer-capabilities. We received responses that suggested that such an engine was not maintained for a while. We ourselves could use the engine for adding NPC to the project, but thats still a far goal. My friend and I got permission from our school to build such an engine as a school project. We got 100 dedicated work days to make this happen, so wish us luck ! Our part of the engine will be handling the network-traffic and status of the connection. Easy to use hooks to draw the plaines in the game should be developed by the core team, if they don't exist yet. If there are such hooks, plz mail them, so that we can tweak data-packets to them. Today we started brainstorming about what data would be interresting for multiplayer. As soon as this is finished I'll post the result for request for comment. The first prototype to be capable of hooking into the game should be ready within 2 months. This will be a kind of software switch, wherein the clients to the heavy work of collision detection and such. Test-releases to test network performance and incompatibilities should be out by next month. Comments are highly appriciated, Ok, here are some various thoughts ... I agree you want to generally use UDP. I'd strongly suggest you build everything with the plib net libraries since that makes all the socket/net platform portability issues go away (plus as Norman mentioned, it is patterned after a proven design.) Even if you have a UDP data channel, you might also want to consider a TCP channel for 'command' type messages ... things that the server might only want to send once. For one application here I did this and used an embedded http server as the command channel. That preserves a 'connectionless' design where either side can shut down and start up without hosing the other side. People have talked about HAL/DIS implimentations before, but nothing has ever been done with that. As I understand it, one thing that DIS does to conserve bandwidth is both sides (client/server) use the same fprediction algorithm. That way the server can know where the clients have extrapolated the other aircraft to be. When this diverges enough from the real position, the server can send new information. If you are talking about building a system that can function over a 56kb modem connection, then I really doubt you will need to seriously consider threaded vs. multiplexed performance issues. Even if this does eventually become an issue, I'd strongly suggest starting out with a simpler multiplexed implimentation, and some day when we have thousands of people served off the same server, we could take the time then to sit down and write a multi-threaded implimentation that runs on some huge super computer with huge pipes. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson writes: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. The variations are probably correct, but the way 3D rendering works you get what appears to be a jump when a pixel boundry is crossed. This is clearest when testing with the magic carpet fdm. Maybe anti-aliasing would fix the problem, but it seems that the only reasonable way to get rid of this is to make the cockpit a special case model and overlay it after all the scenery, etc. is rendered (without the position/orientation transformations). On the other hand I'm not sure that this is a good idea as a perfectly stable cockpit that does not jitter at all wouldn't be realistic either. It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] jitters testing
Jim Wilson wrote: On further investigation, it appears that this is almost certainly due to normal variation in fdm position and orientation output. This theory doesn't work though. Think about it: in cockpit mode, the orientation of the aircraft is bolted to the FDM orientation. If the FDM points left, the cockpit will point left by the same amount. Jitter from the FDM would cause the *scenery* to jitter, not the cockpit. Conversely, in tower view, the scenery should stay put while the aircraft jitters. But it doesn't, the aircraft geometry jitters here too. So the problem somewhere in the model's scene graph; there really aren't any other places it could hide that I can think of. Could you give us a quick rundown of exactly which matrices or ssgTransforms get added to the scene graph and where they come from? I started tracing this out but got distracted by the glut font stuff (different discussion entirely). :) 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] jitters testing
Curtis L. Olson wrote: It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. Actually, the whole cockpit is jittering. The ball just has more high-frequency information to catch your eye. The panel doesn't (er, didn't) jitter because it's drawn via an entirely different code path that doesn't look at aircraft orientation at all -- only viewing offsets. If you apply my current 3D panel code, you'll see the whole cockpit assembly wiggle in exactly the same way. 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] jitters testing
Jim Wilson writes: Curtis L. Olson [EMAIL PROTECTED] said: It seems strange that everything else in the cockpit and 3d model of the aircraft is perfectly stable and only this one instrument is jittery. That's an optical illusion. Turn off the panel and you'll see that the whole cockpit jitters in unison. I actually think it'll be ok once we remove the 2D panel all together. Ok, you are right, the entire 3d aircraft model is jittering. That points to a discrepancy between the model position and the view position (or some rounding or numerical precision issue.) If the view position and model position matched exactly, there shouldn't be any jitter. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New panel code
David Megginson wrote: 1. Can you post a copy of your modified base-package files (a4-yasim-set.xml and a4-blue.xml)? The -set files don't require any significant changes -- just remove the panel entries and that's it. The model files for the A-4 and 172 are attached. All they needed is a panel entry like the one I posted. 2. Are you willing to do the 3D C172 file? I don't want to put your patches in CVS if they'll kill the current 3D cockpit for the 172; OK, attached. I just lifted some rough coordinates from AC3D's demo program and twiddled a bit to get it to look more or less OK. It's not polished, but it'll do. The mag compass is partly obscured by geometry -- it should really move into its own panel somewhere else, or be modeled in full 3D. Also, the background texture doesn't quite match the geometry it's drawn on. But it's there, it works, and it's drawn *behind* the yoke. :) One thing is wrong, though: Something is drawing the 2D panel, even though I removed the entries from the -set.xml file. I'm flummoxed on this one. It's not part of my code changes, as it's there regardless of whether the 3D panel exists or not. It doesn't happen on the A-4; is it possible that something has hard-coded the 172's panel 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) ?xml version=1.0? PropertyList pathc172-dpm.ac/path !-- 3D Panel -- panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path bottom-left x-m-0.12/x-m y-m-0.64/y-m z-m-0.36/z-m /bottom-left bottom-right x-m-0.12/x-m y-m 0.64/y-m z-m-0.36/z-m /bottom-right top-left x-m-0.17/x-m y-m-0.64/y-m z-m 0.06/z-m /top-left /panel !-- LOD for the model as a whole -- animation typerange/type min-m0/min-m max-m1/max-m /animation !-- LOD for specific objects -- animation typerange/type object-nameCabin/object-name object-nameSeat.1/object-name object-nameSeat.2/object-name object-nameSeat.3/object-name object-nameSeat.4/object-name min-m0/min-m max-m50/max-m /animation animation typerange/type object-nameYoke.1/object-name object-nameYoke.2/object-name object-namePedal.1/object-name object-namePedal.2/object-name object-namePedal.3/object-name object-namePedal.4/object-name object-nameThrottle/object-name object-nameMixture/object-name object-nameCompass/object-name object-namePedestal/object-name min-m0/min-m max-m3/max-m /animation !-- Object movements -- animation typeselect/type object-namePropeller/object-name condition less-than property/engines/engine[0]/rpm/property value1500/value /less-than /condition /animation animation typeselect/type object-namePropeller.2/object-name condition greater-than property/engines/engine[0]/rpm/property value1000/value /greater-than /condition /animation animation typetranslate/type object-nameThrottle/object-name property/controls/throttle[0]/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typetranslate/type object-nameMixture/object-name property/controls/mixture[0]/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typetranslate/type object-nameYoke.1/object-name property/controls/elevator/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typerotate/type object-nameYoke.1/object-name property/controls/aileron/property factor-45.0/factor axis x1.0/x y0.0/y z0.0/z /axis center x-m0/x-m y-m-.26/y-m z-m-.29/z-m /center /animation animation typetranslate/type object-nameYoke.2/object-name property/controls/elevator/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typerotate/type object-nameYoke.2/object-name property/controls/aileron/property factor-45.0/factor axis x1.0/x y0.0/y z0.0/z /axis center x-m0/x-m y-m.27/y-m z-m-.29/z-m /center /animation animation typetranslate/type object-namePedal.1/object-name object-namePedal.3/object-name property/controls/rudder/property factor0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation animation typerotate/type object-namePedal.1/object-name object-namePedal.3/object-name property/controls/brakes[0]/property factor-15/factor axis x0.0/x y1.0/y z0.0/z /axis center x-m-0.1/x-m y-m0/y-m z-m-0.9/z-m /center /animation animation typetranslate/type object-namePedal.2/object-name object-namePedal.4/object-name property/controls/rudder/property factor-0.1/factor axis x1.0/x y0.0/y z0.0/z /axis /animation
