Utilizzando PhysX, come posso prevedere dove dovrò generare forme procedurali di collisione del terreno?

In questa situazione, ho valori di altezza del terreno che generi proceduralmente. Per il rendering, utilizzo la posizione della telecamera per generare una mappa di altezza di dimensioni adeguate. Per la collisione, tuttavia, ho bisogno di avere campi di altezza generati in aree in cui gli oggetti potrebbero intersecarsi.

La mia attuale soluzione potenziale, che può essere ingenua, è quella di iterare su tutti gli attori di fisica "svegli", usare i loro limiti / estensioni e velocità per generare sfere in cui potrebbero risiedere dopo un aggiornamento di fisica, quindi generare valori di altezza per intervalli che comprendono gruppi raggruppati di attori. Tuttavia, molti di questi dati sono probabilmente già calcolati da PhysX.

C'è qualche API, forse una serie di query, persino callback dal sistema spaziale, che potrei usare per prevedere dove saranno necessari i valori di altezza del terreno?

— Sion Sheevok
fonte

Mi sembra che tu abbia già codificato la soluzione migliore. Non sei sicuro di come funzioni PhysX, forse puoi invece avere trigger a forma di riquadro di delimitazione sui blocchi di terreno e generare le forme di collisione se qualcosa entra (innesca) in questo riquadro. Fondamentalmente quello che stai facendo, ma viceversa e con la matematica delle collisioni PhysX.

— aeroson,

Se si generano mesh dai dati per il rendering, è possibile passare la mesh a PhysX come mesh collider. Ciò significa che physX e il tuo renderer fanno riferimento allo stesso oggetto tagliando in testa.

— Quel senzatetto
fonte

Non è appropriato presumere che il terreno visibile sia l' unico terreno con cui gli oggetti possono scontrarsi. Il problema consiste nell'identificare rapidamente con quale gamma di terreno si potrebbe scontrarsi in modo che le forme di collisione possano essere generate per loro su richiesta.

— Sion Sheevok,

it.wikipedia.org/wiki/Octree dividendo i dati del mondo in cubi e "suddividendoli" ovunque tu abbia un'entità collidable gratuita puoi quindi effettuare chiamate ai dati del terreno in un'area molto piccola con un sovraccarico molto piccolo. Ecco un esempio che usa i quadrifici per la collisione di particelle 2D ma il concetto è lo stesso per Octrees ma con una dimensione extra. Ciò consentirebbe inoltre ai singoli oggetti collezionabili gratuiti di scontrarsi. youtube.com/watch?v=fuexOsLOfl0 È quindi possibile generare collettori molto piccoli dai dati del terreno vicino agli oggetti collezionabili gratuitamente

— That Homeless Guy

Conosco ocre e partizionamento spaziale - PhysX lo sta già facendo internamente. Ho bisogno di informazioni da PhysX riguardo al suo sistema di partizionamento spaziale in modo da poter generare forme di collisione del terreno dove sono necessarie perché il terreno è procedurale.

— Sion Sheevok,

Ti manca il punto. Sto generando dati per il terreno. Sto campionando quei dati per costruire un campo di altezza. Devo prevedere dove sono necessari i dati sul terreno. Se c'è un oggetto a (-100.0, -100.0), devo generare terreno vicino (-100.0, -100.0) prima di simulare la fisica. Ho anche bisogno di generare una regione di terreno abbastanza grande altrimenti un oggetto potrebbe spostarsi oltre una regione e finire sotto il punto in cui il terreno sarebbe se fosse stato generato in quella regione. PhysX deve già tenere traccia di tali informazioni per prevedere potenziali collisioni: ho bisogno di tali informazioni. Non so se / come farlo.

— Sion Sheevok,

Questo è il metodo di lavoro che ho delineato nella mia domanda, sì. Sto chiedendo se posso ottenere il lavoro che PhysX ha già fatto, in modo da non calcolare in modo ridondante gli stessi risultati. Non ho ancora trovato un modo, ma non ho familiarità con l'API PhysX senza licenza.

— Sion Sheevok,