¿Enrutamiento dinámico en tiempo real?

19

Actualmente estoy haciendo una investigación de búsqueda de rutas y mi simulación es la siguiente: tengo una escena en 3D con un punto de inicio y final representado, soy capaz de crear mallas de navegación, puntos de referencia y polígonos para ayudar con la búsqueda de rutas.

He probado un algoritmo A * y algunas de sus variantes y funcionan perfectamente. Sin embargo, ahora estoy más interesado en la búsqueda de rutas 'dinámicas'. Por ejemplo, mientras encuentro una ruta desde el punto A hasta el punto B, si aparece un nuevo obstáculo de repente, quiero que mi algoritmo pueda volver a planificar de inmediato una ruta y no comenzar a buscar desde cero nuevamente.

He leído un poco sobre el algoritmo D * y me pregunto si esto sería apropiado para lo que necesito o si parece una exageración.

Entonces, mis preguntas son básicamente: ¿Qué algoritmo sería mejor para la búsqueda dinámica de rutas en tiempo real? ¿O qué combinación de técnicas podría utilizar en su lugar?

Andrei
fuente
No estoy seguro de qué algoritmo usan, así que esta no es una respuesta, pero imagino que esto es lo que estás tratando de emular: video de YouTube
MichaelHouse
¿Qué hay de extender A *? Extendiendo lo que está almacenado en los nodos de sus conjuntos abiertos / cerrados por lo que desea y extendiendo A * para considerarlo.
user712092
Estaba buscando la respuesta igual que usted y encontré un artículo sobre HPA * y está relacionado con los videojuegos. Todavía estoy buscando un artículo y probablemente lo implemente. Hasta ahora tiene sentido para mí mejorar el rendimiento y se puede usar tanto en entornos estáticos como dinámicos. Aquí está el artículo
NelsonPunch

Respuestas:

19

D * está bastante involucrado, no recomiendo intentar implementarlo. Incluso cuando los proyectos están bien financiados y están siendo desarrollados por personas inteligentes / experimentadas, se utiliza D * lite, porque D * es muy difícil hacerlo bien.

Puede interesarle esta presentación, que incluye una discusión sobre la búsqueda de caminos de Left 4 Dead:

http://www.valvesoftware.com/publications/2009/ai_systems_of_l4d_mike_booth.pdf

Un enfoque es utilizar una búsqueda general de nivel A * para obtener una ruta general para un agente, y luego realizar una búsqueda detallada de nivel A * para el entorno local de un agente. De esta forma, puede volver a calcular rápidamente la búsqueda A * de detalles del curso si el terreno cambia, y luego volver a calcular rápidamente la búsqueda A * de detalles finos para un pequeño segmento del entorno. Esto no es perfecto Funciona siempre y cuando tus obstáculos no puedan bloquear múltiples nodos del gráfico de detalles del curso, lo cual está bien para la mayoría de los juegos. Este es el método que recomiendo si tiene menos de 100 agentes.

Si desea apoyar a cientos o miles de agentes, puede implementar algo como multitudes continuas. Vea esta investigación: http://grail.cs.washington.edu/projects/crowd-flows/ Que analiza un método basado exclusivamente en la CPU que puede admitir a miles de actores en un entorno dinámico.

Si desea admitir decenas de miles, o cientos de miles de agentes, puede implementar algo como multitudes continuas, con asistencia de GPU. Vea aquí la investigación relevante: https://a248.e.akamai.net/f/674/9206/0/www2.ati.com/misc/siggraph_asia_08/GPUCrowdSimulation_SLIDES.pdf

Aquí hay un video que muestra las multitudes continuas en acción: http://www.youtube.com/watch?v=lGOvYyJ6r1c (Pase a 4:10 para ver grandes obstáculos dinámicos como automóviles y semáforos que afectan a cientos de personas caminando por una ciudad).

Olhovsky
fuente
Gracias por los enlaces. D * Lite parece correcto por lo que he estado leyendo
Andrei
9

¿Has visto comportamientos de dirección simples?

http://www.red3d.com/cwr/steer/

Puede usarlos para desviarse de su camino A * para evitar obstáculos locales y luego volver a su camino una vez que haya terminado.

También es bastante fácil combinar múltiples comportamientos.

