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

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 4: Line 4:
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.--[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 09:53, 16 November 2020 (EST)
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.--[[User:Hooray|Hooray]] ([[User talk: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?
: 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<ref>https://sourceforge.net/p/flightgear/mailman/message/36659646/</ref>: 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'''. <ref>https://sourceforge.net/p/flightgear/mailman/message/36352621/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/37042457/</ref> Tim Moore’s canvas-rendering-on-a-pre-camera fix, again should give us a nice perf win for Canvas-intensive acft<ref>https://sourceforge.net/p/flightgear/mailman/message/36355833/</ref>, since within each camera pass (far camera, near camera), all the passes of a technique are run.<ref>https://sourceforge.net/p/flightgear/mailman/message/29563353/</ref> 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.<ref>https://sourceforge.net/p/flightgear/mailman/message/19718354/</ref>
 
:: --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:20, 16 November 2020 (EST)

Revision as of 16:20, 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)