[Flightgear-devel] IANAE but is this useful?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.gamasutra.com/gdc2002/features/rayner/rayner_01.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8qDMDx58m2d272NoRAlLzAKDOGi+97u+98Z/yla+S8EuKckCxyQCgoQYN LaFduPiDnwqUUQh3tNISPr0= =uzBb -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim compile error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 make[4]: Entering directory `/home/david/flightgear/FlightGear/src/FDM/JSBSim' c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include - -I/usr/X11R6/include -g -O2 -D_REENTRANT -c JSBSim.cpp JSBSim.cpp: In method `bool FGJSBsim::copy_from_JSBsim()': JSBSim.cpp:530: no matching function for call to `FGFCS::GetDePosN ()' JSBSim.cpp:531: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:532: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:533: no matching function for call to `FGFCS::GetDrPosN ()' JSBSim.cpp:534: no matching function for call to `FGFCS::GetDfPosN ()' make[4]: *** [JSBSim.o] Error 1 Anyone else getting this? Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8qEMSx58m2d272NoRAsAlAJ9Rqv93kcAkfIkPiQhKap1U/A5hrQCfSVvd 0yWSkrnFh2MrTOr032fBe5A= =r9hj -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson writes: Sure we do (but implicitly; see below). That's the whole point of a scene graph -- objects draw themselves into their own coordinate system, and their containers, being higher up in the scene graph, set up the modeling transformation appropriately. Yes this is true, but models move within the scene, and the panel needs to be located at a given xyz in relation to the model not the scene. Of course it could be oriented in the scene as it is now, but it really ought to be placed in the model, hence the suggestion that the orientation data come from the FGModel class. I think what Andy's suggesting is that the panel be part of the model's scene graph. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C172 3D Model
For those who didn't read my long post about PLIB problems, there is now a new C172 3D model in the base-package CVS, including the much-requested translucent propeller disk for high RPM. Unfortunately, to see the model correctly, you will have to patch your local plib source tree to fix the AC3D loader. Here are the two (small) patches against the latest plib CVS: http://www.megginson.com/flightsim/plib-smoothing.dif http://www.megginson.com/flightsim/plib-transparency.dif Without these patches, the model is unsmoothed, and the propeller disk and windows are opaque. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] How to download LaRCsim?
Hello, could you say how could I download larcsim from ftp.flightgear.org??? When I try to connect, server asks password. Please help me. Julius ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] JSBSim compile error
make[4]: Entering directory `/home/david/flightgear/FlightGear/src/FDM/JSBSim' c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include - -I/usr/X11R6/include -g -O2 -D_REENTRANT -c JSBSim.cpp JSBSim.cpp: In method `bool FGJSBsim::copy_from_JSBsim()': JSBSim.cpp:530: no matching function for call to `FGFCS::GetDePosN ()' JSBSim.cpp:531: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:532: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:533: no matching function for call to `FGFCS::GetDrPosN ()' JSBSim.cpp:534: no matching function for call to `FGFCS::GetDfPosN ()' make[4]: *** [JSBSim.o] Error 1 Anyone else getting this? Thanks, David No. GetDrPosN() and similar functions are now gone. Are you running from JSBSim CVS? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] How to download LaRCsim?
It comes with FlightGear. Go to this page and read up on how to get the code via anonymous CVS: http://flightgear.sourceforge.net/cvsResources/anoncvs.html Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Julius Sent: Monday, April 01, 2002 5:13 AM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] How to download LaRCsim? Hello, could you say how could I download larcsim from ftp.flightgear.org??? When I try to connect, server asks password. Please help me. Julius ___ 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] Re: [Plib-devel] PLIB/FlightGear Problems
David/Plib developers, I believe we are in the same situation with the plib patches which allow more than 3 concurrent sounds to be played. I believe these are only in the 1.5.x tree. So, that would be another reason to roll out plib-1.6.0 ... I recall some sort of confusion and misunderstanding last time we made this request and I'd like to avoid that if possible. Pushing out a new stable release can be a lot of work, so before we ask too agressively we need to make sure we are close to being ready to roll out a corresponding version of FlightGear that actually requires these changes. I will say that even the current flightgear release would benefit from the ac3d smoothing patches and also from the 3 concurrent sounds patch. Regards, Curt. David Megginson writes: I've run into some philosophical problems about how to handle plib. Right now, plib has two technical problems loading AC3D models: 1. The models are not smoothed. 2. Alpha transparency in a texture is not respected (unless the entire object is partly transparent, which looks stupid). I have a new C172 model ready with windows and a propeller disk, but both of these features require a plib patch to fix #2 -- otherwise, the windows and propeller disk are entirely opaque. The models also look crude and chunky without a patch to fix #1. I thought that I might avoid these problems by converting the model to plib's native ssg format, pre-smoothed, etc., but unfortunately that uncovered another plib bug -- the SSG model loader does not respect the ssgTexturePath, so textures for an .ssg model are not loaded unless you launch FlightGear from the directory containing the textures. I tried every format that plib supports, systematically, and in the end none but AC3D preserved all of the model, including textures and texture alpha information (and then, only with my patches). My patches are inelegant and oversimplistic, so Steve Baker might not want to add them to the plib CVS (the AC3D loader really needs a major structural overhaul, not just a few pieces of duct tape). Even if he does accept them, though, they will be available only in the CVS version of plib, and as a policy, we avoid dependencies on prerelease versions of plib. That means that anyone who builds FlightGear with the latests released plib version will still have opaque windows (from the outside) and an opaque propeller disk at high RPM. Comments? Suggestions? I guess the best possible outcome would be for the plib people to incorporate my patches (or improved versions) and then put out a new official release very soon, which we can require for our next official release. The worst possible outcome is for us to have to distribute patches against plib in the FlightGear distro and to require people to build FlightGear with a patched version. For now, my plib patches are available at http://www.megginson.com/flightsim/plib-smoothing.dif http://www.megginson.com/flightsim/plib-transparency.dif I'll add my new model to the FlightGear base package repository, since CVS developers are capable of managing patched plib trees, but might have to roll back if there are a lot of complaints. Thanks, and all the best, David -- David Megginson [EMAIL PROTECTED] ___ plib-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/plib-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] Panel locking to z-offset
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: Sure we do (but implicitly; see below). That's the whole point of a scene graph -- objects draw themselves into their own coordinate system, and their containers, being higher up in the scene graph, set up the modeling transformation appropriately. Yes this is true, but models move within the scene, and the panel needs to be located at a given xyz in relation to the model not the scene. Of course it could be oriented in the scene as it is now, but it really ought to be placed in the model, hence the suggestion that the orientation data come from the FGModel class. I think what Andy's suggesting is that the panel be part of the model's scene graph. So am I, but panel isn't moved to a scene graph yet. Now that I think about it though, he is still going to need the offsets that the model doesn't know about to implement the mouse action. So never mind. That information is and will be in the property tree. Sometime this week I should be ready to set up the property tree for view data in it's more or less final form. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim compile error
On Mon, 2002-04-01 at 03:22, David Findlay wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 make[4]: Entering directory `/home/david/flightgear/FlightGear/src/FDM/JSBSim' c++ -DFGFS -I../../.. -I../../../src -I/usr/local/include - -I/usr/X11R6/include -g -O2 -D_REENTRANT -c JSBSim.cpp JSBSim.cpp: In method `bool FGJSBsim::copy_from_JSBsim()': JSBSim.cpp:530: no matching function for call to `FGFCS::GetDePosN ()' JSBSim.cpp:531: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:532: no matching function for call to `FGFCS::GetDaLPosN ()' JSBSim.cpp:533: no matching function for call to `FGFCS::GetDrPosN ()' JSBSim.cpp:534: no matching function for call to `FGFCS::GetDfPosN ()' make[4]: *** [JSBSim.o] Error 1 Anyone else getting this? Thanks, It sounds like you've got an old version of JSBSim.cxx. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8qEMSx58m2d272NoRAsAlAJ9Rqv93kcAkfIkPiQhKap1U/A5hrQCfSVvd 0yWSkrnFh2MrTOr032fBe5A= =r9hj -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
Hello, I've found out that flighgear does not compile clean under RedHat 7.2 with Accelerated X Summit 3D drivers 2.1.4 from www.xig.com Are any folks having the same configuration like me and somebody else have seen these errors which comes from xglUtils.c xglUtils.c:218: initializer element is not constant xglUtils.c:218: (near initialization for `glenum_string[157].val') xglUtils.c:335: `GL_NORMAL_ARRAY_COUNT_EXT' undeclared here (not in a function) xglUtils.c:335: initializer element is not constant xglUtils.c:335: (near initialization for `glenum_string[268].val') xglUtils.c:471: `GL_TEXTURE_COORD_ARRAY_COUNT_EXT' undeclared here (not in a function) xglUtils.c:471: initializer element is not constant xglUtils.c:471: (near initialization for `glenum_string[396].val') xglUtils.c:509: `GL_VERTEX_ARRAY_COUNT_EXT' undeclared here (not in a function) right now I just comment out these definitions from xglUitils.c I am using glut from XIG and libGL are from XIG too. stefan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Jim Wilson wrote: David Megginson wrote: I think what Andy's suggesting is that the panel be part of the model's scene graph. Yeah. What he said. :) So am I, but panel isn't moved to a scene graph yet. Now that I think about it though, he is still going to need the offsets that the model doesn't know about to implement the mouse action. Nope; just the matrices. The panel knows that if it runs an airframe coordinate through teh modelview and projection matrices, it'll get screen coordinates in the range [-1:1]. Just invert that matrix and we can go from screen coordinates to airframe, thence to panel coordinates. It's a little more complicated in practice, but that's the essence of the problem. The panel certainly doesn't need to know anything specific about the model or the viewer. It can do it all on its own, without reference to anything but the OpenGL render state. Again, that's the point behind scene graph architectures. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
Stefan wrote: I've found out that flighgear does not compile clean under RedHat 7.2 with Accelerated X Summit 3D drivers 2.1.4 from www.xig.com Are any folks having the same configuration like me and somebody else have seen these errors which comes from xglUtils.c This sounds to me like the XiG drivers are shipping and old or broken gl.h header file. By convention, the gl.h file is standardized by the OpenGL ARB and should always contain symbol definitions for all features, even if those features aren't supported by the implementation. You could try replacing your /usr/include/GL/gl.h file with the one Red Hat installed originally (which I know to be ARB compliant). Alternatively, see if XiG has dropped a broken one somewhere else, like /usr/X11R6/include/GL. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Panel locking to z-offset
Andy Ross writes: Jim Wilson wrote: David Megginson wrote: I think what Andy's suggesting is that the panel be part of the model's scene graph. Yeah. What he said. :) So am I, but panel isn't moved to a scene graph yet. Now that I think about it though, he is still going to need the offsets that the model doesn't know about to implement the mouse action. Nope; just the matrices. The panel knows that if it runs an airframe coordinate through teh modelview and projection matrices, it'll get screen coordinates in the range [-1:1]. Just invert that matrix and we can go from screen coordinates to airframe, thence to panel coordinates. It's a little more complicated in practice, but that's the essence of the problem. The panel certainly doesn't need to know anything specific about the model or the viewer. It can do it all on its own, without reference to anything but the OpenGL render state. Again, that's the point behind scene graph architectures. and you could probably even use the 'hitlist' mechanism almost as is to do this in an SSG way that would return both the face hit and the position in that face :-) I think it is just a matter of putting the cockpit into SSG and then setting up the apropriate 'ray' to intersect with the 'Model' SceneGraph For the 'adventurous' I believe that the 3D cursor stuff from PPE should be convertable to FGFS too. In any event the applicable matrix stuff is all there in 'src / Viewer / ppeViewer.cxx' for anyone inclined to peek Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Panel locking to z-offset
Andy Ross writes: But the core point is valid -- this is essentially a collision detection (or picking -- same thing) problem, and can be solved using all the same tricks. Hence my reference to PPE which constrains the 'picker' to a plane where the math is all worked out for doing this in a SSG friendly way Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Below are some ideas I proposed for chase and tower views. I am wondering if some things like this might now be included w/ the improved view code. I'll reiterate a little. Chase views: [1] One view like the old one, but minus the sway that was due to sideslip. In this case the horizon on the screen is always level. (I don't think the new chase view behaves like this. The horizon is not level, it rolls w/ the aircraft.) [2] What would be seen from a following aircraft. In this case, the horizon will move like it does on the HSI. The final view will look very much like the current cockpit view minus the instruments but w/ the 3D model of the aircraft shown. [3] A lagged version of [2]. Not as important, but neat. It would effectively show what one would record from a video camera in the chase plane. The 3D model of the aircraft will not always be centered on the screen. In extremely rapid maneuvers, the 3D model might even move off of the screen (out of the camera field of view). It seems that to do 2 and 3, the aircraft trajectory history (so many feet of flight path trajectory) needs to be saved and used by the viewer code. Tower view: [1] One version w/ the view positioned at the end of the runway and slightly behind and above the aircraft, looking down on the aircraft. This view is extremely useful for testing new-aircraft nonlinear-aero models. It's hard to judge stall and other extreme maneuvers from the cockpit, but from the tower one can gauge these things pretty well. [2] Another from the tower at the particular airport. Maybe the latest code can already do these things w/ input via xml(?). Regards, Michael At 3/9/02, you wrote: I have a couple of comments below. At 3/9/02, you wrote: As far as I can figure out, there are only three situations we need to deal with in the viewer code: 1. Looking away from a known position. 2. Looking towards a known position from a known distance and angle(s). With respect to the chase view (2), three potential options come to mind: 2.1 What you get now w/ the 'v' key, but with one tweak. This view always keeps the horizon horizontal on the screen. When the aircraft is flying straight down what you see is a plan view. When the aircraft is level what you see is a rearview. When the aircraft is doing a Dutch roll, the horizon is still level. All of this is good. Another tweak to this view, however, is where the view is not sort of tied to the body axis directionally. Right now for an aircraft that has a strong adverse yaw (or Dutch roll), the view sways from side to side (w/ horizon level), and this makes it hard to fly w/o getting airsick (for me). It would be better to simply see the aircraft yawing side to side w/ the view not swaying back and forth. So this view would be tied to the aircraft trajectory history. 2.2 A chase view. This would be a view that looks at the viewed aircraft from a following shadow aircraft. The horizon here would move like it does when flying from inside the aircraft. The viewed aircraft in this case would be centered on the screen as it is now w/ the 'v' key. There is no lag w/ the aircraft centered on the screen. 2.3 A chase view, but more realistic. If one were following the viewed aircraft from a chase plane, there would be some lag in the view. In this case, the viewed aircraft would not stay in the center of the screen. It will only be centered when flying steady state, but for, say, a rapid pull-up, the viewed aircraft would move up from the center of the screen. So the chase view is more or less what a human would see w/ binoculars from the following aircraft --- there would be lag. 3. Looking from one known position towards another. For the tower view, having a zoom feature would be really good. In fact, for all cases, it would be handy if the zoom-in/zoom-out increased the distance between the viewer and viewee. An example of (1) is the view from inside the aircraft; an example of (2) is a chase view; and an example of (3) is a tower view. The view manager class should take care of setting up viewers appropriately for different situations. In every case, we want to be able to specify offsets for all six degrees of freedom. I think that it makes sense to put all of this in a single, configurable viewer class, rather than having separater viewer_lookat, viewer_rph, and (eventually) viewer_tower classes that duplicate most of each-others' code. The main required output is the VIEW matrix to pass to ssgSetCamera, but several parts of FlightGear need vectors and matrices that are byproducts of calculating VIEW as well (such as the world-up vector); it would be nice to minimize these dependencies as far as possible. All of the views can still be managed by the view-manager class (a proper subsystem), but we should try to remove all hard-coded dependencies from the rest of the FlightGear codebase. For example, the scenery code doesn't
[Flightgear-devel] compilation error
Hello, Could someone help me out please? - I'm having a trouble compiling after checking out a copy of CVS today. I have the correct versions of PLIB, SimGear, and MetaKit installed in /usr/local/ - pretty much as per the docs. When I cd into /usr/local/src/FlightGear and run autogen.sh it completes without error as does: ./configure --disable-network-olk --with-x --prefix=/usr/local/FlightGear However, when I issue a make command I get the following error: In file included from ATCdisplay.cxx:28: ../../src/Main/fg_props.hxx:11: simgear/misc/props_io.hxx: No such file or directory Would I be right in thinking that I have screwed up and forgotten something or maybe put something in the wrong place? If it helps I previously had a standard SuSE FlightGear 0.78 rpm installed which I have removed and I'm running SuSE 7.3. Many thanks in advance, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
Thank you for answer. I have submited to XIG this information. Indeed under Mesa's gl.h all the above definitons are included. I have to see what XIG's answer is. Previous they made clear that Mesa does not stand 100% OpenGL ARB. stefan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation error
Matt, If you are building FlightGear from CVS, then you also need SimGear from CVS. Regards, Curt. matthew law writes: Hello, Could someone help me out please? - I'm having a trouble compiling after checking out a copy of CVS today. I have the correct versions of PLIB, SimGear, and MetaKit installed in /usr/local/ - pretty much as per the docs. When I cd into /usr/local/src/FlightGear and run autogen.sh it completes without error as does: ./configure --disable-network-olk --with-x --prefix=/usr/local/FlightGear However, when I issue a make command I get the following error: In file included from ATCdisplay.cxx:28: ../../src/Main/fg_props.hxx:11: simgear/misc/props_io.hxx: No such file or directory Would I be right in thinking that I have screwed up and forgotten something or maybe put something in the wrong place? If it helps I previously had a standard SuSE FlightGear 0.78 rpm installed which I have removed and I'm running SuSE 7.3. Many thanks in advance, Matt. ___ 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] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
On Mon, Apr 01, 2002 at 01:21:15PM -0800, Andy Ross wrote: All that being said, I'd be curious as you how your experience is with the XiG drivers. These provide the only useful Radeon support for Linux, right now, and are rather reasonably priced. The DRI Radeon drivers aren't useful? They work nicely for me . . . Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04773/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
Simon Fowler wrote: Andy Ross wrote: All that being said, I'd be curious as you how your experience is with the XiG drivers. These provide the only useful Radeon support for Linux, right now, and are rather reasonably priced. The DRI Radeon drivers aren't useful? They work nicely for me . . . Correct me if I'm wrong, but the last time I checked the DRI driver lacked support for the (now almost a year old) 8500 cards, had no hardware geometry acceleration, nor multitexture support. These might work, in the sense of producing correct results, but they are only semi-complete at best. Performance-wise, ATIs windows drivers stomp all over them. Whether that consitutes useful or not depends on your perspective, I guess. I should have picked a better term. The Xi Graphics folks at least claim to support the full feature set of the cards. I was curious as to how well it worked. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: compiling under Linux RedHat 7.2 andAccelerated 3D Summit openGL
On Mon, 2002-04-01 at 15:19, Simon Fowler wrote: On Mon, Apr 01, 2002 at 01:21:15PM -0800, Andy Ross wrote: All that being said, I'd be curious as you how your experience is with the XiG drivers. These provide the only useful Radeon support for Linux, right now, and are rather reasonably priced. The DRI Radeon drivers aren't useful? They work nicely for me . . . Simon I've had good luck with the DRI radeon drivers on FreeBSD. I think the only thing that's missing is teh TL and that's currently in one of the DRI CVS branches. BTW I'm getting between 40-100fps in FlightGear depending on the area Cheers, Mike ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Panel locking to z-offset
Andy Ross [EMAIL PROTECTED] said: Nope; just the matrices. The panel knows that if it runs an airframe coordinate through teh modelview and projection matrices, it'll get screen coordinates in the range [-1:1]. Just invert that matrix and we can go from screen coordinates to airframe, thence to panel coordinates. It's a little more complicated in practice, but that's the essence of the problem. The panel certainly doesn't need to know anything specific about the model or the viewer. It can do it all on its own, without reference to anything but the OpenGL render state. Again, that's the point behind scene graph architectures. Interesting. I've read about this method but assumed it was best for more complex scenes. What I was thinking is that with the offset values you could essentially remap the panel's 2D hot spots to new 2D locations, but that's perhaps a bit heavy computationally. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
On Mon, Apr 01, 2002 at 02:43:00PM -0800, Andy Ross wrote: Simon Fowler wrote: Andy Ross wrote: All that being said, I'd be curious as you how your experience is with the XiG drivers. These provide the only useful Radeon support for Linux, right now, and are rather reasonably priced. The DRI Radeon drivers aren't useful? They work nicely for me . . . Correct me if I'm wrong, but the last time I checked the DRI driver lacked support for the (now almost a year old) 8500 cards, had no hardware geometry acceleration, nor multitexture support. These might work, in the sense of producing correct results, but they are only semi-complete at best. Performance-wise, ATIs windows drivers stomp all over them. Whether that consitutes useful or not depends on your perspective, I guess. I should have picked a better term. The 8500 support is currently non-existant, yes, but tcl support is available for the original Radeon chips, and I believe multitexture support is likewise available, at least in the DRI cvs tree (which is quite easy to install and use - certainly no harder than dealing with FlightGear/SimGear/plib cvs trees). There are also binary snapshots of the latest development code available. Support for the 8500 /is/ planned - the docs are available, and the reason there's no support yet is because the developers are working on getting tcl support for the original Radeon working properly. This includes developing the framework for hardware tcl support, so that supporting the full feature set of the 8500 (and in fact /any/ chip that supports hardware tcl and similar) should be much easier. rant As for a comparison with ATI's windows drivers . . . . . How many man-hours has gone into them? Over how many years? Compared to about three people working on the DRI code intermittently over the last couple of years . . . At least they have full documentation now. You might as well say that FlightGear isn't useful, because it doesn't have everything that Fly! does . . . /rant Yes, the DRI drivers are a work in progress, but at present they /do/ work, and they certainly work well enough that I'd choose to use them rather than fork out cash for binary drivers. The Xi Graphics folks at least claim to support the full feature set of the cards. I was curious as to how well it worked. They also ship with a broken gl.h, apparently . . . What that suggests about their quality control is left as an exercise for the reader. Simon -- PGP public key Id 0x144A991C, or ftp://bg77.anu.edu.au/pub/himi/himi.asc (crappy) Homepage: http://bg77.anu.edu.au doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://bg77.anu.edu.au/pub/mirrors/css/ msg04777/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Rationalizing view
Michael Selig [EMAIL PROTECTED] said: Chase views: [1] One view like the old one, but minus the sway that was due to sideslip. In this case the horizon on the screen is always level. (I don't think the new chase view behaves like this. The horizon is not level, it rolls w/ the aircraft.) Actually only the pitch is applied to the model. The roll is not. From the side it does look a little funky. In relation to the horizon, the pitch angle gets doubled. [2] What would be seen from a following aircraft. In this case, the horizon will move like it does on the HSI. The final view will look very much like the current cockpit view minus the instruments but w/ the 3D model of the aircraft shown. Hmmm...try setting the z-offset to -25.0 in the pilot view. [3] A lagged version of [2]. Not as important, but neat. It would effectively show what one would record from a video camera in the chase plane. The 3D model of the aircraft will not always be centered on the screen. In extremely rapid maneuvers, the 3D model might even move off of the screen (out of the camera field of view). It seems that to do 2 and 3, the aircraft trajectory history (so many feet of flight path trajectory) needs to be saved and used by the viewer code. Yes, some sort of fifo buffer would work. Tower view: [1] One version w/ the view positioned at the end of the runway and slightly behind and above the aircraft, looking down on the aircraft. This view is extremely useful for testing new-aircraft nonlinear-aero models. It's hard to judge stall and other extreme maneuvers from the cockpit, but from the tower one can gauge these things pretty well. [2] Another from the tower at the particular airport. Maybe the latest code can already do these things w/ input via xml(?). Almost. It should by the end of the week, maybe sooner. Once I have the basic viewer xml configuration setup, I will probably be expanding it to allow quite a lot of control via xml configs. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] JSBSim Body Axes question
Could someone help me out please? In the JSBSimCoordinates.pdf from http://jsbsim.sourceforge.net, we know that the Xbody Axis positive forward out through out the nose of the plane, Ybody positive out the right side, Zbody Axis positive downwards. Then we know that: (look from the tail of the plane) (1) roll rate (p) clockwise are positive; (2) roll angle (phi) clockwise are positive; (3) left-aileron up and right-aileron down are positive; Right? Assume the plane flying steadily now, if aileron left-up and right-down , that is aileron position increase , the plane would roll anti-clockwise, that is roll rate (or roll angle) would decrease? Right? But why does JSBSim not match it? When I increase aileron position, the roll rate and roll angle increase too. Who can tell me why? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim Body Axes question
On Tue, Apr 02, 2002 at 11:05:18AM +0800, wrote: Could someone help me out please? In the JSBSimCoordinates.pdf from http://jsbsim.sourceforge.net, we know that the Xbody Axis positive forward out through out the nose of the plane, Ybody positive out the right side, Zbody Axis positive downwards. Then we know that: (look from the tail of the plane) (1) roll rate (p) clockwise are positive; (2) roll angle (phi) clockwise are positive; (3) left-aileron up and right-aileron down are positive; Right? The flight controls follow the right hand rule relative to the body axis system. This means that *both* ailerons are positive trailing edge down and negative trailing edge up. Assume the plane flying steadily now, if aileron left-up and right-down , that is aileron position increase , the plane would roll anti-clockwise, that is roll rate (or roll angle) would decrease? Right? But why does JSBSim not match it? When I increase aileron position, the roll rate and roll angle increase too. Who can tell me why? ___ 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: Re: [Flightgear-devel] JSBSim Body Axes question
On Tue, Apr 02, 2002 at 11:05:18AM +0800, wrote: Could someone help me out please? In the JSBSimCoordinates.pdf from http://jsbsim.sourceforge.net, we know that the Xbody Axis positive forward out through out the nose of the plane, Ybody positive out the right side, Zbody Axis positive downwards. Then we know that: (look from the tail of the plane) (1) roll rate (p) clockwise are positive; (2) roll angle (phi) clockwise are positive; (3) left-aileron up and right-aileron down are positive; Right? The flight controls follow the right hand rule relative to the body axis system. This means that *both* ailerons are positive trailing edge down and negative trailing edge up. In the older version of JSBSim, we control the two ailerons at the same time. The turnning orientation of them are opposite(One up , another down)? if so , left-up and right-down are positive? In the newer version of JSBSim , we can control the two ailerons separately. then Can they somtimes act as flags do? and what is the positive position of them? I am using the older version of JSBSim with ailerons controled simultaneously. thanks. Assume the plane flying steadily now, if aileron left-up and right-down , that is aileron position increase , the plane would roll anti-clockwise, that is roll rate (or roll angle) would decrease? Right? But why does JSBSim not match it? When I increase aileron position, the roll rate and roll angle increase too. Who can tell me why? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: Re: [Flightgear-devel] JSBSim Body Axes question
The definition of a positive aileron deflection is when the right-hand aileron deflects according to the right hand rule - that is, trailing edge down (TED). Unfortunately, this results in a negative roll rate - it would be nice if our choice of coordinate system caused a positive aileron deflection to result in a positive roll rate, but this is not the case. :-( Anyhow, yes, Tony wanted to control each aileron individually, so this was changed. It *should* *be* the same to you and I. It's just that the left aileron will get the negative of the right aileron deflection. A control system *could* use the ailerons as flaps AND as ailerons. These are called flaperons. The space shuttle uses the wing outer control surfaces as ailerons and elevator. These are called elevons. You might also combine flaps, spoilers, ailerons, and elevator and call it a slapevon. Well ... maybe not. ;-) In any case, Tony was right to split out the left and right aileron controls because we might want to model an aircraft that addresses various control surfaces in unique and interesting ways. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] =?gb2312?B?UmU6UkU6IFJlOiBbRmxpZ2h0Z2Vhci1kZXZlbF0gSlNCU2ltIEJvZHkgQXhlcyBxdWVzdGlv
bg==?= X-Priority: 3 X-Originating-IP: [166.111.68.48] X-Mailer: Coremail2.0 Copyright Tebie Ltd., 2001 The definition of a positive aileron deflection is when the right-hand aileron deflects according to the right hand rule - that is, trailing edge down (TED). Unfortunately, this results in a negative roll rate - it would be nice if our choice of coordinate system caused a positive aileron deflection to result in a positive roll rate, but this is not the case. :-( Anyhow, yes, Tony wanted to control each aileron individually, so this was changed. It *should* *be* the same to you and I. It's just that the left aileron will get the negative of the right aileron deflection. A control system *could* use the ailerons as flaps AND as ailerons. These are called flaperons. The space shuttle uses the wing outer control surfaces as ailerons and elevator. These are called elevons. You might also combine flaps, spoilers, ailerons, and elevator and call it a slapevon. Well ... maybe not. ;-) In any case, Tony was right to split out the left and right aileron controls because we might want to model an aircraft that addresses various control surfaces in unique and interesting ways. Jon Yes, It is necessary to control the ailerons separately for widely use. I just found that a positive aileron pos result in a positive roll rate -- the JSBSim version is downloaded 2 weeks ago. It run with C172 model. and I did a little change. If you can be sure that positive aileron pos would result in nagative roll rate, that must be my matter. Let me check it . thank you for your patience. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
At 4/2/02, you wrote: Michael Selig [EMAIL PROTECTED] said: Chase views: [1] One view like the old one, but minus the sway that was due to sideslip. In this case the horizon on the screen is always level. (I don't think the new chase view behaves like this. The horizon is not level, it rolls w/ the aircraft.) Actually only the pitch is applied to the model. The roll is not. From the side it does look a little funky. In relation to the horizon, the pitch angle gets doubled. Maybe I should wait until you have it done, but I'd like to comment on my observations which you are surely aware of. As things are now, one gets this when the model is viewed from behind: - pitch is applied to the model (model pitches up-down / horizon is level on screen) - roll is applied to the view (horizon rolls / wings are level on screen) - yaw is applied to the view (horizon swings side-to-side / model is straight nose-to-tail on screen) Then when the model is viewed from the side: - pitch is applied to the view (horizon rolls / aircraft is level --- opposite above) - roll is applied to the model (opposite above) - yaw is applied to the view (horizon swings side-to-side --- same as above) Things are halfway between these two with the quartering views. For me, speaking from experience, this is a recipe for vertigo. But I guess it is also a cure for my addiction to flying the sim! Because I am not ready to be cured, I'd like to propose in these terms above one basic view mode, which is somewhat similar to the way things were. It goes like this: In rearview: - pitch is applied to the model - roll is applied to the model - yaw is applied to the model In sideview, etc: - same as above I think this would be a very intuitive view. In this case, the horizon is always level on the screen and only the model rolls, pitches and yaws. The viewer is always looking at the airplane from a point on a circular perimeter that surrounds the airplane and this disk is always parallel to flat ground. Regards, Michael [2] What would be seen from a following aircraft. In this case, the horizon will move like it does on the HSI. The final view will look very much like the current cockpit view minus the instruments but w/ the 3D model of the aircraft shown. Hmmm...try setting the z-offset to -25.0 in the pilot view. [3] A lagged version of [2]. Not as important, but neat. It would effectively show what one would record from a video camera in the chase plane. The 3D model of the aircraft will not always be centered on the screen. In extremely rapid maneuvers, the 3D model might even move off of the screen (out of the camera field of view). It seems that to do 2 and 3, the aircraft trajectory history (so many feet of flight path trajectory) needs to be saved and used by the viewer code. Yes, some sort of fifo buffer would work. Tower view: [1] One version w/ the view positioned at the end of the runway and slightly behind and above the aircraft, looking down on the aircraft. This view is extremely useful for testing new-aircraft nonlinear-aero models. It's hard to judge stall and other extreme maneuvers from the cockpit, but from the tower one can gauge these things pretty well. [2] Another from the tower at the particular airport. Maybe the latest code can already do these things w/ input via xml(?). Almost. It should by the end of the week, maybe sooner. Once I have the basic viewer xml configuration setup, I will probably be expanding it to allow quite a lot of control via xml configs. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: compiling under Linux RedHat 7.2 and Accelerated 3D Summit openGL
Thanks everybody for answers. In short: There is no XFRee86, DRI support for Radeon 8500 3D. Radeon 8500 is different that standard Radeon therefore I think 3D engine has been changed. I hope 4.3.0 XFRee will have support for that. Yes gl.h from XIG has no definitions for GL constants found under xglUtils.c (some which ended with an error)- Now if this is a not a matter of conformance about OpenGL ARB whhat exactly are those GL constants ? I tried last night to search under OpenGL Reference book but with no success. They are not defined in there. But arent't GL constants part of OpenGL standard, like telling in version 1.2.1 what constants should we find under gl.h ? What GL constants then are added to gl.h in version 1.3 and so on ? I have to see what XIG's answer is. The drivers works really cool. I did not have any problems at all. the performance is really different from a starndard Radeon and the drivers are stable. Right now they have out 2.1.4 - I had previously standard Radeon 64DDRAM, and now Radeon 8500 64 DDR. I have no experience with nVidia cards so much. Is GeForce4Ti 4600 better than Radeon 8500 ? Do you guys have any experience with the new cards from ASUS, Creative or LeadTek ? stefan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
