Assets and Dynamics Computation for Virtual Worlds

1. Assets and Dynamics Computation for Virtual Worlds Sheldon Brown, UCSD Site Director CHMPR Daniel Tracy, Programmer, UCSD Experimental Game Lab Kristen Kho, Programmer, UCSD Experimental Game Lab Erik Hill, Programmer, Experimental Game Lab

2. Scalable City Architecture • The Scalable City project has required larger, more interactive environments than previously practical. • Its development has resulted in many novel techniques.

3. Overview of Dynamics • Scalable City software built to handle large, temporally coherent environments efficiently. • Incremental processing methods • Minimize required work • Example: Physics performance • Resting objects do not affect run-time • Overhead proportional to level of activity, rather than environment scale

4. Spatial Proximity Determination • Sweep and Prune: O(un⅔ + (i + r)n + e + o)

5. Spatial Proximity Determination • Hybrid S&P: O(u + (i + r) + e)

6. Incremental Physics Pipeline • Novel method for processing resting bodies and potential activations caused by collisions. • Again, asymptotically superior performance.

7. Incremental Physics Pipeline Increasing bodies at rest (not being interacted with) in the simulation

8. Parallelizing Physics • Multi-threaded physics engine • Parallelized traditional physics engine components without altering algorithms

9. Client/Server Data Synchronization • Due to high interactive object count, determining minimum data set to synchronize a client is challenging. • What we could not do due to performance constraints: • Clients could not retain knowledge of all objects • Server could not traverse object set for sake of client updates • Server could not efficiently track client knowledge

10. Client/Server Data Synchronization • Our solution utilized: • Spatial proximity detector producing player/object mapping to zones. • Each state change associated with a rule that determined the set of clients to update without explicit object-level knowledge of client state. • All events placed in order-dependent queue with common format. • Result: No measurable overhead for synchronization.

11. Rendering Optimizations • Roads and fences consist of many simple objects that require animation. • Drawing many simple objects is sub-optimal. • Animation updates constrain solutions • New system treats all roads in a city as a single, large mesh with subset of vertices animating • Single draw call, geometry retained on GPU

12. Example: Rendering Optimizations GPU Buffer • We mirror vertices in CPU memory and transfer changes to GPU each cycle. • Transferring updates to GPU has trade-offs • Each operation incurs an overhead that is a “constant plus bytes” transferred. • Optimal for full update is a single, continuous transfer. • Optimal when no updates are necessary is “do nothing”! • Our case is an unknown subset of updates requiring transfer. CPU Buffer

13. Example: Rendering Optimizations • Goals: • Ideal performance on full updates • Ideal performance on few updates • “Graceful degradation” in between • Set of updates will have clusters • Many associated vertices animating together • We want to minimize cost of updating GPU • Divide-and-conquer algorithm

14. Example: Rendering Optimizations GPU Buffer • Accumulate update positions into ranges: • if # updates significant % of range • transfer whole range • else • split ranges on largest gap and recursively call for both sides • Algorithm provides good performance for conditions in which there’s a trade-off between transferring contiguous bytes and limiting total data transferred. CPU Buffer