[Flightgear-devel] Douglas DC-3 Dakota
Hi all E-mailed you guys a few weeks ago about my willingness to help. I work part-time at the South African Air Force Museum, and, seeing as we operate two DC-3's, I can get you any information you need. Tell me what you need, and I can get it. The only problem is : I only work there over weekends (you know, sort of a relief crew for the fulltime staff), so I can only get the info on a Saturday. So if you can email it to me before 0700GMT, I can get the info for you, otherwise you'll have to wait a week. Hope I can help. -- Danie Heath Web Integrator RisC Com cc +27 12 654-5100 083 412 6904 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RedHat 7.2 Enigma and Flightgear
Hi all So my pc is back online after it passed away recently :-) but now I have a different problem (don't worry, it's not the Metakit compiling problem again.) Here's a short summary of my system : AMD 1000 MHz 256MB RAM Leadtek NVIDIA Geforce 2 MX64 OS : Redhat 7.2 Enigma Ok, so I tested my system on Linux before compiling Flightgear (to sort out the display card issues). I tried to play TUX Racer (opengl game that comes with Redhat), and got framerates of about 1 frame/second. I went to NVIDIA's website, downloaded and installed the correct drivers, and now I don't know what the frame rates are anymore (easily above 30 frames/second). Now that's a clear indication that my display card is working mighty fine, as well as OpenGL and all that fancy stuff, so I compiled Flightgear. Everything went well without any problems (quite impressed guys, you do excellent developing). When at last I tried to run Flightgear : ./fgfs --fg-root=/usr/local/FlightGear it gave me the following : GLUT : Fatal Error in fgfs : could not open display : Can anyone please help me ? -- Danie Heath Web Integrator RisC Com cc +27 12 654-5100 083 412 6904 [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Hack for Virtual cockpit problem
Andy Ross writes: > >For a quickie example, look at the places in the code that read the >view_offset and view_tilt stuff. These are the values that represent >the direction of the pilot's head, and as such should be used only by >the core view code to decide on a view direction for the 3D >projection. Exactly ! >But because of the way things grew, they are also read by >places like the panel (my fault), ADA FDM (no idea there), lighting >code (!), and main loop. These places don't care about the difference >between the pilot's head and aircraft frame -- they just want to know >the ultimate direction of the view. Well, except for the panel, which >rightfully should just draw in the aircraft frame and not worry about >view direction at all -- my current code essentially does things >backwards, because those values could be read from the FGViewer object >and set via properties, while the mouse quat couldn't. Well the Mouse code certainly could but let's leave that alone as I REALLY don't want the Mouse reading properties :-) Anyway FWIW The way I envisoned this was that the Mouse Quat well actually the matrix currently called GuiQuat_mat[4][4] in gui_local.cxx would be promoted into the view class or some other logical spot to hold the mouse contribution to the 'eye rotation matrix' in fact I think there is/was a comment to that effect in both gui_local.cxx and viewer_rph.cxx Also realize that we have been WELL AWARE of the fact that the VIEW CODE needs restructuring and have been holding off as what was there was at least temporarily 'good enough'. Good enough to get you and many others hooked on FGFS :-) Also realize that a few of us have been thinking about how this thing works for quite sometime and rather then submitting massive code changes and exerting our personal whims have been instead 'guiding' and 'coaxing' those along who 'wanted' to actually write code so that they understood how it worked and/or so that others could 'feel' involved :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Coordinates fact check
Andy Ross writes:
>
>While I'm thinking about it, can someone with knowlege please let me
>know that I've got the right facts for the following coordinate systems:
> What I'm fuzzier on is where
>the origin is when the scenery tiles are drawn (it has to be local, as
>floats don't have sufficient precision). I can probably figure it out
>from reading the code, but yell if there are nasty subtleties here.
Reread my post from yesterday about how the VIEW is created
and see -
main.cxx
void fgRenderFrame( void ) {
// calculate our current position in cartesian space
scenery.set_center( scenery.get_next_center() );
}
int FGTileMgr::update( double lon, double lat ) {
if ( tile_cache.exists( current_bucket ) ) {
current_tile = tile_cache.get_tile( current_bucket );
scenery.set_next_center( current_tile->center );
} else {
SG_LOG( SG_TERRAIN, SG_WARN, "Tile not found (Ok if
initializing)" );
scenery.set_next_center( Point3D(0.0) );
}
...
}
void FGTileMgr::prep_ssg_nodes()
void FGTileEntry::prep_ssg_node( const Point3D& p, float vis) {
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Coordinates fact check
While I'm thinking about it, can someone with knowlege please let me know that I've got the right facts for the following coordinate systems: Model coordinates (that is, the reference frame of the local aircraft, into which the model and panel geometry will be drawn): Origin = nose of the aircraft (?) X = backwards Y = up Z = left World coordinates (global cartesian coordinates fixed to the earth, into which the scenery is drawn): Origin = center of the earth X = out through lat=0, lon=0 Y = out through lat=0, lon=90E Z = out the north pole I got these off of Curt's very nice coordinates document, so I'm fairly confident that this one is right. What I'm fuzzier on is where the origin is when the scenery tiles are drawn (it has to be local, as floats don't have sufficient precision). I can probably figure it out from reading the code, but yell if there are nasty subtleties here. Plib coordinates (the screen-space coordinates that are used in lieu of OpenGL coordinates as the destination for the viewing orientation): Origin = eye position (duh) X = forward Y = left Z = up This, by way of needless trivia, is same convention YASim uses for aircraft geometry. 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
[Flightgear-devel] Hack for Virtual cockpit problem
Jim Wilson writes:
> I could really use some help visualizing
> the matrices. Which elements are which axis (in Plib)?
x is 1st
y is 2nd
z is 3rd < up >
where x cross y equals z
same as OpenGL xcept there Y is up
> And what does the fourth row/col represent?
fourth column is scaling almost allways 0
4th row is translation
so instead of doing
sgMat4 sgTRANS;
sgMakeTransMat4( sgTRANS, pilot_view->get_view_pos() );
and then later
sgPostMultMat4( sgTUX, sgTRANS )
you can almost always just do this instead
sgSetVec4(sgTUX[3],
pilot_view->get_view_pos()[0],
pilot_view->get_view_pos()[1],
pilot_view->get_view_pos()[2],
1.0);
Another thing to keep in mind is that the rotation matrix
is the upper 3x3 block of the 4x4 matrix and that the inverse
of a 'pure rotation' is just it's transpose
ie if v' = Av then v = -Av'
where ' = 'primed' and - = 'Inverse'
See sgTransposeNegateMat4() is sg.cxx
Another optimization trick is tht something like
sgVec3 ownship_up;
sgSetVec3( ownship_up, 0.0, 0.0, 1.0);
sgMat4 sgROT;
sgMakeRotMat4( sgROT, -90.0, ownship_up );
is going to turn into something like
sgMat ownship;
ownship[0][0] = 0 ;
ownship[0][1] = -1 ;
ownship[0][2] = 0 ;
ownship[0][3] = 0 ;
ownship[1][0] = 1 ;
ownship[1][1] = 0 ;
ownship[1][2] = 0 ;
ownship[1][3] = 0 ;
ownship[2][0] = 0 ;
ownship[2][1] = 0 ;
ownship[2][2] = 1 ;
ownship[2][3] = 0 ;
ownship[3][0] = 0 ;
ownship[3][1] = 0 ;
ownship[3][2] = 0 ;
ownship[3][3] = 0 ;
because the sin and cosine terms are going to be
one of 0, 1, -1
This in turn can be used to 'tweak' a series of Matrix Multiplies
in that most of the terms either just dissapear or merely change sign
For example
using this technique on the model annimation matrix stuff removed
around a hundred assignments and/or fpu ops per moving part :-)
Same kind of trick can be seen in tileentry.cxx -- WorldPosition()
>Also if someone could help me understand how the quats relate to
rotation/axis
>or compare to matrixes. Guess I'm not quite sure how as Norman said, using
>quats would have helped here
quats wouldn't necessarily help you here BUT THEY help earlier in the
pipeline creating the 'eye rotation' matrix from it's various contributors
joystick mouse keyboard ect
FWIW untested but should work
void HeadingPitchToMat(sgMat4 dst, const float heading, const float pitch )
{
sgQuat q;
float cp = (float) cos(pitch*SG_DEGREES_TO_RADIANS/SG_TWO);
float sp = (float) sin(pitch*SG_DEGREES_TO_RADIANS/SG_TWO);
float ch = (float) cos(heading*SG_DEGREES_TO_RADIANS/SG_TWO);
float sh = (float) sin(heading*SG_DEGREES_TO_RADIANS/SG_TWO);
q[SG_W] = 0;
q[SG_X] = ch - (sp * sh);
q[SG_Y] = sp * ch
q[SG_Z] = cp * sh;
SGfloat two_xx = q[SG_X] * (q[SG_X] + q[SG_X]) ;
SGfloat two_xy = q[SG_X] * (q[SG_Y] + q[SG_Y]) ;
SGfloat two_xz = q[SG_X] * (q[SG_Z] + q[SG_Z]) ;
SGfloat two_yy = q[SG_Y] * (q[SG_Y] + q[SG_Y]) ;
SGfloat two_yz = q[SG_Y] * (q[SG_Z] + q[SG_Z]) ;
SGfloat two_zz = q[SG_Z] * (q[SG_Z] + q[SG_Z]) ;
sgSetVec4 ( dst[0], SG_ONE-(two_yy+two_zz), two_xy, two_xz, SG_ZERO ) ;
sgSetVec4 ( dst[1], two_xy, SG_ONE-(two_xx+two_zz), two_yz, SG_ZERO ) ;
sgSetVec4 ( dst[2], two_xz, two_yz, SG_ONE-(two_xx+two_yy), SG_ZERO ) ;
sgSetVec4 ( dst[3], SG_ZERO, SG_ZERO, SG_ZERO, SG_ONE ) ;
}
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hack for Virtual cockpit problem
Norman Vine wrote: > David Megginson wrote: > > Thanks -- the internal cockpit view seems much better. Now the ball's > > in Andy's court to patch up the virtual panel code (and de-quat the > > mouse code), and we're flying! > > exactly the kind of response that led me to coin the phrase > > "MAYDAY MAYDAY FlightGear has been hijacked" Whoa there, boys. :) First, to be fair, the issue isn't the dequating of anything. For the record, quaternions are a perfectly useful and reasonable representation of orientations and rotations and are the appropriate choice for many applications. They are not magic bullets, however, and perfectly useful and reasonable applications have been and will be written without either quaternions or the bugs and unintended interactions (gimble lock being the only big one) that you get from naive application of euler-space representations. End of story? What I need/plan to do, (once over the motivational humps -- it's a pretty daunting task) is take the responsibility for orientation management *out* of the mouse code, and the model code, and the main loop, and put it somewhere safe, where it can be modified sanely (that is, with rotate/pitch/heading eulers) by a front end interface and read sanely (as a matrix) by back end clients. Right now, the difference between "model orientation" and "viewpoint orientation" is terribly muddled, and mixed in with things like "local orientation" (the FDM term -- the view code calls is "UP", I think) that aren't very useful to anyone. For a quickie example, look at the places in the code that read the view_offset and view_tilt stuff. These are the values that represent the direction of the pilot's head, and as such should be used only by the core view code to decide on a view direction for the 3D projection. But because of the way things grew, they are also read by places like the panel (my fault), ADA FDM (no idea there), lighting code (!), and main loop. These places don't care about the difference between the pilot's head and aircraft frame -- they just want to know the ultimate direction of the view. Well, except for the panel, which rightfully should just draw in the aircraft frame and not worry about view direction at all -- my current code essentially does things backwards, because those values could be read from the FGViewer object and set via properties, while the mouse quat couldn't. I know there are egos at stake, and I'm certain that I (or David, or Curt, or Jim Wilson, or...) won't make the same choices that Norman would have. And I'm equally certain that some working code is going to get chopped out simply because I don't understand it as well as I would my own. But the plain truth is that we have a pretty severe code growth situation here, and there aren't any "simple" solutions. If we pick Norms solution (which would work perfectly well), we still have to take a machete to the rest of the code to extricate the euler angles. 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] Hack for Virtual cockpit problem
> It's still a little weird with a steep roll angle. Found an article on > quarternions. It seems that they can be used to solve the problem of the > rotation being off center. Not sure yet how to apply it to this problem. > Maybe if we can feed it an axis that appears a little behind the > origin, apply the euler pitch, and convert it to a rotation matrix it'll > move more realistically: This might be helpful from the JSBSim site: http://jsbsim.sourceforge.net/quaternions.html Jon Jon Berndt Coordinator, JSBSim Project http://jsbsim.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Hack for Virtual cockpit problem
David Megginson writes: >(and de-quat the mouse code) exactly the kind of response that led me to coin the phrase "MAYDAY MAYDAY FlightGear has been hijacked" ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hack for Virtual cockpit problem
David Megginson <[EMAIL PROTECTED]> said: > Jim Wilson writes: > > > This seems to pretty much correct the problem. Part of the problem > > is that rotations are occuring at the firewall (model origin) which > > seems a little un-natural inside the cockpit. The rest of the > > problem is I am just learning how this stuff works (I know I've > > been saying this for a couple months now...but hey I'm slow :-)). > > Thanks -- the internal cockpit view seems much better. Now the ball's > in Andy's court to patch up the virtual panel code (and de-quat the > mouse code), and we're flying! > It's still a little weird with a steep roll angle. Found an article on quarternions. It seems that they can be used to solve the problem of the rotation being off center. Not sure yet how to apply it to this problem. Maybe if we can feed it an axis that appears a little behind the origin, apply the euler pitch, and convert it to a rotation matrix it'll move more realistically: http://www.gamedev.net/reference/articles/article1691.asp#Q47 Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Hack for Virtual cockpit problem
Jim Wilson writes: > This seems to pretty much correct the problem. Part of the problem > is that rotations are occuring at the firewall (model origin) which > seems a little un-natural inside the cockpit. The rest of the > problem is I am just learning how this stuff works (I know I've > been saying this for a couple months now...but hey I'm slow :-)). Thanks -- the internal cockpit view seems much better. Now the ball's in Andy's court to patch up the virtual panel code (and de-quat the mouse code), and we're flying! All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
David Megginson wrote:
> Jon S Berndt writes:
>
> > I like this new capability. I ought to be able to plot the
> > logged data out of the box with my simplot program. As for
> > some other formats, I wonder if someone might provide a
> > couple of perl scripts to do conversions rather than place
> > that burden on FlightGear.
>
> It's easy enough to make the delimiter user-selectable; beyond that, I
> agree that we shouldn't make the logger complicated. In particular,
> I'm not escaping any delimiters that appear in property values, to
> avoid too much processing overhead (and because I'm lazy).
Wasn't the default to just place the string value inside quotes ("")?
That way comma's doen't matter.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Compile failure of latest CVS
* David Megginson -- Tuesday 12 March 2002 19:42: > Apologies -- I'll shrink that. I *think* it's in range for a signed > 64-bit integer, but I'm too lazy to check. Why not -1? Isn't that a sufficiently invalid number of seconds since program start? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How can JSBSim start in the air with a stable manner?
>aerodynamics/Flight control(and so on) are not so easy to >me. One of the so many problems is that >How can I initialize the airplane in the air in a stable >manner when JSBSim running in standalone mode? >It seems that FGTrim can accomplish that. But I do NOT >know how to use it! Greetings! I am forwarding a copy of this email to Tony Peden. Hw wrote the Trim code, so perhaps he can describe how best to use it. We do have documentation on the JSBSim web site. Go to jsbsim.sf.net and select the "Documentation" or "Docs" link. There you will find several links to helpful information. Once you read through these, please contact Tony for more help on trimming. As for trimming in standalone mode, this is not quite implemented, yet. I want to do this, but this particular capability is not quite ready, yet. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
Jon S Berndt writes: > I like this new capability. I ought to be able to plot the > logged data out of the box with my simplot program. As for > some other formats, I wonder if someone might provide a > couple of perl scripts to do conversions rather than place > that burden on FlightGear. It's easy enough to make the delimiter user-selectable; beyond that, I agree that we shouldn't make the logger complicated. In particular, I'm not escaping any delimiters that appear in property values, to avoid too much processing overhead (and because I'm lazy). JSBSim and YASim may choose to expose more of their internals though the property tree now, so that they can be logged (especially YASim, which doesn't already have its own logging feature). I think that the internals should be partitioned by FDM, since each FDM does things its own way; for example, JSBSim could use /fdm/jsbsim/ and YASim could use /fdm/yasim/ as roots, then use whatever properties and formats they want; for example, JSBSim might expose coefficients, while YASim has none to expose. No negotiation require -- do your own things, guys. Perhaps later we might think of common properties for very common stuff like forces and moments. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
David Megginson <[EMAIL PROTECTED]> said: > FlightGear now has the ability to produce multiple logs, each > recording the value of user-selected properties at a user-defined > interval. Details are available in docs-mini/README.logging; Here's > a simple example that logs the rudder and aileron positions to > steering.csv every second or so: > > > >steering.csv >1000 > > Rudder > /controls/rudder > > > Ailerons > /controls/aileron > > > > > Here's some sample output: > > Time,Rudder,Ailerons > 6522,0.00,0.00 > 7668,-0.00,0.00 > 8702,-0.00,0.00 > 9705,-0.00,0.00 > 10784,-0.00,0.00 > 11792,-0.00,0.00 > 12808,-0.00,-0.21 > 13826,-0.00,-0.344000 > 14881,-0.00,-0.066000 > 15901,-0.00,-0.806000 > 16943,-0.00,-0.936000 > 17965,-0.00,-0.534000 > 19013,-0.00,-0.294000 > 20044,-0.00,0.27 > 21090,-0.00,-1.00 > 22097,-0.00,-0.168000 > Cool! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Compile failure of latest CVS
D Luff writes: > Cygwin compile of latest CVS fails in logger.cxx, complaining that > an integer constant is out of range in line 101: > > last_time_ms(-99L) Apologies -- I'll shrink that. I *think* it's in range for a signed 64-bit integer, but I'm too lazy to check. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Compile failure of latest CVS
* Melchior FRANZ -- Tuesday 12 March 2002 19:34: > * D Luff -- Tuesday 12 March 2002 18:08: > > last_time_ms(-99L) > > Yeah, that's a little bit too much for a "long". At least for a 32 bit long. :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Compile failure of latest CVS
* D Luff -- Tuesday 12 March 2002 18:08: > Cygwin compile of latest CVS fails in logger.cxx, complaining that > an integer constant is out of range in line 101: > > last_time_ms(-99L) Yeah, that's a little bit too much for a "long". Shouldn't "-1" be the obvious choice for the initial last_time_ms? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] black and white flightgear
"Curtis L. Olson" wrote: > > Roman Grigoriev writes: > > Guys > > could you please advice me how to make flightgear in black and white pallete > > maybe framebuffer operation helps me? > > if someone covert or render black&white image in OGL please help me > > There might be a clever solution I don't know about, but a brute force > start would be to convert all the textures used by the program to a > grey scale pallete ... IMHO that's the best solution. If you need additional noise over it you can place a glQuad with a noise texture over the whole screen. CU, Christian PS: If you try to generate an infra red view it's *much* more complicated than that. But for a normal vision "bomb camera" it should be fine. -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compile failure of latest CVS
Cygwin compile of latest CVS fails in logger.cxx, complaining that an integer constant is out of range in line 101: last_time_ms(-99L) Cheers - Dave -- [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] How can JSBSim start in the air with a stable manner?
I have learned JSBSim for quite a long time. The aerodynamics/Flight control(and so on) are not so easy to me. One of the so many problems is that How can I initialize the airplane in the air in a stable manner when JSBSim running in standalone mode? It seems that FGTrim can accomplish that. But I do NOT know how to use it! I found that you have discussed this problem in last year. http://www.menet.umn.edu/~curt/lists/fgfs/archive-200101/msg00404.html But I seems that no result about the discussion. I have read some of the JSBSim source, but still do not know how to solve the problem. Could you give me some idea about that? Thanks for your patience! Dirty Bear ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Property Logging
For the people who don't use the CSV format, it would be handy to have a tag that switches over to TSV format. Gnuplot and Octave, for example are much happier with tab separation - I don't have to mention the commas. > FlightGear now has the ability to produce multiple logs, each > recording the value of user-selected properties at a user-defined > interval. Details are available in docs-mini/README.logging; Here's > a simple example that logs the rudder and aileron positions to > steering.csv every second or so: > > > >steering.csv >1000 > > Rudder > /controls/rudder > > > Ailerons > /controls/aileron > > > > > Here's some sample output: > > Time,Rudder,Ailerons > 6522,0.00,0.00 > 7668,-0.00,0.00 > 8702,-0.00,0.00 > 9705,-0.00,0.00 > 10784,-0.00,0.00 > 11792,-0.00,0.00 > 12808,-0.00,-0.21 > 13826,-0.00,-0.344000 > 14881,-0.00,-0.066000 > 15901,-0.00,-0.806000 > 16943,-0.00,-0.936000 > 17965,-0.00,-0.534000 > 19013,-0.00,-0.294000 > 20044,-0.00,0.27 > 21090,-0.00,-1.00 > 22097,-0.00,-0.168000 > > > All the best, > > > David > > -- > David Megginson > [EMAIL PROTECTED] > > > ___ > 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] ANN: Property Logging
FlightGear now has the ability to produce multiple logs, each recording the value of user-selected properties at a user-defined interval. Details are available in docs-mini/README.logging; Here's a simple example that logs the rudder and aileron positions to steering.csv every second or so: steering.csv 1000 Rudder /controls/rudder Ailerons /controls/aileron Here's some sample output: Time,Rudder,Ailerons 6522,0.00,0.00 7668,-0.00,0.00 8702,-0.00,0.00 9705,-0.00,0.00 10784,-0.00,0.00 11792,-0.00,0.00 12808,-0.00,-0.21 13826,-0.00,-0.344000 14881,-0.00,-0.066000 15901,-0.00,-0.806000 16943,-0.00,-0.936000 17965,-0.00,-0.534000 19013,-0.00,-0.294000 20044,-0.00,0.27 21090,-0.00,-1.00 22097,-0.00,-0.168000 All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] black and white flightgear
On Tue, 12 Mar 2002 17:48:53 +0300 "Roman Grigoriev" <[EMAIL PROTECTED]> wrote: >this is not suitable for me >in addition I need to aply noise on this black and white >image Intriguing. Can you tell us what this is about? I have a hunch. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] black and white flightgear
Guys could you please advice me how to make flightgear in black and white pallete maybe framebuffer operation helps me? if someone covert or render black&white image in OGL please help me Thanx Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgReshape
On Tue 12. March 2002 14:27, you wrote: > > -Original Message- > > From: Martin Dressler [mailto:[EMAIL PROTECTED]] > > Sent: 12 March 2002 12:48 pm > > To: [EMAIL PROTECTED] > > Subject: Re: [Flightgear-devel] fgReshape > > > > On Mon 11. March 2002 09:12, you wrote: > > > * [EMAIL PROTECTED] (Martin Dressler) [2002.03.11 01:51]: > > > > I find that we call fgReshape function in each > > > > RenderFrame, and it is > > > > > > IMHO needless. When you remove fgReshape from fgRenderFrame all > > > > resizing works, you only can't change resolution via > > > > property manager. > > > > > > But do we need it? > > > > Do you have some objection, before I send a patch. > > > > > > I can't really answer you question, but it was added to main.cxx in > > > revision 1.40 with a comment about external views. When you take it > > > out, does it break the external views? > > > > No :-) > > > > As I sad, you only can't change resolution via window > > property manager. > > But do we need it? > > Does changing resolution equate to changing the window size? If so, > could we trap a window resize and call fgReshape only in that case? > > Richard > Yes, you are right. It is done automagicaly by glut. when you register fgReshape as reshape function. Madr ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
On Mon 11. March 2002 18:21, you wrote: > Martin Dressler writes: > > There are some diferents how the viewer is initialized and from > > where it take new position. Your viewpoint could be static or > > change position or (and) up vector in some dependency on FDM or > > maybe time. > > Right, but none of that's the viewer's concern. As long as something > (probably the view manager) tells each viewer every frame what the > location(s), orientation(s), and offset(s) are, the viewer doesn't > have to know anything else -- it can calculate all of its matrices and > vectors from that. Hmm I'm more conservative on it. Yeah you are right about viewer class. It should take two points (to define point and vector) or point and vector (camera pos and view dir.) and calculate all of its matrices and vectors from that. I suggest initializing and updating of this pair in some class inherited from viewer class or move viewer class to some new class and make it property of instance. Let viewer manager only to build field of this views and swap between them. Sorry, My English isn't so good to say it correct. IMHO we both thing about the same and I only suggest keep viewmgr class as simple as possible and do all work in specialized classes inherited from some fgview class. fgview class needn't to be the same what we call viewer here. > > > IMHO the view also should control if panel, hud or virtual cockpit > > is used. and if it preserve state if you switch to another view > > and then return back. > > I disagree -- the view code gets *very* hard to understand very > easily. If that information is tracked, it should be tracked > externally (the view manager, again?) and not in the viewer code > itself. Yes, give this information to some fgview class, cause it belong there. > > The viewer code has to do some very complicated matrix and vector > math, and if we have any hope of being able to maintain the code in > the future, we need to keep it as simple as possible. The best > arrangement I can think of is isolating all of the actual view > transformation code in the viewer class, and all of the > FlightGear-related stuff in the view manager class. That way, person > A who knows nothing about matrix math can design new views, etc., and > person B who knows little about the rest of FlightGear, properties, > etc. can optimize the matrix math, etc. Maybe I agree with you but only view manager is something other for me :) > > > All the best, > > > David Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] fgReshape
> -Original Message- > From: Martin Dressler [mailto:[EMAIL PROTECTED]] > Sent: 12 March 2002 12:48 pm > To: [EMAIL PROTECTED] > Subject: Re: [Flightgear-devel] fgReshape > > > On Mon 11. March 2002 09:12, you wrote: > > * [EMAIL PROTECTED] (Martin Dressler) [2002.03.11 01:51]: > > > I find that we call fgReshape function in each > RenderFrame, and it is > > > IMHO needless. When you remove fgReshape from fgRenderFrame all > > > resizing works, you only can't change resolution via > property manager. > > > But do we need it? > > > Do you have some objection, before I send a patch. > > > > I can't really answer you question, but it was added to main.cxx in > > revision 1.40 with a comment about external views. When you take it > > out, does it break the external views? > > No :-) > > As I sad, you only can't change resolution via window > property manager. > But do we need it? > Does changing resolution equate to changing the window size? If so, could we trap a window resize and call fgReshape only in that case? Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgReshape
On Mon 11. March 2002 09:12, you wrote: > * [EMAIL PROTECTED] (Martin Dressler) [2002.03.11 01:51]: > > I find that we call fgReshape function in each RenderFrame, and it is > > IMHO needless. When you remove fgReshape from fgRenderFrame all > > resizing works, you only can't change resolution via property manager. > > But do we need it? > > Do you have some objection, before I send a patch. > > I can't really answer you question, but it was added to main.cxx in > revision 1.40 with a comment about external views. When you take it > out, does it break the external views? No :-) As I sad, you only can't change resolution via window property manager. But do we need it? Regards, Madr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Build Failure with Newest fg_sound.?xx
Jonathan Polley wrote:
> Changing the data structure to read:
>
>
> static const struct {
> char * name;
> double (*fn)(double);
> } __fg_snd_fn[] = {
>
> caused everything to work properly. I know that this is not the proper C+
> + solution, but it worked for me.
This seems appropriate. I'll include this fix in an update I'll sent
later today.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
