Difference between revisions of "Talk:Hackathon Proposal: CompositeViewer and Canvas"

From FlightGear wiki
Jump to navigation Jump to search
Line 13: Line 13:
  
 
{{Appendix}}
 
{{Appendix}}
 +
 +
== 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.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:27, 16 November 2020 (EST)

Revision as of 16:27, 16 November 2020

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)

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?
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]
--Hooray (talk) 11:20, 16 November 2020 (EST)


References

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.--Hooray (talk) 11:27, 16 November 2020 (EST)