Re: [Flightgear-devel] RFC: changes to views and cameras
Hi Tim, On Thursday 26 June 2008, Tim Moore wrote: 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. This is true in general. Mostly I agree. But I would like to be able to still use displays and screens for some parts of the viewer. So while this would be very good to have and probably better for the end performance where you are heading to, we should have that as an addition to the way we can now redirect views to different displays and screens. Just think of a 2 gpu machine. You get the best performance with 2 screenn each on one gpu. Then have exactly one graphics context per gpu. When you have two monitors on each gpu, subdivide that single graphics context among two cameras like you are probably heading to ... 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. Ok, in principle yes. I do not know projdesigned. But Note that you have to be careful with osg. You just can have a sheared frustum in osg as a perspective projection matrix. If you specify arbitrary projection matrices osg bails out when culling ... 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 be used by FGViewer objects by default. This group will be created based on the command line arguments if it isn't specified in preferences.xml. FGViewer objects can either use named camera groups or can create new ones on the fly. I don't know if the creation of new graphics windows on the fly will be supported. Eliminate get_current_view(). There will be a list of active views. Try to eliminate code that depends on the current view. There still needs to be a current location for the terrain pager, but more on that later. 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. Sounds good in general. What we just need is the ability to still redirect some windows to an other display/screen. What would be good to have is the specify a completely different scenegraph in some subcameras. I think of having panel like instruments on an additional screen/display for example. 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. Well, I have an animation that I call rendertexture, where you can replace a texture on a subobject with such a rtt camera. Then specify a usual scenegraph to render to that texture and
Re: [Flightgear-devel] Terrasync mirror short on disk space
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm not sure how to extract that from the logs. The server in question hosts a lot of other stuff that use a lot of bw so just looking at stats for the server would not help. /Arvid Norlander Sven Almgren wrote: | How much data/trafic are we talking about? I might be able to host | something... | | /Sven -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkhl/8gACgkQWmK6ng/aMNlozACfZwJ25lO/FOe23PYwCN2WQHLn voYAnR2ju4+ZbXG+Un7FrIW/ZMayEdmj =AaWY -END PGP SIGNATURE- - 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] Bug in Livery handling
--- Melchior FRANZ [EMAIL PROTECTED] schrieb am Mo, 16.6.2008: Von: Melchior FRANZ [EMAIL PROTECTED] Betreff: Re: [Flightgear-devel] Bug in Livery handling An: flightgear-devel@lists.sourceforge.net Datum: Montag, 16. Juni 2008, 18:41 * Melchior FRANZ -- Monday 16 June 2008: I know that bo105/plib are only correctly shown in fg/plib, and bo105/osg only in fg/osg. bo105/plib should now show up correctly in fg/osg (with random variant and special emblem). bo105/osg are not shown correctly in fg/plib, and probably never will. m. Hi, bo105/plib is now shown as random variant with cow, but there is still the bug between bo105/OSG: Nasal runtime error: no such member: livery_update at C:\Programme\FlightGear-OSG\data}Aircraft\bo105\Models\bo105.xml, line 22 Same error with R22 So Livery Update over mp seems not to work yet. Tested with FGFS OSG build 06/21/2008 win32 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
Re: [Flightgear-devel] RFC: changes to views and cameras
On Sat, 28 Jun 2008 09:04:59 +0200 Mathias Fröhlich [EMAIL PROTECTED] wrote: Hi Tim, On Thursday 26 June 2008, Tim Moore wrote: 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 ... This is true in general. Mostly I agree. But I would like to be able to still use displays and screens for some parts of the viewer. So while this would be very good to have and probably better for the end performance where you are heading to, we should have that as an addition to the way we can now redirect views to different displays and screens. Just think of a 2 gpu machine. You get the best performance with 2 screenn each on one gpu. Then have exactly one graphics context per gpu. When you have two monitors on each gpu, subdivide that single graphics context among two cameras like you are probably heading to ... I received a private comment about this point too. Mapping cameras to different windows, which can be opened on arbitrary screens, will absolutely still be supported. I know that multi-GPU setups are important for professional users and our demos. The setup you just described would be an important test case for my proposed system: 4 monitors attached to two GPUS. As I understand it you will get the best performance with each GPU treated as a large virtual screen, so here you want two graphics windows -- one opened on each display (GPU) -- with two cameras mapped to each window. 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. Ok, in principle yes. I do not know projdesigned. But Note that you have to be careful with osg. You just can have a sheared frustum in osg as a perspective projection matrix. If you specify arbitrary projection matrices osg bails out when culling ... Interesting to know. OK, perhaps no matrix syntax. ... 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. Sounds good in general. What we just need is the ability to still redirect some windows to an other display/screen. What would be good to have is the specify a completely different scenegraph in some subcameras. I think of having panel like instruments on an additional screen/display for example. Yup. We can think about how to specify 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. Well, I have an animation that I call rendertexture, where you can replace a texture on a subobject with such a rtt camera. Then specify a usual scenegraph to render to that texture and voila. I believe that I could finish that in a few days - depending on the weather here :) The idea is to make mfd instruments with usual scenegraphs and pin that on an object
Re: [Flightgear-devel] icons
* Arnt Karlsen -- Thursday 26 June 2008: Shouldn't these icons be in our cvs|svn|git etc repositories? They do IMHO belong to the src package -- to the executable. Adding a top-level dir in the data package only for a few (not so pretty) icons wasn't a good idea, and the inconsistent capitalization makes it even worse. m. - 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] pick lines grey instead of yellow
Hi Nav and Vivian, I have the answer to your question, (why are some pick outlines grey instead of yellow?) If an object has a _material_ animation, specifically, emissions, then it will not be the thick yellow line, but instead a thin line the _same_ color as the emission value. So for example, if the emission value is black, the pick line will also be black, and virtually invisible. Can this be improved? perhaps reverse color and thicker lines? or back to yellow? Stewart - 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
