Board index FlightGear Development Canvas

WINDOW IN WINDOW

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

WINDOW IN WINDOW

Postby deepak » Tue Dec 01, 2009 8:32 am

HI FG developers,

It's just a suggestion that,to have a small window displayed on FG main window based on some event,Which can display and render terrain and A/C with any other view selection(IF main window is showing tower view,the small window can show chase view).It looks good as per my knowledge.I feel the developers are so good in programming to add this feature to the existing one.ALL THE BEST.

Regards
Deepak
Regards
Deepak
deepak
 
Posts: 18
Joined: Wed Nov 18, 2009 1:16 pm
Location: Bangalore

Re: WINDOW IN WINDOW

Postby Torsten » Tue Dec 01, 2009 11:56 am

I feel the developers are so good in programming to add this feature to the existing one.

Our developers are soo good in programming, they already added that feature!
Look at that picture from FSWeekend and spot the Laptop with the secondary display attached at the image's right edge:
http://www.xs4all.nl/~dtalsma/FSWeekend/web/22.html
It has one instance of FlightGear running showing four camera views of the same scene, three of them on the external monitor.

Our wiki knows the basic howto: http://wiki.flightgear.org/index.php/Howto:_Configure_camera_views_in_Windows

This is currently only supported in CVS, not in 1.9.1. If you are using the released version, you have to wait for the next release to use this.

Torsten
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: WINDOW IN WINDOW

Postby deepak » Wed Dec 02, 2009 8:15 am

Hi Torsten,

Thats nice to here the info.But it shows multiple window usage..But i told about a small window with in the current window that shows the different view...

Regards
Deepak
Regards
Deepak
deepak
 
Posts: 18
Joined: Wed Nov 18, 2009 1:16 pm
Location: Bangalore

Re: WINDOW IN WINDOW

Postby Torsten » Wed Dec 02, 2009 9:54 am

The external display shows two small camera views within the fullscreen viewport.
User avatar
Torsten
 
Posts: 648
Joined: Fri Feb 01, 2008 10:22 pm
Location: near Hamburg, Germany
Callsign: offline
Version: next
OS: Linux

Re: WINDOW IN WINDOW

Postby toshi » Fri Feb 05, 2010 4:34 pm

Hi deepak and Torsten,

Unfortunately, I don't know how to set tower view and chase view simultaneously.

But in case of multi cameras whose distance can be determined from the cockpit, I have tried multi cameras in single window using c172p with FlightGear v1.9.1 for windows.
Please refer to 800x600.xml in viewtopic.php?f=2&t=2985&p=26172#p26172.

If the black box issue appears as described in my post above, following setting may solve the problem.

800x600b.xml
Code: Select all
<PropertyList>
<sim>
<rendering>
<camera-group>
<window>
<name>FlightGear - 800x600</name>
<host-name type="string"></host-name>
<display>0</display>
<screen>0</screen>
<width>800</width>
<height>600</height>
</window>

  <!-- c172p-set.xml: position the pilot viewpoint and angle -->
  <!-- <x-offset-m archive="y">-0.21</x-offset-m> -->
  <!-- <y-offset-m archive="y">0.30</y-offset-m> -->
  <!-- <z-offset-m archive="y">0.36</z-offset-m> -->
  <!-- <pitch-offset-deg>-12</pitch-offset-deg> -->

<!-- camera 1 - Cockpit view -->
<camera>
<window>
<name>FlightGear - 800x600</name>
</window>
<viewport>
<x>600</x>
<y>0</y>
<width>200</width>
<height>600</height>
</viewport>
<view>
<x>0</x>
<y>0</y>
<z>0</z>
<pitch-deg>0</pitch-deg>
</view>
<frustum>
<top>0.052</top>
<bottom>-0.052</bottom>
<left>0.0347</left>
<right>0.0693</right>
<near>0.1</near>
<far>120000.0</far>
</frustum>
</camera>

<!-- camera 2 - Rear view -->
<camera>
<window>
<name type="string">FlightGear - 800x600</name>
</window>
<viewport>
<x>600</x>
<y>150</y>
<width>200</width>
<height>150</height>
</viewport>
<view>
<x>0.2</x>
<y>0</y>
<z>15</z>
<pitch-deg type = "double">0</pitch-deg>
</view>
</camera>

<!-- camera 3 - Gear view -->
<camera>
<window>
<name>FlightGear - 800x600</name>
</window>
<viewport>
<x>600</x>
<y>0</y>
<width>200</width>
<height>150</height>
</viewport>
<view>
<x>0.2</x>
<y>-2</y>
<z>3</z>
<pitch-deg type = "double">0</pitch-deg>
</view>
</camera>

<!-- camera 4 - Cockpit view -->
<camera>
<window>
<name>FlightGear - 800x600</name>
</window>
<viewport>
<x>0</x>
<y>0</y>
<width>600</width>
<height>600</height>
</viewport>
<view>
<x>0</x>
<y>0</y>
<z>0</z>
<pitch-deg>0</pitch-deg>
</view>
<frustum>
<top>0.052</top>
<bottom>-0.052</bottom>
<left>-0.0693</left>
<right>0.0347</right>
<near>0.1</near>
<far>120000.0</far>
</frustum>
</camera>

<gui>
<window>
<name type="string">FlightGear - 800x600</name>
</window>
</gui>
</camera-group>
</rendering>
</sim>
</PropertyList>
toshi
 
Posts: 81
Joined: Thu Oct 09, 2008 4:00 pm
Location: Japan

Re: WINDOW IN WINDOW

Postby nebneb » Sun Feb 28, 2010 2:37 pm

