Post on 25-Dec-2015
2
Thatcher Ulrich’sChunked LOD Demo
• Shown at SIGGRAPH 2002
• He has put new data sets on his web page since then
http://www.tulrich.com/geekstuff/chunklod.html
4
Vectors vs. “Axial Vectors”
• or, covariant vs. contravariant forms• or, “physical quantities” vs.
“relationships between physical quantities”
• (simple demo on whiteboard)
• Clifford Algebra• Differential Forms
5
Vectors vs. “Axial Vectors”References
• “Computer Graphics: Principles and Practice” by Foley, van Dam, Feiner, Hughes
• “Jim Blinn’s Corner: Notation, Notation, Notation” by Jim Blinn
6
Batching Geometry by Material
• Still helps even for software rendering, due to cache effects– Provided the rest of your renderer is tight
enough!
8
SLERP
• “Spherical Linear Interpolation”
• Popularized in graphics by Ken Shoemake
• Search for his name on the Web to find a lot of related papers
9
Deriving ‘SLERP’
• For arbitrary-dimension vectors
• Useful for interpolation of rotations, vertex normals, etc.
10
Source Control Systems
• Editorial regarding the flaws in current source control systems
• They should be a valuable tool but instead they are often a nuisance, and at best only alleviate some problems of multi-programmer development
11
Source Control:Visual Source Safe
• Non-Atomic Transactions
• Manual Check-Out -- unacceptable
• Bad Integration (doesn’t even work in vc7!)
12
Source Control:CVS
• Bad at binary files• Bad at directory versioning• Leaves annoying CVS/ directories
everywhere in your source tree• Too difficult for non-programmers to use
– Emphasize the need for a general asset management system
• Maybe ‘subversion’ will fix these problems– subversion.tigris.org
13
Source Control:Perforce, AlienBrain, etc
• Cost money
• Better interfaces than SourceSafe and CVS
14
Forward Declaration:Macros and typedefs
• … are bad because they can’t be forward-declared!
• (FILE *), (size_t)
15
Network Architecture
• Introduction
• Peer-to-Peer, Client/Server, Hybrid
• Lockstep versus Updated– Lockstep is supposed to simplify life but it can
cause software engineering problems! (Shadow Warrior)
16
Client/Server
• Big bandwidth responsibility– Everquest bandwidth bill
• But part of this is the Everquest guys’ fault for writing poor low-level communications
• You control the server– Unless someone hacks you
17
Peer-to-Peer, Hybrid
• Peer-to-peer does not scale
• Hybrid requires very difficult software engineering (handling dropouts, lag, etc)
• Hybrid still cannot solve the “malicious user” problem
18
Cheating
• Cheating has ruined several games– Diablo 1 and 2
• It has hurt others tremendously– Counter-Strike
• Sometimes games can recover by fixing the cheat….– Ultima Online
19
Counter-Strike / Half-LifeNetworking Update
• Yahn Bernier’s lecture from GDC 2000, “Half-Life and Team Fortress Networking”
• Susceptible to internal and external hacking– Executable modifications– Clock speed hacks / DLL replacement
20
Client/Server architecturesare the safest against cheating
• When they have a “don’t trust the client” philosophy
• But this is actually difficult to do, and get good performance– Example of player motion in a shooter
• Example of my first 3D game (bad-feeling motion)
21
Governing Systems
• Idea: Can we let the client be authoritative, without trust?
• Let the client say what it’s doing, but only believe the client within limits
• Difficult
22
TCP vs UDP
• TCP provides reliability
• But it also serializes, which is usually bad– “reliable, ordered delivery”
23
TCP vs UDP
• UDP is not reliable
• Unfortunately, UDP packets have a big header size
• TCP Header Compression is very useful, but generally does not apply to UDP
24
Types of Messages
• Some things we want reliably delivered, and sometimes even ordered– Object creation/destruction– Chat messages
• Some things we don’t– Position updates
25
A Common Solution
• Use TCP for reliable messages, UDP for unreliable messages
• This has drawbacks– Example of multiple entity creation/destruction,
“fireworks”– Old bug in windows 95/98
26
How to Solve This?
• Many TCP channels per client?
• Inelegant, and may not solve the problem– If organized by semantics, won’t solve the
entity deletes problem!
27
The Best Solution
• Implement your own reliable delivery in UDP
• Requires some work, but your code becomes more unified– Unification is important!
• You have the option of implementing more sophisticated reliability than ACK/retransmit
28
Traditional Reliable Delivery
• Buffer the packet bytes in the network layer, and re-send that exact message
29
Application-Centric Reliable Delivery
• Can modify the contents of the packet to reflect the most recent information
• Examples– Health bar update– Object creation– Toggle variable
• Latency is effectively reduced in the case of retransmits
30
Dealing with NATand lobby servers
• NAT = “network address translation”
• Example of people on a LAN connecting to a lobby
31
Deciding What To Transmit
• Limited bandwidth to fit all entity updates into– Apportion this out into slices somehow?– Can we do this without adding latency? A hard
problem!
• Need to accept the fact that the client won’t be perfectly updated about everything, always a little bit wrong
• Approach network communications as an error minimization problem
32
Deciding What To Transmit• Need a metric for the amount of error
between object on client and server– Position, orientation, state variables– Probably attenuated by distance to deal with
viewpoint issues!– What about a rocket with contrail attached?
• Record the world state that you sent to the client, and diff it against current state– A lot of memory!– A lot of CPU!
33
There is a lot of coherence between clients’ world views
• We ought to be able to exploit that
• Example of objects that move a lot– They will have high error in all world views
• How do we detect “a lot of motion”?– Should not use average distance traveled per
frame– Localize within a neighborhood box?– Measure vector-valued variance!
34
Variance of a vector
• Also: “Covariance” of the vector components
• “Variance/Covariance Matrix” of components
• (demo)
• Can be filtered, like scalars, to approximate where something has been over different periods of time