1. Multi-user Extensible Virtual Worlds Increasing complexity of objects and interactions with increasing world size, users, numbers of objects and types of interactions. Sheldon Brown, Site Director CHMPR, UCSD Daniel Tracy, Programmer, Experimental Game Lab Erik Hill, Programmer, Experimental Game Lab Todd Margolis, Technical Director, CRCA Kristen Kho, Programmer, Experimental Game Lab Future Optimizations

2. Multi-User Load Challenges Communications Graphics Rendering Geometry Processing Shaders Rendering techniques Dynamics Computation Physics AI or other application specific behaviors Animation

3. Communication Optimizations Reduce transmission frequency – Present frequency is unrealistic for internet traffic – Server and client will run internally at higher frequency – Client requires methods to produce smooth experience Allow Client to do more work – Client-side interpolation for smoothing movements – Predictive path computation (dead reckoning) – Compensates when server is lagging – Requires dynamics computation on client mimicking server – Preload static animations, simplify synchronization – Re-perform deterministic work – Rebuild assets with deterministic generators

4. Communication Optimizations Reduce transmission frequency – Present frequency is unrealistic for internet traffic – Server and client will run internally at higher frequency – Client requires methods to produce smooth experience Allow Client to do more work – Client-side interpolation for smoothing movements – Predictive path computation (dead reckoning) – Compensates when server is lagging – Requires dynamics computation on client mimicking server – Preload static animations, simplify synchronization – Re-perform deterministic work – Rebuild assets with deterministic generators

5. Client-side Interpolation Both Server and Client operate at 60 fps Communication only occurs at ~10 fps Client slightly behind Server (0.1s) ServerClient 0 10 20 30 Present time on Server Present time on Client

6. Client-side Interpolation Interpolation provides intermediate values Provides smoother animation Drawn to Screen Positions From Server

7. Communication Optimizations Reduce transmission frequency – Present frequency is unrealistic for internet traffic – Server and client will run internally at higher frequency – Client requires methods to produce smooth experience Allow Client to do more work – Client-side interpolation for smoothing movements – Predictive path computation (dead reckoning) – Compensates when server is lagging – Requires dynamics computation on client mimicking server – Preload static animations, simplify synchronization – Re-perform deterministic work – Rebuild assets with deterministic generators

8. Client-side Predictive Path Computation Client may sometimes experience high latency between Server updates Endemic to TCP/IP over internet Client cannot be too far behind server without producing a lack of responsiveness on client – Even with interpolation, high latency response to user input – Requires “turning down” interpolation rate and increasing communication frequency – Use predictive path computation to provide interpolation with future targets

9. Client-side Predictive Path Computation Server copy injected into the client Performs same work on subset of data for prediction Server state may differ from prediction – Client continues to smoothly interpolate between user’s understanding and new destination from server Client Server

10. Communication Optimizations Reduce transmission frequency – Present frequency is unrealistic for internet traffic – Server and client will run internally at higher frequency – Client requires methods to produce smooth experience Allow Client to do more work – Client-side interpolation for smoothing movements – Predictive path computation (dead reckoning) – Compensates when server is lagging – Requires dynamics computation on client mimicking server – Preload static animations, simplify synchronization – Re-perform deterministic work – Rebuild assets with deterministic generators

11. Preloading Static Animations Present communication for animation is most general purpose – Communicates each vertex/face alteration separately – Designed for case of dynamic geometry generation on the server – Also works for statically known animations, but requires more bandwidth Specialize communication – Pre-loading animations done during city loading – Animation updates consist of animation id and an interpolation point – Animation geometry recomputed on the client

12. Communication Optimizations Reduce transmission frequency – Present frequency is unrealistic for internet traffic – Server and client will run internally at higher frequency – Client requires methods to produce smooth experience Allow Client to do more work – Client-side interpolation for smoothing movements – Predictive path computation (dead reckoning) – Compensates when server is lagging – Requires dynamics computation on client mimicking server – Preload static animations, simplify synchronization – Re-perform deterministic work – Rebuild assets with deterministic generators

13. Rebuilding Assets Deterministically Many assets generated algorithmically – Geometry landscape from satellite height map data – Animated roads from landscape & configuration – Lots and animated fences from roads & landscape – House piece, tree, and sign placement Regenerate on client after making deterministic – Challenge in some cases is determinism – Similar algorithm & seed values produce same results Reduces communication during city loading – Preloading static animations increases strain – Uses client compute resources to compensate

14. Multi-User Load Challenges Communications Graphics Rendering Geometry Processing Shaders Rendering techniques Dynamics Computation Physics AI or other application specific behaviors Animation

15. Lot-House selection Logical entities called “lots” grab house pieces to form structures on the landscape Our global broad phase solution quickly determines the set of local house pieces for each lot However, searching the set of those nearby pieces for proper state and texture criteria is now taking a ‘lot’ of time! –All lots in multiple landscapes can now be active at once! –For some cities, lots search over most of the landscape through thousands of house pieces

16. Lot-House selection Lot-HousePiece relationships must be specialized upon a lot’s selection criteria –Both lot & housepiece criteria can change dynamically Eliminating search: Incremental Processing Approach –All processes should be triggered when house piece & lot criteria change –No polling should occur each cycle to find candidate Expand relationship and state-aware system into a more unified and flexible subsystem –Planned changes should reduce overhead from “highest” to “immeasurably small”

17. Identifying the Bottlenecks Communications Graphics Rendering Geometry Processing Shaders Rendering techniques Dynamics Computation Physics AI or other application specific behaviors Animation

18. Next Portion: Future Dynamics & Rendering Optimizations Server: Integrate compute accelerators Physics multistep approach –Step 1: »Cell BE with Bullet variant »Xeon Blades with Scalable Engine –Step2: »OpenCL physics engine across multiple platforms Client: OpenCL-based particle systems Geometry & shader processing on GPU