I would like this to be possible so that maybe we could have a night camera of some sort.
Callsign: NebNeb
nebneb
 
Posts: 15
Joined: Sun Feb 28, 2010 11:50 am

Re: WINDOW IN WINDOW

Postby Hooray » Wed Mar 17, 2010 4:07 pm

nebneb wrote:I would like this to be possible so that maybe we could have a night camera of some sort.


That's actually a different thing, and even a feature request. This discussion is about multiple view windows (separate or integrated), while you are talking about a possibility to change the type of rendering view (thermal, FLIR, night vision) for different surfaces (terrain, water, objects, aircraft).

The cameras were are talking about here are for multiple external views of the same scene.
While you are asking for different types of scenery views-but this sort of stuff is supported by OSG:

Image
http://www.openscenegraph.org/projects/ ... _green.jpg

These things are fairly complicated to implement however, you may want to search the forum for "FLIR".
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: WINDOW IN WINDOW

Postby Hooray » Wed Apr 21, 2010 3:46 pm

nebneb wrote:I would like this to be possible so that maybe we could have a night camera of some sort.


You might want to check out the wiki, there is some documentation available on shader programming, I think that might be one way to get some of this.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: WINDOW IN WINDOW

Postby rahulroyrd350 » Wed Aug 25, 2010 9:19 am

What i want to achieve: Multiple views of the same scene . Lets call them View1 and View2(they may be on 2 separate screens). There should be only one instance of flightgear running. I should be able to have "View1 = Cockpit View & View2 = Chase View" or "View1 = Helicopter View & View2 = Cockpit View" or any other such combination of views. I am using FlightGear 2.0.0

I should be able to switch the view in each viewport without affecting the view in the other view port. i.e i should be able to double right click and change the view on each display with the mouse without affecting the view in the other display.

README.multiscreen in the FlightGear documentation says its possible to create a master camera and a slave camera that is offset from the master camera. BUT I want 2 master cameras that can switch to any view at any time.

Please Help. Perhaps some hack in a souce file in src/Main would help .

I believe Deepak was also hinting at such a feature.
rahulroyrd350
 
Posts: 60
Joined: Wed Oct 28, 2009 6:08 am
Location: India
Callsign: rd350
Version: 2
OS: Fedora 8

Re: WINDOW IN WINDOW

Postby trouble946 » Fri Oct 16, 2015 6:58 am

5 years later and istill multiple screens are trouble.

I want to knw what rahulroyrd350 asked.

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
trouble946
 
Posts: 10
Joined: Fri Jun 12, 2015 6:57 am

Re: WINDOW IN WINDOW

Postby AndersG » Fri Oct 16, 2015 8:59 pm

It (i.e., simultaneously showing different views, such as cockpit view and helicopter view, on one or more screens) is AFAIK still not supported since it (from what I've heard) would require a fairly major rewrite of how FG uses the OSG camera/viewer and fixes for all explicit and/or implicit assumptions that the active cameras are all in the same position that may exist in the FG code.

[EDIT]Clarified "It".[/EDIT]
Last edited by AndersG on Fri Oct 16, 2015 10:39 pm, edited 1 time in total.
Callsign: SE-AG
Aircraft (uhm...): Submarine Scout, Zeppelin NT, ZF Navy free balloon, Nordstern, Hindenburg, Short Empire flying-boat, ZNP-K, North Sea class, MTB T21 class, U.S.S. Monitor, MFI-9B, Type UB I submarine, Gokstad ship, Renault FT.
AndersG
 
Posts: 2524
Joined: Wed Nov 29, 2006 10:20 am
Location: Göteborg, Sweden
Callsign: SE-AG
OS: Debian GNU Linux

Re: WINDOW IN WINDOW

Postby Hooray » Fri Oct 16, 2015 10:33 pm

AndersG wrote in Fri Oct 16, 2015 8:59 pm:It is AFAIK still not supported since it (from what I've heard) would require a fairly major rewrite of how FG uses the OSG camera/viewer and fixes for all explicit and/or implicit assumptions that the active cameras are all in the same position that may exist in the FG code.


"Window in window" using slaved views is supported:

Subject: WINDOW IN WINDOW

Torsten wrote:
I feel the developers are so good in programming to add this feature to the existing one.

Our developers are soo good in programming, they already added that feature!
Look at that picture from FSWeekend and spot the Laptop with the secondary display attached at the image's right edge:
http://www.xs4all.nl/~dtalsma/FSWeekend/web/22.html
It has one instance of FlightGear running showing four camera views of the same scene, three of them on the external monitor.

Our wiki knows the basic howto: http://wiki.flightgear.org/index.php/Howto:_Configure_camera_views_in_Windows

This is currently only supported in CVS, not in 1.9.1. If you are using the released version, you have to wait for the next release to use this.

Torsten



Independent views would require CompositeViewer integration: http://wiki.flightgear.org/CompositeViewer_Support
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: WINDOW IN WINDOW

Postby www2 » Fri Oct 16, 2015 11:01 pm

Hooray any idea how loan to wait for this is add in canvas (with custom render options)?
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Re: WINDOW IN WINDOW

Postby Hooray » Sat Oct 17, 2015 10:12 am

www2 wrote in Fri Oct 16, 2015 11:01 pm: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

Image

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: WINDOW IN WINDOW

Postby www2 » Sat Oct 17, 2015 10:29 am

Hooray i mean render camera views in canvas (e.g. tail cam in a aircraft)
www2
 
Posts: 319
Joined: Thu Apr 16, 2009 2:58 pm
OS: Ubuntu

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests