Collision detection: strategies

Transcription

1 ollision detection: strategies Static ollision detection ( a posteriori, discrete ) approximated simple + quick t = 0 t = 1 NO OLL OLLISION ynamic ollision detection ( a priori, continuous ) accurate demanding t = 0 OLLISION t = 1 ollision detection: Statica ollisions check alla fine un passo ka: «static» (because objects are tested as if they are still) «a posteriori» (because coll are detected after they happen) «discrete» (bacause it is checked at discrete time intervals) Problema: non-compenetrazione violata seppur ripristinata nella collision response Problema: effetto tunnel specie se: - dt grandi, - o vel grandi, - o oggetti sottili t = 0 t = 1 NO OLLISION NO OLLISION Marco Tarini 1

2 ollision detection: inamica ollisions check fatto sul volume occupato dal collision object alla sua velocità la spazzata Vantaggio: compenetrazione prevenuta, non aggiustata «dynamic» (because moving objects are tested) «a priori» (because coll are detected before they happen) «cotinuous» (bacause it is checked over a time interval) Problema: oneroso calcolare e testare volumi spazzati facile per: punti (diventano linee) ka: facile per: sfere (diventano capsule) (come?) In pratica, usato solo per queste primitive (e quando c è bisogno: collisori veloci, collisi piccoli, non si può decrementare il dt) ollision detection: in 2 (easier problem) Same problems, same solutions e.g.: 2 spatial indexing, 2 bounding volumes (2 geom. proxies) ut we have : collision detection for 2 sprites (in screen space) accurate: «pixel perfect» efficient: HW supported! (hard wired) e.g. quad-trees (no need for collision object approximation) e.g. 2, circles NO OLLISION NO OLLISION OLLISION Marco Tarini 2

3 ollision detection Problemi di efficienza: a) test fra due oggetti: ome renderlo efficiente? b)evitare esplosione quadratica dei test N oggetti N 2 tests? ome evitare un numero quadratico di test lassi di Soluzioni: 1) strutture di indicizzazione spaziale 2) VH ounding Volume Hierarchies Marco Tarini 3

4 Spatial indexing structures ata structures to accelerate queries of the kind: I m here. Which object is around me? Tasks: (1) construction / update for static parts of the scene, a preprocessing. heap! for moving parts of the scene, an update! onsuming! (another good reason to tag them) (2) access / usage as fast as possible ommonest structures (in games): Regular Grid k-tree Oct-Tree and it s 2 equivalent: the Quad-Tree SP Tree Regular Grid (or: lattice) a b c d e f g h i j k l m n o p q r s the scene a b c d e f g h i j k l m n o p q r s Marco Tarini 4

5 Regular Grid (or: lattice) rray 3 of cells (same size) each cell: a list of pointers to collison objects Indexing function: Point3 cell index, (constant time!) onstruction: ( scatter approach) for each object [ i ] find the cells [ j ] which it touches add a pointer in [ j ] to [ i ] Queries: ( gather approach) given a point to test p, find cell [ j ], test all objects linked to it Problem: cell size too small: memory occupancy too large quadratic with inverse of cell size! too big: too many objects in one cell sometimes, no cell size is good enough k-tree G H H I N G LO J M I K N L J O M K the scene Marco Tarini 5

6 k-trees Hierarchical structure: a tree each node: a subpart of the 3 space root: all the world child nodes: partitions of the father objects linked to leaves k-tree: binary tree each node: split over one dimension (in 3: X,Y,Z) variant: each node optimizes (and stores) which dimension, or always same order: e.g. X then Y then Z variant: each node optimizes the split point, or always in the middle Quad-Tree (in 2) the (2) world often used for terrains Marco Tarini 6

7 Oct Tree (same, for 3) Quad trees (in 2) Oct trees (in 3) Similar to k-trees, but: tree: branching factor: 4 (2) or 8 (3) each node: splits into all dimensions at once, (in the middle) onstruction (just as k-trees): continue splitting until a end nodes has few enough objects (or limit level reached) Marco Tarini 7

8 SP-tree inary Spatial Partitioning tree the world SP-trees for the oncave Polyhedron proxy Marco Tarini 8

9 SP-trees for the oncave Polyhedron proxy OUT OUT OUT OUT IN OUT IN SP-tree inary Spatial Partitioning tree nother variant a binary tree (like the k-tree) root = all scene (like k-tree) but, each node is split by an arbitrary plane (or a line, in 2) plane is stored at node, as (nx, ny, nz, k) planes can be optimized for a given scene e.g. to go for a 50%-50% object split at each node e.g. to exactly one object at leaves (assuming it is always possible to split any two apart reasonable assumption) nother use: to test (Generic) Polyhedron proxy: note: with planes defined in its object space each leaf: inside or outside (no need to store them: left-child = in, right-child = out) tree precomputed for a given ollision Object Marco Tarini 9

10 Reminder: Plane VS Point test Input: a point a plane given by: its normal: a point on it: Q: on which side of the plane is? : it s the sign of,,,,,,1 the vec4 representing the plane (minus dist. of plane from orig.) VH ounding Volume Hierarchy Marco Tarini 10

11 Marco Tarini 11 VH ounding Volume Hierarchies VH ounding Volume Hierarchies G H J K M M J K G H

12 VH ounding Volume Hierarchy Idea: use the scene hierarchy given by the scene graph (instead of a spatial derived one) associate a ounding Volumes to each node rule: a V of a node bounds all objects in the subtree construction / update: quick! bottom-up: recursive (how?) using it: top-down: visit (how?) note: not a single root to leaf path may need to follow multiple children of a node (in a SP-tree: only one) Spatial indexing structures Recap Regular Grid the most parallelizable (to update / construct / use) constant time access (best!) quadratic / cubic space (2, 3) k-tree, Oct-tree, Quad-tree compact simple SP-tree optimized splits! best performance when accessed optimized splits! more complex construction / update ideal for static parts of the scene? (also, used for generic Polyhedron oll. Obj,) VH simplest construction non necessarily very efficient to access may need to traverse multiple children if uses same hierarchy of the scene-graph: not always the best ideal for dynamic parts of the scene? Marco Tarini 12

13 Physics ngine: an implementation problem Task: ynamics: (forces, speed and position updates ) simple structures, fixed workflow highly parallelizable: GPU Task: onstraints nforcement: (all the various kinds of them ) still moderately simple structures, fixed workflow still highly parallelizable: hopefully, GPU Task: ollisions etection: non-trivial data structures, hierarchies, recursive algorithms hugely variable workflow (e.g.: quick on no collision, more complex on the few exceptions) difficult to parallelize: PU but outcome affect the other two tasks (e.g. creates constraints): ==> PU-GPU communication, and ==> GPU structures updates (problematic on many architectures) Per approfondire alcuni argomenti rwin oumans SIGGRPH 2015 course Müller-ischer et al. Real-time physics (Siggraph course notes, 2008) Marco Tarini 13