Chapter Six Systems Design

1
Chapter Six - Systems Design

• One Thread, Multiple Threads 147
• With One Thread . . . 147
• With Multiple Threads . . . 152

• Important Subsystems 156
• Real-Time Rendering Polygon Culling and
  Level-of-Detail Processing 157
• Real-Time Collision Detection and Response 165
• Computational Resource Management 174

2
Chapter Six - Systems Design

• Conclusion 175
• References and Further Reading 176

• The reading collection at the back of this
  chapter is key to really being able to build a
  NetGame system.

3
What does NetGame software look like?

• One Thread, Multiple Threads
• Important Subsystems
• Real-Time Rendering - Polygon Culling Level of
  Detail Processing
• Real-Time Collision Detection and Response
• Computational Resource Management
• Interaction Management

4
Single ThreadNetGame
5
(No Transcript)
6
Real-Time Rendering - Polygon Culling LODs

• The Generate New Picture box on the previous
  slide is somewhat misleading.
• It is not that simple unless we have unlimited
  graphics power. We usually dont.
• Most of the time we are trying to solve the
  Polygon Culling Problem.
• We try to use available CPU cycles to throw away
  most of our 3D model before we send it through
  the graphics pipeline ...

7
Real-Time Rendering Polygon Culling and
Level-of-Detail Processing

• But we some 1.5B polygons per second so maybe
  this becomes less of a problem ...

8
Hierarchical Data Structures for Polygon Culling

• The classic reference for this is the 1976 paper
  by James Clark Hierarchical Geometric Models for
  Visible Surface Algorithms.
• The idea in the Clark paper is to build a
  hierarchical data structure for the displayable
  world ...

9
Hierarchical Data Structure for the Displayable
World
10
Real-Time Collision Detection and Response

• Movement through our NetGames requires that we
  have some way to determine if we have collided
  with the surfaces in our world so that we can
  stop our movement or react to the collision.
• Interactivity in our NetGames requires that we
  have some way of reaching out and touching an
  object in our game, being able to determine what
  we touched and then being able to react.
• Both Movement Interactivity require real-time
  collision detection response.
• And that is a fine way to consume processor
  cycles ...

11
Real-Time Collision Detection Response

• A Short Survey on Collision Detection
• The problem of collision detection has been
  explored in the literature of computer graphics,
  robotics, computational geometry, computer
  animation, and physically-based
• modeling.

12
Real-Time Collision Detection Response

• Numerous approaches based on geometric
  reasoningDK90, bounding volume hierarchy
  Hub96, spatial representation GASF94, NAT90,
  numerical methodsCam97, GJK88, and analytical
  methodsLM95, Sea93 have been proposed.

13
Real-Time Collision Detection Response

• However, many of these algorithms do not satisfy
  the demanding requirements of general-purpose
  collision detection for NetGames.

14
Real-Time Collision Detection Response

• By unifying several techniques from previous work
  Lin93, exploiting temporal and spatial
  coherence, and utilizing locality and
  hierarchical data structures, the research team
  at UNC has developed several collision detection
  algorithms and systems targeted toward
  large-scale, interactive simulation environments,
  including I-COLLIDECLMP95, RAPIDGLM96, and
  V-COLLIDEHLC 97.

15
Real-Time Collision Detection Response

• Public domain code is available for ftp at
  www.cs.unc.edu/ geom.

16
Real-Time Collision Detection Response

• References
• Cam97 S. Cameron. Enhancing gjk Computing
  minimum and penetration distance between convex
  polyhedra. Proceedings of International
  Conference on Robotics and Automation, 1997.
• CLMP95 J. Cohen, M. Lin, D. Manocha, and M.
  Ponamgi. I-collide An interactive and exact
  collision detection system for large-scale
  environments. In Proc. of ACM Interactive 3D
  Graphics Conference, pages 189196, 1995.

17
Real-Time Collision Detection Response

• DK90 D. P. Dobkin and D. G. Kirkpatrick.
  Determining the separation of pre-processed
  polyhedra A uni ed approach. In Proc. 17th
  Internat. Colloq. Automata Lang. Program., volume
  443 of Lecture Notes Comput. Sci., pages 400413.
  Springer-Verlag, 1990.
• GASF94 A. Garcia-Alonso, N. Serrano, and J.
  Flaquer. Solving the collision detection problem.
  IEEE Comput. Graph. Appl., 143643, May 1994.

18
Real-Time Collision Detection Response

