View Issue Details

IDProjectCategoryView StatusLast Update
0005944The Dark ModCodingpublic21.04.2022 16:58
Reporterstgatilov Assigned Tostgatilov  
PrioritynormalSeveritynormalReproducibilityN/A
Status resolvedResolutionfixed 
Product VersionTDM 2.10 
Target VersionTDM 2.11Fixed in VersionTDM 2.11 
Summary0005944: Optimize LOD thinking
DescriptionIn the upcoming mission "The adventures of Thomas: Lucy's quest", game modelling takes too much time:
  https://forums.thedarkmod.com/index.php?/topic/21371-beta-the-adventures-of-thomas-lucys-quest/&do=findComment&comment=472834
It turns out that this FM has 3000 active entities, must of them are trivial func_static-s with LOD settings.
They cost noticeable time, both for actual "thinking" and for handling active entities.

Since LOD is totally independent from gameplay, it can happen separately from thinking.
We can register all LOD entities in one big array, and write a dedicated code for going through all of them and doing the checks.
This is also good architecturally, because now the code for calling LOD checks is spread over many Think functions of classes derived from idEntity.
TagsNo tags attached.

Activities

stgatilov

stgatilov

21.04.2022 14:53

administrator   ~0014805

Committed major refactoring in svn rev 9907.

---------------------------------------------------------------------------------------------------
Extracted LOD processing from idEntity into LodComponent, and added global LodSystem as a container for them.

All LOD-related members moved from idEntity into LodComponent, which means smaller memory footprint (not all entities use LOD).
All LOD-related processing moved from SomeClass::Think into LodSystem::ThinkAllLod, which is called explicitly during game tic modelling (except for SwapLODModel virtual function).
The only exception is the SEED mess: it still controls LOD manually during its Think function (the same in CStaticMulti).

Every LOD-processed entity creates its own LodComponent from during entity spawn, which is then registered in LodSystem.
LodSystem stores all LodComponent-s in one array, possibly with skips ("dead" elements).
Each LodComponent has pointer to idEntity it corresponds to, and each entity stores lodIdx --- the index of its component inside LodSystem.

Performance of LOD checks has been greatly improved by 1) avoiding touching idEntity memory, 2) storing all stuff in one plain array, 3) fixing the m_DistCheckTimeStamp confusion.
On "Lucy's Quest" first beta, RunGameTic average time reduced from 10.5 ms to 9.6 ms.
All 3046 LOD-enabled entities are processed in 40 us (negligible), and number of active entities reduced from 3859 to only 977.
stgatilov

stgatilov

21.04.2022 16:58

administrator   ~0014806

Added minor tweak in svn rev 9909.

When updating m_DistCheckTimeStamp, make sure its remainder modulo DistCheckInterval does not change.
This ensures that distribution of LOD checks across frames remain the same.

Issue History

Date Modified Username Field Change
21.04.2022 11:19 stgatilov New Issue
21.04.2022 11:19 stgatilov Status new => assigned
21.04.2022 11:19 stgatilov Assigned To => stgatilov
21.04.2022 14:53 stgatilov Note Added: 0014805
21.04.2022 14:54 stgatilov Status assigned => resolved
21.04.2022 14:54 stgatilov Resolution open => fixed
21.04.2022 14:54 stgatilov Fixed in Version => TDM 2.11
21.04.2022 16:58 stgatilov Note Added: 0014806