Re: [Flightgear-devel] Frame spacing and OSG: about to jump down a rabbit hole

[Stuart B. <stu...@gm...>]

Hi Folks,

On Mon, Jan 9, 2023 at 9:29 AM James Turner wrote:

> There is some (understandable) terminology confusion here due to OSG : we
> don’t have many cases of selecting differently detailed models, but all the
> nodes and machinery around paging and loading tiles and models is in
> classes whose name contains LOD, especially the class PagedLOD.
>
> The key parameters there are setting view distances at which the content
> referenced by the PagedLOD is loaded, and determining when (due to culling
> / being too far away) models can be unloaded. Even when the PagedLOD only
> has a single ‘detail level’, all that machinery and parameters are exactly
> what drives our loading schedule, memory consumption and therefore quite a
> bit of our performance.
>

(One trivial, obvious, clarification:  The view distance also determines
when the model referenced by a PagedLOD is loaded in the first place.)

The other elements that have a significant impact is the behaviour of the
DatabasePager which loads the models in one or more separate threads.  This
is controlled by the following properties:
*  /sim/rendering/database-pager/threads - the number of loading threads
(next only)
* /sim/rendering/max-paged-lod - the maximum number of PagedLOD models to
keep in memory
* /sim/rendering/plod-minimum-expiry-time-secs - the minimum time since
last "active" to keep a PagedLOD in memory (irrespective of
/sim/rendering/max-paged-lod)

If the latter two properties are too large then memory occupancy balloons.
If too low, then the DatabasePager can end up wasting time reloading models
and you'll see delays in model loading.

WS3.0 relies very heavily on PagedLOD.  Each 1x1 degree tile has ~340 of
them if every subtile was loaded (which it shouldn't be!).  So tuning the
DatabasePager and getting the right balance is going to be more important
going forward.  The default values of 1800 PagedLOD nodes and an expiry
time of 5 minutes are almost certainly too high and cause memory usage to
grow until one runs out of memory.

One area where we do use LOD nodes very heavily is in the trees, clouds and
instanced buildings (aka "random buildings").  The core code for this is
now 13 years old,  and at the time Tim Moore and I were tuning carefully to
balance CPU and GPU load.  We used a significant number of LOD notes (a
quad-tree of depth 3 for each tile in the case of trees) to cull out as
many of the trees as possible.  Given modern graphics cards, that may not
be as important as it was and it may be better to reduce the number of LoD
nodes.  Fortunately that is parameterized as an argument into the
createForest call, so could be experimented with if anyone is interested -
just hack the code and use the OSG on-screen statistics to look at some
forested region of Canada or Russia!

It's worth getting some real data on this.  Under the Debug menu there's a
Dump Scenegraph which will dump the entirety of the scene graph to
STDOUT/STDERR (I forget which).  I haven't done so in a while, but it's a
useful tool and a bit of grepping will give some insights as to just how
many LOD and PagedLOD nodes we actually have.  We've got lots of code that
is run for each AI model, or each scenery tile so it adds up fast!

-Stuart