Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
James Turner schreef: > I'm not clear what there is to be afraid of :) I mean, of course there > needs to be a way to render basic geometry, and there's an issue about > how to do that internally - a 'line' could be rendered by hand-written > Breshnam code into a texture, it could be an OSG node rendered > orthographically, etc, etc. There's many ways to get a 'vector' line > on the screen, but they're mostly dictated by the underlying OSG > rendering approach we adopt. > What I'm suggesting is to make an abstraction for that so that display designers do not need to worry about the OSG code itself, but just define where their lines, points, rectangles, and text will go and the underlying engine will do the rest. Whether this is sent over the network or just stored in a file isn't really an issue -- it can go either way. I am personally in favor of orthographic rendering. > This is what I have a problem with - I'm concerned to get something > simple and workable behaving with the current panels and systems in > FG. So initially I want in-process code, using the existing property > tree, panels and scene graph. While something like your approach would > give maximum flexibility, it's something we could talk about pursuing > once a basic solution that works in FG is established. If we're > rendering each display as an OSG sub-camera, extracting that logic and > wrapping it in a stand-alone OSG viewer should be simplicity itself - > and so long as it's driven by properties, those can be sent over a > socket. That's an approach which seems a lot more bearable to me than > sending per-frame pixel surfaces over shared memory or sockets / pipes. > > James > My approach wouldn't be sending the pixel surfaces (like video) over a network, but sending the low-level geometry that would result in pixel data. The rendering into the actual framebuffer would be done by the receiving application, this would also allow abstraction over different display engines (fx. for Windows developers who may prefer Direct3D or GDI+), so my idea is to make a VM-like structure with instructions like "draw line", "draw polygon", "translate", "rotate" etc. and a stack-based architecture. These instructions could be executed locally (acting on properties) or sent over a network for remote display, or saved to a file for delayed rendering. A property-based display in an OSG viewer could also be a good idea, though, but it has a minor downside of decreased flexibility, since you're placing part of the instruments' intelligence in the client. But it might be a simpler solution in the short term -- and since the property interface is well documented, it wouldn't be hard to connect that to other flight simulation packages as well. - 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=100&url=/ ___ 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
Frederic Bouvier wrote: > There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1. > I didn't managed to build it under Windows though. Without having a close look at it, I just tried to install the devel package on a stable Debian distribution and noticed that 'librsvg2-dev' pulls a _huge_ list of dependencies, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - 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=100&url=/ ___ 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:54, Frederic Bouvier wrote: > There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1. > I didn't managed to build it under Windows though. Depending on something like librsvg is pretty much my idea of hell. It's heavy, depends on libart (or possibly cairo, now), and doesn't seem to be actively developed. To be persuaded on the SVG front, I'd want to be sure there's a reasonably lightweight solution that would map to primitives we can easily support, i.e raw GL or OSG drawables. And it's not like we need a large set of SVG - I think SVG-Tiny would be sufficient, though I've forgotten what features are in each 'level' of the SVG 1.1 standard. Anyway, I'll do some research on the SVG technologies. I sort of feel it's a side issue anyway - whether the compass rose is drawn as an SVG or PNG is the easy part, it's getting the appearance to be reasonably close to a Boeing/Airbus/Primus/Garmin display that will take time, I feel. If the biggest complaint people have is that the graphical elements aren't sharp enough, I'd be happy :) 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=100&url=/ ___ 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 wrote: > 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. This might be exactly what you need: http://fabrice.bellard.free.fr/TinyGL/ Erik - 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=100&url=/ ___ 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 07:28, R. van Steenbergen wrote: > 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. I'm not clear what there is to be afraid of :) I mean, of course there needs to be a way to render basic geometry, and there's an issue about how to do that internally - a 'line' could be rendered by hand-written Breshnam code into a texture, it could be an OSG node rendered orthographically, etc, etc. There's many ways to get a 'vector' line on the screen, but they're mostly dictated by the underlying OSG rendering approach we adopt. > 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. This is what I have a problem with - I'm concerned to get something simple and workable behaving with the current panels and systems in FG. So initially I want in-process code, using the existing property tree, panels and scene graph. While something like your approach would give maximum flexibility, it's something we could talk about pursuing once a basic solution that works in FG is established. If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes. 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=100&url=/ ___ 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
- "Tim Moore" <[EMAIL PROTECTED]> a écrit : > 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. There is a new OSG pluggin that requires librsvg in OSG 2.6.0 RC1. I didn't managed to build it under Windows though. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - 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=100&url=/ ___ 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=100&url=/ ___ 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: > 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. 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. The layout might be similar to a VM, with high-level instructions to represent points, lines, rectangles, text, etc. The advantage of this is that it will set a predefined interface for displaying geometry but not define the low-level implementation. One might map the instructions one-on-one to OpenGL API calls, or one may not and decide to import the incoming geometry into the existing scene graph. After all, no low level operating system calls (such as creating and manipulating rendering contexts) will be made through the instruction set. - 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=100&url=/ ___ 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 3 Aug 2008, at 19:58, Syd&Sandy wrote: > I look forward to a better glass cockpit system. I did the Primus > 1000 glass cockpits for the Citation's and 777-200 . > I am experimenting with the G1000 with moving map (with pre-rendered > Atlas images),but with nasal code. > Ive tried different combinations of texturing and 2d panel text , > but haven't been happy with any of the results. The moving map aspect is tricky for the G1000 - including an Atlas- style renderer as another layer is possible, it'd also let me build the one GUI element I've been wanting for ages, a 'map' dialog box with navaids and airways overlaid, like the map UIs in MSFS / X- Plane / Fly. I'll definitely leave the moving map for the future, I'm afraid. > I've had visions of making a configurable glass cockpit where you > could specify 2d coordinates of each item (compass rose , ai , speed > tape, etc), and have them drawn in the code to a texture , but I > lack the coding skill to do it. > So I'm happy that someone is going to tackle this problem :) That's basically the approach that feels right to me, but I need to learn / be told more about the current OSG scene to be sure. I'm also unclear how the XML panel elements are handled in the brave new OSG world - are they mapped to custom nodes (which seems like it would work pretty well) or what (I'll go read the code I guess...) The more examples of different appearances that exist for these things, the better - whatever the C++ solution is, it's going to need to be 'styled' with a set of textures and colours for each make of display. 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=100&url=/ ___ 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 3 Aug 2008, at 20:22, R. van Steenbergen wrote: > The only issue I'm currently facing is how to integrate my current > work > into the already estabilished FG code. I'm a good OpenGL and C++ > coder, > but I'm new to the FG code structure. It would be nice if someone were > to give me a heads-up on that. Most of my current code is Win32- > specific > and low level immediate mode OpenGL commands, which i reckon doesn't > really work well with OSG. ;) 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 - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
Syd&Sandy schreef: > On Sun, 03 Aug 2008 14:40:57 +0100 > James Turner <[EMAIL PROTECTED]> wrote: > > I look forward to a better glass cockpit system. I did the Primus 1000 glass > cockpits for the Citation's and 777-200 . > I am experimenting with the G1000 with moving map (with pre-rendered Atlas > images),but with nasal code. > Ive tried different combinations of texturing and 2d panel text , but > haven't been happy with any of the results. > I've had visions of making a configurable glass cockpit where you could > specify 2d coordinates of each item (compass rose , ai , speed tape, etc), > and have them drawn in the code to a texture , but I lack the coding skill to > do it. > So I'm happy that someone is going to tackle this problem :) > Cheers The only issue I'm currently facing is how to integrate my current work into the already estabilished FG code. I'm a good OpenGL and C++ coder, but I'm new to the FG code structure. It would be nice if someone were to give me a heads-up on that. Most of my current code is Win32-specific and low level immediate mode OpenGL commands, which i reckon doesn't really work well with OSG. ;) - 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=100&url=/ ___ 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 Sun, 03 Aug 2008 14:40:57 +0100 James Turner <[EMAIL PROTECTED]> wrote: I look forward to a better glass cockpit system. I did the Primus 1000 glass cockpits for the Citation's and 777-200 . I am experimenting with the G1000 with moving map (with pre-rendered Atlas images),but with nasal code. Ive tried different combinations of texturing and 2d panel text , but haven't been happy with any of the results. I've had visions of making a configurable glass cockpit where you could specify 2d coordinates of each item (compass rose , ai , speed tape, etc), and have them drawn in the code to a texture , but I lack the coding skill to do it. So I'm happy that someone is going to tackle this problem :) Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit displays (rendering, modelling)
Sounds great, IMHO. I agree that MFD/glass cockpit displays aren't very well supported, and I also find the vector idea interesting. Actually, we've had several discussions on IRC about this possibility. And a Nasal interface for it would also be a good idea -- not for actually drawing the screens, but for setting up the structures. Not that I'm trying to put anything on anyone's TODO list, but you might also want to think about extending that idea for drawing HUDs. I never liked the idea of using textures for that, for the same reason that you mentioned: probably too blurry. ISTR that graphics cards manufacturers are dropping the idea of letting hardware draw the lines, and move that functionality to the drivers. But this should still be fast enough. For HUDs it would be necessary to project the image on an arbitrary object, not necessarily a rectangle. I'm working on dropping the old HUD implementation. But if the "new" one is soon becoming the new "old one", I'll not be sad. :-) m. - 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=100&url=/ ___ 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: > > - My plan would be to build some generic classes which can be extended > or configured to support Boeing or Airbus displays, or other similar > systems (including the G1000). My current perception is that this > would be pretty doable - sizes / colours / iconography / positions of > elements change, but the fundamental concepts are pretty consistent. > Does this seem reasonable? Obviously supporting all the features of > each system is an immense amount of work, but I think getting the > common features up and running is doable in the medium term. > > - Any other feedback? I'm interested in docs on the G1000 and Airbus > displays / FMS in particular, to see how they differ from what i know > about the Boeing ones. I don't know anything about military > equivalents, but maybe they are also similar enough to share a C++ core. > > My initial hack would be to get a NAV display running showing the > current route segments and navaids overlays in a specified radius, > working as a custom panel instrument. That would be enough to get the > FPL/WPT/APT/FIX/NAV/etc buttons in various cockpits working, as well > as the NAV display modes (compass, enroute, approach if I recall > correctly). > > Regards, > James > I've been a lurker on this list for quite a while, and some of the FG development crew know me personally. I would be interested in helping out with this, since I am a sim builder and I think the interface for cockpit displays is probably one of the most important things missing in FG at the current time, in terms of the usability for sim building. After all, the flight dynamics and system logic of FG are far better than its Microsoft cousin. Remember, in real-world aircraft, cockpit displays are vector devices. In most sim packages, including FG and FS200x, panels are built by stacking bitmaps on top of each other, according to a specific transformation (fx. the attitude indicator consists of a static mask bitmap and an attitude card which is translated and rotated according to the aircraft's pitch/roll). Although this works very well for 'classic' mechanical gauges, it loses its function when simulating glass displays as it primarily compromises the readability of text. (this isn't a huge issue in mechanical gauges, since they have big numbers and mostly static text number plates. Glass decks, on the other hand, have a lot of transformed text) My suggestion would be to look into the option of making a vector framework, which has all the basic widgets for a glass deck implemented in C++ code. I'm guessing it would be somewhat similar to ARINC661, and the actual arrangement of these widgets could be marked up in an XML file. The framework could render to a texture (for display in a 3D virtual cockpit), a memory buffer (for direct blitting onto the screen) or to a separate device context altogether (for an external display). Network support on this would be a really interesting feature -- allowing outboard 'dumb' cockpit displays to be run off a diskless thin client. I have done some preliminary research on this and some bits of code. I currently have a working example of the Primus 1000 avionics set as seen in the Embraer ERJ-145, but it currently only connects to MSFS. Here's a pic: http://www.stoneynet.nl/openrj/openrj_screenshot.png And here's a ZIP containing the binaries, for the people interested in playing with it (Windows only): http://www.stoneynet.nl/openrj/openrj-0.9.7rc1.zip All the individual displays are plug-in files (Windows DLL files), but for the 2.0 version of the framework I'm trying to stick with UNIX support as much as I can. Most of the code inside the plugin file is just plain OpenGL commands and some math, though, and I reckon this could be easily translated into geometry files (XML or binary for embedded purposes), containing only the display engine in code. Making a moving map (NAV) display is pretty easy, BTW. The simplest, but least accurate way of doing it is to use a rectangular mapping -- mapping latitude and longitude to the X and Y axes directly. Remember that 1 minute of lat/longitude corresponds to 1 nautical mile by definition, and calculating distances is a snap (using the Pythagorean theorem). Define the clipping region of the map using glOrtho in nautical miles around the aircraft (the aircraft is positioned at the origin) and scale the coordinates up 60 times to obtain the easiest mapping. A more accurate mapping can be achieved by drawing the map in 3D, this also solves wrap-around problems, but it is (marginally) slower because of the large number of rotations involved. - 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
[Flightgear-devel] Cockpit displays (rendering, modelling)
After some playing around, the area of FG that I'd most like to see improved, and therefore inclined to work on, is better glass cockpit displays, and the systems behind them. I'm still reading over the code, and looking at different aircraft to get a handle on this (and, err, how difficult it's going to be) In the mean time, some questions: - in the OSG world, what is the 'right' approach for rendering cockpit displays? The KLN-89b uses a render-area-2d (and I think the weather radar does, but is currently non-functional under OSG?). The obvious candidates are a sub-scene rendered by an orthographic camera, or render texture accessed by 2D drawing. Which is the most likely to work well? In terms of things like supporting rendering displays to alternate video devices (for real cockpits), zooming displays for better visibility, and avoid Z-fighting when drawing many overlaid 2D elements. - As I understand it, the current PFD and NAV displays in the A320 / Citation / 787 / 737 are made using pretty elaborate arrangements of the current XML Panel code. I've also seen talk (I think) of people working on the G1000. What do people think is the right balance between Nasal + XML vs C++ code in this area? I think most features of even a Boeing PFD could be done purely in Nasal + XML panels, even things like the variable Max IAS indication and V-speed / flap- retraction markers. The NAV display certainly needs a C++ core for the showing Navaid DB features and the current flight plan, but the border elements and many other parts could still be built using XML. Equally OpenGC does the whole lot in compiled code, and the PFD might be simpler if a few components (airspeed and altitude tracks, for example) were available as pre-built components. - My plan would be to build some generic classes which can be extended or configured to support Boeing or Airbus displays, or other similar systems (including the G1000). My current perception is that this would be pretty doable - sizes / colours / iconography / positions of elements change, but the fundamental concepts are pretty consistent. Does this seem reasonable? Obviously supporting all the features of each system is an immense amount of work, but I think getting the common features up and running is doable in the medium term. - Any other feedback? I'm interested in docs on the G1000 and Airbus displays / FMS in particular, to see how they differ from what i know about the Boeing ones. I don't know anything about military equivalents, but maybe they are also similar enough to share a C++ core. My initial hack would be to get a NAV display running showing the current route segments and navaids overlays in a specified radius, working as a custom panel instrument. That would be enough to get the FPL/WPT/APT/FIX/NAV/etc buttons in various cockpits working, as well as the NAV display modes (compass, enroute, approach if I recall correctly). Regards, 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=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
