Re: [Flightgear-devel] Rationalizing view
Michael, What you are observing isn't exactly how you describe, although it appears that way. I was trying to simplify things by just pointing out that the aircraft stays horizontal (appears to not roll) in the chase view, but that isn't exactly how it works. The difference is that the xyz offsets to the eye position are applied in relation to a vector that is perpendicular to the aircraft in the cockpit view and perpendicular to the ground, that is in relation to the earth (radial from center of earth or world up) in the chase view. Since in both cases the same rotations are applied to the model, then you are seeing the effect of the difference in how the eye is positioned. The axis going to the right, is always in relation to the model (the aircraft orientation). The effect of this is as follows: In the case where the camera is offset in relation to world up (as in chase view) then the horizon doesn't move to pitch looking forward and doesn't move to roll looking sideways. Draw a picture for yourself and you can see what I'm talking about. In the case of chase view make the up axis that the eye is on parallel to a line that goes through the aircraft and is always perpendicular to the ground. However, let the eye rotate right and left with the model. This is not roll I'm talking about only rotation of the axis that the eye is on (can be due to pitch or roll or both). Anyway, this is why I suggested that you set the offset way back in the 3d cockpit view so that you were following the aircraft in cockpit view. When I get done with the first pass on the configurable viewer, experiment with that as well. Then we can go from there. Best, Jim That's why I suggested setting your z-offset way back behind the aircraft. Best, Jim Michael Selig [EMAIL PROTECTED] said: 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
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
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
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
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] Rationalizing view
On Sat 9. March 2002 20:36, 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). 3. Looking from one known position towards another. 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. 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. 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 need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera. Comments? Volunteers? I think that the easiest solution is probably a clean rewrite, but paying close attention to how Norm used the matrices and vectors in the original. 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 think that we should write down the properties tree first and then make new view class. There is also question if support command line parametrs for changing view parametrs and how. I started some coding and found all places where viewer is hardcoded. But total rewrite of view class is IMHO out of my programing skill, specially unlink scenery from FDM position :-( 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] Rationalizing view
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. 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. 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. 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] Rationalizing view
David Megginson wrote: 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. Amen. I spent many hours over the weekend trying to make the view code work in the presence of the virtual cockpit without breaking everything, and got essentially nowhere. I can think of only one or two other times in my career that I've been so befuddled by code. :) 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. This sounds best. Ultimately, the view is just a tuple with six degrees of freedom. The front-end code would feed these numbers via the appropriately complicated mechanism (aircraft phi/theta/psi plus view offset/tilt, for example), but clients would only care about the final numbers, and not the intermediary stuff. Right now, everyone has to agree on everything. There are *lots* of places where the external view is hard-coded as the second view, for example, because it has to be interpreted specially. In practice, everyone only sort of agrees. So most stuff works, until something (virtual cockpit) comes along that wants to interpret the existing numbers in a new way, and boom. I'm going to try tackling the back-end rewrite -- the code that takes view and presents it to the various clients in a consistent way. This is going to touch a lot of stuff, but should result mostly in code removal. Which brings up a good question to ask: can someone provide a quickie overview of the various coordinate systems? I've read the coordinates document, which is good, but incomplete. Really, what I want is a list of all the things that are going to be drawn, and what they expect the modelview matrix (er, plib matrix state, rather) to look like. Specifically, does scenery draw using global cartesian coordinates? Some comments seem to imply that, but I'm dubious -- these would require doubles throughout the matrix pipeline for sufficient precision. Likewise, what are the conventions for the aircraft model? I *think* that it's X-back, Y-right, Z-down, but I'm not sure. Could someone verify? And can someone tell me what the deal is with plib coordinates? I was browsing through the source code and stumbled on a very frightening-looking axis swap matrix (its existence was frightening, the axis swap is obviously trivial) that gets applies in various situations. Are plib coordinates different from OpenGL ones? Eek. 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] Rationalizing view
Michael Selig writes: With respect to the chase view (2), three potential options come to mind: These are excellent suggestions, but I think that we'll want them to end up in the view manager (or elsewhere) rather than in the viewer proper. As long as we tell the viewer, for each frame, what its reference point, orientation, offsets, etc. are, it doesn't need to know whether we're modelling a control tower, chase view, etc. Eventually we might even control some of the views through external scripting. 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] Rationalizing view
David Megginson [EMAIL PROTECTED] said: 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. At first look this doesn't seem all that bad. The hardest part is going to be cleaning up the hard coded bits out there. The routines basically all produce the same thing with different methods which helps. Right now what I need to do is map out all the calculations that are being applied and will come up with a proposal to post here. But it should be too bad once I get my head around the whole thing. Basically what I'm going to look at is modularizing the calculation for each matrix component (camera, center, up) so that new methods like some of what Michael described can be easily added. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
Jim Wilson writes: At first look this doesn't seem all that bad. The hardest part is going to be cleaning up the hard coded bits out there. Here are most of the required outputs, from an analysis I did earlier: - the VIEW matrix, a matrix containing the transformations to put the view in the correct position and orientation (as as the argument to ssgSetCamera) - the UP matrix, rotation matrix to the current notion of up (opposite of gravity) - the current absolute view position in fgfs coordinates - the current view position in fgfs coordinates, relative to the scenery center - the world-up vector - the surface-east vector - the surface-south vector All of the others are byproducts of the VIEW calculation, used for convenience by various bits of the code. The routines basically all produce the same thing with different methods which helps. Right now what I need to do is map out all the calculations that are being applied and will come up with a proposal to post here. But it should be too bad once I get my head around the whole thing. Basically what I'm going to look at is modularizing the calculation for each matrix component (camera, center, up) so that new methods like some of what Michael described can be easily added. Yes, I've been playing with some of that myself. You'll see that I've already moved some of the common code into the temporary FGViewPoint class -- it gets as far as calculating the absolute and relative view position and the world-up vector. 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] Rationalizing view
David Megginson [EMAIL PROTECTED] said: 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). 3. Looking from one known position towards another. 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 need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera. Comments? Volunteers? I think that the easiest solution is probably a clean rewrite, but paying close attention to how Norm used the matrices and vectors in the original. This sounds interesting. Let me think about it for a bit and come back with sample properties in xml format. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
