Gear view in cockpit computer

[android]

Hello everyone, I would like to ask whether it is possible if the gear view inside the cockpit screen can operate and show the live view of the gears in the B787-8 aircraft? I think that this would be an interesting feature and would definitely make the simulation more realistic during taxiing and parking. Does anyone know how to change the change-log/ code to enable this function?



This is the camera view I am referring to. Right now, everything there including the tail cam, gear cam, left wing and right wing views are completely black


Can anyone help?

Thank you and cheers!

[Alant]

The external camera and closely related rear view mirror has been asked for very many times and the consensus is that is quite feasable. However, the problem is that nobody with the relevant skills has yet taken up the challenge. My understanding is that most (but not all) of the interfaces are already there.
This link http://wiki.flightgear.org/Howto:Use_a_ ... Instrument may help you get started.

[Hooray]

This particular wiki article is only kept for reference there, it's pretty outdated (even though technically still correct) - but, these days, it would be better not to implement this as a separate feature as part of the instrumentation subsystem, but just add a new element to the canvas system so that scenery/camera views can be rendered to a texture, mainly because canvases can be used anywhere - as per:

Subject: create window

we've had a number of discussions about possibly supporting camera views as Canvas elements, this isn't currently supported. At some point, this will probably be added, because it would simplify quite a bit of existing code (especially the view manager, and the way camera groups are set up) - however, the corresponding C++ predates Canvas by many years, so it would involve a bit of work.

But we've had a number of aircraft developers, who would also require this functionality for implementing mirrors and/or tailcam views rendered to instruments, or FLIR-type views. All of these wouuld be possible to support once the view manager is refactored such that it can render views to a new Canvas::Element - possibly in combination with supporting effects/shaders per element.
We've several building blocks for this in place already - but we've also seen people getting stuck while working on #1, simply because our existing way of using OSG is not particularly well-suited for having truly independent camera views - for a more technical explanantion, I'd suggest to check out: http://wiki.flightgear.org/CompositeViewer_Support

Given how FlightGear has evolved over time, not just regarding effects/shaders, but also complementary efforts like deferred rendering (via rembrandt), we'll probably see cameras (and maybe individual rendering stages) exposed as Canvases, so that there's a well-defined interface for hooking up custom effects/shaders to each stage in the pipeline - Zan's newcamera work demonstrates just how much flexibility can be accomplished this way, basically schemes like Rembrandt could then be entirely maintained in XML/effects and shader (fgdata) space.

[android]

So there's no solution to fix this?

[Hooray]

So there's no solution to fix this?

Well, not in XML/Nasal space - it would definitely involve touching C++ code.

I've seen a few screen shots from people working towards this independently, but those efforts seem to have stalled meanwhile.
I do know that omega95 and a few other aircraft developers are highly interested in supporting this feature - but as was said previously, it will involve C++ changes.

While I wouldn't necessarily say that we're lacking people with the skills to make this happen (we have at least half a dozen of developers who know perfectly well how to do this) - it's mainly a matter of different priorities for the time being - airliner development has never been a priority for FlightGear core developers - even though some aircraft developers are suggesting otherwise - but the truth is that the relatively high number of "airliners" in FlightGear is mainly because that's what many of our younger aircraft developers are interested in - still, there are many core features/building blocks missing to fully develop modern cockpit displays - in FlightGear terms, Canvas is a fairly recent and even "novel" addition.

It is probably going to be added via Canvas eventually - not so much for airliners in particular, but to support a number of other use-cases, regardless of airliners - such as e.g. tail cams, but also FLIR views etc.
Please keep in mind that it took several years to materialize for the Canvas system itself - the original proposal got first discussed pre-2010, and it got prototyped by TheTom in early 2012. In other words, even good ideas may have a certain "shelf life" and may need to grow momentum/demand to be recognized as such
So nobody is saying that the idea to add this to Canvas would be bad - quite the opposite actually: We'd all agree that this would be a great feature to have and that FlightGear would improve significantly - but for the time being core development resources are allocated elsewhere, and external core contributors are also more interested in other aspects of the simulator.

