MediaWiki has been updated to version 1.35.1. Please report any problems here.

Changes

Jump to navigation Jump to search
13,591 bytes removed ,  18:00, 16 November 2020
m
→‎Open Questions: obsolete: https://sourceforge.net/p/flightgear/mailman/message/37148460/
Line 122: Line 122:     
Neither of these are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need a complete overhaul to use the [[PagedLOD]] scheme of OSG, and the Flightgear [[View manager]] would need to be aware multiple active views.<ref>=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html</ref>
 
Neither of these are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need a complete overhaul to use the [[PagedLOD]] scheme of OSG, and the Flightgear [[View manager]] would need to be aware multiple active views.<ref>=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html</ref>
  −
=== Open Questions ===
  −
{{See also|Vulkan Scene Graph}}
  −
'''Status 08/2020'''
  −
  −
It would be very nice if CompositeViewer just works. However, James emphasized that we have a very complex display stack, with lots of permutations, and frankly we’re trying to /simplify/ the display layer, in anticipation of VSG in the future, not add more special cases to it.  Since we don’t really have a large pool of 3D renderer developers, we need to be able to use a standard one without too much additional work or customisation.
  −
  −
Getting rid of Rembrandt, and making Compositor the only rendering pipeline, will drastically help with reducing the number of code paths we need to maintain. So we should not be in a hurry to add a new optional code path we have to test for, and which might interact weirdly with multi-camera / fgviewer / stereoscopic / etc. <ref>https://sourceforge.net/p/flightgear/mailman/message/37075182/</ref>
  −
  −
What we need is a bit more analysis of what it might impact, in terms of multi-camera support, performance across different platforms and so on.  Especially, knowing how it will impact switching to VSG in the future, if VSG isn’t going to have an equivalent, then we should be be quite reluctant to start using it.<ref>https://sourceforge.net/p/flightgear/mailman/message/37075174/</ref>
  −
  −
Jules stated, performance is guaranteed unchanged if CompositeViewer is disabled. But he hasn't profiled performance with it enabled, but certainly hasn't
  −
noticed any particular differences and  wouldn't expect any such difference in the case where one is only using a single view.<ref>https://sourceforge.net/p/flightgear/mailman/message/37076818/</ref>
  −
  −
Regarding VSG specifically, Jules asked on the vsg-users group and it looks like VSG will certainly support what OSG CompositeView does<ref>https://sourceforge.net/p/flightgear/mailman/message/37076818/</ref>. See: https://groups.google.com/forum/#!topic/vsg-users/a68-CjA8kso
  −
  −
About this specific feature, there’s one concern: from memory (which may be incorrect), the CompositeViewer changes the OSG multi-threading model significantly, because there are multiple contexts. And since most of our long-standing crashing bugs are around OSG multi-threading, usually in combination with some other feature (eg, particles, or reset), James is not in agreement about the ‘risk free’ nature, if it touches threading at all. But, hopes, if it’s off by default, we can find out.
  −
  −
James added, he would also be happier if we could get Fernando to do a code review, to make sure we’re not touching anything which might affect the CompositOR. James also offered to  help with reviewing things <ref>https://sourceforge.net/p/flightgear/mailman/message/37077081/</ref>.
  −
  −
  −
