Source 2 Multi-Threaded Physics Dispatch and VScript Architecture: Fundamental Mechanics and Deep Mathematical Modeling

[Grace Rogers]

I’ve been digging into how Source 2 actually partitions physics work across the thread pool, and I’m trying to understand the work-stealing mechanics behind the dispatcher. When the main physics thread gets overloaded with broad-phase collision queries, does the job system use a deques-per-worker model with LIFO stealing, or does it rely on a central queue with FIFO ordering? Plus importantly, how does the scheduler decide when to spin up additional worker threads versus letting idle cores sleep—is there a configurable threshold, and does that threshold shift dynamically based on frame-time pressure during competitive matches?

Second question is about VScript integration and deterministic replay. When VScript callbacks inject into the physics tick, are they marshalled onto a dedicated job or executed inline on the main thread? That distinction matters a lot for replay determinism, because if script-driven entity forces aren’t serialized consistently across frames, the memory state could drift between recorded and replayed runs. Has anyone actually benchmarked job system scalability past 8 cores on modern hardware—do you see linear gains, or does contention on the physics lock cause diminishing returns?

Battlestation:

"• Processor: i5-13600K"

"• Graphics: RX 7800 XT"

"• Memory: 32GB DDR5 6000MHz CL30"

[Author]

Posts