Re: [Flightgear-devel] Re: Wing motion
On December 19, 2005 02:49 am, Melchior FRANZ wrote: (C) tween method: this isn't implemented in fgfs yet, but plib offers an ssgTweenController (A morph controller) class. Maybe we should make it available in fgfs for wings/blades. It interpolates between two or more objects with the same number of verticesfaces, so one would only need two instances of the wing and could smoothly interpolate. Would probably work better than either (A) or (B). (see http://plib.sourceforge.net/ssg/branches.html and the test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx) On December 19, 2005 04:38 am, Melchior FRANZ wrote: I had already started. Just have to finish now. :-) m. I am looking forward to it, although I'm not too excited about having to create another instance of the wings. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On December 13, 2005 01:28 am, Mathias Fröhlich wrote: Well I swapped the minor and major aguments ... Yep. That line that you have added works. That one, appart from the color issue? Other than the color issue, the simulation seems to run fine. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On December 13, 2005 10:38 pm, Ampere K. Hardraade wrote: That one, appart from the color issue? Other than the color issue, the simulation seems to run fine. Ampere Actually, no. I've just noticed another problem. http://www.students.yorku.ca/~ampere/fgfs-screen-002.jpg Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On December 12, 2005 01:19 pm, Mathias Fröhlich wrote: On Donnerstag 08 Dezember 2005 02:08, Ampere K. Hardraade wrote: https://bugs.freedesktop.org/show_bug.cgi?id=5142 So, the problem seems to be that pbuffer is not supported? Can you test the attached patch? Greetings Mathias It didn't work. X still throws the GLXUnsupportPrivateRequest at line 496 in RenderTexture.cpp. Apparently, the return false; statement at line 1849 never got run. I will do some more investigation later on. GNU gdb 6.3.90_20051119-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) break RenderTexture.cpp:496 Breakpoint 1 at 0x83ba20c: file RenderTexture.cpp, line 496. (gdb) break RenderTexture.cpp:521 Breakpoint 2 at 0x83ba2fb: file RenderTexture.cpp, line 521. (gdb) break RenderTexture.cpp:1849 Breakpoint 3 at 0x83b9654: file RenderTexture.cpp, line 1849. (gdb) run Starting program: /usr/local/FlightGear/bin/fgfs [Thread debugging using libthread_db enabled] [New Thread -1221092768 (LWP 10061)] Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1221092768 (LWP 10061)] 0xafd330f8 in ?? () from /usr/X11R6/lib/modules/dri//r200_dri.so (gdb) cont Continuing. Disabling HW TCL support opening file: /usr/local/FlightGear/share/FlightGear/Navaids/carrier_nav.dat /usr/local/FlightGear/share/FlightGear/Navaids/TACAN_freq.dat [New Thread -1492231248 (LWP 10066)] Breakpoint 1, RenderTexture::Initialize (this=0xae429d0, width=256, height=256, shareObjects=true, copyContext=false) at RenderTexture.cpp:496 496True); (gdb) next X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 129 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 30 Current serial number in output stream: 31 Program exited with code 01. (gdb) quit Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On December 12, 2005 07:09 pm, Ampere K. Hardraade wrote: On December 12, 2005 01:19 pm, Mathias Fröhlich wrote: On Donnerstag 08 Dezember 2005 02:08, Ampere K. Hardraade wrote: https://bugs.freedesktop.org/show_bug.cgi?id=5142 So, the problem seems to be that pbuffer is not supported? Can you test the attached patch? Greetings Mathias It didn't work. X still throws the GLXUnsupportPrivateRequest at line 496 in RenderTexture.cpp. Apparently, the return false; statement at line 1849 never got run. I will do some more investigation later on. After some investigation, I found that the new if...else statement never got run because RenderTexture was able to successfully try the glx version 1.3 functions. I moved the new if...else statement so that the it gets run before RenderTexture can try the glx version 1.3 functions. FlightGear now starts up fine. However, there is some strange coloring issue: http://www.cs.yorku.ca/~cs233144/fgfs-screen-001.jpg Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Some FG videos...
On December 11, 2005 07:10 am, Pigeon wrote: Hi all, Cooked up some FG videos for everyone's pleasure... http://pigeond.net/photos/flightgear/videos/ Perhaps in the future we could make some short video clips for little parts of various FG flying tutorials too. Pigeon. That's awsome! Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
On November 18, 2005 08:56 pm, Ampere K. Hardraade wrote: On November 17, 2005 01:03 pm, Melchior FRANZ wrote: I had hoped that this thread would grow and offer a whole set of nice screenshots. :-) m. Perhaps we can have a weekly screenshot competition? The best screenshot of the week get uploaded to FlightGear's frontpage. Ampere We seem to be missing a screenshot of our online map. :) http://www.cs.yorku.ca/~cs233144/onlineMap.jpg Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Thesis Advice
On December 8, 2005 09:51 am, bass pumped wrote: Hi all, I'm trawling for topics to do my masters thesis on. My interest in intelligent flight control. Anyone have any good ideas?? Thanks, Someone asked the exact same question last month. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040828.html Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
https://bugs.freedesktop.org/show_bug.cgi?id=5142 So, the problem seems to be that pbuffer is not supported? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot (and more)
On December 2, 2005 09:33 am, Josh Babcock wrote: Perhaps it would be easy to write a null autopilot. Put that in the base package, and anyone who wants no autopilot in their aircraft could select that. I know nothing of autopilots though. Josh How about disabling avionic functions by default unless the aircraft-set.xml specifically demands them? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot
On November 30, 2005 12:25 pm, Melchior FRANZ wrote: Could be added to the list of admitted features for 1.0, next to landing lights ... :-) m. Just so people don't pull their hair out trying to come up with a solution to the landing lights: http://mail.flightgear.org/pipermail/flightgear-devel/2005-June/037572.html Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On December 2, 2005 05:50 am, Harald JOHNSEN wrote: The code creates a pbuffer the standard way, there is nothing special in rendertexture, the only things special is the choice of the api, using glx pre or post 1.3 - and this code won't work well for long since mesa lies on version numbers. The only standard test of pbuffers that I know is fgl_glxgears. But perhaps there is a test case somewhere in the mesa/xorg cvs, after all how do they test their code ? Harald. Whether glXVersion1_3Present is true or false doesn't seem to make a difference. Last time I tried this, when glXVersion1_3Present is true, I get the GLXUnsupportPrivateRequest error at line 496. When glXVersion1_3Present is false, I get the same error at line 521. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 30, 2005 08:22 pm, Curtis L. Olson wrote: Perhaps explain to them what our code is attempting to do, and then ask if they know of a GLX supported way to do it. I would do that if I can. However, I am not a programmer, and nothing in RenderTexture.cpp makes any sense to me. :( What exactly is our code attempting to do? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 26, 2005 10:50 pm, Ampere K. Hardraade wrote: I finally managed to compile Xorg from source today and managed to get more information from gdb. I have also filed a bug report with Xorg: https://bugs.freedesktop.org/show_bug.cgi?id=5142 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Ah ha! A reply! https://bugs.freedesktop.org/show_bug.cgi?id=5142 The reply is as follow: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 142 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 32 Current serial number in output stream: 33 Any clue what FG was trying to do when this was generated? All of the various FG mailing list threads referenced in this bug talk about RenderTexture. That makes me suspicious that FG is trying to do something with pbuffers or some other unsupported GLX functionality. Mesa warning: GL User Error: called without context: DeleteTextures That seems suspicious. What should I write in response? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
I finally managed to compile Xorg from source today and managed to get more information from gdb. I have also filed a bug report with Xorg: https://bugs.freedesktop.org/show_bug.cgi?id=5142 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 25, 2005 01:35 am, Mathias Fröhlich wrote: I got the following errors when doing a make-install. What do I need to change? It looks like the RenderTexture stuff is not found at all. Did you get a compile error during RenderTexture compiles too? Greetings Mathias I think I have done something extremely stupid. :( I could use some instructions on how to use the TestRenderTexture.cpp file. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 24, 2005 01:50 am, Mathias Fröhlich wrote:
Well, as far as I can see and remember:
The client libraries send a request to the 'display system' and the
'display system' bails out with an 'unsupported request'.
The error message is somehow misslieading, since the problem happens when
communicating with dri/drm instead of the X server - the reason I called it
'display system' above.
Since the same error happens regardless of using sgix pbuffers and glx-1.3
pbuffers and glxinfo announces sgix pbuffers (I got a glxinfo output in a
private mail) it is a X/GLX/GL internal problem.
Ampere maybe you can try to reproduce the problem using that
TestRenderTexture.cpp.
Greetings
Mathias
Same problem:
Breakpoint 1, RenderTexture (this=0xad87d40, strMode=0x40 Address 0x40 out of
bounds) at RenderTexture.cpp:110
110 if (rt2-IsMipmapped())
(gdb) next
151 glTexParameteri(rt2-GetTextureTarget(),
(gdb)
154 }
(gdb)
166 if (rt2-IsTexture())
(gdb)
167 bShowDepthTexture = false;
(gdb)
168 }
(gdb)
169
(gdb)
172 }
(gdb)
178 void DestroyRenderTexture(RenderTexture *rt2)
(gdb)
180 delete rt2;
(gdb)
SGBbCache::init (this=0xad87d40, cacheCount=64) at bbcache.cxx:118
118 if( colorBits 8 )
(gdb)
121 rt-Reset(rgba ctt);
(gdb)
125 if( rt-Initialize(256, 256, true) ) {
(gdb)
X Error of failed request: GLXUnsupportedPrivateRequest
Major opcode of failed request: 145 (GLX)
Minor opcode of failed request: 16 (X_GLXVendorPrivate)
Serial number of failed request: 30
Current serial number in output stream: 31
Program exited with code 01.
(gdb)
The program is not being run.
(gdb)
The program is not being run.
(gdb)
The program is not being run.
(gdb) quit
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 24, 2005 03:01 pm, Mathias Fröhlich wrote: Also the chance that this is already fixed with the next pending xorg release is high IMO. I dan no longer try, but if somebody can install the current release candidate and see if it is still there, we will know. Ok, I know about the upstream lag for X releases. This is a major problem, but it is also an offtopic for this list ... Greetings Mathias I downloaded, compiled and installed the CVS version of Xorg some weeks ago. FlightGear crashed with the same message when launched. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Need help debugging some Nasal scripts
Is there a seperated program which I can used to test Nasal scripts without having to run FlightGear? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 24, 2005 01:50 am, Mathias Fröhlich wrote: Well, as far as I can see and remember: The client libraries send a request to the 'display system' and the 'display system' bails out with an 'unsupported request'. The error message is somehow misslieading, since the problem happens when communicating with dri/drm instead of the X server - the reason I called it 'display system' above. Since the same error happens regardless of using sgix pbuffers and glx-1.3 pbuffers and glxinfo announces sgix pbuffers (I got a glxinfo output in a private mail) it is a X/GLX/GL internal problem. Ampere maybe you can try to reproduce the problem using that TestRenderTexture.cpp. Greetings Mathias Ignore what I wrote in my last E-mail. I didn't realize I have errors when compiling. I got the following errors when doing a make-install. What do I need to change? ../../src/Instrumentation/libInstrumentation.a(od_gauge.o): In function `~FGODGauge':/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:85: undefined reference to `RenderTexture::~RenderTexture()' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:85: undefined reference to `RenderTexture::~RenderTexture()' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:85: undefined reference to `RenderTexture::~RenderTexture()' ../../src/Instrumentation/libInstrumentation.a(od_gauge.o): In function `FGODGauge::endCapture(unsigned int)':/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:138: undefined reference to `RenderTexture::EndCapture()' ../../src/Instrumentation/libInstrumentation.a(od_gauge.o): In function `FGODGauge::allocRT()':/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:45: undefined reference to `RenderTexture::RenderTexture(char const*)' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:47: undefined reference to `RenderTexture::Reset(char const*, ...)' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:51: undefined reference to `RenderTexture::Initialize(int, int, bool, bool)' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:53: undefined reference to `RenderTexture::BeginCapture()' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:77: undefined reference to `RenderTexture::EndCapture()' :/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:49: undefined reference to `RenderTexture::Reset(char const*, ...)' ../../src/Instrumentation/libInstrumentation.a(od_gauge.o): In function `FGODGauge::beginCapture(int)':/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:98: undefined reference to `RenderTexture::BeginCapture()' ../../src/Instrumentation/libInstrumentation.a(od_gauge.o): In function `FGODGauge::beginCapture()':/usr/local/src/flightgear/src/Instrumentation/od_gauge.cxx:110: undefined reference to `RenderTexture::BeginCapture()' /usr/local/lib/libsgsky.a(bbcache.o): In function `SGBbCache::allocTextureMemory(int, int)':/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:84: undefined reference to `RenderTexture::BeginCapture()' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:86: undefined reference to `RenderTexture::EndCapture()' /usr/local/lib/libsgsky.a(bbcache.o): In function `~SGBbCache':/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:106: undefined reference to `RenderTexture::~RenderTexture()' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:106: undefined reference to `RenderTexture::~RenderTexture()' /usr/local/lib/libsgsky.a(bbcache.o): In function `SGBbCache::init(int)':/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:115: undefined reference to `RenderTexture::RenderTexture(char const*)' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:119: undefined reference to `RenderTexture::Reset(char const*, ...)' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:121: undefined reference to `RenderTexture::Reset(char const*, ...)' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:125: undefined reference to `RenderTexture::Initialize(int, int, bool, bool)' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:127: undefined reference to `RenderTexture::BeginCapture()' :/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:150: undefined reference to `RenderTexture::EndCapture()' /usr/local/lib/libsgsky.a(bbcache.o): In function `SGBbCache::beginCapture()':/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:259: undefined reference to `RenderTexture::BeginCapture()' /usr/local/lib/libsgsky.a(bbcache.o): In function `SGBbCache::endCapture()':/usr/local/src/simgear/simgear/scene/sky/bbcache.cxx:304: undefined reference to `RenderTexture::EndCapture()' collect2: ld returned 1 exit status make[2]: *** [fgfs] Error 1 make[2]: Leaving directory `/usr/local/src/flightgear/src/Main' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/flightgear/src' make: *** [install-recursive] Error 1 Ampere
Re: [Flightgear-devel] Realistic daytime skycolor
On November 23, 2005 04:39 am, Erik Hofman wrote: Ampere K. Hardraade wrote: Speaking of sky and color, I think FlightGear could use more blue in its ambient light source. Are you sure this isn't because of the humidity level which colors the sky more pale. Erik I was referring to the ambient light that is casted on every object in the scene. Before dawn and after dust, everything is casted in a shade of blue. Even when the sun is up, there is a slight shade of blue on objects that are hidden behind a shadow. In FlightGear, this shade of blue seems to be missing, which is why I said that FlightGear could use more blue in its ambient light source. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 22, 2005 01:06 pm, Erik Hofman wrote: Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik First of all, thanks for looking into this. I have just tried your patch (I assume it was commited to the CVS). Unfortunately, it didn't work. I am still getting the GLXUnsupportPrivateRequest error at exactly the same spot. [EMAIL PROTECTED]:~$ gdb /usr/local/FlightGear/bin/fgfs GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-linux...Using host libthread_db library /lib/tls/libthread_db.so.1. (gdb) break RenderTexture.cpp:497 Breakpoint 1 at 0x838d864: file RenderTexture.cpp, line 497. (gdb) run Starting program: /usr/local/FlightGear/bin/fgfs [Thread debugging using libthread_db enabled] [New Thread -1220531616 (LWP 14145)] Program received signal SIGFPE, Arithmetic exception. [Switching to Thread -1220531616 (LWP 14145)] 0xafdb10a8 in ?? () from /usr/X11R6/lib/modules/dri//r200_dri.so (gdb) cont Continuing. Disabling HW TCL support opening file: /usr/local/FlightGear/share/FlightGear/Navaids/carrier_nav.dat /usr/local/FlightGear/share/FlightGear/Navaids/TACAN_freq.dat [New Thread -1491719248 (LWP 14148)] Breakpoint 1, RenderTexture::Initialize (this=0xae0b168, width=256, height=256, shareObjects=true, copyContext=false) at RenderTexture.cpp:497 497GL_TRUE); (gdb) next X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 30 Current serial number in output stream: 31 Program exited with code 01. (gdb) quit Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thesis?
On November 21, 2005 09:47 pm, Szabolcs Berecz wrote: Oh, and usually I'm not too interested in user interfaces and graphics, but I don't say there is no chance to work on something like that... I will have time to go into details and start working on something the next week. I would appreciate if you could suggest something. Thanks, Szabi Algorithm related: Interpetating, storing, altering and displaying accurate GIS data in WGS84 Coordinate System. (www.terragera.org) AI related: Application of artificial intelligent in civilian aviation, and experimentation of AI ATC within FlightGear Flight Simulator. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
On November 22, 2005 01:06 pm, Erik Hofman wrote: Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik I do. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
On November 22, 2005 10:51 am, Joacim Persson wrote: How about simply taking photos from various angles, but document the exact position from which each photo is taken? From that it should be possible to calculate the position for a number of points with (hopefully) fairly good precision. I don't see how that's going to work unless one has a fisheye lense and is able to take pictures with exactly 180 degrees view. If the photographing method is standardised, it could even be possible to write a script for the calculations. Like snaps taken 30° apart from a defined distance. Identify the same spot on the craft in two or more pictures etc... Use the same lens for all photographs. Take also a photo of a grid so you know where you have the angles in pictures taken with that setting. The high-tech method would be using a laser scanner. ;) Laser huh? Last year, some people in the upper year in my faculty made a device called Geopod. It can measure the range and angle for points on a building. It has a fish eye lens at the top, which is tied to a digital camera, as well as a mirror and a laser range finder at the bottom. Using a labtop connected to the device, one can specify points on the photograph taken by the digitial camera for measurment, and the mirror will rotate to allow the laser range finder to calculate the range of the points. Using the data gathered, one can reconstruct the building (or a room) in a computer. It is not exactly a high tech device, but the components used to build it are darn expensive. Beside, I doubt one can bring such a device to an airshow without arousing suspicion. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Speaking of sky and color, I think FlightGear could use more blue in its ambient light source. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747 patch
On November 20, 2005 06:14 pm, Jim Wilson wrote: As far as the plane actually taking off with no elevator or flaps, that is certainly not normal for something as heavy as a 747. Maybe with light fuel, but still doubtful. Maybe Andy has an idea on this. It is unlikely that the two things you observed are related unless there is a large error weight distribution. Other times I've seen weight location problems in YASim configurations it seemed as though the aircraft would move around and even pop the nose way up (or down), which is not occuring here. Best, Jim I think the 747 in FlightGear is a bit tail-heavy. The pitch of the aircraft is VERY sensitive, especially when compared to the roll. Also, with less than 10% fuel, I can get the nose up at 0kts by turning up the throttles to full and releasing the parking brakes. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
On November 20, 2005 09:52 am, Innis Cunningham wrote: BAE 146 Metroliner Gulfstream DHC Dash 8 Fokker 50 Erik? If you could get into the cockpit of the above aircrafts, you might want to get some 360 shots of the cockpit. It might also be worthwhile to bring a measuring tape along. :P For the exterior of the aircraft, you might want to pay more attentions to the rivets and take notes of how many frames/stations in the fuselage and wings. Frames usually have equal distance between one another, so they can serve as very good measuring devices. Finally, here is a thought that has been floating in my mind for a while, and I hope you could try it out: take some stereoscopic views of aircrafts. Having some stereoscopic photographs of an aircraft may help modellers make estimations better. (Okay, this is just a theory, but this would be a good opportunity to vertify my theory with an experiment.) :P Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG 0.9.9 shadows and stuff
On November 19, 2005 10:18 am, Rodrigo Flores wrote: Hi, I have 3D clouds, but can´t see the shadows. I also noticed that FG 0.9.9 don´t work with full screen mode because using this feature FG starts with a strange green colour and very slow fps. Finally, the old fonts in the FG 0.9.8 format are still there, couldn´t see the fonts showed in the Concorde screenshot. Try starting FlightGear with the parameter --bpp=24. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
On November 18, 2005 09:11 pm, Curtis L. Olson wrote: Ampere K. Hardraade wrote: Perhaps we can have a weekly screenshot competition? The best screenshot of the week get uploaded to FlightGear's frontpage. Sounds like a great idea. Are you volunteering to manage it? :-) Curt. On November 19, 2005 03:12 am, Vivian Meazza wrote: I think that this is a good idea. Since it was his idea, I nominate Ampere to run it. Vivian What do you guys mean by manage/run it? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Need help debugging some Nasal scripts
Hello all, Since I can't get my copy of FlightGear to run, I can't test these scripts myself. Therefore, if you could play around with the two scripts in http://www.cs.yorku.ca/~cs233144/ and tell me about any error that you may receive, that would be great. The two scripts are implementations of the double-linked-list and tree object. Thanks in advance, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [0.9.9] screenshots for flightgear.org
On November 18, 2005 07:26 am, AJ MacLeod wrote: Erm.. it's called atmosphere. FG looks very impressive around dawn and dusk, and some of the rougher edges in the scenery are hidden. AJ Sure, FG looks very impressive during dawn and dusk, but the planes are a different matter. They look extremely odd being completely dark. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
On November 17, 2005 01:03 pm, Melchior FRANZ wrote: I had hoped that this thread would grow and offer a whole set of nice screenshots. :-) m. Perhaps we can have a weekly screenshot competition? The best screenshot of the week get uploaded to FlightGear's frontpage. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [0.9.9] screenshots for flightgear.org
On November 17, 2005 05:31 pm, AJ MacLeod wrote: I agree that new screenshots are probably the first thing some folk will look for before deciding to bother downloading... So here are a couple of airliners in case they're wanted - no idea why I have so many screenshots of the things when I almost never fly them! http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg http://www.adeptopensource.co.uk/personal/fg/737-Inverness-ground-dawn.jpg http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-daytime.jpg AJ Other than the one taken during daytime, I think the rest should be kept away from being presented. They are simply too dark. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
On November 16, 2005 03:51 am, Erik Hofman wrote: Would it be possible not to initialize the rendetexture code if we don't need it, e.g. we have not 3d clouds enabled? But how would we handle the case where r200 users start without 3d clouds enabled and when browsing through the menu find the 3d clouds option and enable it at runtime? Erik May be we can add two try...catch statements from lines 493 to 497 and from 512 to 517 in RenderTexture.cpp, so that we can do a return false; as soon as we encounter an error (to duplicate what is done in line 474)? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: terrain texture question
On November 16, 2005 05:37 pm, Melchior FRANZ wrote:
* Josh Babcock -- Wednesday 16 November 2005 23:25:
I considered using a Nasal script, but I don't know how the
script would know when the winter textures are being used.
if (getprop(/sim/startup/season) == winter) { ?? }
m.
I believe you would need more checkings. We don't have snow all the time in
winter.
Speaking of snow: is there anything about snow accumlation in METAR data? I'm
just curious.
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
On November 16, 2005 07:47 pm, Ampere K. Hardraade wrote: May be we can add two try...catch statements from lines 493 to 497 and from 512 to 517 in RenderTexture.cpp, so that we can do a return false; as soon as we encounter an error (to duplicate what is done in line 474)? Ampere That didn't work. =( Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
On November 15, 2005 12:39 pm, Curtis L. Olson wrote: However, I would like to give everyone the opportunity to mention any show stopping bugs that we should be concerned about. For some reasons, the logic between line 1832 and 1858 in RenderTexture.cpp is causing X to throw GLXUnsupportedPrivateRequest for those who are using r200 driver. The problem would be gone if one were to make an early exist by adding return false; before line 1832. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
Here is another one: http://www.airliners.net/open.file/958673/L/ It is amazing how they changed the livery so quickly! Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
On another note, this was taken in Singapore recently: http://www.airliners.net/open.file/957790/L/ Compare to what we have in FlightGear now: http://www.students.yorku.ca/~ampere/fgfs-screen-005.jpg Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing
On November 12, 2005 01:10 pm, Alex Perry wrote: Debian is packaging 2.4.0 under the name freeglut3. Is there a specific upstream release that contains the fix, so that I can file a bug against the existing package ? Otherwise, Debian will be unable to build a current FGFS release. You can get SDL and use the --enable-sdl flag when running configure for FlightGear. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: A380 arrived in EDHI (Hamburg-Finkenwerder)
On November 12, 2005 01:50 pm, Martin Spott wrote: You might want to ignore the two Windows PeeCees for your model ;-) Martin. Yes, I notice that, too. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
On November 11, 2005 07:26 pm, Ampere K. Hardraade wrote: I am also getting GLXUnsupportedPrivateRequest error. This is so darn annoying! I used to be able to get around this problem by migrating back to XFree, or failing that, start XServer under 16-bit depth. Now, I can't go with either option: Debian has moved onto Xorg, and SDL doesn't allow me to run OpenGL application under 16-bit depth. I am also using ATI card -- ATI 9200 SE to be precise. Ampere Okay. So far, I have tried: Using the CVS version of Xorg -- no luck. Using the CVS version of Mesa -- no luck. Other OpenGL applications seem to run fine. It's only FlightGear that crashed with the GLXUnsupportedPrivateRequest error during launch. Any idea how I can get around the problem? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On November 11, 2005 06:23 am, Martin Spott wrote: Ima Sudonim wrote: http://translate.google.com/translate?u=http%3A%2F%2Fwww.linux- user.de%2Fausgabe%2F2005%2F11%2F070-flightgear%2Flangpair=de% 7Cenhl=ensafe=offie=UTF-8oe=UTF-8prev=%2Flanguage_tools Oh yeah: flies are still an expensive pleasure :-) Martin. It is pretty enjoyable to kill them with elastic bands. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] LibGL error
I am also getting GLXUnsupportedPrivateRequest error. This is so darn annoying! I used to be able to get around this problem by migrating back to XFree, or failing that, start XServer under 16-bit depth. Now, I can't go with either option: Debian has moved onto Xorg, and SDL doesn't allow me to run OpenGL application under 16-bit depth. I am also using ATI card -- ATI 9200 SE to be precise. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: 0.9.9 scenery?
On November 11, 2005 08:59 pm, Pigeon wrote: Today 08:59:41 pm Speaking of scenery, there are still people from time to time having trouble installing new sceneries. (The whole Scenery/ vs Scenery/Terrain/ and Scenery/Objects/ issues). I think it's worthwhile updating the docs and the getstart guide with these details. It's quite well described at Franz's page: http://members.aon.at/mfranz/flightgear/flightgear-howto.html Another thing is a lot of people expect scenery to be scenery + 3d buildings/objects. While, when you download scenery from FG's site they are pretty much terrain only. It might be useful to emphasising these things in the docs as well. Pigeon. I think it would a good idea to provide a document on how to use Terrasync as well. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Is it any mistake?
On November 11, 2005 08:05 pm, Gerard ROBIN wrote: Le vendredi 11 novembre 2005 à 19:47 -0500, Ampere K. Hardraade a écrit : On November 11, 2005 07:32 pm, Gerard ROBIN wrote: DO http://ghours.club.fr/fgfs-tux.tar.gz Is it GPL'ed? If so, it will be a good idea to put it into FlightGear's hangar. Ampere Don't know , i only remember it was included in an old FG package. some files are 2001-01 dated. This is the aircraft with tux that some people are looking for: http://ghours.club.fr/Happy-penguin.jpg Would it be possible to put the tarball on our server somewhere? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
A bit off topic: does anyone have success in compiling FlightGear and related libaries using GCC-4.0? I want to get my system sorted before I test the pre-release, but I might ended up not being able to test FlightGear if GCC-4.0 has trouble compiling FlightGear. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
On November 9, 2005 02:46 pm, Curtis L. Olson wrote: The more build errors and platform bugs we can catch now, the smoother the v0.9.9 release will be for your favorite platform! Well, I still can't get FlightGear to run under Xorg at 24bit depth. I am still getting the following messages: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 41 Current serial number in output stream: 42 freeglut (/usr/local/FlightGear/bin/fgfs): Failed to create cursor If I switched to 16bit, I get the following messages: freeglut (/usr/local/FlightGear/bin/fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. Here are my graphic related packages: ii xserver-common 6.8.2.dfsg.1-10 files and utilities common to all X servers ii xserver-xfree866.8.2.dfsg.1-10 transitional package for moving from xfree86 ii xserver-xfree86-dri-trunk 2004.02.28-2 The XFree86 X server [DRI trunk] ii xserver-xorg 6.8.2.dfsg.1-10 the X.Org X server ii xlibmesa-dri 6.8.2.dfsg.1-10 Mesa 3D graphics library modules [X.Org] ii xlibmesa-gl6.8.2.dfsg.1-10 Mesa 3D graphics library [X.Org] ii xlibmesa-gl-dev6.8.2.dfsg.1-10 Mesa 3D graphics library development files [ ii xlibmesa-glu 4.3.0.dfsg.1-14sarge1 Mesa OpenGL utility library [XFree86] ii xlibmesa-glu-dev 4.3.0.dfsg.1-14sarge1 Mesa OpenGL utility library development file lspci: :02:0b.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) (prog-if 00 [VGA]) Subsystem: C.P. Technology Co. Ltd: Unknown device 2074 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), Cache Line Size: 0x04 (16 bytes) Interrupt: pin A routed to IRQ 169 Region 0: Memory at e000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at d000 [size=256] Region 2: Memory at ff9f (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff9c [disabled] [size=128K] Capabilities: available only to root Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On November 4, 2005 04:23 pm, Durk Talsma wrote: So, for starters, I would like to explore some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of course :-)). I'd build them myself If I had shown any signs of talent in the field of 3D modeling :-(. Cheers, Durk I have data on every single aircraft of Airbus. I just need the time to be able to work on them. On November 5, 2005 03:22 am, Durk Talsma wrote: On Friday 04 November 2005 23:40, Christian Mayer wrote: Wouldn't it be better to add those models to the existing (and yet to come) high-poly models as a different LOD? Would be possible, but aircraft loading and unloading time is going to be an issue. Unless we can move the aircraft loader into a separate thread, or come up with a very sophisticated multiframe aircraft loader, I would prefer to start with using something that is simple from the start. Cheers, Durk Having done multiple Level-of-Details for the MD-11, using multiple models for different Level-of-Details don't really excite me. Beside, when one is inside an airport, where planes are lined up wingtip by wingtip, such a scheme doesn't really reduce polycount by much, if at all. In my opinion, it would be more flexible and more efficient to have a single high-poly model for the aircraft instead. If the model is divided into sufficient number of objects, then it would be a simple matter of hiding more and more objects as the aspect ratio of the aircraft decreases. For example, a wing can be divided into the following components: wing +leading edge - +slats - - +top portion - - +bottom portion - - +sides - +slot of slats +middle portion - - +front spar - - +rear spar - - +top portion - - +bottom portion +trailing edge - +spoilers - - +top portion - - +bottom portion - - +sides - +flaps - - +leading edge - - +sides - - +remaining portions One can hide the objects starting from the bottom-most of the tree, and work toward the root of the tree as the plane becomes more and more out of range. One can also hide objects that are hidden, such as the bottom of the spoilers and the leading edge of the flaps when the plane is in a clean configuration. The latter ability will be very useful when the AI Aircraft is inside an airport. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
On November 5, 2005 08:46 pm, Curtis L. Olson wrote: I was scanning through the cvs logs trying to refresh my memory on what has been changed, added, and fixed since the release of v0.9.8 (last January). Here's what I came up with, although after staring at cvs logs for 2 hours I started having minor hallucinations. So I'm posting this here in hopes that people can add to it, or correct my mistakes. If you contributed something that is missing, or poorly described here, please send me something better. Thanks! Curt. There is also heat-haze and chrome effect. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
On November 1, 2005 12:43 pm, Andy Ross wrote: Erik Hofman wrote: Ampere K. Hardraade wrote: A texcopy function that allows one to copy one part of the texture to another would be useful. Although it would be doable, one problem with this is that the textures themselves are stored in video memory so updating them isn't as easy as it sounds. And the APIs are complicated. Traditional (1.1) OpenGL can only do this to and from the framebuffer, not between textures. What I meant was copying one part of the texture to another part of the same texture. Sorry for the confusion. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On November 2, 2005 03:04 am, Buchanan, Stuart wrote: Does anyone know what the performance hit of using a 3D instrument (say the ASI) rather than the standard 2-D one is? From a quick look, most of the instruments work by simply shifting the needle texture slightly forward from the back-face. I have been considering using the 3-D instruments for my changes to the C182, but backed off in case the performance hit was unacceptable. -Stuart Polycount has very little effect on performance. The biggest hit on performance is texture, in particular the alpha in the texture. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
On October 30, 2005 04:23 am, Erik Hofman wrote: This can be done now by using the texture animations; texrotate and textranslate See FlightGear/data/Docs/model-howto.html for more information. Erik A texcopy function that allows one to copy one part of the texture to another would be useful. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contacting tower
On October 18, 2005 05:51 am, Frank Olaf wrote: Another point is that I am not always able to contact the tower when pressing the ' key, even though I am on the correct radiofrequency. Er... try flying out of the ATC's control area before you attempt to contact the tower. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On October 17, 2005 02:28 am, Martin Spott wrote: I' pretty sure it easier to convert the PDF's into some common vector drawing format than adding editing capabilities to [X,K,G]PDF. Once you have a nice vector format you can easily load that into your favourite editor, and group the necessary lines together. No -- no editing. Just an interface for the user to select what is appropiate for export. An airport diagram doesn't just contain taxiways' information after all. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On October 17, 2005 02:23 pm, Durk Talsma wrote: - airport animations Just wondering what type of animations you were thinking of. We have support for moving aircraft now, but no ground vehicles yet, although this could be done using animation scripts. Bridges' movement, illumination, and so on; and yes, being able to use animation scripts and Nasal scripts in an airport would be great, and we should take these into account in our discussion as well. The problem is that at this point the requirement for FlightGear and x-plane start to deviate and I don't think we can expect an x-plane datamanager expect to switch to use a more sophisticated database format, just to support that *other* flight sim that happens to be using his database too. It's a difficult situation... In my opinion, if X-Plane wants to stay on a sinking boat, it doesn't mean we should follow either. ;-) I really think a new format is a must. If people insist, we can have an importer/exporter to exchange compatible data between Robin's database and our own database. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On October 15, 2005 08:51 pm, David Luff wrote: I know there was some talk of extracting taxiways from the FAA's PDFs, I can't realistically see that happening! That was a proposal from me. The idea is to have a program (could be a modified version of KPDF) to read a vector based PDF file such as this: http://204.108.4.16/d-tpp/0510/00375AD.PDF and spit out the taxiway outlines. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On October 16, 2005 03:43 am, Harald JOHNSEN wrote: I thought about the taxiway structure/format a while back. I came to the conclusion that a raw polygon editor is about the only way you're going to be able to create taxiways properly. You mean, ac3d or blender ? No need to use a special editor if you want to draw polygons. One can use rectangular or bent taxiway sections but when you get to all the weird and wonderful taxiway layouts it's impossible to do with a generic taxiway structure. This is very apparent where taxiways intersect other taxiways, runways or aprons. The only thing that made sense to me was a 2D CAD type app like TaxiDraw which can draw polygons of any shape and size. I don't want to do pixel or vertex editing, If I must do that then I use ac3d and I can do everything without any constraint. There is a tool for another sim that uses points, lines and splines to define the taxiways. I agree with the accessment that using raw polygons is about the only way to have proper taxiways. Really, a taxiway is anything but rectangular, and no matter how you mix and match a bunch of rectangles, it is simply impossible to achieve the level of complexity that you can see in real life. A CAD type application for drawing taxiways may not be a bad idea. However, I think that the process of taxiway generation should have nearly zero human involvement instead. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
Regarding Robin's DB: having accurate taxiways is not the only concern. Some other items that we should take notice of include: - buildings placement - gates' position - tower/ILS frequencies - runway/taxiway signs - airport animations - runway/taxiway conditions due to weather - ground pathways for AI traffics Time might as well be spent on thinking of how we are going to convince Robin to use our new format instead of thinking of a way to expand Robin's database. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways information
On October 11, 2005 09:42 am, Vassilii Khachaturov wrote: 1) by some kind of image processing following the Ghostview output. Of course, since the internal graphics is vector, it might be possible to infer more from various rendered resolutions. 2) Other approach would be to reverse engineer the original PS, if any, from the PDF --- I'm afraid it's not very gratifying... Why would there be needs of reverse engineering? The purpose of reading the PDF file is only to extract the taxiways' outline. 3) Yet another approach would be to ask the FAA for the data source feed --- after all, this is U.S. government work that is in public domain. And, of course, this is only a US-related solution... I have seen airport diagrams in PDF format for airports in countries other than the US. For example: http://www.sia.aviation-civile.gouv.fr/aip/enligne/metropole/aip/VAC/T/VAC AD 2.LFBO.pdf Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How does the weather work in FlightGear?
On October 10, 2005 03:37 am, Erik Hofman wrote: Buchanan, Stuart wrote: FlightGear can fetch the current weather at your starting airport, or you can set the wind, cloud layers etc manually. I don't know if the weather conditions are global, or change as you fly to different locations. It interprets the data from the nearest METAR station. The data is fetched from noaa.gov. Erik In my opinion, it would be better if data from multiple nearby METAR stations is used instead of fetching data from only one station. I often fly with real-weather-fetch enabled, and the plane gets a huge jolt whenever the weather is updated. The change in the visual aspects is also too sudden. Using data from multiple METAR stations could avoid the above problems and allow us to have a smooth transistion in weather. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A question regarding accurate taxiways information
Since FAA has airport diagrams in PDF format, would it be possible to extract taxiways information directly from a PDF file such as this http://204.108.4.16/d-tpp/0510/00375AD.PDF to produce taxiways usable in FlightGear? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On October 6, 2005 10:28 pm, Lee Elliott wrote: I'll try modelling a few bits and bobs if that'll help. That will be great. Thank you. Texturing isn't really my forte and I've still got to do the MiG-15... I notice that in the CVS a few days ago. It was a decent surprise. =) Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On October 7, 2005 08:28 am, Karsten Krispin wrote: Great work so far! :) Thank you. =) What exactly is beeing ment by scripting and sidestick? If you mean to programm a more or less functional Airbus-Cockpit with its Fly-By-Wire capabilities (Yes.. I also mean that typical stuff around FBW, flight envelope protection and so on..) and some basic FMC and FCU functions? - Luckily I also have had such an idea. Unfortunately I did not have the time to become familiar with this stuff. Yes, I meant the FBW system with all the flight envlope protection (the fun stuff). However, I also have quite a few things on my mind as well (the boring stuff). The first thing I have to deal with is the way, the XML-Instruments work. Is it possible to use the XML-Instruments in a 3d-Cockpit or do you have to rewrite the whole stuff to animations? As far as I know, the instruments that you see ARE the XML-Instruments that you referred to. Unfortunately, I have absolutely no experience in this area. Perhaps those who had experience with instruments can answer your question better. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little update to the A380 from me, as well as a little request.
On October 8, 2005 10:15 am, Karsten Krispin wrote: Is it possible that you have a manual of the Airbus, or from where do you get your ideas? I don't have any manual on Airbus. I wish I have. There are some books in my university's library, as well as some online references to help me script the FBW system. Unfortunately, I haven't got a chance to use them yet. Because the Airbus-System are working intern more or less in the same way. Type-Rating issue on so on... So, I thought we first write a core. That one could be extended on one hand to an A32X/330/340- and on the other hand to an A380 cockpit. Here, a manual could be helpfull. While commonality is a well-known strong point of Airbus, it cannot be applied to the fly-by-wire system. The aerodynamic properties of each family of aircraft is different, as do the flight control systems. Even the fly-by-wire system is different on each family: the A32X have special computers dedicated to each FCS-related task, while the A33X/A34X have integrated some of these computers into one unit. The A380 has even more integration in its fly-by-wire system than the former other families. You can't use a fly-by-wire system from one aircraft and expect it will work on another. I also got an answer from Steve Knoblock. He said, as you assumed as well, that the XML-Instruments are the one displayed in an 3D-Cockpit. Now there is still one point: When programming an FMC and the to this according Navigation Display, we need a possibility to spawn objects on runtime to place Waypoints in it and connect them and so on. Is there a way like in HTML with JavaScripts DOM? Not that I know of. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A little update to the A380 from me, as well as a little request.
Hello, As some of you may know, I have been working on the A380's cockpit for the past few months. Since my work has been commited to the CVS, I decided to show you guys a screenshot of my progress so far: http://www.students.yorku.ca/~ampere/fgfs-screen-005.jpg As you can see, a few components are still missing, so there is quite a bit of work ahead before the cockpit can be considered as finished. Notably, the sidesticks are missing; as do the throttles, some instruments on the front panel, the seats for the pilots... and the textures (glow, no glow, and in-between). Since I have been quite busy lately, I want to concentrate my work on the scripting aspect of the A380. Thus, it would be nice if people can volunteer to fill in the missing pieces. AJ has already been working on the sidesticks, but it will be nice if there are a few more volunteers. =P Thank you, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
On October 5, 2005 07:58 am, Curtis L. Olson wrote: Do you mean replace the instant cvs snapshots with snapshots only taken at weekly intervals? :-) By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
On October 5, 2005 01:49 pm, Curtis L. Olson wrote: If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... Curt. How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
I have been wondering this for quite a while: will it be a good idea to provide weekly CVS snapshots? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
On October 3, 2005 07:35 am, Melchior FRANZ wrote: (C) which features need to be completed? MultiPlayer. Currently, the MP still lacks the capability to transfer animations or radio messages across the network. However, since MP can boost FlightGear's popularity immensely, we should get these aspects of the MP sorted out, so that we can advertise loudly about our mutliplayer capability. (D) which a/c should be included? I don't think any aircraft should be included, as we have a download page for them. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Does FlightGear model eclipse?
There will be an eclipse tomorrow, and I was just wonder whether FlightGear has this modelled. http://news.bbc.co.uk/2/hi/science/nature/4299074.stm Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A little emergency encountered inside FlightGear
On September 28, 2005 04:02 am, Erik Hofman wrote: Looking at a patch commit to simgear/scene/model at Sept. 25th I see there was a patch to set the factor to 0.0 by default which doesn't seem such a great idea after all. I've backed out that patch again, could you test it for me? Erik I have updated my copy of SimGear and FlightGear again, but the problem is still there. Does anyone have this problem as well? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A little emergency encountered inside FlightGear
I was practicing landing the unlandable today, and ran into a little emergency. It is a bit amusing and I thought I'd share it with you guys. http://www.students.yorku.ca/~ampere/fgfs-screen-001.jpg http://www.students.yorku.ca/~ampere/fgfs-screen-003.jpg As you can see, there is a problem with the main landing gears on the 747. The bug appears again after I restarted FlightGear. I have never seen this happening until I updated my CVS version of SimGear and FlightGear yesterday. I haven't touched anything in the data directory, so I think this might be FlightGear/SimGear related. In addition, each time I press F3, two screenshots are made: one ordinary screenshot, and another with a dialog box which looks similar to this (http://www.students.yorku.ca/~ampere/fgfs-screen-004.jpg). As a side note, I made it safely back to the airport, braked, and taxied to the tarmac. Those who have had trouble braking on large jets may want to hold Shift+B on touch down. Provided that Caps-Lock is off, holding Shift+B will toggle the brake between on and off states, thus preventing the nose wheel from sinking into the runway. Enabling Caps-Lock and hold B alone will also work. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nasal on Mac/Sparc/Irix fixed. Maybe.
On September 20, 2005 05:15 pm, Andy Ross wrote:
Ampere: there is one incompatible change here. The strc() function
has been removed in favor of the array syntax for addressing bytes
out of a string. The A380 scripts are the only code that uses it, so
I didn't bother including a compatibility version. Basically, where
you used to write strc(s, 10), you can just do s[10] now. If you
need something to limp along until you can update the code, we can use
something like this in globals.nas:
strc = func(s, n) { s[n] }
Andy
I am not too excited about going through 3000 lines of code to replace the
strc() function at the moment, although I will look into it.
Thanks for the head's up.
Ampere
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
On September 15, 2005 10:00 am, Andy Ross wrote: Ampere K. Hardraade wrote: Anway, I like the idea of having a dedicated online message board for FlightGear. The primary reason why I like online message board is that all the posts in a topic are grouped under one thread and are sorted by dates, which is more organized in my opinion. This is another situation where a pro forum post has more to do with bad email client software than it does with email as a whole. Nope. I can sort mails by thread, date, and author fine. It's just that I feel a message board is more organized. In anycase, it doesn't matter, as majority of the developers object to the idea of switching to a message board. On September 15, 2005 05:39 pm, [EMAIL PROTECTED] wrote: probably we could think of a support forum... Thorben I agree. I think it is an advantage to have an online message board for the users. Having an online community for users to be in will make people more incline to stay, thus culturing more loyal users. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
On September 14, 2005 01:03 pm, Curtis L. Olson wrote: What would people think of abandoning our mailing lists and converting over to online/web-based forums? I always wanted to ask the same question, but I have a believe that FlightGear uses a mailing list for a reason, so I never ask. Anway, I like the idea of having a dedicated online message board for FlightGear. The primary reason why I like online message board is that all the posts in a topic are grouped under one thread and are sorted by dates, which is more organized in my opinion. Old discussions can also be read easily this way. Also, I think an online message board is more convient because all the messages are stored in one centralized location, and people can access the board from anywhere on any machine. I will stop here however, since it is pretty obvious that the majority have a different view than I do when it comes to message board. Perhaps one can think about removing the user list and turning it into a message board? I think FlightGear would be able to attract more loyal users this way. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags inXML.
On September 13, 2005 02:52 pm, Gabor Toth wrote: Hi Innis, I've done a quick measure, and I got no difference in FPS. My config is 900MHz P3, 384MB RAM, GeForce FX5500. Gabor It should be tested across the network. The MD-11, a resource sucker, has decent framerate offline as well. However, those who see it online have their framerate dropped below 1 fps. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Issues regarding the texture-path tags in XML.
On September 12, 2005 04:10 am, Melchior FRANZ wrote: ... unless you use a 'material' animation, which I would prefer in any case. Not only does this allow livery switching at runtime, it also doesn't require to duplicate *all* textures. See the bo105's emblem for an example. m. Okay, I will look into that. Thanks, Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
On September 11, 2005 12:19 pm, Mathias Fröhlich wrote: I would prefere everything open sourced over everything closed, but in this case, try the ati binary driver ... This one should do ... That's not an option for me. ATI's binary drivers don't support PCI card, and my graphic card is a PCI card. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Simgear-cvslogs] CVS: SimGear/simgear/screen RenderTexture.cpp, 1.9, 1.10
On September 6, 2005 02:33 pm, Mathias Fröhlich wrote: Yay! This brought back 3D-clouds which I've been missing for a long time (using XFree86 4.3 + ATI's proprietary driver for Mobility Radeon 9600) :-) Good to hear ... Thanks Mathias Unfortunately, 3D clouds is still not working over here. I am still getting the RenderTexture Error: Couldn't find a suitable pixel format message everytime I start FlightGear. I am using ATI Radeon 9200 SE PCI version with the opensource driver from XFree. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On September 10, 2005 09:28 am, Curtis L. Olson wrote: My understanding is that for the USA, the X-Plane data for runways comes primarily from DAFIF. Taxiways are all hand drawn and placed. Outside the USA the runway data is manually generated by anyone who wants to submit new airports, so quality and accuracy is all over the map. Curt. Google has some pretty accurate taxiways for their map. Check out http://pigeond.net/flightgear/fg_server_map.html in map mode. Does anybody where Google got their data from? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On September 10, 2005 06:36 am, Jon Stockill wrote: We've just been discussing another problem on irc - the green texture isn't really appropriate for a city, but I left out the city areas since the texture it uses contains its own roads. I'm not really sure of a solution to this. Personally, I think green is fine in the near term. When more models are loaded for a city, the city would not appear to be so green. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On September 10, 2005 01:03 pm, Ralf Gerlich wrote: You can get quite detailed aerial photos for most urban areas in the USA from http://www.terraserver-usa.com David Luff's TaxiDraw has support for automatically loading such photos and showing them in the editor. However, I'm still searching for free detailed aerial photos for other areas of the world such as Germany. Here the government wants you to pay twice for the photos: Once via tax and once when you want to use the photos. The license under which you get those photos here is quite limited as well. Regards, Ralf I think you misunderstood. I was referring to the taxiways under map mode, not satellite mode. If you go in map mode, you will see that Google got some pretty accurate vector data for taxiways generation. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Lufthansa liveries
On September 10, 2005 02:42 pm, [EMAIL PROTECTED] wrote: No one gave you credit for your great work... I wonder why, because it IS great. I have told you so via IRC, but perhaps this is a better way to do it! I encourage you to keep up that kind of stuff and perhaps have a look at other existing liveries that need improving! (Not necessarily thinking about my Twin Otter here, but wouldn't say No ;-)) I also would like to know exactly how you did that... Thorben Well, I haven't seen the liveries so I cannot say. However, from the screenshots, the liveries look pretty good. The method that is used to allow multiple livery needs to be done properly though by making use of the texture-path tags. Some modifications to the XML's is suffice to allow multiple livery. Duplicated model is not needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: very long startup time
On August 25, 2005 04:12 pm, AJ MacLeod wrote: I don't know if this is exactly what you noticed, but I've just found that with today's CVS, if you have real-weather-fetch true in preferences.xml, FG won't start properly at all, but hangs immediately after startup in a manner almost identical to the current cygwin problem. AJ I think that problem is due to metar data being too old. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear freezes (float point interrupt)
I believe I have fixed my freezing problem by removing Xorg and moving back to XFree. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear freezes (float point interrupt)
On August 17, 2005 04:55 am, David Luff wrote: Alternatively, does FG freeze when you start it without all the options above? Cheers - Dave It seems to. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear freezes (float point interrupt)
On August 17, 2005 10:02 am, Andy Ross wrote: This sounds to me a lot like a hardware problem. Can you make it happen when running other 3D applications? Have you tried memtest86? Andy I think I reproduced it by increasing CPU load (ie. loading other applications). As for memtest86, I do not know how to use the program. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear freezes (float point interrupt)
Lately, my computer has been freezing on me unpredictably while I am using FlightGear. (Note: I'm not saying FlightGear is to blame.) Normally, I just cold boot the machine. Today however, after multiple freezes, I was too angry to try again. I went away to do other things, and when I came back, FlightGear seems to got killed by the kernel. When I relaunch FlightGear later, I got a lot of this: Floating point interrupt (SIGFPE) Unfortunately, this was the only message I've got. I start FlightGear using the following command: /usr/local/FlightGear/bin/fgfs --fg-scenery=/usr/local/FlightGear/data/FlightGear/Scenery-0.9.8 --aircraft=b1900d --airport=KSAC --bpp=24 --geometry=1280x600 --fov=69.9 --multiplay=out,10,81.169.158.37,5002 --multiplay=in,10,192.168.0.194,5002 --callsign=AMPERE --enable-real-weather-fetch --enable-clouds3d Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
On July 25, 2005 06:42 am, Vivian Meazza wrote: Radar Echoing Area is (REA) and is also known as the Radar Cross Section (RCS). It's not quite the same thing as the radar visibility range. RCS is a property of the target, and varies with the target aspect w.r.t. the radar, and also the radar frequency. Radar visibility range is a function of the RCS and the power density of the radar at the target. Depending on the level of realism you want for radar, we either need a crude visibility range as a property of the target, or the RCS (probably an estimate) and have the radar work out if the target is visible, taking into account the RCS and the radar horizon. Vivian The RCS idea also occured to me a while ago. In fact, I have actually given it some thought as to how such effect would work in FlightGear. The first idea involves estimating the radar reflection of aircrafts in real time. A camera with an aspect ratio of 0.1 will act as the radar and cycle its view through all the aircrafts in the vicinity at certain intervals. The camera will render what it sees off screen, without any light other than a spot light pointing in the same direction as the camera, without fog, without clouds, without billboard objects, with the sky as black and everything else according to their specular reflectiveness. The renderings will then be analyzed later, with the visibility of each plane corresponds to the average brightness of their rendering. This method will be slow, but it will give some nice effects. The most notable are probably terrain obstructions and interferences. The second idea involves mapping out the RCS values of the planes at different angles, and storing the results in 360x360 pixels, mono-color bitmaps. Then it is simply a matter of doing a look up in FlightGear to find out the RCS of a plane at any given moment, multiplying the value by the power of the radar, and dividing the result by the square of the distance between the plane and the radar This will be much faster than the first method, although it won't give such effects as terrian obstructions and interferences. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code (was:Multiplayer crashes with unknown aircrafts, any solution?)
On July 24, 2005 01:08 pm, Mathias Fröhlich wrote: Since the fg_server only forwards the network packets without looking into them, this will still work with that code. It would appear that fg_server is doing more than merely forwarding network packets now. Those who are using your patch are getting the following messages: FGMultiplayRxMgr::MP_ProcessData - Position message received with insufficient data Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
On July 23, 2005 12:03 pm, Paul Surgeon wrote: What a pity as I don't know of any good replacements and writing VOIP software is not a trivial task. Doing an apt-cache search voip get me kphone and libopenh323. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
On July 19, 2005 06:33 am, Oliver Schroeder wrote: 1) out of reach . . . This will need to apply on chat messages as well. 3) artificial life at airports . . . There is a traffic manager in FlightGear. May be you can make use of that. On July 19, 2005 01:27 pm, Harald JOHNSEN wrote: For VFR we have a nearly hard coded limit of 10 NM from the metar, and at that range I don't think one can really see another aircraft. If your plane has some TCAS instrumentation then you will need perhaps 20 to 40 nm. I do not think there is a need to make a special case for TCAS capable aircrafts. As Pigeon said, make that a separate window, because the ATC line is allready nearly impossible to read ;) It should not be hard to code but the atc code is not good for that (anyway it does not queue messages). I agree. That ATC line is horrible. Use a Nasal-generated transparent window instead. One will then have control over the font size, font style, font color of the displayed text, as well as the number of lines that can be displayed. As for the message buffer, a queue can be used. There is a queue written in Nasal already: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Aircraft/A380/Systems/AFDX/Switch/queue.nas?rev=1.3cvsroot=FlightGear-0.9content-type=text/vnd.viewcvs-markup Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code
On July 17, 2005 08:08 am, Harald JOHNSEN wrote: receiver property tree using the c172p model root0\ |-position/* |-surface/* |-other properties 'player' 1 property subtree in receiver memory using a Concorde model root1\ |-position1/* |-surface1/* |-eof 'player' 2 property subtree in receiver memory using the ufo model root2\ |-position2/* |-surface2/* |-eof So on the receiver side the c172p.xml, concorde.xml and ufo.xml animation code point to the root0 property tree so all animations will reflect the receiver plane animations. An apparent simple hack is to change the root while rendering other 'player' models How about creating root-less nodes to act as seperated property trees for these aircrafts? This way, it will be easier to fool the animation files of these aircrafts into taking the proper values. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
I just noticed that when one is inside an object, or the shadow volume of an object, then the shadow casted by that object is not visible. Here is an example: http://www.students.yorku.ca/~ampere/fgfs-screen-010.jpg Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
On July 15, 2005 01:25 pm, Frederic Bouvier wrote: As always, it may need an up-to-date ( I mean CVS ) base package. Just try it and report success or failure. -Fred There were some problems related to multiplayer reported by CVS users yesterday. Specially, regardless of other planes actual position, they are all jammed around the CVS users' camera. People who use the original 0.9.8 don't experience this problem. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Overhaulling the networking code (was: Multiplayer crashes with unknown aircrafts, any solution?)
On July 15, 2005 05:41 am, Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Erik I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: gui theming
On July 11, 2005 04:26 am, Melchior FRANZ wrote: Screenshot du jour (and my current style; more that just a test): http://members.aon.at/mfranz/fgfs_gui8.jpg [50 kB] m. That's so nice. I would have no objection if that is made default. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
