Talk:Hackathon Proposal: CompositeViewer and Canvas
FWIW, I don't seem to recall seeing any performance issues back when we were prototyping the original CanvasView element. However, that was obviously not using CompositeViewer (single window/GC). In general slave cameras are cheaper, and at least for static cameras or those fixed to an aircraft (exterior views like tail/gear/FLIR etc), they might still be preferable?
In fact, CompositeViewer is usually needed whenever we have an *independent* entity (where object A may see a completely different part of the scene than object B, so that B may no longer get access to the PagedLOD nodes that A discarded already), but if the camera can be "slaved" to a parent object in the scene, that's probably what should be done? Looking at osgcompositor.cpp, it can combine both kinds of cameras at runtime.--Hooray (talk) 09:53, 16 November 2020 (EST)
- Not sure whether this relevant, but Fernando said that Canvas uses scene-graph cameras, and it seemed that the use of scene-graph cameras caused some issues with canvas-view, but it would be quite a lot of work to change canvas to use slave cameras? --Cgdae (talk) 10:57, 16 November 2020 (EST)
- scene graph cams basically means that canvas based scenes are rendered "redundantly", that's true regardless of Comp/CV. And an obvious optimization for a number of canvas heavy aircraft (think shuttle, airliners). For full context, refer to these comments Post_FlightGear_2020.2_LTS_changes#Canvas:
- Review Tim's original suggestion: Another [Canvas] optimization is to use a pre-render camera that isn't in the scene graph to do the Canvas rendering. Otherwise the Canvas textures are rendered at least twice, in the near and far cameras.  Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft, since within each camera pass (far camera, near camera), all the passes of a technique are run. Also, Mathias stated once: that it would be good to be able to specify a completely different scenegraph in some subcameras, i.e. for having panel like instruments on an additional screen/display for example.
- Yes, doing something similar to Tim's patch would be the first step to get this upstream. We had to hack a lot around this to get something working. It isn't necessarily hard but it was definitely beyond the scope of a contained event like FSWeekend.
- Even if the other implementation was based on slave cameras, the performance impact should be the same. The overhead that is caused by slave cameras or the CompositeViewer stack is almost negligible. All of the performance drops we are seeing are caused by traversing the scene multiple times (effectively twice for two views). If extra views are also being rendered on considerably big textures, we might also see the GPU fill-rate play a role, specially on limited GPUs like Intel Integrated GPUs. James mentioned something along these lines too, so I think we can all agree that we have to be careful on what parts of the scenegraph we are going to render and the size of the texture we are rendering to.
- --Icecode (talk) 11:55, 16 November 2020 (EST)
btw, the canvas-view based approach makes it possible to prototype things without needing to edit an aircraft and without exiting/restarting FlightGear for each and every change. The original CanvasView patches simply used ~20 lines of Nasal code (via the Nasal console) to set up a Canvas GUI dialog that would add a Canvas.Image node which in turn showed the requested view. That made it possible to go through several iterations quickly (rapid prototyping), i.e. only booting up with simple aircraft (ufo), little/no scenery to get going quickly. Just mentioning this because the Post-hackathon write-up mentions some aircraft integration issues. Stuart once mentioned that he made enormous progress on the FG1000 when he adopted a similar GUI-centric workflow, without prototyping things via the -set.xml pathway (one option might be to to traverse the view manager properties and procedurally add buttons to a Canvas dialog for each view) --Hooray (talk) 11:27, 16 November 2020 (EST)
sooner or later, each view element would require a handle to the relevant properties to set up/manipulate the associated compositor (node masks, effects, LOD) and the view manager used by that view. --Hooray (talk) 12:07, 16 November 2020 (EST)