Thus, in the meantime you could file a feature request linking to your thread here so that other people interested in similar features can leave a vote or provide feedback.
Like I said, if this is implemented via Canvas it will no longer be specific to airliner avionics, but could just as well be used for combat aircraft (helicopters/jets) but also for a WWII mirror etc.
And we do have people who have a need to access scenery views without being restricted to a single aircraft/cockpit.

Currently, I'd guess that it may take us another 3-4 release cycles until this materializes - i.e. about 1.5-2 years - but that doesn't meant that the work ahead is so difficult, it just means that there are quite a few other things that have a higher priority for people working with the corresponding code - so if someone new were to step up, the whole thing could certainly be prototyped in a few weeks and even make it into FlightGear 3.4 - so it's mainly a manpower issue. And like Alant said previously, newcomers will also find that they need to know how to build FG from source, how to use gitorious and obviously know enough about C++ and OSG to make working modifications.
Even the number of active core developers with these skills is fairly low - many used to prefer outside the OSG/rendering department.

But given the time frame mentioned above, it wouldn't even be far-fetched that a skilled person might pick up the necessary skills along the way - we've seen that happen when Thorsten started weather development - and more recently, wlbragg has started contributing C++ patches to TerraGear. And overall, we're a pretty helpful bunch of people here - popular feature requests like these will certainly get a lot of support/feedback and pointers.

As you can read on the wiki, we do have several branches doing similar things - so it's mainly a matter of extracting functionality and unifying/integrating it.
Also, rendering an existing camera view to a texture is relatively simple (see Zan's newcamera branch) - the more challenging aspect is the CompositeViewer work that lies ahead if we want to do this "properly" and not just via a restricted workaround ...

[android]

So there's no solution to fix this?

Thus, in the meantime you could file a feature request linking to your thread here so that other people interested in similar features can leave a vote or provide feedback.

Thank you for your detailed description... I really hope that FG can surpass FSX one day, making it the world's best flight sim (currently, it's the best FREE flight sim).

Btw, I would like to know where can I file a feature?

[Hooray]

You can file feature requests using the bug tracker, see: https://code.google.com/p/flightgear-bu ... %20request

[wlbragg]

Would this view be like a cam located inside the wheel well that points at the gear to see their state?

[Hooray]

Would this view be like a cam located inside the wheel well that points at the gear to see their state?

yeah, that sums it up pretty well - it's basically like the tail-camera seen on many more recent airliners.

http://www.historyofpia.com/apbhv_gs98c.jpg


To support this kind of thing via Canvas, we'd need to adapt the existing view manager code and render a slave camera to a Canvas group - i.e. by turning the whole thing into a CanvasElement sooner or later. That would allow cameras to be specified according to the existing syntax/properties.

Fully-independent cameras would still not be supported though, because that would require the previously mentioned switch to use OSG's CompositeViewer, so that each camera can have its own associated tile manager, the necessary steps to make this possible were completed by Zakalawe and Stuart as part of using PagedLOD meanwhile.