BigSandwich
fuente
+1. No estoy seguro de por qué eso fue rechazado. Aunque esto es simple, y posiblemente no sea la respuesta que estaba buscando el autor de la pregunta, creo que es sobre el tema y lo encontré útil :)
Olhovsky
1
He leído e implementado este comportamiento de dirección en nuestro último juego. Ahora lo vamos a reemplazar nuevamente con otros métodos. Creo que no funciona bien junto con rutas óptimas precompletas. La "combinación" de múltiples comportamientos generalmente produce malos resultados. Si todavía planea usarlo, no intente seguir y seguir su camino al mismo tiempo. En cambio, cambie al 100% de dirección y cambie al 100% una vez que haya superado el obstáculo.
Imi
4

Dado que su publicación está en la parte de "Desarrollo de juegos" del intercambio de pila, esto es lo que la mayoría de los programadores de juegos le responderían: ¡No se trata de la búsqueda dinámica en tiempo real, se trata de la ruta dinámica en tiempo real * siguiente *!

Algunos casos de borde en los que un borde en su gráfico de navegación está totalmente obstruido requeriría que el buscador de ruta recalcule otra ruta, pero la mayoría de las veces simplemente puede dirigir sus entidades alrededor de los obstáculos, haciendo predicciones de posición y evitando en la dirección correcta. Para la mayoría de los juegos, sería demasiado pesado tener que predecir con el tiempo la posición de los agentes dinámicos, especialmente porque no puedes predecir con precisión las acciones de los jugadores o las decisiones de los agentes.

Entonces, mi consejo sería comenzar implementando Comportamientos de dirección (http://red3d.com/cwr/steer/), manejar los casos en los que el camino se vuelve imposible y luego agregar una capa encima para manejar los casos extremos que no t manejado por las dos soluciones anteriores.

Espero que esto ayude

emartel
fuente
UH no. "Seguir ruta" es lo mismo que encontrar ruta. Existen muchos enfoques que permiten el seguimiento en tiempo real de miles de agentes cuando los obstáculos están cambiando, en una PC de escritorio. Ciertamente, no es demasiado costoso encontrar un camino para un solo agente, cuando los obstáculos se mueven. Aquí hay uno de esos enfoques, de muchos: grail.cs.washington.edu/projects/crowd-flows Existen versiones aceleradas por GPU de multitudes continuas.
Olhovsky
Tendría que estar en desacuerdo con este. Cualquier motor tratará la búsqueda de ruta y el seguimiento de ruta como dos problemas distintos, donde el primero es una búsqueda gráfica del área navegable y el otro intenta buscar el vector de movimiento óptimo dentro del espacio local. He trabajado en la simulación de multitudes produciendo middleware utilizado por juegos AAA sin necesidad de depender de la GPU. La mayoría de las implementaciones utilizarán un campo de flujo (el buscador de ruta) y la dirección para seguir el flujo y evitar otros agentes (el seguidor de ruta). Como decía mi respuesta, esta es una respuesta de "programador de juegos", no una respuesta académica.
emartel
Sé que no necesita la GPU para las multitudes continuas, por lo que vinculé una versión basada en CPU. Su descripción del seguimiento de ruta sigue siendo una búsqueda de búsqueda de ruta, es solo una búsqueda de búsqueda de ruta en un nivel de detalle diferente, en un conjunto de datos diferente. Entonces, lo que realmente tiene es un pase de orientación de detalle del curso y un pase de búsqueda de detalle detallado. En última instancia, está tratando de encontrar el camino que debe seguir un actor. Inventar nuevos términos para esto simplemente confunde las cosas.
Olhovsky
1
Lo siento, pero "seguir el camino" no es un término inventado. Lea los documentos producidos por la industria y verá que se usa una y otra vez: enlace o enlace solo para vincular algunos. Lamentablemente, no puedo vincularlo a las documentaciones protegidas por NDA de motores / middlewares ampliamente utilizados en la industria.
emartel
1
Su primer enlace es el enlace que di en mi respuesta por cierto. Muy bien, podría ser justo describir ese tipo de búsqueda de ruta como ruta de seguimiento. En última instancia, ambos están tratando de encontrar el camino a seguir, pero creo que en este caso estoy equivocado, y deberíamos llamar a lo que vemos en su segundo enlace como camino a seguir. Por ejemplo, el acto de vincular puntos de ruta gruesos con splies cúbicos / curvas de biezer / insert-your-method-here. Dicho esto, sigo totalmente en desacuerdo de que no es factible implementar la búsqueda de caminos alrededor de obstáculos dinámicos, como parece sugerir su respuesta.
Olhovsky