Re: [Flightgear-devel] Automatic/abstracted rendering settings

[James T. <ja...@fl...>]

> On 14 Oct 2020, at 17:19, merspieler <mer...@ai...> wrote:
> 
> Wouldn't such statistics be great to see where most performance
> is left on the table so we could improve performance in that area

Alas, the problem there is not lack of information, it’s legacy code+data. We have a pretty good idea where the bottlenecks are, and they’re structural: we need to 

	-ditch the OpenGL fixed-function stuff (display lists are evil…..)
	-massively flatten our scene hierarchy, to avoid tiny draw buffers (Stuart's STG merge is the way to go here)
	- ideally use a single texture atlas sheet for all tiles+scene textures, so they can be batched (also related to STGmerge, but also defining a single texture atlas for most scene models and then force^^encouraging modellers to use it if they possibly can : not for the Eiffel tower but for anything that’s glass/stone/concrete/metal…)
	- switch to Vulkan

Help with any of those is welcome: on STG merge, texture-atlasing, replacing the fixed function pieces (2D panels, HUD especially).

The STGmerge work doesn’t even need C++, it could be done in any language that can run the OSG tools to make a single mesh+STG+texture per tile (or sub-tile). And it’s doable today, could even be compatible with 2020.3; if we load fewer nodes, and make larger VBOS, we will run faster, and *more* faster on modern GPU+drivers which hate our teeny-weeny little 500 triangle draw commands right now.

The fixed-function removal, is actively in hand (Gaetan is working on the 2D panel part, and I’m going to focus on PUI in the rest of this year). I hope that means next year I can focus on Vulkan, or at least, using OSG as if /were/ VSG, so the migration in a year or two when VSG is stable, is not so painful.

Kind regards,
James