This is actually one of the longer-standing feature-request, that even pre-dates Canvas in its current form - the original idea to implement this, is detailed at (particularly, see Zan's comments): http://wiki.flightgear.org/Howto:Use_a_ ... Instrument

A few years ago, Zan had a working prototype - pre-dating his own work related to extended CameraGroups - meanwhile, extending Canvas would make more sense than starting from scratch.

EDIT (10/2015) - just for future reference:

Subject: WINDOW IN WINDOW

Hooray any idea how loan to wait for this is add in canvas (with custom render options)?

Well, we can already render an arbitrary number of nested canvases (i.e. one canvas rendering another canvas, which is basically the requirement for window-in-window (pip) setups):

Equally, we have code/patches that extend the CanvasElement base class to add support for effects/shaders. As far as I am aware, this hasn't yet been incorporated - http://wiki.flightgear.org/Canvas_Devel ... 2F_Shaders



As has been said previously, the proper way to support "cameras" via Canvas is using CompositeViewer, which does require a re-architecting of several parts of FG: http://wiki.flightgear.org/CompositeViewer_Support

Given the current state of things, that seems at least another 3-4 release cycles away.

So, short of that, the only thing that we can currently support with reasonable effort is "slaved views" (as per $FG_ROOT/Docs/README.multiscreen).

That would not require too much in terms of coding, because the code is already there - in fact, CameraGroup.cxx already contains a RTT/FBO (render-to-texture) implementation that renders slaved views to an offscreen context. This is also how Rembrandt buffers are set up behind the scenes.

So basically, the code is there, it would need to be extracted/genralized and turned into a CanvasElement, and possibly integrated with the existing view manager code.

And then, there also is Zan's newcameras branch, which exposes rendering stages (passes) to XML/property tree space, so that individual stages are made accessible to shaders/effects.

Thus, most of the code is there, it is mainly a matter of integrating things, i.e. that would require someone able to build SG/FG from source, familiar with C++ and willing/able to work through some OSG tutorials/docs to make this work: http://wiki.flightgear.org/Canvas_Devel ... ng_Cameras

On the other hand, Canvas is/was primarily about exposing 2D rendering to fgdata space, so that fgdata developers could incorporatedevelop and maintain 2D rendering related features without having to be core developers (core development being an obvious bottleneck, as well as having significant barrier to entry).

In other words, people would need to be convinced that they want to let Canvas evolve beyond the 2D use-case, i.e. by allowing effects/shaders per element, but also to let Cameras be created/controlled easily.

Personally, I do believe that this is a worthwhile thing to aim for, as it would help unify (and simplify) most RTT/FBO handling in SG/FG, and make this available to people like Thorsten who have a track record of doing really fancy, unprecedented stuff, with this flexibility.

Equally, there are tons of use-cases where aircraft/scenery developers may want to set up custom cameras (A380 tail cam, space shuttle) and render those to an offscreen texture (e.g. GUI dialog and/or MFD screen).

It is true that "slaved views" are kinda limited at the moment, but they are also comparatively easy to set up, so I think that supporting slaved camera views via Canvas could be a good way to bootstrap/boost this development and pave the way for CompositeViewer adoption/integration in the future.

However, right now I am not aware of anybody working towards this.

Ironically, this gives a lot of momentum to poweroftwo's osgEarth effort, because that can already support independent viewers/cameras, and it would be pretty straightforward to render an osgEarth camera/map to a Canvas texture and use that elsewhere (GUI dialog/MFD screen etc).

However, currently, I am inclined to state that Canvas is falling victim to its own success, i.e. the way people (early-adopters) are using it is hugely problematic and does not scale at all.

So we really need to stop documenting certain APIs and instead provide a single scalable extension mechanism, i.e. registering new features as dedicated Canvas Elements implemented in Nasal space, and registered with the CanvasGroup helper - absent that, the situation with Canvas contributions is likely to approach exactly the dilemma we're seeing with most Nasal spaghetti code, which is unmaintainable and is begging to be rewritten/ported from scratch.

Which is simply because most aircraft developers are only interested in a single use-case (usually their own aircraft/instrument), and they don't care about long-term potential and maintenance, i.e. there are now tons of Canvas based features that would be useful in theory, but which are implemented in a fashion that renders them non-reusable elsewhere: http://wiki.flightgear.org/Canvas_Devel ... FlightGear

So at the moment, I am not too thrilled to add too many new features to Canvas, until this is solved - because we're seeing so much Nasal/Canvas code that is simply a dead-end due to the way it is structured, i.e. it won't be able to benefit from future optimizations short of a major rewrite or tons of 1:1 support by people familiar with the Canvas system. Which is why I am convinced that we need to stop implementing useful functionality using the existing approach, and instead adopt one that is CanvasElement-centric, where useful instruments, widgets, MFDs would be registered as custom elements implemented in Nasal space (via cppbind sub-classing).

If we don't do that, we will continue to see cool Canvas features implemented as spaghetti code monsters that reflect badly upon Nasal and Canvas due to lack of of design, and performance.

Subject: WINDOW IN WINDOW

Hooray i mean render camera views in canvas (e.g. tail cam in a aircraft)

tail cams are slaved cameras, so could be using code that already exists in FG, which would need to be integrated with the Canvas system, to be exposed as a dedicated Canvas element (kinda like the view manager rendering everything to a texture/osg::Geode).

There's window setup/handling code in CameraGroup.cxx which sets up these slaved views and renders the whole thing to a osg::TextureRectangle, which is pretty much what needs to be extracted and integrated with a new "CanvasCamera" element - the boilerplate for which can be seen at: http://wiki.flightgear.org/Canvas_Devel ... ew_Element

So the CameraGroup code is in $FG_SRC/Viewer/CameraGroup.cxx, where you can find a buildCamera() routine that builds a camera using a property node read from an XML file, as per $FG_ROOT/Docs/README.multiscreen: http://sourceforge.net/p/flightgear/fli ... p.cxx#l798

The whole RTT/FBO texture setup can be seen here: http://sourceforge.net/p/flightgear/fli ... p.cxx#l994

That code would be redundant in the Canvas context, i.e. could be replaced by a Canvas FBO instead.

The next step would then be wrapping the whole thing in a CanvasCamera and exposing the corresponding view parameters as properties (propertyObject) so that slaved cameras can be controlled via Canvas.

Otherwise, there is only very little else needed, because the CanvasMgr would handle updating the Camera, and render everything to the texture that you specified.

Subject: WINDOW IN WINDOW

The multiscreen readme only shows how to set up multiple screens in flight gear but to show different views e.g. Cockpit & helicopter no read me file shows that.

Any ideas on how

Here's an example setting up multiple views on a single screen using several slaved (offset) views:

http://wiki.flightgear.org/FlightGear_W ... r#Approach


http://wiki.flightgear.org/Howto:Config ... ew_windows


Also see: http://wiki.flightgear.org/index.php/FS ... dering.xml

[legoboyvdlp]

This is all good reading... Canvas too complicated for me xD Is that 787-8 the latest Git? My version is blank between N1/2 and temperature, no grey boxes.

[ayman94]

Hello,

I am trying to display a view (like the gear view) in a cockpit instrument. I've read that some efforts have been make by some users, but I haven't found any complete solution. I've been trying to follow http://wiki.flightgear.org/Howto:Use_a_Camera_View_in_an_Instrument but since I am quite new to FlightGear and completely new to OSG, I'm not able to write a proper cam_display.cxx source file to make it work. Is this already supported by Canvas or something else?

Thank you

[Hooray]

If you don't know any C++/OSG and SG/FG internals, and have never built SG/FG from source, the short answer remains NO.
If you do, the long answer is to be found in this very topic - i.e. the situation hasn't really changed, we have various bits and pieces all of the place in FG, but these are not exactly well integrated for the time being.

I could provide more pointers and code snippets doing some of this, but that really only makes sense if you do have C++ experience and do have a working build environment setup up and running.

Nevertheless, a rough prototype would involve coming up with a new Canvas::Element that is based on Canvas::Image to render a raster image.
The next step would involve changing the raster image to be a a fgfs screenshot, next you would want to look at the way the view manager is structured, and look at the way the CameraGroup stuff works so that you can set up a slaved view. And then you would expose a handful of view manager properties to become attributes of the new Canvas element.

Most of this is relatively well documented, and there are several examples to be found in the codebase demonstrating how to do this stuff - but it is a steep learning curve if you don't have much of a C++/osg background.

Note that none of this involves any truly independent views - we're just talking slaved views here, i.e no CompositeViewer stuff.

[ayman94]

Thanks for the reply. My main problem is that I don't now very well how to get started. I've read that there is more than just one way to achieve this, but none of them looks very clear for me. The wiki article I referred to, for instance, says that the code for the new instrument has to be a class that inherits the od_gauge, and states some steps, but some additional indications on how to implement these steps (i.e. examples of code) would be welcome. I see it not very easy, as I've been working with FG only during one year for an academic project and I didn't go deep in detail trhough the C++ code. Despite this, I've already rebuilt FG from source in order to modify the HUD and I'm not so new to its internal behaviour.

[Hooray]

Sorry for getting back to this so late.
The wiki article you are referring to is outdated - these days, it is recommended to tackle this at the Canvas::Element level.
You'd basically create a new Canvas element for adding slaved views to a Canvas - so that this can be shown on an arbitrary MFD.
The code to do this is readily available in FG, it's just not integrated at all:



The first step is adding a new Canvas element, according to the tutorial at: http://wiki.flightgear.org/Canvas_Devel ... ew_Element
More specifically, the following pointers are most applicable in your case: http://wiki.flightgear.org/Canvas_Sandbox#CanvasCamera

Once you have that working, you have a new Canvas element that is waiting to be populated with functionality.
Thus, you would need to check out $FG_ROOT/Docs/README.multiscreen to learn how multiple views can be configured via preferences.xml: http://wiki.flightgear.org/Howto:Config ... ew_windows

The next step would involve looking at the underlying C++ code to this procedurally, i.e. without using XML - the most relevant sources are in $FG_SRC/Viewer: http://api-docs.freeflightsim.org/fligh ... 9a63b.html

And specifically CameraGroup.cxx and renderer.cxx


http://api-docs.freeflightsim.org/fligh ... _8cxx.html
http://api-docs.freeflightsim.org/fligh ... _8cxx.html
http://wiki.flightgear.org/User:Hooray/Foo

The most relevant search query for the archives (devel list/forum and code base itself) is indeed CameraGroup - make sure to also search the wiki, too.

At that point, you would be able to create a new Canvas Element that renders a slaved scenery view to a texture - which is when you may want to look at the underlying view manager, to also map view-specific properties to the new Canvas element.


Anyway, I am not sure that this is something you want to tackel without a serious background in either SG/FG internals, or at least in C++ and OSG.
Absent that, you may be facing a steep learning curve.
My suggestion would be to get in touch with other folks interested in this functionality, especially people able to patch/rebuild FG related C++ sources who've previously expressed interest in working on related features - more recently Icecode GL mentioned that he's was interesting in doing some Canvas hacking, and he's also mentioned CameraGroup specifically.

[Hooray]

Here's a PM I recently received from F-JJTH (former FG core developer), I am reposting this in public to share his patches with others, and to "thank" him, too - given that he's disabled receiving PMs on the forum:

Hi Hooray,

I looked at the forum and I see you often take the example of Zan camera as the top of the feature to get in FG.
In fact I implemented this feature more than 1 year ago. Here is the patch:

Code: Select all

From 9637fb0ac157d3df21feb60b279a7c8ccb8adf57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20de=20l=27Hamaide?= <cl-----e---ma----ez@hotmail.fr>
Date: Tue, 23 Feb 2016 21:42:11 +0100
Subject: [PATCH] Implement CameraDisplay instrument

---
 src/Cockpit/CMakeLists.txt             |   4 +-
 src/Cockpit/CameraDisplay.cxx          | 239 +++++++++++++++++++++++++++++++++
 src/Cockpit/CameraDisplay.hxx          |  73 ++++++++++
 src/Cockpit/cockpitDisplayManager.cxx  |   6 +-
 src/Instrumentation/instrument_mgr.cxx |   3 +-
 5 files changed, 322 insertions(+), 3 deletions(-)
 create mode 100644 src/Cockpit/CameraDisplay.cxx
 create mode 100644 src/Cockpit/CameraDisplay.hxx

diff --git a/src/Cockpit/CMakeLists.txt b/src/Cockpit/CMakeLists.txt
index 42b03ba..6d722ea 100644
--- a/src/Cockpit/CMakeLists.txt
+++ b/src/Cockpit/CMakeLists.txt
@@ -11,6 +11,7 @@ set(SOURCES
     render_area_2d.cxx
     wxradar.cxx
     NavDisplay.cxx
+    CameraDisplay.cxx
    )
    
 set(HEADERS
@@ -24,7 +25,8 @@ set(HEADERS
     render_area_2d.hxx
     wxradar.hxx
     NavDisplay.hxx
+    CameraDisplay.hxx
    )
 
 
-flightgear_component(Cockpit "${SOURCES}" "${HEADERS}")
\ No newline at end of file
+flightgear_component(Cockpit "${SOURCES}" "${HEADERS}")
diff --git a/src/Cockpit/CameraDisplay.cxx b/src/Cockpit/CameraDisplay.cxx
new file mode 100644
index 0000000..51c1d0a
--- /dev/null
+++ b/src/Cockpit/CameraDisplay.cxx
@@ -0,0 +1,239 @@
+// camera display texture
+//
+// Written by Clément de l'Hamaide
+//
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License as
+// published by the Free Software Foundation; either version 2 of the
+// License, or (at your option) any later version.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, write to the Free Software
+// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+//
+//
+
+#ifdef HAVE_CONFIG_H
+#  include "config.h"
+#endif
+
+#include <osg/ImageStream>
+
+#include <Main/fg_props.hxx>
+#include <Viewer/viewmgr.hxx>
+#include <Scenery/scenery.hxx>
+#include <Viewer/renderer.hxx>
+
+#include <simgear/scene/material/EffectGeode.hxx>
+#include <simgear/scene/util/OsgMath.hxx>
+
+#include "CameraDisplay.hxx"
+#include "panel.hxx"
+
+
+
+class FindAndReplaceStaticTextureVisitor : public osg::NodeVisitor
+{
+  public:
+    FindAndReplaceStaticTextureVisitor( const char* name, osg::Texture2D* new_texture ) :
+      osg::NodeVisitor(osg::NodeVisitor::TRAVERSE_ALL_CHILDREN),
+      _tex_name( osgDB::getSimpleFileName(name) ),
+      _new_texture(new_texture)
+    {}
+
+    virtual void apply(osg::Geode& node)
+    {
+      simgear::EffectGeode* eg = dynamic_cast<simgear::EffectGeode*>(&node);
+      if( !eg )
+        return;
+      simgear::Effect* eff = eg->getEffect();
+      if (!eff)
+          return;
+      osg::StateSet* ss = eff->getDefaultStateSet();
+      if( !ss )
+        return;
+
+      for( size_t unit = 0; unit < ss->getNumTextureAttributeLists(); ++unit ) {
+        osg::Texture2D* tex = dynamic_cast<osg::Texture2D*>( ss->getTextureAttribute(unit, osg::StateAttribute::TEXTURE) );
+        if( !tex || !tex->getImage() || tex == _new_texture )
+          continue;
+
+        if( !_tex_name.empty() ) {
+          std::string tex_name = tex->getImage()->getFileName();
+          std::string tex_name_simple = osgDB::getSimpleFileName(tex_name);
+          if( !osgDB::equalCaseInsensitive(_tex_name, tex_name_simple) )
+            continue;
+        }
+
+        // insert a new group between the geode an it's parent which overrides the texture
+        osg::ref_ptr<osg::Group> group = new osg::Group;
+        group->setName("canvas texture group");
+        group->addChild(eg);
+        osg::ref_ptr<osg::Group> parent = node.getParent(0);
+        parent->removeChild(eg);
+        parent->addChild(group);
+
+        osg::StateSet* stateSet = group->getOrCreateStateSet();
+        stateSet->setTextureAttribute( unit, _new_texture, osg::StateAttribute::OVERRIDE );
+        stateSet->setTextureMode( unit, GL_TEXTURE_2D, osg::StateAttribute::ON );
+
+        SG_LOG(SG_INSTR, SG_DEBUG, "CameraDislay: replaced texture '" << _tex_name << "'" << " for object '" << parent->getName() << "'");
+        return;
+      }
+    }
+
+  protected:
+    std::string _tex_name;
+    osg::Texture2D     *_new_texture;
+};
+
+
+
+CameraDisplay::CameraDisplay(SGPropertyNode *node) :
+  _num(node->getIntValue("number", 0)),
+  _viewNum(node->getIntValue("view-number", 0)),
+  _enabled(true),
+  _initialized(false),
+  _name(node->getStringValue("name", "cd")),
+  _texturePath(node->getStringValue("texture-path",
+   "Aircraft/Instruments/Textures/camera-display.rgb"))
+{}
+
+
+CameraDisplay::~CameraDisplay()
+{
+  if( !_initialized )
+    return;
+}
+
+
+void CameraDisplay::bind()
+{
+  _instrument_node = fgGetNode("/instrumentation/camera-display", _num, true);
+  _name_node       = _instrument_node->getChild( "name", 0, true);
+  _texture_node    = _instrument_node->getChild( "texture", 0, true);
+  _enabled_node    = _instrument_node->getChild( "enabled", 0, true );
+  _view_node       = _instrument_node->getChild( "view-number", 0, true );
+
+  _view_node->setIntValue(_viewNum);
+  _name_node->setStringValue(_name);
+  _enabled_node->setBoolValue(_enabled);
+  _texture_node->setStringValue(_texturePath);
+
+  _view_node->addChangeListener(this);
+  _enabled_node->addChangeListener(this);
+}
+
+
+void CameraDisplay::init()
+{
+  if(_initialized)
+    return;
+
+  if ( !fgGetNode("/sim/view", _viewNum, false) ) {
+    SG_LOG(SG_INSTR, SG_DEBUG, "CameraDisplay: can't find view-number " << _viewNum);
+    return;
+  }
+ 
+  std::string path = _texture_node->getStringValue();
+  SGPath tpath = globals->resolve_aircraft_path( path );
+  if (!tpath.exists()) {
+    SG_LOG(SG_INSTR, SG_WARN, "CameraDisplay: display texture not found:" << path);
+    return;
+  }
+
+  _initialized = true;
+}
+
+
+void CameraDisplay::postinit()
+{
+  if( !_initialized )
+    return;
+
+  setView( _view_node->getIntValue() );
+
+  //TODO: setup an osg::Texture
+  //      setup an osg::Camera
+  //      attach the osg::Camera to the osg::Texture2D
+  //        in a way the camera draw on the osg::Texture2D
+  //      attach the osg::Texture2D to the 3D model
+  //        in a way the current 3D model texture being replaced by the osg::Texure2D
+#if 1
+  int tex_width = 512, tex_height = 512;
+  _texture = new osg::Texture2D;
+  _texture->setTextureSize( tex_width, tex_height );
+  _texture->setInternalFormat( GL_RGBA );
+  _texture->setFilter( osg::Texture2D::MIN_FILTER, osg::Texture2D::LINEAR );
+  _texture->setFilter( osg::Texture2D::MAG_FILTER, osg::Texture2D::LINEAR );
+
+  FindAndReplaceStaticTextureVisitor ftv( _texture_node->getStringValue(), _texture.get() );
+  globals->get_scenery()->get_aircraft_branch()->accept(ftv);
+
+  _camera = new osg::Camera;
+  _camera->setViewport( 0, 0, tex_width, tex_height );
+  _camera->setClearColor( osg::Vec4(1.0f, 1.0f, 1.0f, 1.0f) );
+  _camera->setClearMask( GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT );
+  _camera->setRenderOrder( osg::Camera::PRE_RENDER );
+  _camera->setRenderTargetImplementation( osg::Camera::FRAME_BUFFER_OBJECT );
+  _camera->attach( osg::Camera::COLOR_BUFFER, _texture.get() );
+  _camera->setReferenceFrame( osg::Camera::ABSOLUTE_RF );
+  _camera->addChild( globals->get_scenery()->get_scene_graph() );
+  _camera->setProjectionMatrixAsPerspective(/*fov*/ 85.0, /*ratio*/ 1.88, /*near*/ 0.1, /*far*/ 120000.0);
+  globals->get_renderer()->addCamera(_camera, false);
+#endif
+}
+
+
+void CameraDisplay::update(double dt)
+{
+  if( !_initialized || !_enabled )
+    return;
+#if 1
+  if( _view != globals->get_current_view() )
+    _view->update(dt);
+
+  osg::Vec3f position( toOsg(_view->getViewPosition()) );
+  osg::Quat orientation( toOsg(_view->getViewOrientation()) );
+  osg::Matrix viewMatrix( osg::Matrix::translate(-position) * osg::Matrix::rotate(orientation.inverse()) );
+
+  _camera->setViewMatrix( viewMatrix );
+#endif
+}
+
+
+void CameraDisplay::valueChanged(SGPropertyNode *node)
+{
+  if(!_initialized)
+    return;
+
+  if (node == _enabled_node) {
+    _enabled = node->getBoolValue();
+    return;
+  }
+
+  if (node == _view_node) {
+    _view = globals->get_viewmgr()->get_view( node->getIntValue() );
+    setView( node->getIntValue() );
+    return;
+  }
+}
+
+
+void CameraDisplay::setView(int v)
+{
+  std::vector<SGPropertyNode_ptr> viewList = fgGetNode("/sim", true)->getChildren("view"); 
+  for (unsigned int i = 0; i < viewList.size(); i++) {
+    if( viewList[i]->getIndex() == v ) {
+      _view = globals->get_viewmgr()->get_view(i);
+      break;
+    }
+  }
+}
+
diff --git a/src/Cockpit/CameraDisplay.hxx b/src/Cockpit/CameraDisplay.hxx
new file mode 100644
index 0000000..69e432a
--- /dev/null
+++ b/src/Cockpit/CameraDisplay.hxx
@@ -0,0 +1,73 @@
+// camera display texture
+//
+// Written by Clément de l'Hamaide
+//
+//
+// This program is free software; you can redistribute it and/or
+// modify it under the terms of the GNU General Public License as
+// published by the Free Software Foundation; either version 2 of the
+// License, or (at your option) any later version.
+//
+// This program is distributed in the hope that it will be useful, but
+// WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+// General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, write to the Free Software
+// Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA.
+//
+//
+
+#ifndef _INST_CAMDISPLAY_HXX
+#define _INST_CAMDISPLAY_HXX
+
+#include <Viewer/view.hxx>
+
+#include "od_gauge.hxx"
+
+/*
+ * CameraDisplay class
+ *
+ * A subsystem instrument who reproduces a camera and its display
+ */
+
+class CameraDisplay : public SGSubsystem, public SGPropertyChangeListener
+{
+  public:
+    CameraDisplay(SGPropertyNode *node);
+    virtual ~CameraDisplay();
+   
+    virtual void bind();
+    virtual void init();
+    virtual void postinit();
+    virtual void update(double dt);
+    virtual void valueChanged(SGPropertyNode *node);
+   
+    void setView(int v);
+   
+  protected:
+
+ 
+  private:
+    int _num;
+    int _viewNum; 
+    bool _enabled;
+    bool _initialized;
+    FGODGauge *_odg;
+    std::string _name;
+    std::string _texturePath;
+    flightgear::View *_view;
+    SGPropertyNode_ptr _name_node;
+    SGPropertyNode_ptr _view_node;
+    SGPropertyNode_ptr _enabled_node;
+    SGPropertyNode_ptr _texture_node;
+    SGPropertyNode_ptr _instrument_node;
+    osg::ref_ptr<osg::Camera> _camera;
+    osg::ref_ptr<osg::Texture2D> _texture;
+    osg::Matrix _viewMatrix;
+    /*osg::Camera *_camera;
+    osg::Texture2D *_texture;*/
+};
+
+#endif
diff --git a/src/Cockpit/cockpitDisplayManager.cxx b/src/Cockpit/cockpitDisplayManager.cxx
index 18e6e7d..0a46ff8 100644
--- a/src/Cockpit/cockpitDisplayManager.cxx
+++ b/src/Cockpit/cockpitDisplayManager.cxx
@@ -37,6 +37,7 @@
 #include "NavDisplay.hxx"
 #include "groundradar.hxx"
 #include "wxradar.hxx"
+#include "CameraDisplay.hxx"
 
 namespace flightgear
 {
@@ -112,7 +113,10 @@ bool CockpitDisplayManager::build (SGPropertyNode* config_props)
       
         } else if ( name == "navigation-display" ) {
             set_subsystem( id, new NavDisplay( node ) );
-           
+
+        } else if ( name == "camera-display" ) {
+            set_subsystem( id, new CameraDisplay( node ) );
+
         } else {
             // probably a regular instrument
             continue;
diff --git a/src/Instrumentation/instrument_mgr.cxx b/src/Instrumentation/instrument_mgr.cxx
index 751f6c7..3bd1dfa 100644
--- a/src/Instrumentation/instrument_mgr.cxx
+++ b/src/Instrumentation/instrument_mgr.cxx
@@ -209,7 +209,8 @@ bool FGInstrumentMgr::build (SGPropertyNode* config_props)
         } else if (( name == "groundradar" ) ||
                    ( name == "radar" ) ||
                    ( name == "air-ground-radar" ) ||
-                   ( name == "navigation-display" ))
+                   ( name == "navigation-display" ) ||
+                   ( name == "camera-display" ))
         {
         // these instruments are handled by the CockpitDisplayManager
         // catch them here so we can still warn about bogus names in
--
1.9.1


It works with default rendering and Rembrandt if I remember correctly.
If you read a bit the code you will understand how it works:
- On 3D side you just need to assign the texture "Aircraft/Instruments/Textures/camera-display.rgb" to the object you want display the camera
- On FG side, you must create a <camera-display> instrument in your instrumentation.xml
- All views defined by the aircraft author are available in the display
- You can control the camera position/orientation by modifying the property tree /sim/view[n]/ ...

Best regards,
Clément

As simple as that,