Skip to content

Terrain::ChunkManager::createChunk is called twice for the same position, lod on initial loading

This basically makes a part of preloader work unused (creation and caching of terrain chunks) and slows down the main thread during culling stage. The cache has key (position, lod, lodFlags) and second createChunk call happens because of lodFlags mismatch. For example:

  1. getChunk cache miss and subsequent createChunk call creates a new osg::Node on terrain preloading.
[03:04:03.543 V] getChunk cached center=-8 9 lod=3 lodFlags=196608 obj=(nil)
[03:04:03.560 V] getChunk addEntryToObjectCache center=-8 9 lod=3 lodFlags=196608 node=0x7f479d3cfe40
  1. getChunk cache miss due to changed logFlags when called on culling:
[03:04:04.762 V] getChunk cached center=-8 9 lod=3 lodFlags=200705 obj=(nil)
[03:04:04.763 V] getChunk addEntryToObjectCache center=-8 9 lod=3 lodFlags=200705 node=0x55aa446f9ac0

200705 != 196608. Different logFlags means what kind of neighbour chunks (nodes) are present around given position. This logic does lookup for them but only accounts for those which level of detail is less. So in binary view 200705 is 110001000000000001 and 196608 is 110000000000000000. As you may notice some lower bits are missing when preloading happened.

This is ok in Morrowind due to small terrain size but very impactful in Oblivion.

There is a difference in the logic on how loadRenderingNode (calls getChunk which calls createChunk) is called on culling and preloading. Before 01cc6108 the logic was similar (single iteration over all nodes). After mentioned commit something called "passes" was introduced with https://github.com/OpenMW/openmw/pull/3126 saying that it speeded up chunk creation without mentioning any passes. Why there are only 3 of them and what is this distance modifier means is unclear.