PIntO WoW Scripts // Declare two variables that refer to a pawns. - - PowerPoint PPT Presentation

▶
pinto wow scripts
SMART_READER_LITE
LIVE PREVIEW

PIntO WoW Scripts // Declare two variables that refer to a pawns. - - PowerPoint PPT Presentation

Dec 06, 2023 243 likes •1.14k views

PIntO WoW Scripts // Declare two variables that refer to a pawns. var pawn P, Q; // Here is a function that makes use of P. // It displays some information about P. function MyFunction() { // Set P's enemy to Q. P.Enemy = Q; // Tell P to

slide-1
SLIDE 1

PIntO

slide-2
SLIDE 2

WoW

slide-3
SLIDE 3

Scripts

// Declare two variables that refer to a pawns. var pawn P, Q; // Here is a function that makes use of P. // It displays some information about P. function MyFunction() { // Set P's enemy to Q. P.Enemy = Q; // Tell P to play his running animation. P.PlayRunning(); }

slide-4
SLIDE 4

Potentially Interesting Objects

  • Objects register queries
  • Often restricted to clients
  • Often implicit
  • Server returns relevant objects
slide-5
SLIDE 5

Discovery Today

  • Almost universally distance based
  • “Let me know about everything within x

meters”

  • Games use imposters
  • Only simple for centrally controlled

content

slide-6
SLIDE 6

Mirror’s Edge

slide-7
SLIDE 7

Mirror’s Edge

slide-8
SLIDE 8
slide-9
SLIDE 9
slide-10
SLIDE 10

Shortcoming

  • Distance doesn’t capture what’s

important

slide-11
SLIDE 11
slide-12
SLIDE 12
slide-13
SLIDE 13
slide-14
SLIDE 14
slide-15
SLIDE 15

Solid Angle

  • Object could be far away, but big
  • Object could be nearby, but small
  • We care about apparent size or

solid angle

  • “Let me know about all objects that are

bigger than n pixels on my screen”

slide-16
SLIDE 16

Query Comparison

  • For same # of objects, better quality
  • For same quality, fewer objects
slide-17
SLIDE 17

Non-visual ?

  • Discovery, not communication
  • Reflects real “discovery”
slide-18
SLIDE 18

Outline

  • Motivation
  • Previous Work
  • BVH++
  • Continuous Queries and Cuts
  • Distributed Queries
slide-19
SLIDE 19

Implementation

  • How do we efficiently evaluate these

queries?

  • All objects with solid angle < x
  • Standing query - continuous stream of

updates

  • Not much guidance from CG literature
slide-20
SLIDE 20

Implementation

  • Doesn’t seem too different from distance

query

  • Just a slightly different constraint
  • Maybe we can reuse existing techniques
slide-21
SLIDE 21

Bounding Volume Hierarchy

C D B A

slide-22
SLIDE 22

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-23
SLIDE 23

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-24
SLIDE 24

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-25
SLIDE 25

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-26
SLIDE 26

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-27
SLIDE 27

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-28
SLIDE 28

G E

Bounding Volume Hierarchy

F C D B A A B C D E F G

slide-29
SLIDE 29

Why does this work?

  • Conservative check on entire group
  • If boundary of bounding volume is out
  • f range, contained objects must be too
  • Quickly cull large subtrees
slide-30
SLIDE 30

Outline

  • Motivation
  • Previous Work
  • BVH++
  • Continuous Queries and Cuts
  • Distributed Queries
slide-31
SLIDE 31

Solid Angle Queries

  • Use same BVH
  • Bounding volumes must have larger solid

angle

  • Recurse if bounding volume satisfies

constraint

slide-32
SLIDE 32

Results

  • 50,000 objects (1m) randomly placed
  • ver 1km2
  • 50 queriers
  • Branching factor: 10
  • Solid angle comparisons:
  • Brute force: 50,000
  • BVH: 60,466 (No culling!)
slide-33
SLIDE 33

What went wrong?

  • Too conservative
slide-34
SLIDE 34

What went wrong?

  • Too conservative
slide-35
SLIDE 35

BVH++

  • Track largest object

in subtree

  • Check against virtual

worst-case object

  • As close as

possible

  • As big as possible
slide-36
SLIDE 36

BVH++

  • Track largest object

in subtree

  • Check against virtual

worst-case object

  • As close as

