How to create 2 master camera and 2 views in flightgear 3.0

[Divi]

I have to create two master cameras to controls the two different views in two different scene rendering dynamically.

but flightgear only using viewer class . This is createing one master camera no.of slave cameras. but i need CompositeViewer class. how to use CompositeViewer class in flightgear and how to render through CompositeViewer class.



Kindly help me....

[Hooray]

You can find a ton of pointers on exactly this discussion at: http://wiki.flightgear.org/CompositeViewer_Support
A summary of the most recent Canvas-related discussion on supporting independent camera views is to be found at: http://wiki.flightgear.org/Canvas_Devel ... ng_Cameras
The main search terms for the devel list are "compositeviewer" and "PagedLOD"

[Divi]

Thank you for the reply.... If we are changing flightgear from viewer class to composite viwer class means should we change simgear and osg also....???

[Hooray]

No, OSG doesn't need to be touched.

Most of the required PagedLOD work (involving the tile manager in SimGear) has been recently completed - so there isn't too much missing in terms of refactoring on the SG side - primarily, you'll want to look at the "view manager" in $FG_SRC/Viewer and identify "singleton" use-cases there.

First of all, you'll have to replace the existing viewer with a single CompositeViewer - FlightGear's view manager is property-controlled, and there's currently the hard-coded assumption that there's only ever a single active MAIN view (other supported views are SLAVE views, i.e. slaved to the main view).

you'll find dozens of references to something like globals->get_view_mgr() in quite a few places demonstrating the underlying assumption.
Personally, I would just change the function's signature and add an optional index, defaulting it to 0 - that way, you won't have to touch all the places wanting to have the single main view.

Once that is working, it comes down to trial & error, i.e. testing multiple independent viewers, each having their own instance/access to the tile manager - the work itself is well understood and pretty straightforward, and pretty much all core developers agree that this is a worthwhile thing to aim for - it's just not currently being prioritized or being worked on by anybody else as far as I am aware.

If you're interested in seriously pursuing this, you'll want to look at the CompositeViewer example in the OSG source tree, and read up on discussions about CompositeViewer coding on the OSG list.
For the SG/FG side of things, the aforementioned wiki articles should be pretty comprehensive already - and then you'll probably want to get in touch with fellow FG developers using the FG developers mailing list.

Even if you should find that you cannot tackle this anytime soon, it would obviously be helpful to to review the wiki article and help update it - e.g. by adding any pointers/advice or questions you might have for others interested in pursuing this. This includes any findings you might make in the archives, or by discussing this change with other contributor.

That being said, this is not a particularly good time to discuss this with fellow FG coders, simply because of the upcoming code freeze/release.

Depending on your degree of familiarity with OpenGL/OSG coding, you could have a basic version of this running within 3-4 weekends - but I guess it might take at least another 4-6 weeks of spare time coding to actually tease out all the hard-coded assumptions about having a single main view only.

The other issue is getting your work reviewed, i.e. committed upstream, which is known to be a particularly long, tedious and painful process - especially for anything non-trivial that may possibly break critical parts of the simulator - which is why it's a good idea to start networking early on, i.e. by discussing this work way ahead of time and getting people involved to provide feedback - which may involve working through a gitorious topic branch.

The underlying PagedLOD in SimGear work is generally understood to be vital for other parts of the simulator, so anything related to this should also be appreciated.

Two overlapping efforts that would be important to keep in mind are:

• reset/re-init: http://wiki.flightgear.org/Reset_%26_re-init
• OSG windows: http://wiki.flightgear.org/Howto:Config ... ew_windows

[Hooray]

Responding to this in public because I've been getting a few PMs related to this:

There are a few things worth keeping in mind, i.e. the title says "in flightgear 3.0", while we're approach 3.4 already - i.e. next is already beyond that.

Thus, it would make sense to use SG/FG "next" as the base line for anything involving this, i.e. by cloning the corresponding gitorious repositories, so that people can more easily track what you're doing, e.g. also to get possibly involved and provide help.