* [https://github.com/vsg-dev/VulkanSceneGraph/blob/master/ROADMAP.md VSG Roadmap]
  −
* [https://vsg-dev.github.io/VulkanSceneGraph/docs/Design/HighLevelDesignDecisions.html VSG High Level Design]
  −
* https://github.com/vsg-dev/VulkanSceneGraph/tree/master/src/vsg/viewer
  −
  −
Supporting an '''optional''' CompositeViewer mode does not need to cause any significant problems. The changes to the code are actually very simple and well-defined, and it'll be easy to keep things very separate as things develop.
  −
  −
Jules and James agreed about the need to avoid adding to complexity in the rendering pipeline, and Jules expects as long as care is taken it will be fairly easy to keep CompositeViewer-specific code logically separate.
  −
  −
Jules hopes that CompositeViewer is fundamentally risk-free, in a way that most significant changes to a project like Flightgear are not, because ultimately OSG CompositeViewer is a very simple generalisation of OSG Viewer - instead of a Viewer also /being/ a View, a CompositeViewer /has/ one or more Views. That's all there is to it.
  −
  −
So we've always got the basic scenario to fall back on where there is just a single view and things are essentially identical to a standard non-CompositeViewer setup.<ref>https://sourceforge.net/p/flightgear/mailman/message/37076818/</ref>
  −
  −
<!--
  −
=== OSG stuff ===
  −
{{Note|As a general note, osgViewer::CompositeViewer should have osgViewer::View attached to it NOT osgViewer::Viewer. It's a composite of View's not composite of Viewer.  If you look at all the OSG example they illustrate the correct usage.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70462.html</ref>}}
  −
  −
The OSG's osgViewer is designed to support multiple views on to one or more scenes using the osgViewer::CompositeViewer class.  See the osgcompositeviewer example.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg69640.html</ref>
  −
  −
The CompositeViewer was written specifically for multiple Views.
  −
  −
Robert wouldn't recommend using slave Camera's for doing multiple views, while possible it's just a mess in terms of management.  slave Camera's are tools for helping rendering a single view, but with a view that is composed of several components - either spread across multiple windows, or a view that requires multiple passes such as distortion correction, field of view etc.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg74474.html</ref>
  −
  −
The osgViewer has a mechanism for avoid multiple traversals of shared
  −
scene graphs if mutlple View's share the same root node of the scene
  −
graph.  If shared component isn't the topmost node then the OSG has no
  −
straight forward way to know whether a subgraph has been traversed or
  −
not that frame.  One could implement a mechanism to avoid this
  −
visiting a node multiple times in one frame but it would be really
  −
costly to do, an expense that would only be a benefit for a very small
  −
number of users, but would slow performance for everyone else.
  −
  −
  −
The most efficient way to avoid this multiple traversals issue is to
  −
implement to have a custom callback that is tailored to the specific
  −
usage case that a user has.  I don't know enough about the specific
  −
callbacks and scene graph set up you have so I can't pinpoint the best
  −
route.
  −
  −
If you have a shared subgraph that you don't want traversed multiple
  −
times per frame then use an UpdateCallback that has a frameNumber
  −
member variable that keep track of the the frameNumber (use
  −
NodeVisitor::getFrameStamp()'s FrameNumber) of the last traversal,
  −
when a traversal calls the update callback you only traverse the
  −
subgraph if the frameNumber is different and then set the frameNumber
  −
to the present frame,  if the frameNumber is the same then you just
  −
return immediately.  This custom UpdateCallback you'd place as high as
  −
you can in your scene graph to make sure the traversal stops as soon
  −
as possible.
  −
  −
Another approach is to move this frameNumber tracking into your
  −
existing update callbacks, and simple return right away with the
  −
frameNumber is the same.  This requires a small tweak to the callbacks
  −
but is such a small change it's generally pretty easy to integrate.
  −
  −
Finally you can simple make your callbacks resilient so that the are
  −
no ill effects from being called multiple times.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg74476.html</ref>
  −
  −
* For multiple views the way to do it with the OSG is to use the osgViewer::CompositeViewer class, and then each osgViewer::View you set up the approrpiate Camera's CullMask.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78309.html</ref>
  −
* The draw traversal doesn't touch the scene graph nodes so NodeMasks/TraversalMask have no baring on it. The OSG's cull traversal builds the internal rendering graphs each frame and the draw traversal simply traversals these rendering graphs. So to control the draw traversal you use the masks in the cull traversal.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78308.html</ref>
  −
* shader handling with multiple views: The OSG provides equivalents to the OpenGL built ins for you so you don't need to provide them yourself, so just ditch the callbacks and just use gl_ModelViewMatrix or osg_ModelViewMatrix.  The OSG has provision for doing automatic conversion from gl_ModelViewMatrix to osg_ModelViewMartrix, it's enabled by default for GL3 and GLES2 builds, but if not then you can enable if you want to use it.  See the osgsimplegl3 example. These uniforms that the OSG provides for the projection and modelview matrices work seamlesly across multiple views. Just use them and it'll work out of the box. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75995.html</ref>
  −
  −
The two options for off screen rendering are a  PixelBuffer context or
  −
FrameBufferObject, if you have an existing on screen window in your
  −
application then using a FrameBufferObject becomes preferable.  The
  −
way to do it would be to set up your viewer's off screen Camera with
  −
FBO settings and a custom final draw callback to do the read to main
  −
memory.  The read will be more efficient if you use a pair of
  −
PixelBufferObjects - the osgscreencapture example illustrates this in
  −
action.
  −
  −
  −
When already using CompositeViewer the most natural thing to do
  −
would be to have a dedicated View with it's master Camera as the
  −
offscreen camera, this way you can control the Camera's view matrix in
  −
straight forward manner in the same way to the rest of the Camera's.
  −
Also during debugging having the option of making this Camera an
  −
onscreen one would give you means to visually QA things as you go
  −
along.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70703.html</ref>
  −
  −
-->
  −
  −
<!--
  −
  −
== Use Cases ==
  −
{{See also|Canvas Popout Windows|View Manager Improvements}}
  −
  −
{{FGCquote
  −
  |I have to create two master cameras to controls the two different views in two different scene rendering dynamically.<br/>
  −
<br/>
  −
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.
  −
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=227827#p227827
  −
    |title=<nowiki>How to create 2 master camera and 2 views  in flightgear 3.0</nowiki>
  −
    |author=<nowiki>Divi</nowiki>
  −
    |date=<nowiki>Tue Dec 23</nowiki>
  −
  }}
  −
}}
  −
  −
  −
{{cquote|<nowiki>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.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28647.html|title=<nowiki>Multiple views without slaving to master camera</nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
  −
  −
{{cquote|I have just been trying out the multiple screen feature in FG. I found that the GUI camera (including the menu bar, hud and 2D panel) appears in only
  −
one of the windows. Is there any way I can make the GUI to appear in all the windows? Actually I want to be able to view the hud and 2D panel in all the
  −
windows.
  −
  −
Also when I change the view in any one of the windows, the view changes in the other windows as well. Is it possible to make the windows independent of
  −
each other. I want to display the cockpit in one window at all times, in the second window I want to be able to shuttle between helicopter / chase or
  −
model views.
  −
  −
Also I have observed that in the second screen where I'm displaying lets say the Helicopter view the aircraft remains static while the environment moves.
  −
This is because the cockpit view in my Master screen is defined as 'lookfrom'. Can I define 'lookfrom' for one screen and 'lookat' for the
  −
other screen.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27112.html|title=<nowiki>[Flightgear-devel] Help needed with multi-screen</nowiki>|author=Kavya Meyyappan|date=Fri, 19 Mar 2010 03:31:50 -0700}}</ref>|Kavya Meyyappan}}
  −
  −
-->
  −
  −
<!--
  −
== Known Limitations ==
  −
{{See also|Unifying the 2D rendering backend via canvas|Howto:Using_FlightGear_as_an_Image_Generator_(IG)#Challenges}}
  −
  −
There are a few limitations of the FlightGear multi-camera/view/display system. Tim Moore is the person who developed this feature (nothing existed before his efforts) and maybe he can offer more insight. 
  −
  −
  −
{{Main article|FlightGear and OpenGL ES}}
  −
For example, in the case of:
  −
  −
* the built-in GUI ([[PUI]])
  −
* HUD (scheduled to be re-implemented via the [[Canvas]] system as per [[Post FlightGear 2020.2 LTS changes]])
  −
* 2D instrument panels (scheduled to be re-implemented via the [[Canvas]] system as per [[Post FlightGear 2020.2 LTS changes]])
  −
  −
there would need to be some significant code restructuring to allow these to be displayed on other windows.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27114.html</ref>
  −
  −
There's a limitation in Plib that forces the GUI to be drawn on one window.<ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html</ref>
  −
-->
      
== Related ==
 
== Related ==

Navigation menu