 |
First I committed generic and minor fixes/improvements, completely unrelated to the problem: r10808 Fixed bug in idWinding::ClearFree. r10809 Fixed self-assignment in idList and idHashIndex. r10810 idRenderWorldLocal::TraceAll: quickly retunr false for zero-length rays. r10811 Support TF_DEFAULT filtering in CPU-side idImage sampling. r10812 Added idList::FillZero method + converted some usages. The following commits contain generic but more involved improvements: r10813 Support debug polygons with depthtest = false. r10814 Added idRenderWorld::DebugFilledBox method. r10815 Implemented exponential search algorithm. r10816 Exposed cubemap sampling on CPU as idImage::Sample method. r10817 Added a way to make image CPU-resident during runtime. r10818 Refactor loading particle collisions texture using new defer mechanism. r10819 Implemented generic Poisson sampling. I tested this stuff independently, it should work fine =) Finally some commits specific to the new system: r10820 Added idRenderModel::GetLoadVersion method to detect model reloads. r10821 Now it is possible to generate point samples on idRenderModel. r10822 Added LightEstimateSystem + LightQuerySystem to track light intensity at various objects. The last is the main one: it adds both halves of the huge system. The testmap is here: r17085 Added test map for debugging LightEstimateSystem. So the new stuff is in trunk now, and it is possible to enable it by setting "g_lightQuotientAlgo 1". However, I have not enabled it as new default yet. I'm afraid I'll have to review all the usages because the new system work correctly only if you continuously "track" entities. And the old system seems to enjoy quering intensity at random instant moments and doing nothing after that. Debug visualization is controlled by cvar "g_showLIghtQuotient". Also there are various settings in cvars "g_les*". |
|
|
Some generic fixes and improvements of LES: r10827 Set residency IR_BOTH if image is not found => defaulted. r10828 idRenderWorld::TraceAll now passes RenderEntity handle into filter too. r10832 Save/restore Light Estimate System. And some commits for integration: r10829 Updated default track duration from 300 ms to 10 sec. r10833 Always track dead/unconscious AI bodies and dropped melee weapons in LES. I tried looking the code which uses GetLightQuotient, and there are just too many nested usages. That's why I concentrate on the cases where it is actually requested all the time, and they are: 1) dead/KOed AI bodies 2) dropped melee weapons 3) alive AIs Cases 1,2 should be covered now since they are simply tracked all the time. Case 3 is partly covered by default track duration larger than visual stim period, the first stim will most likely return zero value though. P.S. I have noticed that there are tons of non-entity queries into the old LAS. Replacing them with the new LES will be hard =( |
|
|
I looked into non-entity queries into LAS: LAS.queryLightingAlongBestLine: Only used in idEntity::GetLightQuotient, which I replaced completely LAS.queryLightingAlongLine: idAI::GetMaximumObservationDistanceForPoints(p1, p2) -> float CanSeePositionExt(pos, fov, lit) -> bool script canSeePositionExt never used with lit = true (there are other C++ usages with lit = false) idEntity::GetLightQuotient This is completely replaced CDarkmodAASHidingSpotFinder::TestHidingPoint(TONS of args) This whole class is dead because cv_ai_search_type = 4 CSearchManager::GetNextSearchSpot(Search*, idAI*, idVec3&) Only used when canSearchCooperatively = 0, which is non-skelly undead, spiders, non-humanoids. So it seems that all queries into LAS were disabled, except for rare monsters. I guess people simply don't bother about how properly these monsters search, since they are not sentient. I think we can simply drop illumination check in this case, then they should behave like humaniods I believe. |
|
|
Oops, I think I missed some more usages of GetMaximumObservationDistanceForPoints. CanSeeTargetPoint(pt, entity, lit) CanSeeRope State::OnVisualStim in case of door GetObservationPosition(pt) script getObservationPosition used by observer_ai script CSearchManager::JoinSearch if destination is unreachable In case of doors/ropes, I can probably support "light of this point on this entity" query. (TEST EDIT) |
|
|
More commits: r10834 g_lightQuotientAlgo is now global cvar, and we can disable LAS completely. r10835 Now LightQuerySystem processes queries in parallel using job system. r10836 Disabled parallel LightQuerySystem processing. r10837 Accelerate bounding box check in TraceAll, don't instantiate dynamic models for it. r10844 Set g_lightQuotientAlgo 1 by default. So the new system is now enabled, and works for entities (bodies, weapons). Also I believe I redirected point queries from LAS to entity queries in the new system (ropes, doors). I don't remember if any queries to LAS remain, but now it is easy to check: "g_lightQuotientAlgo 2" prints warnings on such queries. |
|
|
I guess I did not finish this task completely. g_lightQuotientAlgo is still 1, so the old system still coexists along with the new one, and is probably used for something. In the best case it did not go through enough testing, in the worst case I noticed some problems and stopped there. The work should be continued after 2.13. |
|
|
A bit more progress: r10998 Ignore lighting conditions in idAI::GetObservationPosition. r10997 Completely disable old LAS code in favor of new "Light Estimate System". From now on we'll see console warnings like "darkModLAS::queryLightingAlongLine disabled!" if some calls still try to reach the old LAS. |
|
|
Looking at 0006623 (missing items not detected), now I'm rethinking the tracking issue. I think it would be better to drop hardcoded tracking (currently exists for guard bodies and dropped melee weapons) and just rely fully on auto-tracking on every request. To make this work, we just need to make sure the light-factor queries for an entity come frequently enough, so that 1) tracking does not end before, and 2) guard does not pass by the entity. I guess I'll bump visual stim frequencies to the delay of 500 ms at most, except for "alive guard" stims, which are known to cause performance issues in densely-inhabited missions (i.e. "AT1: Lucy"). Another issue I have noticed is that guards no longer detect blood markers (which are left after killing a guard in combat using broadheads of sword). I tracked this issue down to a very funny fact: "atdm:blood_marker" does not have any model, thus LightEstimateSystem cannot produce any sample points on its geometry, thus it is always fully unlit. I guess the proper fix would be assigning an appropriate model/mesh to blood markers, something like a box of approximately the right size... Okay, the same happens for "atdm:absence_marker", I suppose. This entity has no geometry, so it stays unlit. |
- Anonymous