For the OSG side of things (3D rendering involving scenery/terrain), there are only 3 main developers that are generally comfortable reviewing/working with this code:

• Mathias Frohlich (original OSG port)
• Tim Moore (effects/shader & window support integration)
• Frederic Bouvier (Rembrandt/deferred rendering)

Of these 3 only #1 is actively involved in FlightGear - Fred hasn't been seen posting in months, and Tim only shows up occasionally to answer a few OSG related questions.
However, Mathias is generally busy with other aspects of FlightGear - namely, HLA/OpenRTI.

Thus, the main challenge is finding someone comfortable reviewing/commenting on related changes/work.

From experience, other core developers (active or not) are generally not comfortable making related commits unless they've been previously reviewed by any of these 3 (ideally all of them).

It is easier to get feedback for anything involving PagedLOD (James Turner & Stuart Buchanan).
Otherwise, even a successful CompositeViewer integration may face a tedious review/commit process (c.f. osgEarth review), due to the lack of active core developers familiar with OSG usage in SG/FG involving anything 3D (scenery/terrain/viewer).

Equally, there are existing features that may be affected by this work, especially:

• effects/shaders
• OSG windowing
• Rembrandt
• particles (considered for being deprecated)

And then there are existing features that should ideally be well-integrated with this.

Overall, there's a number of benefits in not touching the main rendering pipeline and implementing CompositeViewer as an optional feature instead.

This should greatly help simplify the whole review process. The most straightforward option for doing just that involves adding a new Canvas element that merely implements a single CompositeViewer using PropertyBasedElement.

Unlike most other rendering related components in FlightGear, Canvas is being actively maintained by one of the most active core developers, who's also familiar with OSG coding.

By wrapping OSG's CompositeViewer via a custom Canvas element, you could experiment with multiple viewers without having to touch the main pipeline - you would implement this separately right from the get-go. The details of adding a custom Canvas element are detailed at: http://wiki.flightgear.org/Canvas_Devel ... ew_Element

The very first iteration of this could simply be showing a 3D model loaded from disk ($FG_ROOT) - while later iterations may be hooked up to the tile manager in FG/SG.
The whole thing would be rendered to an off-screen rendering context (RTT) and could be easily shown in any dialog/window.
There's Zan's newcamera branch demonstrating how to do this (see the wiki for details).

Once you're satisfied with the state of things, you could add a new canvas placement for OSG windows and show your Canvas/CompositeViewer texture there.

This would have a number of technical advantages, such as being easier to review/integrate - as well as having a sizable following of contributors who've previously expressed an interest in Canvas having CompositeViewer support.
Thus, even if core developers should not be able to review this anytime soon, there would be at least a handful of contributors wanting to get this reviewed, including people who regularly patch/build the sources.

And without touching the main rendering pipeline, there would also be less porting/maintenance overhead involved, as well as practically no chance for breaking anything in terms of existing features.

Equally, the feature itself wouldn't be widely used yet, so would be straightforward to review in terms of existing functionality/regressions.

However, FlightGear's usability/documentation, and especially developer documentation, is generally outdated, and if not lacking altogether, pretty pathetic in comparison to many other, similar-sized, open source projects.

So there's a certain barrier to entry, too. There's a tendency for contributors to become "lurkers" after 12-18 months, and whenever someone seems really familiar with FlightGear internals, that someone has either literally spent years contributing to the project (or even just using it), or that someone has some related professional domain expertise/qualifications. But overall, there's an increasing number of developers who find themselves having to abandon FlightGear involvement sooner or later.

Overall, the FlightGear/SimGear code bases contain a number of pretty ingenious ideas and implementations/approaches - there are/were some really clever folks involved in FlightGear obviously, but FlightGear's main issues WRT the C++ code base is lack of integration and lack of continued refactoring/integration - i.e. there are tons of re-invented wheels all over the place, as well as a number of poorly-integrated features that were never updated in the light of more recent additions, which can be seen by the degree of overlappinig, and even duplicate, code in various places.

