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:
-
getChunk
cache miss and subsequentcreateChunk
call creates a newosg::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
-
getChunk
cache miss due to changedlogFlags
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.