Determinare se due oggetti in rapido movimento devono essere inviati per un controllo delle collisioni


8

Ho un motore di fisica 2D di base in esecuzione. È praticamente un motore a particelle, utilizza solo forme di base come AABB e cerchi, quindi non è possibile alcuna rotazione. Ho implementato un CCD in grado di fornire un TOI accurato per due oggetti in rapido movimento e tutto funziona senza intoppi.

Il mio problema ora è che non riesco a capire come determinare se due oggetti in rapido movimento debbano persino essere controllati uno contro l'altro in primo luogo. Sto usando un albero quad per il partizionamento spaziale e per ogni oggetto in rapido movimento, lo controllo contro gli oggetti in ogni cella che passa. Funziona bene per determinare la collisione con la geometria statica, ma significa che qualsiasi altro oggetto in rapido movimento che potrebbe scontrarsi con esso, ma che non si trova in nessuna delle celle controllate, non viene mai considerato.

L'unica soluzione a cui riesco a pensare è o avere le cellule abbastanza grandi e incrociare le dita che questo è abbastanza, o implementare una sorta di algoritmo di forza bruta. Esiste un modo corretto di affrontarlo, forse qualcuno ha risolto questo problema in modo efficiente. O forse c'è un modo migliore di partizionare lo spazio che tiene conto di questo?

Ecco un diagramma:

inserisci qui la descrizione dell'immagine

Le "aree di effetto" degli oggetti A e B devono essere incrociate. Ma con il modo in cui sto attualmente controllando le collisioni non tiene conto di questo. Ancora una volta, posso pensare ad alcune soluzioni come quella di verificare se i percorsi degli oggetti si incrociano una volta che la loro velocità è superiore a x, o qualcosa del genere, ma sembra un hack ed è un casino da provare e implementare.


Potresti dare uno scenario di esempio in cui il tuo metodo fallisce?
Anko,

1
Penso che andrebbe così: gli oggetti A e B sono in questa configurazione: [A] [] [B]. A sta andando verso destra e B verso sinistra. Vanno veloci. Il controllo delle collisioni è il seguente: la cella successiva è vuota per A? Sì, bcs non c'è nulla nella cella centrale. La cella successiva è vuota per B? Sì. Quindi nessuna collisione. Ma la fisica reale mostrerebbe che probabilmente A e B si scontreranno (specialmente in questo gioco a una dimensione che io descrivo;)
Cystack,

@Cystack Ho implementato il CCD. La situazione che hai descritto non è un problema. I due oggetti stanno andando uno di fronte all'altro, l'implementazione che ho descritto lo raccoglierà e lo risolverà.
dreta,

La fisica della situazione è chiara. Diciamo che puoi identificare un oggetto come "in rapido movimento" in anticipo. Quindi, quando si esegue un controllo delle collisioni, è necessario controllare non solo la cella in cui si trova l'oggetto, ma tutte le celle attraversate nell'ultimo passaggio. Quindi ogni oggetto in rapido movimento ha effettivamente più posizioni, come l'intera striscia verde che hai disegnato nell'immagine sopra.
theJollySin

@ theJollySin ho già descritto la soluzione che stai dando, è un trucco, un caso speciale, sto cercando una soluzione generale se ce n'è una.
dreta,

Risposte:


5

Il problema di cui stai parlando è spesso chiamato "rilevamento di collisioni a fase larga" e la tua soluzione è un "volume spazzato", non un vero e proprio hack, ma solo il modo in cui viene fatto (prendi semplicemente AABB dell'oggetto incluso sia l'inizio che la fine del movimento e usalo per la collisione, anche se le cose diventano un po 'difficili con le rotazioni).

Quindi il passaggio all'algoritmo di rilevamento delle collisioni a fase larga che rende questo veloce si chiama "Sweep and Prune".


Ho scartato SAP prima che sorgesse questo problema. Lo sto facendo in JavaScript, il che rende evidente il sovraccarico degli elenchi, inoltre le matrici possono diventare inaffidabili quando si tratta di prestazioni. Immagino che dovrò riconsiderare le cose. Grazie, l'algoritmo risolve davvero il problema.
dreta,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.