Changes

Jump to navigation Jump to search
m
→‎Create a Canvas Element subclass: + per-view/camera frame throttling comments
Line 446: Line 446:     
=== Standardize the View manager  ===
 
=== Standardize the View manager  ===
{{Note|As of 11/2020, Jules has already created a custom view manager implementation (Sview) that supports multiple independent instances, so this step might be obsolete by now.}}
+
{{Note|As of 11/2020, Jules has already created a custom view manager implementation (see {{flightgear file|src/Viewer/sview.cxx}}) that supports multiple independent instances, so this step might be obsolete by now.}}
    
<small>The first step would be to port the view code to SimGear so it can be used and known by the Compositor and Canvas. The view manager ({{flightgear file|src/Viewer/viewmgr.cxx}}) currently has some hardcoded assumptions, so it would either need to be rewritten to remove them or a new interface for the Views could be created specifically for the Canvas Camera View.
 
<small>The first step would be to port the view code to SimGear so it can be used and known by the Compositor and Canvas. The view manager ({{flightgear file|src/Viewer/viewmgr.cxx}}) currently has some hardcoded assumptions, so it would either need to be rewritten to remove them or a new interface for the Views could be created specifically for the Canvas Camera View.
Line 473: Line 473:  
* whether or not to enable OSG StatsHandler per view, i.e. for troubleshooting per view
 
* whether or not to enable OSG StatsHandler per view, i.e. for troubleshooting per view
 
* whether or not to enable event handling: "Extra view windows don't yet handle events so one cannot change the view angle/zoom after creation." <ref>https://sourceforge.net/p/flightgear/mailman/message/37161269/</ref>
 
* whether or not to enable event handling: "Extra view windows don't yet handle events so one cannot change the view angle/zoom after creation." <ref>https://sourceforge.net/p/flightgear/mailman/message/37161269/</ref>
 +
 +
Note, we can use the view's Camera's LODScale to adjust the which level of LOD child is selected for each view.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg66861.html</ref>
 +
Another common suggestion is to control the update rate of slave cameras by inserting them into the scene graph as needed, and then use a PostDrawCallback for the camera that removes the
 +
camera again when it is no longer needed.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg66868.html</ref>
 +
Robert (OSG) states that most apps should manage the frame for their own applications and data.  The OSG is a general purpose scene graph rather than a domain specific IG.  It gives you the tools to do your
 +
job, but it doesn't do it all for you.  The run() method stuff available in OSG/Viewer is really only for entry level app development.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26257.html</ref>
 +
More sophisticated types of frame rate management are well beyond what  the viewer convenience methods like run are supposed to handle.  People  should expect to roll your own frame management for this type of app.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26184.html</ref>
 +
    
Simplifying a lot, this Canvas Element would be an aggregation of:
 
Simplifying a lot, this Canvas Element would be an aggregation of:

Navigation menu