Re: [Flightgear-devel] perplexing make error
The next thing to try would be to find all the .deps subdirectories throughout the entire project and nuke them. I think running the following should do the trick: make distclean-depend make couldn't find a target for that guy, but I can kill them manually. I'm trying a cvs -dPA at the moment. Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy. -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear performance
I find that Linux provides the most CONSISTENT performance, since FlightGear supports multiple threads under Linux (./configure --with-threads). I use this so the page build rate does not get degraded by the loading of scenery. I do build under both Windows (9x) and Linux and see very similar FPS values. I would go with the compiler environment you prefer. If you prefer an IDE, you may want to use MSVC under Windows. I don't know if you can build FlightGear under something like KDevelop. Jonathan Polley On Wednesday, April 17, 2002, at 09:15 AM, Curtis L. Olson wrote: Marcel Wittebrood writes: Dear developers, I am in process to become a developer. I wandered though the archives but could not find an answer to my question : Which operating system (Lunix or Windows) gives the best flightgear performance on the same computer ? Stated in other words. Is there any noticeable difference in the number of frames/ sec. when running on either Windows or Linux ? There isn't a direct answer to your question. It depends mostly on the particular video card you have and the quality of it's windows vs. linux driver software. For nvidia cards, nvidia makes both the linux and windows drivers and as I understand it, they share a common core code set, so performance between windows/linux with nvidia hardware is nearly identical. For other cards your results may vary. But in terms of windows vs. linux there really isn't much difference once the applications is up and running. You might find differences in compiling with gcc on linux vs. cygwin on windows. (But gcc on linux vs. msvc on windows might be a fairer test to do.) You might find differences if you measure just the amount of time to load data off the hard drive, although your quality of disk subsystem hardware (i.e. scsi vs. ide) plays a big part there as well. You might find differences if you run other intensive programs on the same machine at the same time (but you don't want to do that usually on either platform.) You might find differences if you are low on memory and have to page swap. But, for smooth frame rates on any platform you want a fast processor, a fast video card, good drivers for that video card, enough memory so you don't have to page swap, and you don't want other processes running and competing for the cpu. So, the answer is yes you may find some differences if you look closely, but no probably none that have any real signficance (beyond the quality of your video card drivers.) Choose your favorite OS, hardware, compiler, and video card and hopefully flightgear will run just fine on it. If not, hopefully you can help us fix the problems and/or port the code to your platform. Best 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Coordinate Systems
My model uses a rotation matrix to specify its orientation. But it looks like FlightGear wants Euler angles. Is there funcitonality for converting from one to the other in FG or PLIB? Also, I'm using a cartesian vector for position. Is there a good way of converting to geocentric coordinates? I didn't consider driving around the world when I started my project:) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] perplexing make error
Keith Wiley writes: The next thing to try would be to find all the .deps subdirectories throughout the entire project and nuke them. I think running the following should do the trick: make distclean-depend make couldn't find a target for that guy, but I can kill them manually. I'm trying a cvs -dPA at the moment. If the cvs update -dPA doesn't do the trick, try killing all your .deps subdirectories inside the FlightGear src. 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] perplexing make error
I managed to sort out the problems and get things to compile. I was forced to remove my altered versions of fg_init.cxx and options.cxx. It refused to merge them, or replace them, or compile them, or whatever. But by removing my files, it recvsed the cvs versions and it compiled. I am still dreadfully disappointed in the framerate. It runs about 1 or 2 fps, whereas if I run the latest binary download I get 7 or 8 fps. Keith Wiley[EMAIL PROTECTED] http://www.unm.edu/~keithw http://www.mp3.com/KeithWiley Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy. -- Edwin A. Abbott, Flatland ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Coordinate Systems
Sam Varner [EMAIL PROTECTED] said: My model uses a rotation matrix to specify its orientation. But it looks like FlightGear wants Euler angles. Is there funcitonality for converting from one to the other in FG or PLIB? Yes in Plib. Also, I'm using a cartesian vector for position. Is there a good way of converting to geocentric coordinates? That's in SimGear. Take a look at location.cxx in cvs for usage of both in FlightGear. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinate Systems
Jim Wilson writes: Sam Varner [EMAIL PROTECTED] said: My model uses a rotation matrix to specify its orientation. But it looks like FlightGear wants Euler angles. Is there funcitonality for converting from one to the other in FG or PLIB? Yes in Plib. Eventually anything displayed by SSG, the SceneGraph component of PLib, has its orientation specified by a rotation matrix. So it may be you do not need to go from Matrix to Euler Angles and back again to a Matrix. My guess is that your orientation is with respect to the local tangent plane and this may in fact be good enough as is, if not it certainl;y is no more then a Matrix multiply away :-) Also, I'm using a cartesian vector for position. Is there a good way of converting to geocentric coordinates? That's in SimGear. Take a look at location.cxx in cvs for usage of both in FlightGear. Main / Location.hxx is a good place to start looking but my question is what does your 'cartesian vector' represent ? It could well be that there is a 'short cut' you can take as geocentric coordinates are also a 'cartesian vector'. Hard to tell you exactly what is the 'best approach' for you to take with out a little more info Note that I may be a little vague as to exactly what Matrix you want to use to transform your vectors in that others are restructuring the pipeline but I believe that the one you are probably most interested in is still called UP This represents the surface normal's orientation matrix at the current location Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinate Systems
On Wed, 2002-04-17 at 18:47, Norman Vine wrote: Eventually anything displayed by SSG, the SceneGraph component of PLib, has its orientation specified by a rotation matrix. So it may be you do not need to go from Matrix to Euler Angles and back again to a Matrix. My guess is that your orientation is with respect to the local tangent plane and this may in fact be good enough as is, if not it certainl;y is no more then a Matrix multiply away :-) If someone shows me how to use my matrix directly, I'll do that. For now I've written a conversion function that I'll probably stick into my matrix class. Main / Location.hxx is a good place to start looking but my question is what does your 'cartesian vector' represent ? It could well be that there is a 'short cut' you can take as geocentric coordinates are also a 'cartesian vector'. The position vector points from some anonymous origin to the origin of the vehicle's frame. The origin is wherever the vehicle would be if you didn't move it. You could put the origin wherever you want by explicitly setting the position vector, as long as you do the correct transformation to FlightGear's coordinate system. What origin makes the most sense in this context? Note that I may be a little vague as to exactly what Matrix you want to use to transform your vectors in that others are restructuring the pipeline but I believe that the one you are probably most interested in is still called UP I'll give it a try. This represents the surface normal's orientation matrix at the current location Is this normal to the sea-level surface or normal to the terrain? Thanks for your help. I'm getting close. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinate Systems
Can you describe your matrix? Is this of any use to you?: http://jsbsim.sourceforge.net/quaternions.html If someone shows me how to use my matrix directly, I'll do that. For now I've written a conversion function that I'll probably stick into my matrix class. smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] perplexing make error
Curtis L. Olson [EMAIL PROTECTED] said: Keith Wiley writes: The next thing to try would be to find all the .deps subdirectories throughout the entire project and nuke them. I think running the following should do the trick: make distclean-depend make couldn't find a target for that guy, but I can kill them manually. I'm trying a cvs -dPA at the moment. If the cvs update -dPA doesn't do the trick, try killing all your .deps subdirectories inside the FlightGear src. make distclean gets the .dep directories. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinate Systems
Sam Varner writes: On Wed, 2002-04-17 at 18:47, Norman Vine wrote: Eventually anything displayed by SSG, the SceneGraph component of PLib, has its orientation specified by a rotation matrix. So it may be you do not need to go from Matrix to Euler Angles and back again to a Matrix. If someone shows me how to use my matrix directly, I'll do that. For now I've written a conversion function that I'll probably stick into my matrix class. Cool - get it running first as they say :-) Main / Location.hxx is a good place to start looking but my question is what does your 'cartesian vector' represent ? The position vector points from some anonymous origin to the origin of the vehicle's frame. The origin is wherever the vehicle would be if you didn't move it. You could put the origin wherever you want by explicitly setting the position vector, as long as you do the correct transformation to FlightGear's coordinate system. What origin makes the most sense in this context? My guess is the scenery_center and update everything to reflect this when this changes. I think that we can just borrow code from 'prep_ssg_node' in svenery / tile_entry.cxx to handle this when that need arises This represents the surface normal's orientation matrix at the current location Is this normal to the sea-level surface or normal to the terrain? from the ellipsoid's sea-level surface The normal reported by the scenery class is the normal to the terrain at this point. Clear as mud, right :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Propellor graphics
The spinning propellor (on c172-3d) needs a bit of work. It spins even when the model is parked and the engine stopped. If pause mode is on, it spins more slowly but still does not stop. With magnetos off but starter engaged, the tachometer shows about 600 RPM (i.e. 10 revs per second). The propellor spins at one and a bit revs per second. I think the propellor is supposed to be directly driven from the engine crankshaft, but I'm not sure. The two blades are not twisted relative to each other: one blade is pushing and the other pulling. The transparency feature is not working for me, so the propellor disc suddenly appears as an opaque object. I have applied David Megginson's plib-smoothing.dif and my plib (from CVS) already appears to have the equivalent of the transparency patch. That bug may be the only reason for the following observation: The disc that fades in at higher speeds is solid grey for me. It needs to have a (radial) colour profile that matches the blades, i.e. mostly black with some red bits. The expected grey appearance will come automatically when a partially transparent black disc is displayed over a light background (sky etc.). But nevertheless it is a nice fun, eye-catching feature. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
Jonathan Polley wrote: My C training goes back to circa 1985, at which time all floats were passed as doubles. Yes, they were. In fact, the modern C/C++ compilers to which I have access still do this (I don't use gcc, except to rebuild FlightGear). Oh? Which compilers? All floating-point co-processors do their work in extended precision (usually 80-96 bits) and shorten the numbers back to the range desired by the user, Certainly some do. I'm pretty sure that not all do, at least not for functions that can be done significantly faster at lower precision. and the single-precision math libraries I have used just cast the results of the double-precision routines to be single-precision (it saves on duplicated code). At work we use an Intermetrics C compiler (Intertools for NEC V20 series processors) that is supplied with a standard software floating-point library that includes separate single and double-precision versions of most of the routines. There is also an alternate version of the library which uses the same data sizes (4 and 8 bytes) but does not calculate to the full accuracy, and is considerably faster. You can choose the most appropriate library for your application. I must be older than anyone else here, but my collegiate C training drove home the fact that mixing integer and floating-point can give you unpredictable results. Granted, this was pre-ANSI C. Maybe it was unpredictable before standardisation, but I feel that's unlikely; I don't have the original (KR) reference book to check. Another possibility is that the teacher couldn't predict the results because he/she didn't know the language well enough ... that's quite common, unfortunately. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Purpose of the Next Release?
On Wednesday, April 17, 2002, at 07:45 PM, Julian Foad wrote: Jonathan Polley wrote: My C training goes back to circa 1985, at which time all floats were passed as doubles. Yes, they were. In fact, the modern C/C++ compilers to which I have access still do this (I don't use gcc, except to rebuild FlightGear). Oh? Which compilers? We use Rational Ada/C for our embedded development. Their C compiler passes passes floats as doubles for C, but will pass a Float as a single, Long_Float as double, in Ada (nothing like consistency). We get burned by that every so often. This is primarily for Solaris (were our simulation environment runs), so it may be a Sun convention as well. I believe I have also seen this interaction between the Aonix Ada compiler and MSVC. I tend to see these problems due to our mixed language development. [...] Maybe it was unpredictable before standardisation, but I feel that's unlikely; I don't have the original (KR) reference book to check. Another possibility is that the teacher couldn't predict the results because he/she didn't know the language well enough ... that's quite common, unfortunately. My C profs were a couple of C hackers form ATT Bell Labs. Given what their area of research was (data communication), I don't think this was the issue. My main purpose for the single- vs. double-precision question was this: On this program, given its hardware requirements, does it make sense to work with single-precision floating point numbers? In our case, there will be no speed improvement (all platforms need FPUs) and the space savings is negligible. The other issues are just personal whininess. My primary job is supporting avionics software development. Because it is written in Ada, and my work has become mostly C, I get to deal with many strange forms of interaction. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Propellor graphics
Julian Foad writes: The spinning propellor (on c172-3d) needs a bit of work. It spins even when the model is parked and the engine stopped. If pause mode is on, it spins more slowly but still does not stop. For me, the propellor does stop completely. With magnetos off but starter engaged, the tachometer shows about 600 RPM (i.e. 10 revs per second). Yes, I think the tach probably should only read 100-200 rpm while the engine is cranking, before it catches. Maybe Alex (or David) could watch this on their next flight? The propellor spins at one and a bit revs per second. I think the propellor is supposed to be directly driven from the engine crankshaft, but I'm not sure. Yes, the propellor spins way to slowly compared to engine rpm. This might be intentional so that it maintains 'smooth' animation. But, it is maybe just a little noticably too slow ... The two blades are not twisted relative to each other: one blade is pushing and the other pulling. I've mentioned this to David M. before, but I'm not sure I communicated this well. He really needs to take a look at a real prop and visualize how it pushes the air as it turns. One of the blades of the prop is definitely angled 'backwards.' The transparency feature is not working for me, so the propellor disc suddenly appears as an opaque object. I have applied David Megginson's plib-smoothing.dif and my plib (from CVS) already appears to have the equivalent of the transparency patch. That bug may be the only reason for the following observation: The disc that fades in at higher speeds is solid grey for me. It needs to have a (radial) colour profile that matches the blades, i.e. mostly black with some red bits. The expected grey appearance will come automatically when a partially transparent black disc is displayed over a light background (sky etc.). You need to upgrade to the latest cvs-plib to get a transparent prop. David found a bug/limitation in plib when he was trying to impliment a semi-transparent prop disk. Unfortunately it's there in the stable 1.4.x releases. But nevertheless it is a nice fun, eye-catching feature. Yes, David did a very nice job on his first crack at it. A few more little tweaks and it will 'perfect.' :-) 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] Propellor graphics
Curtis L. Olson wrote: Yes, the propellor spins way to slowly compared to engine rpm. This might be intentional so that it maintains 'smooth' animation. But, it is maybe just a little noticably too slow ... Actually, I think this is a recent change. I remember doing some back of the envelope (er, wristwatch, in this case) work to verify the speeds when the feature first went in, and the speed looked pretty much correct. But in current code, it's slow; maybe an extra factor of something or other got added? 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