• GJK88 E. G. Gilbert, D. W. Johnson, and S. S.
  Keerthi. A fast procedure for computing the
  distance between objects in three-dimensional
  space. IEEE J. Robotics and Automation, vol
  RA-4193203, 1988.
• GLM96 S. Gottschalk, M. Lin, and D. Manocha.
  Obb-tree A hierarchical structure for rapid
  interference detection. In Proc. of ACM
  Siggraph'96, pages 171180, 1996.

19
Real-Time Collision Detection Response

• HLC97 T. Hudson, M. Lin, J. Cohen, S.
  Gottschalk, and D. Manocha. V-collide
  Accelerated collision detection for vrml. In
  Proc. of VRML Conference, pages 119125, 1997.
• Hub96 P. M. Hubbard. Approximating polyhedra
  with spheres for time-critical collision
  detection. ACM Trans. Graph., 15(3)179210, July
  1996.

20
Computational Resource Management

• In our multi-threaded NetGame system, there is
  one fundamental question above all
• How do we make sure the threads of our NetGame
  dont hog the processors?

21
(No Transcript)
22
Threads Shared Memory
23
Threads versus Processes

• Creation of a new process using fork is expensive
  (time memory).
• A thread (sometimes called a lightweight process)
  does not require lots of memory or startup time.

24
fork()
fork()
25
pthread_create()
Process A Thread 1
pthread_create()
Process A Thread 2
Stack
26
Multiple Threads

• Each process can include many threads.
• All threads of a process share
• memory (program code and global data)
• open file/socket descriptors
• signal handlers and signal dispositions
• working environment (current directory, user ID,
  etc.)

27
Thread-Specific Resources

• Each thread has its own
• Thread ID (integer)
• Stack, Registers, Program Counter
• errno (if not - errno would be useless!)
• Threads within the same process can communicate
  using shared memory.
• Must be done carefully!

28
Thread Creation

• pthread_create(
• pthread_t tid,
• const pthread_attr_t attr,
• void (func)(void ),
• void arg)
• func is the function to be called.
• When func() returns the thread is terminated.

29
pthread_create()

• The return value is 0 for OK.
• positive error number on error.
• Does not set errno !!!
• Thread ID is returned in tid

30
Thread IDs
Each thread has a unique ID, a thread can find
out it's ID by calling pthread_self(). Thread
IDs are of type pthread_t which is usually an
unsigned int. When debugging it's often useful to
do something like this printf("Thread
u\n",pthread_self())
31
Thread Arguments
When func() is called the value arg specified in
the call to pthread_create() is passed as a
parameter. func can have only 1 parameter, and
it can't be larger than the size of a void .
32
Thread Lifespan
Once a thread is created, it starts executing the
function func() specified in the call to
pthread_create(). If func() returns, the thread
is terminated. A thread can also be terminated
by calling pthread_exit(). If main() returns or
any thread calls exit()all threads are terminated.
33
Detached State
Each thread can be either joinable or
detached. Detached on termination all thread
resources are released by the OS. A detached
thread cannot be joined. No way to get at the
return value of the thread. ( a pointer to
something void ).
34
Joinable Thread
Joinable on thread termination the thread ID and
exit status are saved by the OS. One thread
can "join" another by calling pthread_join -
which waits (blocks) until a specified thread
exits. int pthread_join( pthread_t tid,
void status)
35
Shared Global Variables
Sharing global variables is dangerous - two
threads may attempt to modify the same variable
at the same time. Just because you don't see a
problem when running your code doesn't mean it
can't and won't happen!!!!
36
Avoiding Problems

• pthreads includes support for Mutual Exclusion
  primitives that can be used to protect against
  this problem.
• The general idea is to lock something before
  accessing global variables and to unlock as soon
  as you are done.
• Shared socket descriptors should be treated as
  global variables!!!

37
pthread_mutex
A global variable of type pthread_mutex_t is
required pthread_mutex_t counter_mtx PTHREAD_M
UTEX_INITIALIZER Initialization to
PTHREAD_MUTEX_INITIALIZER is required for a
static variable!
38
Locking and Unlocking

• To lock use
• pthread_mutex_lock(pthread_mutex_t )
• To unlock use
• pthread_mutex_unlock(pthread_mutex_t )
• Both functions are blocking!

39
Thread Safe library functions

• You have to be careful with libraries.
• If a function uses any static variables (or
  global memory) its not safe to use with threads!

40
Thread Summary
Threads are awesome, but dangerous. You have to
pay attention to details or it's easy to end up
with code that is incorrect (doesn't always work,
or hangs in deadlock).