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
Re: [Flightgear-devel] Help needed with multi-screen
On Fri, Mar 19, 2010 at 3:41 AM, Kavya Meyyappan kavya.meyyap...@gmail.comwrote: Dear FG members, I have just been trying out the multiple screen feature in FG. I found that the GUI camera (including the menu bar, hud and 2D panel) appears in only one of the windows. Is there any way I can make the GUI to appear in all the windows? Actually I want to be able to view the hud and 2D panel in all the windows. No, there's a limitation in Plib that forces the GUI to be drawn on one window. Also when I change the view in any one of the windows, the view changes in the other windows as well. Is it possible to make the windows independent of each other. I want to display the cockpit in one window at all times, in the second window I want to be able to shuttle between helicopter / chase or model views. Also I have observed that in the second screen where I'm displaying lets say the Helicopter view the aircraft remains static while the environment moves. This is because the cockpit view in my Master screen is defined as 'lookfrom'. Can I define 'lookfrom' for one screen and 'lookat' for the other screen. Neither of these are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need a complete overhaul to use the PagedLOD scheme of OSG, and the Flightgear view manager would need to be aware multiple active views. Tim -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
R. van Steenbergen wrote: James Turner schreef: Yeah, that's an absolute non-starter, same as the OpenGC code - low level OpenGL will not be flexible enough, or efficient in the OSG scene-graph, is my perception. I hope Tim Moore will pitch in with his opinion on the best way to do the OSG integration, separate camera feels like the best choice to me, but I need to think about the details. James I fear, though, that in some way you are going to have to fall back to the rendering of very basic geometry (points, lines, rectangles) because they are the basic make-up of a 2D vector display. Lots of interesting issues here. Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the existing examples we have of a custom glass instrument. The weather radar does work in FlightGear OSG; there isn't any weather yet, but it can show other aircraft traffic and is the basis for the ATC radar. od_gauge.cxx uses the method that would be used for any glass instrument: an osg::Camera that is bound to an off-screen render target, i.e a texture. The texture can then be used anywhere in the scene. You can integrate arbitrary OpenGL code with an OSG application. It is most friendly to setup and change all OpenGL state using OSG's StateSet mechanism, but even that is not necessary. We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in Main/renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a scene and its rendering, and that might not play well with arbitrary existing OpenGL code. If a vector description of instruments is the way to go, then you should look at using SVG with OpenGL and OSG. The big player here is cairo+glitz, but the last time I looked at this it was hard, perhaps impossible, to coax glitz to draw into an OpenGL context that it had not created. Perhaps this has been solved. Another library is svgl at svgl.sourceforge.net, but I have no idea if it is still alive. Any solution that renders to memory using the CPU is going to be too slow, IMHO. A moving map is a different beast. It would make sense to implement that as a scene graph in its own right with its own pager. That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway. I am thinking about a small 'dumb' GL rendering application that takes in geometry data in some sort of byte-code from stdin, a file or a socket, and outputs GL frame buffer data into a block of memory. If it would be possible to offer that block of memory to OSG as a texture and tell it to map it onto some surface, we pretty much get what we're looking for, including the degree of flexibilty required by deck builders. This tiny app could have other uses as well, as the Blender crew might be interested into an app that generates pixel data from a raw geometry stream, maybe incorporating GPU-accelerated rendering. It will be much more efficient to integrate this directly into FlightGear and render to a texture. Otherwise your program and FlightGear will thrash with graphics context switches and you'll have the cost of copying from memory to GPU. Tim - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
On 4 Aug 2008, at 10:43, Tim Moore wrote: Lots of interesting issues here. Yep :) Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the existing examples we have of a custom glass instrument. The weather radar does work in FlightGear OSG; there isn't any weather yet, but it can show other aircraft traffic and is the basis for the ATC radar. od_gauge.cxx uses the method that would be used for any glass instrument: an osg::Camera that is bound to an off-screen render target, i.e a texture. The texture can then be used anywhere in the scene. Okay, that fits my basic expectations, great. I'll look more closely at the od_guage as well as the wx_radar. You can integrate arbitrary OpenGL code with an OSG application. It is most friendly to setup and change all OpenGL state using OSG's StateSet mechanism, but even that is not necessary. We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in Main/ renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a scene and its rendering, and that might not play well with arbitrary existing OpenGL code. Also good to know, though purely in terms of sane design I'd want some better structure than just hacking up low-level GL calls I think. I was aware the OSG could wrap arbitrary GL code, I'd just forgotten it was that easy. Silly me. If a vector description of instruments is the way to go, then you should look at using SVG with OpenGL and OSG. The big player here is cairo+glitz, but the last time I looked at this it was hard, perhaps impossible, to coax glitz to draw into an OpenGL context that it had not created. Perhaps this has been solved. Another library is svgl at svgl.sourceforge.net, but I have no idea if it is still alive. Any solution that renders to memory using the CPU is going to be too slow, IMHO. Yeah, I've also (just) been looking at the state of the art in SVG - GL rendering. I was hoping to find something reasonably compact, but there's various dead links and so on. We already have some of the components (XML parser) so my preferred approach would be to make something like an osg-svg-kit by borrowing code from a project like svgl, but I really haven't looked at enough code to be sure about that. I'm also pretty wary of SVG as a technology, I've worked on the Mozilla SVG code in the distant past. I'm also very aware that even for a stand-alone cockpit-display running full-screen, many elements can be drawn much cheaper as a texture than as SVG graphics. It's not as aesthetically pure as specifying everything in pure vector formats, but I'd be happy to use a mixture of simple vector graphics and bitmap textures to start with, and the replace the textures with vector art once there's a suitable renderer. Anyway, going to play with svgl now. A moving map is a different beast. It would make sense to implement that as a scene graph in its own right with its own pager. That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway. Yep, I agree, moving map is a much harder problem, and not something I'm going to worry about in the short term. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: changes to views and cameras
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. 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. - 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
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 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. 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. 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 ... Vivian - 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
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 ... 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. Good thing to have!!! Just still support graphics context on different screens/displays too ... GReetings and thanks!!! Mathias - 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
... It sounds like the arrangement I described could be easily hooked up to your animation. 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. Good thing to have!!! Just still support graphics context on different screens/displays too ... You bet. 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
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 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. 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. - 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
James Turner schreef: On 4 Aug 2008, at 10:43, Tim Moore wrote: Lots of interesting issues here. Yep :) Instrumentation/wxradar.cxx and Instrumentation/od_gauge.cxx are the existing examples we have of a custom glass instrument. The weather radar does work in FlightGear OSG; there isn't any weather yet, but it can show other aircraft traffic and is the basis for the ATC radar. od_gauge.cxx uses the method that would be used for any glass instrument: an osg::Camera that is bound to an off-screen render target, i.e a texture. The texture can then be used anywhere in the scene. Okay, that fits my basic expectations, great. I'll look more closely at the od_guage as well as the wx_radar. You can integrate arbitrary OpenGL code with an OSG application. It is most friendly to setup and change all OpenGL state using OSG's StateSet mechanism, but even that is not necessary. We use the GUI code from PLIB, which doesn't know anything about OSG. See the SGPuDrawable class in Main/ renderer.cxx for the implementation. The one catch is that OSG has a strong notion of separation between the update of a scene and its rendering, and that might not play well with arbitrary existing OpenGL code. Also good to know, though purely in terms of sane design I'd want some better structure than just hacking up low-level GL calls I think. I was aware the OSG could wrap arbitrary GL code, I'd just forgotten it was that easy. Silly me. A cockpit display doesn't require *arbitrary* GL calls, only the ones related to drawing geometry and transformation are useful. Most special API calls like the ones found in GLU aren't even used. And I don't think basic geometry and transformation would be difficult to map. I'm also very aware that even for a stand-alone cockpit-display running full-screen, many elements can be drawn much cheaper as a texture than as SVG graphics. It's not as aesthetically pure as specifying everything in pure vector formats, but I'd be happy to use a mixture of simple vector graphics and bitmap textures to start with, and the replace the textures with vector art once there's a suitable renderer. Err, come on... Compared to a full scene graph, rendering a full-vector graphics cockpit display is like rendering the desktop for most contemporary graphics cards. Textures have their uses (as bitmaps), but they aren't the way to go when emulating vector graphics when you have GPU cycles to spare. My software runs pure vector and it runs smoothly even on a 7-year-old Celeron without a 3D card. And for the record, that's on Windows 2000. A moving map is a different beast. It would make sense to implement that as a scene graph in its own right with its own pager. That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway. Yep, I agree, moving map is a much harder problem, and not something I'm going to worry about in the short term. James I did a moving map with complete navigation database and flight plan support in one file for my OpenRJ project (see a previous post), and it's about 300-400 lines of code total, including the surrounding MFD's. So a separate scene graph can work if that's what you want but it is not really neccessary. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Disappearing scenery
On Sun, Sep 19, 2010 at 4:40 PM, ThorstenB bre...@gmail.com wrote: Hi, good news - I've done more debugging in the tile cache module and think I already found something... I'm seeing two issues with the tile cache, sometimes causing active scenery to be kicked when the cache is full - and this results in the missing patches. I'm also seeing cases where all active scenery tiles are dropped. This can also happen when cycling through the tower view - so this doesn't always help. Both issues are timestamp related (maybe depend on frame rate, system load, slow USB disks :-) or so...). * First problem is that the tiles' timestamps are only updated when the tiles are freshly loaded from disk or they are actively displayed (some magic osg CullCallback does that - haven't fully understood this yet). So when a tile belonging to the current position was not The cull callback is called from OSG's culling traversal. If OSG determines that an object's bounding sphere intersects the viewing frustum, it calls the cull callback -- if there is one -- to traverse that object and perform finer grain culling. If there is no cull callback, OSG does the traversal itself. Anyway, it's a good way to perform an action when an object is in view. displayed for a while, its timestamp is old. When the view then moves or teleports into a new position, and then back to the original position, the same tiles get scheduled again - but are still found in the cache. Since their timestamps remain old, they are kicked from the cache soon afterwards, when more tiles are loaded. This is what causes the random scenery tiles disappear effect... = I'm testing a fix now, which updates a tile's timestamp whenever it is scheduled to be loaded, but then found in the cache. That sounds correct. * The second issue is about the timestamps updated through this magic osg CullCallback. These timestamps can be newer than the current time used by the cache module for loading new tiles (seems to be a frame ahead or so). When a new set of tiles is scheduled to be loaded, and the cache is already filled with many future timestamp tiles, then the new tiles immediately kick each other from the cache (are never really loaded). When this happens, all scenery for a new position is lost (complete whiteout)... The timestamp used by the cull callback comes right from OSG's frame stamp and should be consistent with the tile code. there could be a logic error in the tile cache. Is all the tile cache and osg code single-threaded? If these osg callbacks, the cache management and tile loading were not in the same thread, it would explain where future timestamps could come from (maybe on slow machines only). If it's all single-threaded then I'll have another look to locate this. It is possible for the tile cache code, which runs in the update traversal, and the cull callback to run in different threads. However, they should never run at the same time: the cull traversal starts when the the update traversal has finished, and the next update traversal blocks on the cull and draw traversals. Now, the code that actually loads the tiles -- the database pager -- does run asynchronously. I'll need to check if any of the tile cache code runs in the database pager thread, but don't think any does. Tim Another option I'm already testing is introducing a flag to lock all tiles belonging to the current view position in the cache. The primary condition checked by the cache would then be to never kick tiles belonging to the current position (i.e. current inner or outer ring). Timestamps remain a secondary condition to pick from tiles not belonging to the current position. This would make things a lot more robust than relying on whacky timestamps alone. FG only supports one view position at a time, right? Multiple view positions (e.g. one screen for the tower view and a second screen for the plane) would complicate a locked to cache flag quite a lot... Yes, and that's not really supported by the current architecture, neither by the tile cache nor by osgViewer::Viewer. We would need to move to a CompositeViewer model, which supports several scene graphs, and rely completely on the osg database paging machinery. Tim Maybe someone could comment on the threading issue. I'll do some more testing, and then hope to propose a patch... cheers, Thorsten -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Start uncovering the many advantages
