Consejos para deteccion en 3D.

Iniciado por BlackZeroX, 11 Junio 2011, 11:31 AM

0 Miembros y 2 Visitantes están viendo este tema.

BlackZeroX

.
Estoy realizando un pequeño motor para un juego en C+OpenGL y me veo en la necesidad de crear una técnica viable para detectar las colisiones

Hay alguna manera lógica de detectar colisiones ( con rangos de error para no exigirle al procesador demasiado ) de manera que dichos objetos estén constantemente en movimiento y cambiando de forma, se que lo puedo hacer con la formula para saber la distancia entre dos puntos, pero la verdadera pregunta es como detectar la colisión entre dos masas?.

Mis opciones hasta ahora son:
*Definir el centro de la masa(figura)  (Detección de colisión por círculos) ( me parece viable, aunque definir el centro lo tendria que hacer en tiempo de diseño de las masas, y estos centros tendrían que ser "invisibles" cosa que no me agrada. ).

*Crear una masa "invisible" (Detección de choques por rectángulos) ( Es decir definir tantos rectángulos en lugares X de la masa y definir los centros de estos rectángulos y posteriormente por medio de 3 de sus vértices de un rectángulo (Coordenadas X,Y,Z de los 3 vértices) la una 4 ajena a este rectángulo. ).

Algunas sugerencias o ideas?

P.D.: No meto códigos ya que solo deseo obtener ideas.

Temibles Lunas!¡.
The Dark Shadow is my passion.

Draklit

Mi idea cuando empecé a leer esto fue exactamente la de los rectángulos (aunque yo me imaginaba uno sólo por cuerpo); o podrías definir puntos en los cuerpos en donde se verifique la cercanía con puntos en los demás cuerpos (creo que es viable), sólo algunos puntos.

Foxy Rider

¿Te interesa el aprendizaje o simplemente hacer algo ? si es la segunda, tirate por algún motor como Bullet, Newton u ODE (Bullet es más poderoso, pero más complejo)

Si te interesa aprender tenés muchas formas, como Ray, Sphere, Bounding Box, etc ... en este terreno depende específicamente de qué hagas .. te dejo un texto  http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=30 (fijate los primeros métodos de detección de colisión)

Saludos.

BlackZeroX

#3
Me falto aclarar que las opciones que tengo son las que menciono vertex Bounding Sphere y Bounding Box, la del método Ray estoy un poco indeciso.

Gracias vertex.

aunque ya revise todos los códigos de nehe hace tiempo (1 o 2 años leidos y comprendidos completamente), pero no me satisfacen (a lo mejor sea por que soy muy exigente en todo, en este caso que no solo haga un juego y después requiera un código ya creado por mi no pueda o se me complique o tenga que modificar muchas cosas, por ejemplo un prueba de de fisica para un trabajo "X").

Por otro lado me interesa aplicar/aprender/hacer, de nada sirve "hacer por hacer" si no se rescata algo, de hecho tenia pensado usar el motor Havok pero me retracte y decidi crear uno para aplicar y a su vez reafirmar (y posiblemente me sirva para una entrega de proyecto en la universidad donde resido, al igual que apra alguna exposición donde requiera algún ejemplo practico y visual).

P.D.: Havok Game Dynamics SDK es usado en los juegos de alta gama como Halo (1, 2, 3), Fallout 3, Assassin's Creed, BioShock, Call of Duty 4: Modern Warfare, entre otros. esto quiere decir que no es un motor de fisica cualquiera.

Dulces Lunas!¡.
The Dark Shadow is my passion.

Foxy Rider

@BlackZeroX: yo te recomendaba algo cross-platform y opensource, a diferencia de lo privativo de havok y el quilombete de sus licencias ... (pero sí, es un motor de primera línea)

Respecto a usar algo hecho o hacerlo vos, depende de tus prioridades ... como dice el artículo de gamedev : escribe juegos, no motores
si pensabas hacer un juego (si esa era tu finalidad), usar algo armado hubiese sido lo mejor para no mirar mucho a los costados e ir directo a lo que querés hacer ....
si pensabas aprender u estudiar (y sólamente eso), entonces sí tiene sentido que lo hagas vos..

Los códigos y tutos de nehe son una referencia, no están pensados para ser copiados, están pensados para que veas los algoritmos y aprendas (y lo implementes a tu manera) ...

Insisto, depende de qué quieras testear ...  Para objetos móviles y con  lo poquítisimo que describiste de la escena vas a estar  bien con bounding sphere o bounding box ...

En sitios como gamasutra, gamedev, realtimerendering y demás vas a encontrar recursos sobre los diferentes algoritmos y para qué están optimizados...

Saludos.

BlackZeroX

Si puse que deseaba usar Havok pero a ultima hora me arrepentí?...

La cuestión NO es crear un motor de video-juegos de manera concreta (iria para largo tiempo), lo que deseo hacer es un simple juego PERO creando todo, es decir, nada de motores ajenos, aun que si me sirven TODOS o partes de las clases seran exelentes.

el tema solo es para IDEAS lo demás es a mi razon de pensar, no me gusta mucho lo fácil y hacer por hacer, me gusta hacer y que encajen mis códigos en otros lugares sin modificar mucho o de plano no tocar nada (esto seria lo mejor que me puede pasar).

Por ahora ya tengo un código hecho para el manejo de los "espacios de masas" para detectar colisiones por medio de "Bounding Sphere/Box" usando una heuristica que determina cuales objetos están cerca usando un poco el Ray y no saturar el Procesador (una clase base/global de manera independiente vaya sin usar los for() de manera que recorran todos, solo recorren los mas cercanos).

Al igual por ahora estoy determinando TODOS estos espacios por medio del diseñador gráfico y exportando en un formato que me brinda toda la información (ASE), y no me gusta mucho definir todo desde el diseñador pero bueno si no hay alternativa tendre que hacerlo xS.

P.D.: Me gusta crear mucho mis propios algoritmos, me alimentan mi materia gris, aun que ver codigos ajenos esta bien pero antes mejor me esfuerzo si no, "no podre salir de la caja sin puertas ni ventanas y tendré que comer las boronas de otros", me bonita frase me salio...

Dulces Lunas!¡.
The Dark Shadow is my passion.