branchrust_reboot/main/triggerparentdelayedexit_optimcancel
53 Commits over 0 Days - ∞cph!
Update: adding a TODO to enable minor logic caching
Tests: none, trivial change
Update: TriggerParentDelayedExit cleanup logic only runs when trigger is disabled
We always ran cleanup when OnEmpty got invoked, even if decided to delay the exit, which disabled delay functionality
Tests: built a wonky ship and jumped around gaps - parenting was in effect long enough
Bugfix: TickMode 1 - add missing overrideOtherTriggers check
Tests: none, trivial change
Update: remove dead vars and cache == null check
Tests: none, trivial change
Update: add paste_line <name> [count = 1] [offset = 1] - will spawn the clipboard in a line using player's facing with offset-sized spacing
- also if pasting players, make sure they run their ForceTriggerUpdate
- codegen
Tests: spawned a 100 boats in a line
Bugfix: TriggerParentDelayedExit::SupportsTickSkipping was always evaluating to false
- switched it to be off by default, as it was likely off during my earlier testing
Tests: none, trivial change
Bugfix: VerifyRays - avoid trying to read hit array outside of working area
I asssumed we always call it with tightly-sized arrays, but it's not the case on client
Tests: shot in the sky with a couple bursts - no NREs
Optim: TraceRaysUnordered - optimize collider validation using burst jobs
- added UtilityJobs.FlipBoolJob and ScatterToJob<T>
This brings costs down across the board:
* 128 rays - 0.37ms -> 0.25ms, 33% improvement (serial was 0.49ms, 49%)
* 1k rays - 2.59ms -> 1ms, 61% (serial was 4.33ms, 77%)
* 8k rays - 18.9ms -> 6.26ms, 67% (serial was 34.79ms, 82%)
Tests: unit tests
Optim: TraceRaysUnordered - run water traces in parallel to raycasts
Not the best impl, but shows improvement for smaller ray counts (where we're not dominated by Verify):
* TraceRaysUnordered - 128rays: 0.44ms -> 0.37ms, 1k+ rays same
* TraceRays - 128rays: 0.56ms -> 0.50ms, 1k+ rays same
Can apply the same to sphere casts as well.
Tests: unit tests
Optim: TriggerParent.TickMode 1 - use cached water and ladder results in UsePlayerUpdateJobs 2 env
- codegen
This should allow us to skip ~30% of the overall runtime. Can be disabled via TriggerParent.UsePlayerV2Shortcuts 0 (defaults to 1)
Tests: none, will check tomorrow once brain is fresh
Optim: TriggerParent.TickMode 1 - avoid unnecessary entity lookups in RunClippingChecks
Microoptim, but why not
Tests: none, trivial change
Optim: TriggerParent.TickMode 1 - skip RunClippingChecks for entities that failed RunCheckForObjUnderFeet
Tests: none, trivial change
Clean: remove a couple TODOs
Was worried about a bug, but deeper scrutiny think the code is correct
Tests: none, trivial change
Clean: refactor TriggerParent.ShouldParentEntitiesJobs
- Added profiling scopes
No functional changes. This makes data flow easier to track and manage, and helps visualizing stages in perf snapshots.
Tests: built a long-boat in tickmode 1, spawend 6 players on it, went to edit mode and back, jumped on-and-off as it was moving
Bugfix: Add missing Native collection disposal in GamePhysics
Audited all of GamePhysics, looks to be the only cases that slipped in
Tests: unit tests + built a boat with tickmode 1
Optim: use persistent buffers for TriggerParent::RunCustomJobsQueue
- codegen
Tests: with tickmode 1 - built a boat, jumped on-off
Clean: rip out tickmode 1 and 2, rename Jobs mode as tickmode 1
- codegen
Out of all versions it's fastest, so only going to continue with it vs baseline 0
Tests: compiles
Bugfix: properly clean-up TriggerParent and TriggerParentDelayedExit when it gets disabled
Reimplements intents of `139965`.
Tests: built & finished a boat, jumped around while moving, put it into edit, finished, jumped around - no errors, no extra invokes
Bugfix: TriggerParentDelayedExit - skip entity-delay logic when trigger gets disabled
This left invalid invokes running when editing existing player boat, inflating the perf cost
Tests: edited existing boat, checked profiler - saw no perf samples gor persistent queue
Bugfix: early out when double-remove happens
Not sure why yet, but saw the same with double-add before, so going to replicate. Also noticed that we can be tracked, but have null-entitycontents, which leads to wasted Invokes, adding overhead - checking
Tests: built boat, spawned npc, went to edit mode - no more errors
Update: Codegen
Tests: ran "check compile errors"
Optim: in tickmode 3, run OverlapOBB and TraceRealm queries in parallel
Should help in many-boats-players scenarios, in theory
Tests: built a boat and jumped around as it was moving
Bugfix: SelectNearestNHitsJob - ensure we emit an end if we couldn't select requested number of hits
- Added couple early returns to avoid div by 0 issues
Tests: rode a boat with tickmode 3
Update: initial full version of TriggerParent.ShouldParentEntitiesJobs
inlines ToClipping so that we can batch OverlapOBB, but doesn't batch expensive-but-rare checks - need to see if we need this during playtest
Tests: built a boat, finished it, enabled tickmode 3, tried jumping on/off the boat
Update: Added GamePhysics.OverlapOBBs
- added basic consistency unit test: TestOverlapOBBsConsistency
Tests: ran unit test
Bugfix: GamePhysics.TraceRealmRays now considers non-entity hits as valid
- fix build failures in CLIENT only mode
- also added option to specify whether to run water query or not
Tests: ran unit tests(C+S and C separately) - they pass
Tests: rework GamePhysicsTests.TraceRealms to work in C+S and C modes
No longer permitting running S realm tests in C editor (as that created impossible spawn scenarios)
Tests: ran unit test in both modes
Tests: add TestTraceRealmRays unit test
Shows that there's a bug with TraceRealmRays - will submit next
Tests: ran unit tests
Optim: Use burst to generate sort jobs
Despite replacing previous optim, saves us another 0.1ms on top of it (4.25ms -> 4.15ms avg for 2k rays). Left a comment that we need alloc-free tasks to optim further(scheduling sort jobs is expensive, but thread safe).
Tests: ran unit tests
Optim: manually kick off sort jobs to worker threads when enough is accumulated
On a 2k TestTraceRays gives us 0.15ms (4.25ms -> 4.4ms). Building jobs using burst might be faster though, gonna try that next.
Tests: ran unit tests
Bugfix: ensure we free counts array only after all sorting jobs are done
Tests: ran unit tests (though they didn't catch it before)
Tests: reduce ray count for Perf.TestTraceRay/-s to 2k
8k is too much, hangs serial rays. 2k is already very bad (3.4s avg per run for serial, 7.1ms for batched)
Tests: reran tests
Tests: Add TraceRay/-s perf tests
The numbers of serial vs batched are a bit too crazy(128 rays: 7.5ms vs 0.3ms; 1024: 716ms vs 2.2ms), but looks like managed sort is too costly. Need to investigate the 8k batched hang(5min+ )
Tests: ran the perf tests
Tests: add perf tests for TraceRaysUnsorted and TraceAllUnordered(radius == 0)
At 128 rays perf is same, at 8k we get 25% faster without water checks/41% faster with water. Need to profile deeper if we get more wins
Tests: ran the new tests
Clean: reorganize GamePhysics tests into Unit child class
Prep for Perf unit tests.
Tests: ran all relevant tests, discovered we forgot to implement 1 fully - chasing up separately
Update: made GamePhysics.TraceRays return guaranteed nearest hits
- added fast path for TraceRays with maxHits == 1
- Added tests for TraceRaysUnordered, rewrote test for TraceRays to be more thorough
Tests: ran unit tests
Update: started on ShouldParentEntitiesJobs (incorrect name)
- Simplified ShouldParentEntities (also incorrectly named)
Converted CheckForObjUnderFeet to burst jobs, need to do IsClipping internals next (needs a bunch more on the GamePhysics side)
Tests: none, not ready
Update: GamePhysics.TraceRays now supports ignore entities
- Added TraceRealmRays (not unit tested, will do that tomorrow)
- Added unit tests for TraceRays
- TraceRays skips sorting if maxHitsPerTrace is less than 2
Tests: unit tests
Update: hook up PersistentObjectQueue as well
- consolidate work scheduling to AddTo-/RemoveFromActiveTriggers
- fixed an exception when unity sends 2 OnTriggerEnter for 1 entity (not sure how, but TriggerBase handled it already)
Just the most complicated version left - custom queue with jobs
Tests: jumped on and off from moving boat
Update: hooked up the crude queue, added server var
- partial codegen (Grid<T> borkage)
- Fixed a couple bugs with invalid tracking on TriggerParents in StableObjectCache
Can move on to other queue impls
Tests: craggy, toggled default and batched mode
WIP: TriggerParent managed queue, no batching, no burst
Still need to implement using PersistentObjectWorkQueue and experiment with batched-burst queries and compare all, as this version should have a bit more overhead due to bookkeeping.
Tests: none, not plugged in
Merge: from opt_triggerparent_timeslice
- Optim: reduced component accesses and added support for triggerparent.ontick timeslicing
Tests: jumped around the boat