Whenever you see a well-integrated piece of code, it's usually been developed by a single developer - often spanning several years. Otherwise, there's very little going on in terms of active networking and collaboration/cooperation.

In general, core developers are in short supply, especially those willing/comfortable to get new functionality implemented that they neither wrote themselves and that also doesn't involve components they originally developed. And people with OSG/rendering-level experience/expertise are in even shorter supply; in a few instances, fellow contributors who spent considerable time and resources on doing related development, have literally waited 12+ months for getting their work reviewed and committed.

The remaining number of active core developers is not only very low but generally also very busy and already juggling tons of duties/responsibilities, and more often than not, also don't feel sufficiently qualified to review/commit patches outside their own domain/comfort zone (e.g. involving the main rendering/scenery engine). But this doesn't just apply to OSG/rendering level additions, but also other areas - such as for example FDM-related patches.

So this is a chicken/egg problem obviously - and people wanting to do FG related development should be aware of these challenges (especially newcomers), because the project has -at least so far- failed -pretty miserably- at recognizing this issue and dealing with it constructively, which is unfortunately -but understandably- adding to the frustration new contributors are facing, especially those spending literally months working on new functionality (e.g. osgEarth), only to see their work then literally getting ignored for 12+ months - up to a point when updating things is causing considerable integration issues, for very little tangible results in return.

Back when the whole Canvas idea was originally discussed, none of the people involved in that discussion stepped up to actually prototype, let alone, implement the system - so it took a few years until the idea took shape, and the developer who prototyped and designed the system went quite a bit further than originally anticipated - but I think it's safe to say that not even Tom was foreseeing the increasing focus on GUI and MFD use-cases, as well as as the increasing trend to use it for mapping/charting purposes.

So the original focus on 2D rendering is/was very valid, and the system is sufficiently flexible to allow it to be extended using custom elements for rendering camera/scenery views at some point. All the community support and momentum certainly is there, and I'm sure that TheTom will gladly review any contributions related to this.

[Divi]

Thanks for the replies...

Currently, i have created 2 cameras with separate views and I have assigned separate eventhandlers also. Now am facing the problem at the time of rendering. Separate windows opening for the cameras but the splash screen is coming only on one window. I guess rendering initialization happening only on the second window.....


How to resolve it.... ??? Kindly suggest some ideas...


Thank you...

[Hooray]

IIRC, the splash screen is assigned to a single main window - but you can check the window handling code to see if/how the splash screen is initialized and integrated there, i.e. by starting up stock FG with multiple slave views and checking how things are working/integrated there.

Note that the splash screen can also be explicitly disabled using a property.
But I doubt that this is about the splash screen showing up or not, right ?
What about the other camera, is it rendering/updating correctly ?

The splash init routine seems to contain other init, code too - see: https://gitorious.org/fg/flightgear/sou ... r.cxx#L432

As you can see, the splash node is explicitly added in the foreach() loop for the non-classical pipeline.
This is also where you can see that CompositeViewer isn't currently being used at all.

I've updated the wiki article accordingly, and encourage you to do also add your own findings/patches there: http://wiki.flightgear.org/CompositeViewer_Support

If the window isn't initialized properly, it shouldn't update correctly - to fix that, I would also suggest to look at the window handling code in FG.

Depending on the nature of your changes, you should find at least a handful of examples on doing these things correctly, i.e. by looking at the way Tim, Mathias, Fred and Zan have structured their code (window handling, fgviewer, Rembrandt, newcameras).

In general, you might want to share your changes using gitorious so that others can have a look and provide more specific feedback.

PS: I am assuming that you are using a conventional osg viewer and not CompositeViewer yet ? If you are using CompositeViewer already, it would be even more important to look at your changes so that others can contribute to this.