Con PhysX, ¿cómo puedo predecir dónde necesitaré generar formas de colisión de terreno procesal?

En esta situación, tengo valores de altura del terreno que genero procesalmente. Para renderizar, uso la posición de la cámara para generar un mapa de altura de tamaño apropiado. Sin embargo, para colisión, necesito tener campos de altura generados en áreas donde los objetos pueden cruzarse.

Mi solución potencial actual, que puede ser ingenua, es iterar sobre todos los actores físicos "despiertos", usar sus límites / extensiones y velocidades para generar esferas en las que puedan residir después de una actualización física, luego generar valores de altura para rangos que abarcan grupos agrupados de actores. Sin embargo, es probable que PhysX ya haya calculado gran parte de esos datos.

¿Hay alguna API, tal vez un conjunto de consultas, incluso devoluciones de llamada del sistema espacial, que podría usar para predecir dónde se necesitarán los valores de altura del terreno?

— Sion Sheevok
fuente

Me parece que ya codificó la mejor solución. No estoy seguro de cómo funciona PhysX, tal vez pueda tener activadores en forma de cuadro delimitador en sus fragmentos de terreno y generar las formas de colisión si algo ingresa (activa) a este recuadro. Básicamente lo que está haciendo, pero al revés y con las matemáticas de colisión PhysX.

— aeroson

Si está generando mallas a partir de sus datos para renderizar, podría pasar la malla a PhysX como una malla de colisionador. Lo que significa que physX y su renderizador hacen referencia al mismo objeto cortando sobrecarga.

— Ese chico sin hogar
fuente

No es apropiado asumir que el terreno visible es el único terreno con el que los objetos pueden chocar. El problema es identificar rápidamente con qué rango de terreno podría colisionar para que se puedan generar formas de colisión a pedido.

— Sion Sheevok

en.wikipedia.org/wiki/Octree dividiendo los datos del mundo en cubos y "cortándolos" donde tenga una entidad libre colisionable, puede hacer llamadas a los datos del terreno dentro de un área muy pequeña con muy poca sobrecarga. Aquí hay un ejemplo que utiliza cuadrúpedos para la colisión de partículas en 2D, pero el concepto es el mismo para Octrees pero con una dimensión adicional. Esto también permitiría que los objetos colisionables libres individuales colisionen entre sí. youtube.com/watch?v=fuexOsLOfl0 A continuación, puede generar colisionadores muy pequeños a partir de los datos del terreno cerca de los objetos colisionables libres

— Ese hombre sin hogar

Estoy familiarizado con los octrees y la partición espacial: PhysX ya lo está haciendo internamente. Necesito información de PhysX con respecto a su sistema de partición espacial para poder generar formas de colisión del terreno donde sean necesarias porque el terreno es de procedimiento.

— Sion Sheevok

Te estás perdiendo el punto. Estoy generando datos para el terreno. Estoy muestreando esos datos para construir un campo de altura. Necesito predecir dónde se necesitan los datos del terreno. Si hay un objeto en (-100.0, -100.0), necesito generar terreno cerca de (-100.0, -100.0) antes de simular la física. También necesito generar una región de terreno lo suficientemente grande o, de lo contrario, un objeto puede moverse más allá de una región y terminar debajo de donde estaría el terreno si se hubiera generado en esa región. PhysX ya debe rastrear dicha información para predecir posibles colisiones. Necesito esa información. No sé si / cómo hacerlo.

— Sion Sheevok

Ese es el método de trabajo que describí en mi pregunta, sí. Estoy preguntando si puedo obtener el trabajo que PhysX ya ha hecho, de modo que no estoy calculando de manera redundante los mismos resultados. Todavía no he encontrado una manera, pero no estoy tan familiarizado con la API PhysX sin licencia.

— Sion Sheevok