Talk:Hackathon Proposal: CompositeViewer and Canvas
Performance
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)
SceneGraph Cameras vs. Prerender Cams
- 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[1]: 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. [2][3] Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft[4], since within each camera pass (far camera, near camera), all the passes of a technique are run.[5] 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.[6]
- here's how Canvas cameras/texture targets are set up under the hood
- This is how Canvas placements are registered (the canvas provides a default placement that is added via the gui camera) [1]
- This is the API used to insert cameras from simgear into fg
- which ends up here
- and here's how the PUI prerender cam is set up (splash.cxx containing another example based on James' comments [7])
- 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)
- Regarding texture size vs. extra views, we could detect that and log a warning to the console, i.e. do a test for sane ranges (128x128,256x256,512x512) and then add a configurable warning, possibly based on property rules to detect whenever an unreasonable texture size is used for extra views. If Canvas::View were to inherit from Canvas::Image, this could be done directly as part of the child class.
- Right, may I then suggest that some time next year, we'll actually explore the idea you outlined at [2], i.e. providing an "aggregation of a Compositor instance, a View and a pointer to a osg::Group" that could then be instantiated elsewhere ? This could then be used by the CanvasView module (or like you said by code unrelated to the canvas), we could begin adding stubs for property-controlled node masks, LOD and a framerate cap and use this setup to easily tinker with different use-cases and investigate what's possible/missing, as well as the resulting performance impact. --Hooray (talk) 18:36, 16 November 2020 (EST)
aircraft-less prototyping
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)
interface properties
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)