[Flightgear-devel] RFC: changes to views and cameras
Hi, I'd like your comments on some changes to views and OSG cameras in FlightGear before I start working on them. In particular, my understanding of how FGViewer works might not be complete. What we have now FGViewer calculates the parameters of a view. This includes camera-independent parameters such as the view origin and direction. These parameters are calculated differently based on, among other things, whether the viewpoint is tied to a model and whether the view direction is fixed, relative to a model, or always tracking another model. FGViewer filters and dampens some of these parameters. FGViewer also controls some basic camera parameters such as the field of view (fov) and a modification of the camera aspect ratio called the aspect ratio multiplier. There is only one active FGViewer object at a time. This is managed by FGViewMgr and is accessed using get_current_view(). The origin of the current view is used by the tile manager to make sure that visible scenery is loaded. Each frame, code in Main/renderer.cxx uses the current view to update the Open Scene Graph cameras. The arrangement of the OSG cameras is dictated by the osgViewer::Viewer class that we use to render the view on the scene. There is one master camera with several attached slave cameras. The master camera sets principal view (position, orientation) and projection (the frustum) parameters. The slaves can either specify additional transforms to those parameters, in both model-view and projection space, or they can be absolute in their own right. Currently the out the window views are rendered in relative slave cameras, while the GUI and HUD are drawn in an absolute slave. Slave cameras are created using properties in preferences.xml. One slave is always created that is aligned with the viewing parameters of the master camera. Others can be opened in different graphics windows, possibly on other displays and screens. A slave camera is presently created in its own window. Parameters for the slave are currently pretty limited; they include the dimensions and position of the window, shear values in projection space, and heading-deg, a heading offset that I suspect was added specifically for LinuxTag :) The shear-x and shear-y values are really only useful for setting up a video wall type display where monitors arranged around the master view show a view in an offset frustum with the same aspect ratio and fov as the master. Problems With the Current Approach Many features are not now possible using only a single running instance of FlightGear. There can't be more than one view at a time. It would be nice to keep the principal out the window view around -- in order to fly the aircraft -- while having inset model views, tower views, missile-cam views, an a340 tail-strike view, etc. Our OSG camera creation procedure is completely insufficient for many things that people want to do with FlightGear. The requirement that slave cameras be opened in different graphics windows doesn't match well the most common multi-head graphics hardware. Most people are using a setup that drives several monitors with one graphics card, such as the Nvidia TwinView or Matrox 2Go products. These configurations work best with a single graphics window that spans all the monitors; the graphics context switches needed to render to different windows on the same graphics card are expensive. The camera parameters we support are not sufficient to specify monitors arranged around a cockpit for a real out-the-window view, to say nothing of views projected onto a screen or dome. Furthermore, for those configurations the FGViewer should never be able to change the field of view or other camera parameters. Proposal Define a CameraGroup object that is the bridge between an FGViewer and the OSG cameras that render the view. An FGViewer points to one CameraGroup, and only one active view can drive a CameraGroup at a time. The CameraGroup manipulates osg::Camera objects as necessary. Subclasses of CameraGroup might not respond to FGViewer requests to change camera parameters. Extend the camera creation options in preferences.xml to specify named CameraGroup objects. Allow the specification of graphics windows to which slave cameras in CameraGroup objects are assigned. Allow the full specification of viewing parameters -- position, orientation -- either as relative to a master camera or independent. Allow the camera parameters to be specified relative to the master, as they are now, or independently. The camera parameters can be specified using the Clotho / glFrustum scheme (top, bottom, left, right) or a syntax used by ProjectionDesigner (http://orihalcon.jp/projdesigner/) that uses field of view, aspect ratio, and offset. A full 4x4 matrix can also be specified. Camera groups can be created and destroyed on the fly; the CameraGroup will create OSG cameras as necessary and attach them to the proper graphics window. A camera group named default-camera-group will
Re: [Flightgear-devel] RFC: changes to views and cameras
Tim Moore wrote Sent: 26 June 2008 11:53 To: FlightGear developers discussions Subject: [Flightgear-devel] RFC: changes to views and cameras Hi, I'd like your comments on some changes to views and OSG cameras in FlightGear before I start working on them. In particular, my understanding of how FGViewer works might not be complete. What we have now FGViewer calculates the parameters of a view. This includes camera-independent parameters such as the view origin and direction. These parameters are calculated differently based on, among other things, whether the viewpoint is tied to a model and whether the view direction is fixed, relative to a model, or always tracking another model. FGViewer filters and dampens some of these parameters. FGViewer also controls some basic camera parameters such as the field of view (fov) and a modification of the camera aspect ratio called the aspect ratio multiplier. There is only one active FGViewer object at a time. This is managed by FGViewMgr and is accessed using get_current_view(). The origin of the current view is used by the tile manager to make sure that visible scenery is loaded. Each frame, code in Main/renderer.cxx uses the current view to update the Open Scene Graph cameras. The arrangement of the OSG cameras is dictated by the osgViewer::Viewer class that we use to render the view on the scene. There is one master camera with several attached slave cameras. The master camera sets principal view (position, orientation) and projection (the frustum) parameters. The slaves can either specify additional transforms to those parameters, in both model-view and projection space, or they can be absolute in their own right. Currently the out the window views are rendered in relative slave cameras, while the GUI and HUD are drawn in an absolute slave. Slave cameras are created using properties in preferences.xml. One slave is always created that is aligned with the viewing parameters of the master camera. Others can be opened in different graphics windows, possibly on other displays and screens. A slave camera is presently created in its own window. Parameters for the slave are currently pretty limited; they include the dimensions and position of the window, shear values in projection space, and heading-deg, a heading offset that I suspect was added specifically for LinuxTag :) The shear-x and shear-y values are really only useful for setting up a video wall type display where monitors arranged around the master view show a view in an offset frustum with the same aspect ratio and fov as the master. Problems With the Current Approach Many features are not now possible using only a single running instance of FlightGear. There can't be more than one view at a time. It would be nice to keep the principal out the window view around -- in order to fly the aircraft -- while having inset model views, tower views, missile-cam views, an a340 tail-strike view, etc. Our OSG camera creation procedure is completely insufficient for many things that people want to do with FlightGear. The requirement that slave cameras be opened in different graphics windows doesn't match well the most common multi-head graphics hardware. Most people are using a setup that drives several monitors with one graphics card, such as the Nvidia TwinView or Matrox 2Go products. These configurations work best with a single graphics window that spans all the monitors; the graphics context switches needed to render to different windows on the same graphics card are expensive. The camera parameters we support are not sufficient to specify monitors arranged around a cockpit for a real out-the-window view, to say nothing of views projected onto a screen or dome. Furthermore, for those configurations the FGViewer should never be able to change the field of view or other camera parameters. Proposal Define a CameraGroup object that is the bridge between an FGViewer and the OSG cameras that render the view. An FGViewer points to one CameraGroup, and only one active view can drive a CameraGroup at a time. The CameraGroup manipulates osg::Camera objects as necessary. Subclasses of CameraGroup might not respond to FGViewer requests to change camera parameters. Extend the camera creation options in preferences.xml to specify named CameraGroup objects. Allow the specification of graphics windows to which slave cameras in CameraGroup objects are assigned. Allow the full specification of viewing parameters -- position, orientation -- either as relative to a master camera or independent. Allow the camera parameters to be specified relative to the master, as they are now, or independently. The camera parameters can be specified using the Clotho / glFrustum scheme (top, bottom, left, right) or a syntax used by ProjectionDesigner (http://orihalcon.jp/projdesigner/) that uses field of view, aspect ratio, and offset. A full 4x4
[Flightgear-devel] icons
Someone from Debian just pointed out to me that the icon set I made is no longer available at my old website (defunct), and I don't have a new one to post them on ATM. Perhaps they should be included in the distribution like data/icons. I sent the Debian guy a tarball but in the future it would be nice if they were easier for package maintainers to find. If someone wants to do this, let me know and I will send you the tarball. Josh - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: changes to views and cameras
On Thu, 26 Jun 2008 14:23:23 +0100 Vivian Meazza [EMAIL PROTECTED] wrote: Tim Moore wrote Sent: 26 June 2008 11:53 To: FlightGear developers discussions Subject: [Flightgear-devel] RFC: changes to views and cameras Hi, I'd like your comments on some changes to views and OSG cameras in FlightGear before I start working on them. In particular, my understanding of how FGViewer works might not be complete. ... It all looks well thought through and comprehensive ... BUT what's the likely/possible impact on framerate? There's little enough to spare on all but the most modern and capable machines already. Of course if there is significant negative impact on the frame rate that would be Comprehensive Rational And Purposeful ... For the configurations supported today, there will be no change in frame rate. Some multihead configurations i.e., multiple monitors on one card, will be faster. If you load up your display with different views, the frame rate will probably be lower :) Tim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: changes to views and cameras
Hi, at least from my point it sounds good and resonable. These are features really missing and will not only keep FlightGear up to date aganinst the commercial sims- it will make it better. This proposal is a little vague; the specifics need to be worked out when the CameraGroup is implemented and FGViewer is changed to use it. But I wonder how long you need for all this, and what happens to all the other things you announced? Shadows, shader library... I know you are the only one in the moment beside Till Busch and Stuart ??? who are working on the OSG-part of FlightGear. Don't understand me wrong: these changes you want to do are important, so we can be very lucky having someone like you working on that. ... Future Possibilities. The cameras in a camera group don't need to render directly to the screen. They can render to a texture which can be used either in the scene, like in a video screen in the instrument panel, or for distortion correction in a projected or dome environment. Open Scene Graph supports a CompositeViewer object that supports rendering from several widely separated viewpoints, complete with support for multiple terrain pager threads. We could move to CompositeViewer and support simultaneous views from e.g., the tower, AI models, drones, etc. Yes, that are rhings very important. So from my point of view as mostly user and 3d-modeller there is nothing against as long the perfomance doesen't decrease too much. Regards HHS __ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Is YASim a blade element theory model?
Hi, Thank you for answering my last question and it was really helpful. I have another question on the Flight Dynamic Models YASim. Can I say YASim is a Blade Element Theory Model? If not, what kind of model is that. For example, a total forces and moments theory model or kinematic model. BTW, from the documentation of JSBsim, I would say that is also a total forces and moments theory model, right? Thanks again for all your help. Sophia Wong - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: changes to views and cameras
On Thu, 26 Jun 2008 16:23:03 + (GMT) Heiko Schulz [EMAIL PROTECTED] wrote: Hi, at least from my point it sounds good and resonable. These are features really missing and will not only keep FlightGear up to date aganinst the commercial sims- it will make it better. This proposal is a little vague; the specifics need to be worked out when the CameraGroup is implemented and FGViewer is changed to use it. But I wonder how long you need for all this, and what happens to all the other things you announced? Shadows, shader library... I know you are the only one in the moment beside Till Busch and Stuart ??? who are working on the OSG-part of FlightGear. Don't understand me wrong: these changes you want to do are important, so we can be very lucky having someone like you working on that. ... True enough, but I have a specific short-term need for the camera work. My work on the shader support for shadows is proceeding, albeit slowly. If anyone else feels like they want to dive into it, I'm happy to shift gears into mentor mode on that. Tim - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is YASim a blade element theory model?
I don't know about YASim, but I am in the process of digging through JSBSim in an effort to extract the mathematical model. To me it does appear the JSBSim is a total forces and moments theory model. You may want to see the following bits of the JSBSim documentation: FGForce class: http://jsbsim.sourceforge.net/JSBSim/classJSBSim_1_1FGForce.html FGAircraft class: http://jsbsim.sourceforge.net/JSBSim/classJSBSim_1_1FGAircraft.html FGPropgate class: http://jsbsim.sourceforge.net/JSBSim/classJSBSim_1_1FGPropagate.html These papers are also referenced by the JSBSim docs, and may help you(you can get them all for free online): Cooke, Zyda, Pratt, and McGhee, NPSNET: Flight Simulation Dynamic Modeling Using Quaternions, Presence, Vol. 1, No. 4, pp. 404-420 Naval Postgraduate School, January 1994 D. M. Henderson, Euler Angles, Quaternions, and Transformation Matrices, JSC 12960, July 1977 Richard E. McFarland, A Standard Kinematic Model for Flight Simulation at NASA-Ames, NASA CR-2497, January 1975 Sophie, hopefully this will help you, also If you have any insights for me to help me extract the mathematical model from the code, then let me know. Cory On Thu, Jun 26, 2008 at 3:22 PM, [EMAIL PROTECTED] wrote: Hi, Thank you for answering my last question and it was really helpful. I have another question on the Flight Dynamic Models YASim. Can I say YASim is a Blade Element Theory Model? If not, what kind of model is that. For example, a total forces and moments theory model or kinematic model. BTW, from the documentation of JSBsim, I would say that is also a total forces and moments theory model, right? Thanks again for all your help. Sophia Wong - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is YASim a blade element theory model?
Hi, Thank you for answering my last question and it was really helpful. BTW, from the documentation of JSBsim, I would say that is also a total forces and moments theory model, right? Sophia Wong JSBSim allows you to specify functions (which can include tables, real numbers, etc.) that calculate the forces and moments acting on the vehicle. You could call it a coefficient buildup method, but it's a bit more flexible than that. Jon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is YASim a blade element theory model?
I don't know about YASim, but I am in the process of digging through JSBSim in an effort to extract the mathematical model. By the way, I am working feverishly - really - at getting together a formal JSBSim User's manual. Jon Jon S. Berndt Development Coordinator JSBSim Project www.JSBSim.org - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear Tracker restart
Hi, Please restart FlightGear MP servers because tracker was down. Thank you, Gabor - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Is YASim a blade element theory model?
May I help you with the manual? I am working on documenting the math of the model. I have to create many of the underlying equations in electronic format. It would be easy for me to provide web-ready or pdf format equations. I could help you document, and you could help me verify the math. Cory On 6/26/08, Jon S. Berndt [EMAIL PROTECTED] wrote: I don't know about YASim, but I am in the process of digging through JSBSim in an effort to extract the mathematical model. By the way, I am working feverishly - really - at getting together a formal JSBSim User's manual. Jon Jon S. Berndt Development Coordinator JSBSim Project www.JSBSim.org - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
