View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005944 | The Dark Mod | Coding | public | 21.04.2022 11:19 | 06.01.2024 20:17 |
Reporter | stgatilov | Assigned To | stgatilov | ||
Priority | normal | Severity | normal | Reproducibility | N/A |
Status | resolved | Resolution | fixed | ||
Product Version | TDM 2.10 | ||||
Target Version | TDM 2.11 | Fixed in Version | TDM 2.11 | ||
Summary | 0005944: Optimize LOD thinking | ||||
Description | In 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. | ||||
Tags | No tags attached. | ||||
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. |
|
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. |
|
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 | |
06.01.2024 20:17 | stgatilov | Relationship added | related to 0006359 |