possible

  • As big as possible
slide-37
SLIDE 37

Results

  • Solid angle comparisons:
  • Brute force: 50,000
  • BVH: 19,631
slide-38
SLIDE 38

Branching Factor

  • Higher branching factor potentially allows

better culling

slide-39
SLIDE 39

Branching Factor

  • Future evaluation
  • Some operations on tree are linear in

branching factor

  • Maintenance cost vs. traversal cost
  • Timing based - depends on optimized

implementation

slide-40
SLIDE 40

Outline

  • Motivation
  • Previous Work
  • BVH++
  • Continuous Queries and Cuts
  • Distributed Queries
slide-41
SLIDE 41

Continuous Queries

  • Good approach for one-off queries
  • Could just reevaluate periodically
  • How frequently?
  • Wasted effort - check same nodes

repeatedly, even if they don’t change

slide-42
SLIDE 42

Query Cuts

  • Maintain “cut” representing stopping

points of evaluation

  • Leaves
  • or internal nodes which do not satisfy

constraint

slide-43
SLIDE 43

Query Cuts

A B C D E F G

slide-44
SLIDE 44

Query Cuts

A B C D E F G

Cut - ordered list of CutNodes CutNode - stores references to parent Cut, BVH node BVH Node - stores bounds, max object size, unordered set of CutNodes

slide-45
SLIDE 45

Query Cut Updates

  • Query change (position, solid angle) causes

results to change

  • Traverse cut, pushing it up or down
  • Sequence of all children failing test

pushes cut up

  • Cut pushed down as usual
slide-46
SLIDE 46

Query Cut Updates

  • Sequence of all children failing test pushes

cut up

A B C D E F G

slide-47
SLIDE 47

Query Cut Updates

  • Sequence of all children failing test pushes

cut up

A B C D E F G A

slide-48
SLIDE 48

Query Cut Updates

  • Sequence of all children failing test pushes

cut up

A B C D E F G A

slide-49
SLIDE 49

Query Cut Updates

  • Cut pushed down as usual

A B C D E F G A

slide-50
SLIDE 50

Query Cut Updates

  • Cut pushed down as usual

A B C D E F G A F

slide-51
SLIDE 51

Query Cut Updates

  • Cut pushed down as usual

A B C D E F G A F

slide-52
SLIDE 52

Query Cut Updates

  • Due to object change (position, size)
  • or addition, removal
  • Update BVH
  • Reevaluate cuts, pushing up or down
  • BVH nodes store pointers to cut nodes

to quickly determine which nodes in which cuts require adjustment

slide-53
SLIDE 53

Query Cut Updates

  • Some BVH updates cause major

adjustments to tree

  • Merge/split
  • ... and splits can even percolate all the

way up to the root

  • insertion where all ancestors are full
slide-54
SLIDE 54

Query Cut Updates

  • Current approach
  • “Lift” all cuts to stable point
  • Mark for retraversal and update
  • Simple but expensive

A B C D E F G A

slide-55
SLIDE 55

Query Cut Updates

  • Current approach
  • “Lift” all cuts to stable point
  • Mark for retraversal and update
  • Simple but expensive

A B C D E F G A F

slide-56
SLIDE 56

Query Cut Updates

  • Current approach
  • “Lift” all cuts to stable point
  • Mark for retraversal and update
  • Simple but expensive

A B C D E F G A D’

slide-57
SLIDE 57

Query Cut Updates

  • Current approach
  • “Lift” all cuts to stable point
  • Mark for retraversal and update
  • Simple but expensive

A B C D E F G A D’

slide-58
SLIDE 58

Query Cut Updates

  • Any approach that:
  • ensures the cut remains structurally

valid

  • marks the cut for re-traversal using

update procedure

  • will work
  • More complicated solution might keep cut

closer to final cut, making update cheaper

slide-59
SLIDE 59

Considerations

  • Updating queries:
  • due to object motion can be expensive
  • due to query motion almost always

better than re-evaluating one-off query

  • Polling might be cheaper for frequent

movement, especially of objects

  • or when reevaluating position due to

velocity frequently

slide-60
SLIDE 60

Considerations

  • Trees for static vs. dynamic objects
  • Also reduces maintenance cost by

isolating frequently adjusted nodes in their own tree

  • Static tree: cut-based, event-driven queries
  • Dynamic tree: poll-based queries
