343
edits
Talk:Hackathon Proposal: CompositeViewer and Canvas: Difference between revisions
Jump to navigation
Jump to search
Talk:Hackathon Proposal: CompositeViewer and Canvas (view source)
Revision as of 16:55, 16 November 2020
, 16 November 2020no edit summary
No edit summary |
|||
| Line 11: | Line 11: | ||
:: --[[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) | ||
::: 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. | |||
::: --[[User:Icecode|Icecode]] ([[User talk:Icecode|talk]]) 11:55, 16 November 2020 (EST) | |||
== aircraft-less prototyping == | == aircraft-less prototyping == | ||