Predlazem ti upotrebu quadtree-a da bi efikasno pronasao koje objekte trebas da ukljucis u "jednom stepu" kretanja kontrolisanog ode-om. Drugim recima, fizicke objekte podeli u dve grupe... oni koji su u stabilnom stanju (neaktivni) i oni koji se krecu (aktivni) i upisi ta stanja u nodove u poslednjem nivou qt (listu svih fizickih objekata i broj aktivnih i neaktivinih). Ako AABBox zauzima vise nodova dodaj isti taj objekta u sve nodove u odgovarajucu grupu (akt/neak) kao i u listu. Zatim u parent node upisu broj aktivnih i neaktivnih objekata iz child nodova i tako sve dok ne dodjes do najstarijeg noda (TN). U njemu ces imati broj aktivnih i neaktivnih nodova (sto se fizike tice). Sad mozes brzo da nadjes da li postoji razlog da pokreces ODE u nekom frameu (ako je broj aktivnih objekata u TN = 0 fizika moze da kulira). Inace, ako je razlcit od nule, ispitas cetiri child noda koliko ima u svakom aktivnih i tako skaces po aktivnim nodovima sve dok ne dodjes do poslednjeg nivoa (BNs) odakle uzimas listu objekata. Za sve objekte iz BNs gde postoje aktivni objekt generisi parove (npr. ako u nekom aktivnom nodu iz BNs imas objekte A, B, C i npr. B je aktivan generisi parove AB, AC, BC. Ako susedni nod sadrzi objekte A, B, D generisi parove AB, AD, BD. Par AB vec postoji u listi pa ga ne treba dodati.
Ako nisi prestao da citas na pola sledi objasnjenje cemu sve ovo. ODE koristi ne bas tako savrsen sistem da proverava da li se preklapaju AABB za sve objekte mirovali oni ili ne... pa racunaj ako imas 400 objekata koliko je tu provera 400 + 399 + 398.... = 400*401/2. Upotrebom qt proveravas da li se AABB dva objekta seku samo u "blizini" aktivnih objekata. Nisam siguran da li su kasnije dodali hash strukturu koja radi slicnu stvar - da se izbegne iteracija reda o(N^2) - N broj objekata.
Nakon sve ove price tek imas listu kandidata za objekte koji su potencijalno u koliziji. Za sve objekte iz liste (AB, AC, BC, AD, BD,...) proveri da li im se seku AABB pa tek ako se seku AABB treba da primenis detaljan test kolizije i generisanje kolizionih tacaka. O tome mozes jako mnogo da nadjes ako nabavis Eriksonovu knjigu "Real-time colision detection". Mislim da je ODE-ov test kolizije debelo baziran na njoj.
Dakle, QT/OT mogu da ti koriste samo za nalazenje parova objekata koji su "blizu" ali nije efikasan nacin za generisanja kolizionih tacaka.
ODE je sam po sebi brz i ako ga dobro tviknes moze da bude stabilan - mislim da deo koji samo racuna kretanje objekata na osnovu polozaja, kontakta, jointa bla bla... Usko grlo je svakako nacin kako ces da implementiras CD izmedju dva objekta (ako ces da koristis samo kocke, tipa tetirs pojacan sa ODE-om onda ce ti biti dovoljno da koristis CD koja vec postoji u ODE-u, za sve preko toga najbolje da sam pises CD - po mogucnosti google->copy->paste.
Sam ODE "smo" naterali da se "vrti" na XBOX-u (uzasno spor hardver za danasnje pojmove jelte) u igri koja nazalost nikad nije ugledala svetlo dana [
http://www.elitesecurity.org/t161748-0#1107304]
Inace, cela prica je cool ako je gravitacija nula (lepo za neku superdjuraizsvemiraigru).. ali ako hoces da ti objekti ne propadnu kroz podlogu moras jos dodatno za sve aktivne objekte da uradis test kolizije sa podlogom, a tu je opet lepo ako npr. koristi BSP ili vec kakvu god sturkutru kojim mozes brzo da pribavis prvo listu trouglova koje sece AABB objekta pa onda testiraj geometriju objekta vs lista "blizih" trouglova terena.
Moze ti takodje biti od koristi
http://www.rowlhouse.co.uk/jiglib/ Koliko znam isti taj baja sad radi u Cryteku vec tamo na nekom Far Cry-u -- nikad cuo