slide-61
SLIDE 61

Reporting Results

  • Deltas on result set (additions, removals)
  • Sort by solid angle
  • Prioritize additions
  • But probably not the dominant factor in

quality over time

  • Downloading content likely much slower
slide-62
SLIDE 62

Outline

  • Motivation
  • Previous Work
  • BVH++
  • Continuous Queries and Cuts
  • Distributed Queries
slide-63
SLIDE 63

Distributed

  • Each space server starts out only with local
  • bjects

SS 1 SS 2

A B

Local

C D

Local

slide-64
SLIDE 64

Distributed

  • Space servers aggregate queries and send
  • ne query to each other space server

SS 1 SS 2

A B

Local

C D

Local

Q(1 -> 2) Q(2 -> 1)

slide-65
SLIDE 65

Distributed

  • Results from these queries used to

maintain global tree

SS 1 SS 2

A B

Local

C D

Local

A B

Global

C A

Global

C D B

slide-66
SLIDE 66

Distributed

  • Global tree answers queries from

connected objects

SS 1 SS 2

A B

Local

C D

Local

A B

Global

C A

Global

C D B

Q(A) Q(C) Q(D) (Object Hosts)

slide-67
SLIDE 67

What about updates?

  • Loc takes care of updates
  • PIntO triggers subscriptions in Loc

automatically

  • For other servers and connected objects
slide-68
SLIDE 68

Server Discovery

  • How do servers know to query each
  • ther?
  • PIntO service
  • Collects region, max object size, and

query from space servers

  • Answers queries about which servers

have objects that might satisfy query

  • Same data structure works!
slide-69
SLIDE 69

SS N SS 1

PIntO Conceptual Model

S S S S A C D B E F G H

PIntO Service ... Space Servers Objects

slide-70
SLIDE 70

Evaluations

  • # of servers
  • Very limited in range query (4 or 8

neighbors)

  • Potentially all servers for solid angle
  • # of objects in global tree
  • Efficiency of query aggregation
  • # objects returned in object query / #
  • bjects returned by server queries ?
slide-71
SLIDE 71
slide-72
SLIDE 72

Insertion

  • Recursively select best child node
  • Min volume increase

A B C D E F G

slide-73
SLIDE 73

Insertion

  • Recursively select best child node
  • Min volume increase

A B C D E F G X

slide-74
SLIDE 74

Insertion

  • Recursively select best child node
  • Min volume increase

A B C D E F G X F

slide-75
SLIDE 75

Insertion

A B C D E F G X

  • Split nodes as necessary
  • Possibly reorders children
  • May obtain new root
slide-76
SLIDE 76

Insertion

  • Split nodes as necessary
  • Possibly reorders children
  • May obtain new root

A B C D E F G X F’ G

slide-77
SLIDE 77

Insertion

  • Split nodes as necessary
  • Possibly reorders children
  • May obtain new root

A B C D E F G X F’ G G H

slide-78
SLIDE 78
slide-79
SLIDE 79

Deletion

  • Find leaf node (hash table)

A B C E F G D

slide-80
SLIDE 80

Deletion

  • Find leaf node (hash table)

A B C E F G C D

slide-81
SLIDE 81

Deletion

  • Remove
  • Merge parent’s children if:
  • All children are leaf nodes
  • Fewer children than branching factor

A B E F G C D

slide-82
SLIDE 82

Deletion

  • Remove
  • Merge parent’s children if:
  • All children are leaf nodes
  • Fewer children than branching factor

A B E F G D

slide-83
SLIDE 83

Deletion

  • Remove
  • Merge parent’s children if:
  • All children are leaf nodes
  • Fewer children than branching factor

A B E F G D F D

slide-84
SLIDE 84

Deletion

  • Remove
  • Merge parent’s children if:
  • All children are leaf nodes
  • Fewer children than branching factor

A B E F G D

slide-85
SLIDE 85

Deletion

  • Remove
  • Merge parent’s children if:
  • All children are leaf nodes
  • Fewer children than branching factor

A B E F G F’

slide-86
SLIDE 86
slide-87
SLIDE 87

Split

  • Select two seeds for new nodes
  • e.g. pair of objects (nodes) that cause

worst increase in volume

  • Add each object to one group
  • based again on which causes the least

harm

slide-88
SLIDE 88