Re: [Flightgear-devel] 3d cloud rendering problems
From: Curtis L. Olson [EMAIL PROTECTED] Norman Vine writes: Curtis L. Olson Norman Vine writes: I think you are on to something ! That would explain the lightening of the clouds with each pass. BUT this only started after I updated my code the other day !. Also I never had the 'text' texture Right now I'm wondering if it is related to the use of glColorMaterial()? The curious thing is that the 'coloring bug' and the the texture 'jitter' just appeared recently and I can't see what changed to cause it. Dohh! Disabling lighting seems like it may have fixed the problem. Still playing. Yes! clouds now appears like they should : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-ok.png However, there are still problems : 1. I can't see clouds from the cockpit, (Well, not really, there are clouds in the cockpit : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-inboard.png or is it fire ?) 2. When I take a screenshot from the chase view, the plane model disappears, 3. The propeller disk is drawn with the wrong blend function : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-propeller.png (taken with win screen capture, otherwise there is no cockpit with F3) 4. I can see plain textures sometimes (often when in the cockpit) : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-texture.png Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear CVS failure?
Jon Berndt writes: I get this error this evening for the SimGear CVS server: $ cvs update -dP ? metakit-2.4.2 ? metakit-2.4.2-32.tar ? zlib-1.1.3.tar.gz ? simgear/metakit ? simgear/zlib ? src-libs/boost ? src-libs/Makefile ? src-libs/Makefile.in cvs server: Updating . cvs server: failed to create lock directory for `/var/cvs/SimGear-0.0/SimGear' (/var/cvs/SimGear-0.0/SimGear/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/var/cvs/SimGear-0.0/SimGear' cvs [server aborted]: read lock failed - giving up Jon, You'll need to do a fresh checkout of the CVS trees. See the specific instructions on the simgear.org and flightgear.org web pages. 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] Re: [Flightgear-cvslogs] Base CVSupdate:'FlightGear/FlightGear/Aircraft/c172'
Tony Peden writes: The 48 in number checks with my copy of the POH (from which many other numbers have been derived, so we should probably stick with that) You've talked before about forking, and that might not be a bad idea. Right now, we're more-or-less targetting a 172R, but the 48 number (and perhaps many others) come from a POH for earlier models. I have the performance tables and WB both for the 172R and the 172P -- let me know what numbers you'd like. My suggestion is that c172.xml (and --aircraft=c172) would disappear altogether, and we'd have c172p.xml and c172r.xml instead. 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] Modeling wing twist animation
Jim Wilson writes: One possible application of being able to apply the smoothing calculation to a group of 3D Model objects (as opposed to a single object in ac3d format) is in animating the Wright Brother's twisting wing lateral control method. One way would be to use and interpret user data entries in the model, but I'm wondering if it would be better (or possible) to do it through the xml model animation interface. That way the ac3d models would be complete as is (without interpreting the user data) and the behavior could be more easily modified (in XML) by someone that did not have the software. It's an interesting suggestion, but smoothing (as I use the term) isn't the main problem -- you want to be able to move some vertices without moving others. Smoothing just tweaks the normals to hide sharp edges. 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] Re: [Flightgear-cvslogs] Base CVSupdate:'FlightGear/FlightGear/Aircraft/c172'
On Thu, 2002-09-19 at 04:26, David Megginson wrote: Tony Peden writes: The 48 in number checks with my copy of the POH (from which many other numbers have been derived, so we should probably stick with that) You've talked before about forking, and that might not be a bad idea. Right now, we're more-or-less targetting a 172R, but the 48 number (and perhaps many others) come from a POH for earlier models. I have the performance tables and WB both for the 172R and the 172P -- let me know what numbers you'd like. My suggestion is that c172.xml (and --aircraft=c172) would disappear altogether, and we'd have c172p.xml and c172r.xml instead. I don't really object to that -- except that I wonder how many folks will be able to really tell the difference. Surely, even in the real thing, the differences are fairly subtle. I'm also not so sure that we have the fidelity that making that distinction implies. 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 -- 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] 3d cloud rendering problems
Curtis L. Olson wrote: Norman Vine writes: Curtis L. Olson Norman Vine writes: I think you are on to something ! That would explain the lightening of the clouds with each pass. BUT this only started after I updated my code the other day !. Also I never had the 'text' texture Right now I'm wondering if it is related to the use of glColorMaterial()? The curious thing is that the 'coloring bug' and the the texture 'jitter' just appeared recently and I can't see what changed to cause it. Dohh! Disabling lighting seems like it may have fixed the problem. Still playing. Hmm. which makes me think it might have something to do with the shininess code from me you applied recently? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Another automake victim
Curtis L. Olson wrote: As of version 0.8.0, configure.in no longer exists. It is replaced by configure.ac. As long as you run autogen.sh first, you should be fine. Otherwise, make sure you have at least automake-1.5 and autoconf-2.52 installed. Regards, Curt. William Earnest writes: The Bergrens wrote: Sounds like you need the perl module called strict to be installed. Or maybe your perl installation is hosed. You can get perl modules from cpan.org, I think. - Original Message - From: William Earnest [EMAIL PROTECTED] To: Devel Flightgear [EMAIL PROTECTED] Sent: Tuesday, September 10, 2002 10:38 PM Subject: [Flightgear-devel] Another automake victim Hello all, Came back from vacation to find the new release and lots of discussion. Read everything (I think), and managed to get CVS caught up, including the new SimGear path. Updated plib without problem, then went to SimGear to continue. At the autogen.sh step, got the following pile of errors, which has me rather puzzled. Supposedly have automake 1.5 installed, as well as autoconf 2.52. Any suggestions? [wde@hulk SG]$ ./autogen.sh Can't locate strict.pm in @INC (@INC contains: /usr/share/automake /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/bin/automake line 39. ./autogen.sh: test: -lt: unary operator expected Host info: Linux i686 Can't locate strict.pm in @INC (@INC contains: /usr/share/automake /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503 /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .) at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/share/automake/Automake/Struct.pm line 29. BEGIN failed--compilation aborted at /usr/bin/automake line 39. automake: () Running aclocal Running autoheader /usr/bin/m4: configure.in: No such file or directory ERROR: autoheader didn't create simgear/simgear_config.h.in! -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ 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 Hi again, Thanks for the clue, I finally found some remains of a previous perl installation that had eluded me before. That got rid of the odd compilation errors. I am now left with this: Host info: Linux i686 automake: 1.5 (15) Running aclocal Running autoheader /usr/bin/m4: configure.in: No such file or directory ERROR: autoheader didn't create simgear/simgear_config.h.in! In flightGear, I get a similar complaint about configure.in, but the setup continues, and the ready to configure stage is reached. This has me hopeful that there is not too much else before I can catch up. Starting to suffer from sim withdrawal with nothing working. :-) -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Curt, That may be it. As message showed, automake is 1.5, and the error comes from running autogen.sh. However, autoconf is at 2.13, so now to search for a newer one. Thanks! -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Base Package size (was 3D clouds)
- Original Message - From: Frederic Bouvier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 19, 2002 12:21 AM Subject: Re: [Flightgear-devel] Base Package size (was 3D clouds) Here is a large.sky file that fetch field56.cld in Clouds3D (not Clouds3D/SkyClouds, I don't see a need for an additional level) I see your point --- agreed The update to the loader handled the problem wherein the $fg_root was not used to determine the pathname string returned by the archive.getInfo(...) method. Reducing the level should not be a problem. Just say yes. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/c172'
I don't really object to that -- except that I wonder how many folks will be able to really tell the difference. Surely, even in the real thing, the differences are fairly subtle. I'm also not so sure that we have the fidelity that making that distinction implies. I recommend the split, although I'd tend to move the P back to N. Analogy: Think of driving two cars - one has carb engine, the other fuel injected (you really care in winter) - one has ABS, the other does not (only matters if you brake hard) - one has sports suspension and the other regular (only for bad roads etc) In normal city traffic, you won't notice the difference. However, for emergency stuff, if you forget ... you'll probably die. When operating at full performance (eg mountain roads for skiing) ditto. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SimGear CVS failure?
Am I supposed to be getting fgfs-0.9 and simgear-0.3? SimGear-0.3 won't let me get it! ;-) == (Logging in to [EMAIL PROTECTED]) CVS password: Fatal error, aborting. cvs: no such user cvs login: authorization failed: server cvs.simgear.org rejected access to /var/cvs/SimGear-0.3 for user cvs Fatal error, aborting. cvs: no such user cvs checkout: authorization failed: server cvs.simgear.org rejected access to /var/cvs/SimGear-0.3 for user cvs cvs checkout: used empty password; try cvs login with a real password smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] SimGear CVS failure?
Curt changed the username password ... to force people to read the web page. Am I supposed to be getting fgfs-0.9 and simgear-0.3? SimGear-0.3 won't let me get it! ;-) == (Logging in to [EMAIL PROTECTED]) CVS password: Fatal error, aborting. cvs: no such user cvs login: authorization failed: server cvs.simgear.org rejected access to /var/cvs/SimGear-0.3 for user cvs Fatal error, aborting. cvs: no such user cvs checkout: authorization failed: server cvs.simgear.org rejected access to /var/cvs/SimGear-0.3 for user cvs cvs checkout: used empty password; try cvs login with a real password ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SimGear CVS failure?
I'm using the password on the simgear web page. What's going on? Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Perry Sent: Thursday, September 19, 2002 9:09 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] SimGear CVS failure? Curt changed the username password ... to force people to read the web page. Am I supposed to be getting fgfs-0.9 and simgear-0.3? SimGear-0.3 won't let me get it! ;-) == (Logging in to [EMAIL PROTECTED]) CVS password: Fatal error, aborting. cvs: no such user cvs login: authorization failed: server cvs.simgear.org rejected access to /var/cvs/SimGear-0.3 for user cvs Fatal error, aborting. cvs: no such user cvs checkout: authorization failed: server cvs.simgear.org rejected access to /var/cvs/SimGear-0.3 for user cvs cvs checkout: used empty password; try cvs login with a real password ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] Base CVS update:'FlightGear/FlightGear/Aircraft/c172'
Alex Perry writes: The last ten degrees _are_ mostly drag, but that's what you need (a) to get a steep final in rugged terrain (b) for fast descents in emergency management (c) for a relatively quick flare for short fields Speaking of quick flares, I'm finally getting the hang of *raising* the flaps to shorten my flare on shorter fields (not when the wheels are higher than a few inches above the runway, of course). 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
[Flightgear-devel] Progress, not quite there.
Hi again, Finally got the auto* mess resolved with a new version of autoconf. Properly gets thru configure in [Sim|Flight]Gear. Haven't been able to follow the new cloud work and this error appears related to that. Get a series of errors similar to the following in SimGear: SkyLight.cpp:202: cannot convert `int' to `GLenum' for argument `1' to `glLightfv (GLenum, GLenum, const GLfloat *)' SkyLight.cpp:203: cannot convert `int' to `GLenum' for argument `1' to `glLightf (GLenum, GLenum, float)' Hint appreciated, hoping to get caught up soon. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SimGear CVS failure?
Jon Berndt writes: I'm using the password on the simgear web page. What's going on? Are you using the correct user name as well? 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] 3d cloud rendering problems
Frederic Bouvier [EMAIL PROTECTED] said: 4. I can see plain textures sometimes (often when in the cockpit) : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-clouds3d-texture.png Same here. I don't have a model loaded so what I see is a font texture. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SimGear CVS failure?
OK, so which versions should I be using? I want to use the latest, as usual. Is there a reason not to? Jon smime.p7s Description: application/pkcs7-signature
re: [Flightgear-devel] Modeling wing twist animation
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: One possible application of being able to apply the smoothing calculation to a group of 3D Model objects (as opposed to a single object in ac3d format) is in animating the Wright Brother's twisting wing lateral control method. One way would be to use and interpret user data entries in the model, but I'm wondering if it would be better (or possible) to do it through the xml model animation interface. That way the ac3d models would be complete as is (without interpreting the user data) and the behavior could be more easily modified (in XML) by someone that did not have the software. It's an interesting suggestion, but smoothing (as I use the term) isn't the main problem -- you want to be able to move some vertices without moving others. Smoothing just tweaks the normals to hide sharp edges. Yes that's right. Moving individual vertices would of course be ideal, but it was a bit more than I was hoping for right now :-) What I'm talking about is gathering all the vertices in a group of objects and calculating the smoothing for all as if they were one. Then I can break the trailing wing tips into multiple objects, but not lose their edges. Basically I want to break the wing up but have the normals calculated as if it was whole. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgfs cvs
When I update fgfs cvs I get a hang here: cvs server: Updating src/WeatherCM cvs server: Updating tests hangs Is there a problem with the server? Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] fgfs cvs
Jon Berndt wrote: When I update fgfs cvs I get a hang here: cvs server: Updating src/WeatherCM cvs server: Updating tests hangs Is there a problem with the server? Jon Jon, Try removing any compression option such a -z3 if you are using it. I had a similar problem a few months ago. -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Progress, not quite there.
SkyLight.cpp:202: cannot convert `int' to `GLenum' for argument `1' to `glLightfv (GLenum, GLenum, const GLfloat *)' SkyLight.cpp:203: cannot convert `int' to `GLenum' for argument `1' to `glLightf (GLenum, GLenum, float)' Hint appreciated, hoping to get caught up soon. -- Check back about a week ago, there was a post and, I believe, a patch posted. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS build problem, was Another automakevi ctim
I did that for both SimGear and FlightGear. Now I can build SimGear without any problem, but FlightGear no longer builds! Here is the error: /usr/local/lib/libsgclouds3d.a(SkyContext.o): In function `_10SkyContext': /usr/local/src/cvs-devel/SimGear/simgear/sky/clouds3d/SkyContext.cpp:57: undefin ed reference to `glInitialize' /usr/local/lib/libsgclouds3d.a(SkyTextureState.o): In function `SkyTextureState: :Activate(void)': /usr/local/src/cvs-devel/SimGear/simgear/sky/clouds3d/SkyTextureState.cpp:92 : un defined reference to `glActiveTextureARB' /usr/local/src/cvs-devel/SimGear/simgear/sky/clouds3d/SkyTextureState.cpp:15 4: u ndefined reference to `glActiveTextureARB' collect2: ld returned 1 exit status make[2]: *** [fgfs.exe] Error 1 make[2]: Leaving directory `/usr/local/src/cvs-devel/FlightGear/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/cvs-devel/FlightGear/src' make: *** [all-recursive] Error 1 Any ideas? Mark -Original Message- From: Norman Vine [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 18, 2002 5:39 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Another automake victim Boslough, Mark B writes: I can build the stable cvs versions of simgear and flightgear now, but the devel version of simgear does not build, failing as follows: SkyContext.hpp:40: extgl.h: No such file or directory Do a cvs update Hopefuly this should all be in place as of a couple of hours ago. Norman ___ 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
RE: [Flightgear-devel] CVS build problem, was Another automakevi ctim
I just tried that and unfortunately I get exactly the same problem. I am going to try again from scratch. I do have a question. How do I keep the two CVS branches separated? When I do a make install for simgear on the stable branch, does that not overwrite the simgear for the devel branch? I'm just wondering what is the best way to keep the branches totally isolated from one another. Sorry if this has been answered elsewhere (as I am sure it has). Mark -Original Message- From: Norman Vine [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 19, 2002 12:53 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] CVS build problem, was Another automake vi ctim Boslough, Mark B writes: I did that for both SimGear and FlightGear. Now I can build SimGear without any problem, but FlightGear no longer builds! Here is the error: undefined reference to `glInitialize' undefined reference to `glActiveTextureARB' Any ideas? Try the following % cd $SIMGEAR % ./autogen.sh % cd simgear/sky/clouds3D % make install % cd $FLIGHTGEAR % make Please report back Norman ___ 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
Re: [Flightgear-devel] CVS build problem, was Another automake vi ctim
Boslough, Mark B writes: I just tried that and unfortunately I get exactly the same problem. OK I know what the problem is I am going to try again from scratch. Try changing SimGear\simgear\sky\clouds3d\Makefile around line 99 to read like this EXTRA_WIN32_SOURCES = extgl.c #EXTRA_WIN32_SOURCES = I do have a question. How do I keep the two CVS branches separated? When I do a make install for simgear on the stable branch, does that not overwrite the simgear for the devel branch? I'm just wondering what is the best way to keep the branches totally isolated from one another. Sorry if this has been answered elsewhere (as I am sure it has). The trick is to install the packages into different Sandboxes The easiest way for me is to use the --prefix=$PATH option when configuring a package HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS build problem, was Another automakevi ctim
Boslough, Mark B writes: I just tried that and unfortunately I get exactly the same problem. I am going to try again from scratch. I do have a question. How do I keep the two CVS branches separated? When I do a make install for simgear on the stable branch, does that not overwrite the simgear for the devel branch? I'm just wondering what is the best way to keep the branches totally isolated from one another. Sorry if this has been answered elsewhere (as I am sure it has). This is a slightly advanced operation, so don't feel too bad. You can start by using a different --prefix argument to ./configure for each branch, i.e. ./configure --prefix=/usr/local/experimental/ ./configure --prefix=/usr/local/stable/ 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] CVS build problem, was Another automakevi ctim
Thanks, I will try that. This is a slightly advanced operation, so don't feel too bad. You can start by using a different --prefix argument to ./configure for each branch, i.e. ./configure --prefix=/usr/local/experimental/ ./configure --prefix=/usr/local/stable/ 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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS question...
After many newbie-fied mistakes and misunderstanding I have now setup /home/cvsroot on my linux box and checked out up-to-date copies of the devel releases into: /home/cvsroot/SimGear /home/cvsroot/FlightGear /home/cvsroot/fgfsbase I also have a stable and working FGFS 0.8 which I'd like to keep (to play with if I bugger up the CVS version!). How do you guys compile a development version beside a stable one without it interfering? In other words what do you specify to ./configure when compiling these sources to keep them from starting a fist fight with each other? BTW, well done on the clouds guys they're coming along nicely and will look pretty sweet when they're done :-) Many thanks, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Question/Problem, WRT New Sky Code
Huzzah! I can run again!
Thanks for the help,
Jonathan Polley
On Thursday, September 19, 2002, at 07:09 AM, Norman Vine wrote:
Jonathan Polley
I did see this code block in SkySceneLoader.cpp (I assume that it is
global data):
// Need to add a light here until we figure out how to use the sun
position and color
SkyLight::SkyLightType eType = SkyLight::SKY_LIGHT_DIRECTIONAL;
SkyLight *pLight = new SkyLight(eType);
Is there any way I can defer this until after the main() starts?
Good catch :-)
try something like
SkyLight *pLight = NULL;
bool SkySceneLoader::Load(std::string filename)
{
if ( !pLight ) {
pLight = new SkyLight(eType);
if( !pLight)
DO SOMETHING DRASTIC
}
SkyArchive archive;
.
___
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
re: [Flightgear-devel] CVS question...
Matthew Law writes: I also have a stable and working FGFS 0.8 which I'd like to keep (to play with if I bugger up the CVS version!). How do you guys compile a development version beside a stable one without it interfering? In other words what do you specify to ./configure when compiling these sources to keep them from starting a fist fight with each other? I don't, personally. If I did, I would use a separate --prefix argument to each one and install it into an entirely different subtree. BTW, well done on the clouds guys they're coming along nicely and will look pretty sweet when they're done :-) I agree, but I'd be happier if they'd work with 16bpp as well as 32bpp (32bpp is too slow at 1600x1400 on my notebook). I guess I'd better pitch in soon rather than complaining. I think we might end up with a combination of the current texture approach and 3D clouds. For overcast, 3D probably doesn't make sense, since there's no hole to fly through anyway. Cirrus is a separate problem we'll have to address. 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
[Flightgear-devel] 3D Cloud Problems on Big-Endian Platforms
I decided to enable the 3D clouds so I could see the source of my
recent pain ;). It seems as if the file large.sky as some endian
issues. My FlightGear session hung as the process consumed 1GB (and
counting) of memory. I restarted it under gdb and found that it was
trying to load 452984832 bytes of data. Well, 452984832 is also
0x1b00 so the warning flags went off.
FWIW, here is the info out of gdb:
(gdb) backtrace
#0 0x90074b68 in memmove ()
#1 0x0015fbc0 in SkyArchive::AddData(char const*, SkyArchiveTypeCode,
void const*, unsigned, unsigned) (this=0xbfffddd0, pName=0xbfffdae1
CloudFile, eType=STRING_TYPE, pData=0xfa9f000, iNumBytes=452984832,
iNumItems=1) at SkyArchive.cpp:179
#2 0x00160d84 in SkyArchive::_Load(__sFILE*) (this=0xbfffddd0,
pSrcFile=0xa00069a8) at SkyArchive.cpp:1194
#3 0x001608e0 in SkyArchive::Load(char const*) (this=0xbfffddd0,
pFileName=0xa00069a8 \r¡ZM¡Z) at SkyArchive.cpp:976
#4 0x0005d92c in SkySceneLoader::Load(std::string) (this=0x2aa9f000,
filename={static npos = 4294967295, _M_dataplus = {allocatorchar =
{No data fields}, _M_p = 0xbfffde40 ¡Z¡Z¡Z\220.¡Ziy}, static
_S_empty_rep_storage = {0, 0, 67, 0}}) at
/usr/include/gcc/darwin/3.1/g++-v3/bits/basic_string.h:754
#5 0x00014a50 in fgInitSubsystems() () at
/sw/include/simgear/misc/sg_path.hxx:106
#6 0x5ef0 in fgIdleFunction() () at main.cxx:1282
As you can also see, at frame 3, there is a rather interesting file
name.
I will go back to what I had before, but let me know when you want me
to give the 3D clouds another shot on the Mac.
Jonathan Polley
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Norman Vine writes: I doubt if any amount of fiddling would make the 3D clouds work well in anything less then 32 bit color, as the eye is VERY sensitive to grey. I'm looking for work-at-all, not work-well. I don't care if they're pretty, as long as I can scud around 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] Re: 3d Clouds code
Norman, Ah there was a typo in the Makefile.am 'corrected' one attached SimGear/simgear/sky/clouds3d/Makefile.am Please 'report' back to the list as to how this works Does not yet work. However the offending lines seem to be different, now. This is the new result: - ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/Networ kOLK/libNetworkOLK.a ../../src/Objects/libObjects.a ../../src/Time/libTime.a ../ ../src/Environment/libEnvironment.a ../../src/Input/libInput.a -lsgroute -lsgsky -lsgclouds3d -lsgephem -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -ls gdeb ug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibnet -lpl ibss g -lplibsg -lplibul -lmk4 -lz -lpthread -lm -lglut32 -lglu32 -lopengl32 -lu ser3 2 -lgdi32 -lplibsl -lplibsm -lwinmm -lm /usr/local/lib/libsgclouds3d.a(SkyContext.o): In function `_10SkyContext': /usr/local/source/simgear/simgear/sky/clouds3d/SkyContext.cpp:57: undefined refe rence to `glInitialize' /usr/local/lib/libsgclouds3d.a(SkyTextureState.o): In function `SkyTextureState: :Activate(void)': /usr/local/source/simgear/simgear/sky/clouds3d/SkyTextureState.cpp:92: undefined reference to `glActiveTextureARB' /usr/local/source/simgear/simgear/sky/clouds3d/SkyTextureState.cpp:154: undefine d reference to `glActiveTextureARB' collect2: ld returned 1 exit status make[2]: *** [fgfs.exe] Error 1 - Regrads, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
David Megginson writes: I don't understand enough about OpenGL, but why would alpha work at 16bpp in textures (like panel instruments or propeller disks) and not in clouds? We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. 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] CVS question...
Curtis L. Olson writes: We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. The Impostors are generated with regular OpenGL calls just like everything else and then read out of the back buffer into a texture which then serves as an 'impostor' for the real OpenGL object. eg you are substituting a glQuad for the entire set of calls that were made to draw the object initially. hence the name 'impostor'. You can see the impostors getting created after you find and follow the directions in this line in SkyCloud.cpp // Uncomment this swap buffers to visualize cloud illumination computation. Whatching these things get created gives you a GOOD ideaof how much work the 'impostor' is saving you Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Norman Vine writes: Curtis L. Olson writes: We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. The Impostors are generated with regular OpenGL calls just like everything else and then read out of the back buffer into a texture which then serves as an 'impostor' for the real OpenGL object. eg you are substituting a glQuad for the entire set of calls that were made to draw the object initially. hence the name 'impostor'. You can see the impostors getting created after you find and follow the directions in this line in SkyCloud.cpp // Uncomment this swap buffers to visualize cloud illumination computation. Whatching these things get created gives you a GOOD ideaof how much work the 'impostor' is saving you Mark Harris mentioned that the back buffer requires a destination alpha for imposter rendering to work. Perhaps that's why things aren't great with a 16bit color buffer, you probalby aren't even getting an alpha channel there? 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] IFR in FlightGear
Tony Peden writes: Coming from one who lives in a place that is overcast 9 months out of the year, I must point out that there is a solution to that problem ... IFR. David comments: Surprisingly, I find this much harder when I am above the overcast layer because I *can* see: I tend to look out the window at the cloud horizon and my instrument scan goes to crap. As soon as I'm in the cloud and there's nothing out the window but white, my scan goes back to normal. When outside IMC, even when IFR, you are _supposed_ to be looking out at the scenery and almost never at the instruments. When not in a cloud, you are just as responsible for see-and-avoid as any other VFR aircraft. Therefore, above an overcast, you should be doing full traffic scans as usual, occasionally glancing in to check heading,altitude,navigation against your IFR clearance before going back to the traffic scan again. If you don't do that, you're setting yourself up to be a midair statistic. In FlightGear, do something like ... shift-4 [traffic] shift-7 [traffic] shift-8 [scan] [traffic] shift-9 [traffic] shift-6 [traffic] shift-9 [traffic] shift-8 [nav] [traffic] shift-7 [traffic] ... and repeat. Also, when you exit a cloud, whether side, bottom or top, do a full traffic scan that includes shift-1 and shift-3 before much else because you've got about 20 seconds before collision with a legal VFR aircraft and a lot less for someone who is cutting corners ... or if you're in class G. And, yes, maintaining IFR tolerances when in bumpy VMC is very busy work. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Clouds code
Norman, The better way to do this is to #include simgear_config.h in any file that needs the WIN32 symbol (or any other AC_DEFINE()'d symbol.) Regards, Curt. Norman Vine writes: Michael Basler Norman Vine wrote: Ah there was a typo in the Makefile.am 'corrected' one attached SimGear/simgear/sky/clouds3d/Makefile.am Please 'report' back to the list as to how this works Does not yet work. Hmm... Arrgh I forgot I had to tweak the configure.ac file because it no longer sets $CFLAGS=-DWIN32 Yep that's it In the windows section of configure.ac we need to set $CFLAGS . else dnl Win32 libs echo Win32 specific hacks... AC_DEFINE([WIN32], 1, [Define for Win32 platforms]) dnl this next line added for extgl.h CFLAGS=$CFLAGS -DWIN32 With this change AND the Makefile.am I posted earlier everything should work did for me with a fresh tarball modified as above Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] IFR in FlightGear
I did my first IFR flight last weekend (First one after getting my Instrument rating). It was in an Piper Arrow, which I have flown only two times before. Sky conditions where 2000 to 4000 overcast with 10sm+ visibility. I found it harder to fly the plane when VFR than when in actual because of the extra scanning you have to do outside the aircraft. For the first half of the flight, I was constantly fighting to keep within 10 degrees and 100 feet. After I got the hang of doing that, it was a little easier, but trying to learn a new complex plane and do an IFR flight in semi VFR conditions was a lot of work. I would recommend to anyone that is new to Instrument flight to go up with a safty pilot and practice. It is completely different than flying with the hood or foggles. BTW, in the last 4 months, I have flown 6 different models of aircraft.. I find it very rewarding and would recommend it to anyone. Ryan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alex Perry Sent: Thursday, September 19, 2002 9:22 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] IFR in FlightGear Tony Peden writes: Coming from one who lives in a place that is overcast 9 months out of the year, I must point out that there is a solution to that problem ... IFR. David comments: Surprisingly, I find this much harder when I am above the overcast layer because I *can* see: I tend to look out the window at the cloud horizon and my instrument scan goes to crap. As soon as I'm in the cloud and there's nothing out the window but white, my scan goes back to normal. When outside IMC, even when IFR, you are _supposed_ to be looking out at the scenery and almost never at the instruments. When not in a cloud, you are just as responsible for see-and-avoid as any other VFR aircraft. Therefore, above an overcast, you should be doing full traffic scans as usual, occasionally glancing in to check heading,altitude,navigation against your IFR clearance before going back to the traffic scan again. If you don't do that, you're setting yourself up to be a midair statistic. In FlightGear, do something like ... shift-4 [traffic] shift-7 [traffic] shift-8 [scan] [traffic] shift-9 [traffic] shift-6 [traffic] shift-9 [traffic] shift-8 [nav] [traffic] shift-7 [traffic] ... and repeat. Also, when you exit a cloud, whether side, bottom or top, do a full traffic scan that includes shift-1 and shift-3 before much else because you've got about 20 seconds before collision with a legal VFR aircraft and a lot less for someone who is cutting corners ... or if you're in class G. And, yes, maintaining IFR tolerances when in bumpy VMC is very busy work. ___ 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
