Dla małej ilość elementów algorytm „brute force” jest bardzo efektywny. Nieskomplikowany, polegający na tym że bada się kolizje każdego z każdym.

Problem jednak powstaje przy większej ilości obiektów dla których kolizje musimy sprawdzić. Ilość wywołań metody checkCollision() dla n liczby obiektów rośnie dość szybko O((n2-n)/2). Brute force zaczyna tak obciążać procesor że fps odczuwalnie spada. Trzeba poszukać rozwiązania… a tych wcale nie jest mało…

Spatial Hashing

Chyba najprostsza metoda grupowania obiektów. Na obszar gry „nakładamy” siatkę i zapamiętujemy referencję do obiektu w każdej komórce siatki nad którą obiekt się znajduje.

Jest trochę problemów z optymalnym dopasowaniem wielkości komórki, ale zysk i tak będzie spory. Badamy kolizje tylko tych obiektów które znajdują się w tych samych komórkach.

Test dla 500 obiektów i porównanie z algorytmem brute force:

Dobra – źle nie jest… ale i tak nie czułem pełni satysfakcji po napisaniu… otóż Michaela Baczynski na potrzeby silnika motor2 napisał quadtree – też algorytm do grupowania obiektów. I cholera… jego jest szybszy… i to dużo.

Nie jestem tak dobry jak myślałem… Tylko że do zwykłych gier quadtree średnio się nadaje. Ma tą wadę iż dla obiektu będącego na środku i tak musimy zbadać kolizje z wszystkimi innymi obiektami – a gry robię tak że postać (dla której badam kolizje) przeważnie jest na środku. Czyli tak średnio…

No nić pozostaje mi tylko zoptymalizowanie silnika „spatial hashing”… bo przecież szybszy być musi…

Skorzystałem do budowy struktury danych udostępnione przez Michaela Baczynskiego. Zresztą test też jest jego pomysłu.

Źródła:
Struktury danych
Collision Detection
Spatial hashing implementation