Simulation Level-Of-Detail and Culling

1. Simulation Level-Of-Detail and Culling Stephen Chenney University of Wisconsin at Madison http://www.cs.wisc.edu/~schenney

2. Level-Of-Detail and Culling for Physics and AI Stephen Chenney University of Wisconsin at Madison http://www.cs.wisc.edu/~schenney

3. Preamble • Dynamics is the general term covering both Physics and AI: • Describes the motion or actions of virtual entities • Refers to all the stuff that changes over time • Simulation is the process of computing the dynamics • Computes what outcome occurs over time under a given dynamics model

4. The Problem • Large gaming environments contain lots of moving stuff • Cars in a city • Combatants in a battle • System resources are limited • CPU resources on one machine • Network resources in distributed games • How do we re-create a convincing large, complex environment?

5. Example • Say we want to create a city driving game with: • Great car physics • Great pedestrian motion • Trees waving in the breeze • Dogs chasing cats • All of these things can be individually simulated, but not cheaply • How do we re-create New York?

6. The Observation (not a new one) • Most of the world is not perceivable most of the time • Most of the world is invisible from any viewpoint • Most visible things are far away • A player’s attention may be focused on something else • We can save resources by concentrating only on what is perceivable

7. Static Geometry • Most static geometry is also not perceivable most of the time • Visibility Culling avoids considering geometry that cannot be visible • Level-of-Detail reduces the complexity of what is visible

8. Simulation Level-of-Detail • Use a cheap simulation if the motion is not easily perceived • Problems: • How is a cheaper simulation created? • How do we control the cost/error tradeoff? • Solution (for now): Cheap simulations are created by hand

9. Simulation Culling • Avoid simulating objects that are not visible • Problem: How do you know if a moving object is visible if you don’t do work to find out where it is? • Solution: Do some work, but much less than the complete simulation • In special cases, can do no work

10. Sim LOD Design Issues • It must be cheaper to simulate distant cars, people and other things • The viewer can still see the objects, so they must move reasonably at all times • The distant characters must remain consistent with the game-play • Reasonable motion may still change the game • e.g. From a distance, two cars passing very near may look reasonable, but if a crash is not found it might change the outcome of the game

11. Sim LOD Examples • One approach used in practice is to “disappear” the distant objects • Stop rendering and simulation • Looks bad and may destroy game-play • Approximate the motion to generate a coarse solution without the detail • Linear instead of higher-order motions • Cars use simple tire or suspension models • Pedestrians have fewer joints

12. Who’s Done Sim LOD (Academic) • Carlson and Hodgins, “Simulation Level of Detail” 1997 • Developed two approximations for hopping robots, and made the robots play a little game • Setas, Gomes and Rebordão, “Dynamic Simulation of Natural Environments", 1995 • A Sim LOD models for trees (hard to find) • Grzeszczuk, Terzopoulos and Hinton, “NeuroAnimator”, 1998 • Use neural networks to approximate the mapping from one state to the next

13. Hopping Robot LOD(Carlson and Hodgins) • The original hopping robot is a dynamic model • Pieces have mass/inertia • Controlled by applying forces

14. Hopping Robot LOD (2) • Second level of detail is a kinematic model • Apply accelerations directly • Acceleration profiles approximate dynamic data Dynamics Kinematics a a t t

15. Hopping Robot LOD (3) • Third level of detail is point mass • Do not move robot leg • Motion of top part fitted to dynamic data • To maintain game-play: • Switch to high-detail model when robots are near collision • Approximations are accurate enough to make sure the other things look good • Use point mass model for out-of view motion

16. Sim Culling Design Issues • We only want to use resources for things in view • The right things should be in view at the right times • Cars must enter the visible region from out of view • Things should be moving correctly when they enter the view • What is NOT a constraint? • The viewer doesn’t see out-of-view motion

