20,741
edits
Talk:Hackathon Proposal: CompositeViewer and Canvas: Difference between revisions
Jump to navigation
Jump to search
m
Talk:Hackathon Proposal: CompositeViewer and Canvas (view source)
Revision as of 18:17, 22 November 2020
, 22 November 2020→SceneGraph Cameras vs. Prerender Cams: for future reference
m (→SceneGraph Cameras vs. Prerender Cams: https://sourceforge.net/p/flightgear/mailman/message/37157855/) |
m (→SceneGraph Cameras vs. Prerender Cams: for future reference) |
||
| (One intermediate revision by the same user not shown) | |||
| Line 10: | Line 10: | ||
:: 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> | :: 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> | ||
* [https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/ODGauge.cxx#l217 here's how Canvas cameras/texture targets are set up under the hood] | |||
* [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/canvas_mgr.cxx#l72 This is how Canvas placements are registered] (the canvas provides a default placement that is added via the gui camera) [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/gui_mgr.cxx#l205] | * [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/canvas_mgr.cxx#l72 This is how Canvas placements are registered] (the canvas provides a default placement that is added via the gui camera) [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/gui_mgr.cxx#l205] | ||
* [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/FGCanvasSystemAdapter.cxx#l68 This is the API used to insert cameras from simgear into fg] | * [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas/FGCanvasSystemAdapter.cxx#l68 This is the API used to insert cameras from simgear into fg] | ||
* [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer.cxx#l974 which ends up here] | * [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/renderer.cxx#l974 which ends up here] | ||
* [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/PUICamera.cxx#l302 and here's how the PUI prerender cam is set up] (splash.cxx containing another example based on James' comments <ref>https://sourceforge.net/p/flightgear/mailman/message/37157855/</ref>) | * [https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/PUICamera.cxx#l302 and here's how the PUI prerender cam is set up] ([https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Viewer/splash.cxx#l273 splash.cxx] containing another example based on James' comments <ref>https://sourceforge.net/p/flightgear/mailman/message/37157855/</ref>) | ||
:: --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:20, 16 November 2020 (EST) | :: --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 11:20, 16 November 2020 (EST) | ||
| Line 20: | Line 21: | ||
::: 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. | ::: 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. | ||
::: --[[User:Icecode|Icecode]] ([[User talk:Icecode|talk]]) 11:55, 16 November 2020 (EST) | ::: --[[User:Icecode|Icecode]] ([[User talk: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. | |||
:::: so that means, draw masks (node masks) per compositor and LOD ranges need to be mapped to the view element then (see below), right ? And a dedicated prerender camera outside the scene graph for just MFDs ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:09, 16 November 2020 (EST) | :::: so that means, draw masks (node masks) per compositor and LOD ranges need to be mapped to the view element then (see below), right ? And a dedicated prerender camera outside the scene graph for just MFDs ? --[[User:Hooray|Hooray]] ([[User talk:Hooray|talk]]) 12:09, 16 November 2020 (EST) | ||