17. Traditional Sim Culling • Place a boundary outside the view • Create, delete or reflect objects at the boundary • Where do you put the boundary? • Too close and the player will notice it • Too far and the sim is too expensive • But what if the things reaching the boundary are important? An ambulance? • But what if it is important to keep track of things happening a long way away? • Strategy games

18. Who’s Done Sim Culling? • Chenney and Forsyth, “Culling Dynamic Systems” 1997, 1999 • Use approximations and statistical models to cull objects that don’t move far • To some extent, the visibility community • Particularly Craig Gotsman and co-workers • To some extent, the distributed sim people • Chenney, Arikan and Forsyth, “Proxy Simulations” • Work in progress

19. Culling Dynamic Systems • Say something has been out of view, has been culled, and then re-enters • Must make a very large time-step, from last seen time to current time • Step must capture all that should have happened while the object was hidden • You turn an hourglass, look away, and turn back later. The sand should have run through • The step must be cheap, to avoid lag

20. Cheap State Updates • Use approximations to make very large time-steps • Jump in a few steps from last known to needed state • There may be error, but the player can’t detect them because the object has been out of view • Use random models for ultra large time-steps • Over such long periods out of view, any reasonable state is acceptable

21. Culling Bumper Cars • Cars move roughly in circles around the track • Can approximate by assuming a circular path and constant speed motion • Fit speed to observed data • Can randomly place cars around the track • Estimate the distribution from observed data

22. The Amusement Park • Speedups on the order of 20x, arbitrarily large if we make the park bigger

23. Tools • For certain types of simulation, automatic tools can build models for culling • Continuous, autonomous systems (no user) • Low dimension state space • Eg Pendulums, amusement park rides, traffic lights • Written in Java targeted to VRML, but could be hacked • Off my web page: http://www.cs.wisc.edu/~schenney

24. What if things move? • How do we know whether something should re-enter the view in the first place? • The paradox: • We don’t compute motion for things we can’t see • We don’t know what we can see if we don’t compute motion • Solution: Do just enough work to maintain the visibility information

25. Dynamic Visibility • The key to efficient dynamic visibility is the detection of important events • Must at least know when a moving object crosses the boundary of the view • Good way to think about game-play too • Provided we get a reasonable event stream, we will have acceptable simulation

26. Cheap Event Streams • Can run the simulation and look for the events as they occur • EXPENSIVE: must test every event on every frame, must know where everything is on every frame • Can predict when events will occur, and jump from one event to the next • Can be cheap, because no intermediate state is computed • Discrete event simulation

27. Proxy Simulations • Generate correct event streams for out-of-view objects • Some events keep track of objects’ locations • Others keep track of important interactions between objects (crash, death, …) • Applicable when costly out-of-view events are important to game-play • Strategy games, or • Very expensive motion just out of view

28. Path Planning Task • Say you have 1000’s of bots all trying to get from point A to point B • Combatants in a war-game • Obey certain rules (such as non-penetration) • Most are out of view at any given time • You want to know when they cross terrain tile boundaries • Each crossing is an event • Locations on tiles let you do visibility

29. Path Planning Proxy v1.0 • Assume that: • All bots would travel at maximum speed in a straight line • All the collision avoidance introduces delays in travel times, so they effectively go slower • To know when next event occurs: • Intersect ray in dir of travel with tile boundary • Divide dist by average speed with delay • BUT, what about the following case…

30. Why it’s Hard • Think about bots crossing a bridge • Delay depends on # of bots • If things got clogged, a player could look away • The predicted travel times would use average delays, and the backup would clear magically • Solution: Take context into account

31. Path Planning Proxy v2.0 • Use the number of bots in a tile as a parameter controlling the delay time • All the information is available • The model is more complex, and the fitting process is harder • Path Planning Proxy Demo: • A delay mode as above • More complex path-planning model avoids static obstacles

32. Path Planning Speedups

33. Fast Network Simulation? • The problem of avoiding computation is similar to that of avoiding network traffic • In distributed gaming, all the state is known somewhere • Existing systems rely heavily on servers to do “area of interest” management • We might be able to do peer-to-peer

34. Conclusion • Being able to approximate and predict motion gives major speedups • Key Idea: Decide what you care about, and aim to capture that • These are hard research problems • This technology will enhance the quality of motion in games

37. Culling Dynamic Systems • “When something comes back into view, its state should be consistent with its expected motion while out of view” • If an object doesn’t move far, the above problem is the only one to solve • Key idea: Consistent does not mean exact, it means expected

38. Viewer Expectations • We only have to get the statistics right, not the precise motion • A viewer doesn’t know exactly what should happen, only roughly what should happen • So, provided the state we show is plausible, the viewer can’t complain • Use statistical models to capture plausible states, and use sampling to choose one of them • Also use approximations in some cases

39. Dynamic Visibility • Simplest approach: On each frame, compute the actual location of the object and test its visibility • Must have precise location information for every object on every frame - expensive • Slightly better: Associate each object with a cell - all objects in visible cells are considered visible • Test for cell entry/exit on every frame, so still need precise location information

40. Better Location Tracking • If an object is out of view, it doesn’t immediately matter exactly where it is • All that matters is that it isn’t visible • Eg: only need to know which street a car is on, not where on the street it is • Temporal bounding volumes (TBVs) record where something is without giving its exact location • A region of space guaranteed to contain the object

41. TBVs for Cars in a City Car 1 on Road 2 until t=35; Car 2 on Road 2 until t = 27; Car 3 on Road 1 until t=43; Road 1 Car 3 Road 2 Car 1 Car 2 Road 3

42. TBVs and Visibility • An object is considered visible if its TBV is visible • One design issue: Make TBVs compatible with efficient visibility • If visibility uses a cell structure, use cells as the TBVs • An object’s TBV changes when it enters or leaves a cell • If a cell is visible, all the objects in it are visible

43. TBVs for Cars in a City If Road 1 is visible, then Car 3 is visible; If Road 2 is visible, then Cars 1 and 2 are visible; If Road 3 is visible, no cars are visible; Road 1 Car 3 Road 2 Car 1 Car 2 Road 3

44. Advantages of TBVs • Integrate easily into visibility schemes • Only need to be able to say whether the region (whatever its shape) is visible • Last for many frames: • Objects need not be considered on every frame, any computation serves for several frames • Visibility data structures need not be fully recomputed on every frame • Some experience in computing them • Collision detection and rigid-body simulation

45. Simulation with TBVs • Basic data structures: • A priority queue of events - an event for the time each object leaves a cell it’s in, one one for when it enters a new cell • Each object stores the cells it is in • Each cell stores the objects in it • Main loop repeatedly processes event with earliest time

46. TBVs for Cars in a City At time t=27, Car 2 moves onto Road 3; Update the road that Car 2 is on, and update the Cars on Roads 2 and 3; Schedule a new event time for Car 2 Road 1 Car 3 Road 2 Car 1 Car 2 Road 3

47. Computing TBVs • Computing effective TBVs is an open research area • Good bounds exist for: • Ballistic rigid-body motion • Simple motions, like straight line motion • Not so good bounds exist for maximum-speed motion • Very loose if object infrequently moves at maximum speed

48. TBVs as Guarantees • A TBV guarantees the location of an object for some period • If the TBV is wrong, the player will experience the wrong thing! • Consider a traffic bottleneck - a bridge • A TBV guarantees which side of the bridge the car is on • If is updated incorrectly, the car could cross the bridge too fast or too slow • A player could cheat by looking away!!!

49. Case Study: Cars in City • Cars (tricycles) move through city • Random direction choices at intersections • Stop-sign traffic rules • Tight coupling between motions of cars makes it hard • We care that these properties are maintained • Specifically, we will check that travel times are maintained • Indicative of errors, and things like correct density follow from correct travel times

50. City Model