Emular lanzamiento de un dado 3D

[shephiroth]

Muy buenas. Hace ya bastante tiempo q no posteo nada.

Llevo ya un par de años con java por la universidad, y este año por fin hemos empezado con 3d. He hablado con el profesor y no vamos a profundizar demasiado, es mas introduccion al 3D que a la programacion 3D en java, asi que apenas hemos dado como crear una geometria por triangulos y cuadrados, como usar colores (se han comentado las texturas, pero por encima), y como hacer pequeñas animacion donde diversos objetos tienen diferentes comportamientos que pueden hablar entre si.

Bueno, ahora que ya sabeis donde me encuentro, me gustaria poder emular la tirada de un dado, pero hacerla real. He leido q lo mejor es crear la animacion por separado, y una vez q sepas q cara va a ser la q va a quedar establecer una rotacion del cubo inicial para q coincida el resultado de la tirada con un numero random pre-elegido. Esto tiene 2 inconvenientes para mi:

1) Hay alguna forma de hacer una tirada sin preevaluar la tirada???
2) Como hago para evaluar los rebotes. Si yo le doy una inclinacion aleatoria al dado, entiendo q le doy una velocidad vectorial q imite la gravedad, un movimiento vectorial hacia delante que imite la fuerza ejercida sobre el dado, y un movimiento rotacional q imite el movimiento de muñeca. Pero cuando haga colision con "la mesa", como se evalua en q punto del dado ha chocado, y como afecta esto a los 3 vectores anteriores?? No se si me explico.

Bueno, toda ayuda será mas que agradecida.

P.D: Prefiero criticas negaticas pero q ayuden, a criticas positivas q no ayuden a nada.

[fjfnaranjo]

¿Que tal si grabas varias secuencias de animación que acaben todas en la misma cara del dado y simplemente distribuyes aleatoriamente el mapeado de la textura por las caras del mismo?

Esto debería servirte a no ser que quieras por algún motivo que el dado se comporte con física real, en cuyo caso yo lo que haría sería lo que tu dices. Lo lanzaría hacia un vector ligeramente alterado con una fuerza más o menos aleatoria. Con respecto a lo que comentas de los rebotes, revisar algo de la parte de mecánica que se estudia en la física del bachilletaro podría servirte. Pero si lo que necesitas es algo más complejo vas a tener que estudiar física de colisiones de sólidos rígidos, que tiene bastante tarea. Obviamente, si no es necesario llegar a ese nivel de detalle lo suyo es que uses cualquiera de los motores de física libres que hay disponibles.

EDIT: Había puesto "sólidos duros" en lugar de "sólidos rígidos" xD

[tamat]

Añado a lo que dice fj que si no tienes mucha idea de temas de 3D no es buena idea meterse en colisiones y fisica (dos temas que no debes confundir con render 3D y que son mucho mas complejos). Lo mejor es pregrabar animaciones y jugar con las texturas en el dado.

Y un apunte más, entiendo que en tu universidad se de Java (aunque me de rabia toda esa generacion de profesores que solo sabe programar en Java y enseña a sus alumnos todo en Java cuando este es un lenguaje que solo tiene sentido en la web), pero si realmente quieres hacer cosas 3D ve olvidandote de Java y poniendote las pilas en C++.

[senior wapo]

Te va a quedar mucho más bonito precalculando un par de animaciones resultonas y trucando la textura/rotación inicial, pero ya que te empeñas en usar físicas, te doy unas ideas. Vatya por delante que lo mejor es usar un motor de física existente, pero bueno.

Los motores de físicas funcionan de manera numérica, no analítica. Te pillas unas fórmulas muy sencillas para actualizar las posiciones y rotaciones y haces varios pequeños pasos de simulación por cada fotograma de animación.  Dar varios pasos con cálculos sencillos es más rápido, paralelizable y facil que hacer cálculos exactos que no cometen error pero son un coñazo. Básicamente reemplazas un movimiento o reacción complejo con pequeños pasos en línea recta, como cuando dibujas una spline o círculo mediante muchos segmentos pequeños, o calculas 37*B sumando B 37 veces en un bucle. Es feo, es impreciso, y es facil. Funciona.

Esto se reduce a hacer sumas y restas de posiciones, ángulos y velocidades cuando el objeto no interactúa con ningún otro.
Cuando un objeto colisiona con otro necesitas calcular los puntos/áreas  de contacto y aplicar determinadas reglas para reasignar las nuevas direcciones, posiciones, rotaciones y velocidades de los cuerpos que han interactuado (contactado).
Primero calculas que porcentaje del movimiento deberías haber hecho para que simplemente contactasen sin invadirse. Recalculas la posición haciendo solo ese movimiento. Ahora están en contacto y tienes un % de la energía (del movimiento) por usar ya que no has dado el paso completo pues invadía al otro cuerpo.
Calculas, con reglas que tu te definas, la nueva velocidad/rotación desde el punto de contacto, por unidad de tiempo. La aplicas en un mini paso reducida por el % de movimiento que te queda por hacer en este paso de simulación. Ya tienes la posición final para este fotograma.

Como mínimo necesitas dos copias del estado del mundo (posiciones y tal): uno es el último estado válido conocido (el pasado), que es simplemente el último estado calculado en el fotograma anterior, y otro es el que va a ser el presente cuando lo tengas bien calculado, y que lo vas a modificar, deshacer, repetir y engorrinarr varias veces en cada mini paso de simulación hasta que te salga correcto.

En tu caso es muy sencillo ya que tu mundo consta de un cubo y un plano infinito (la mesa). La colisión la detectas por la distancia entre el plano y el centro de la esfera cuyo radio es la mitad de la diagonal del cubo y centro el del cubo. Si la esfera colisiona detectas la distancia entre los vértices y el plano para saber si ha chocado una esquina, una arista o se desliza por una cara.

Según el tipo de colisión reaccionas de una manera u otra. Búscate reacciones que queden bien y a correr. SI quieres que sea realista te toca repasar física. Puedes salir del paso usando el producto entre la normal del plano y el movimiento del dado (coseno de su ángulo) y hacer palanca en el punto de contacto, por decir algo al azar.

Te recomiendo un tutorial muy majo sobre físicas en Gamasutra, el de los autores del juego Hitman. Es muy sencillo y bien explicado, usando métodos numéricos muy asequibles, en lugar de complejas fórmulas analíticas.
http://www.gamasutra.com/view/feature/2904/advanced_character_physics.php

[Tei]

Hay una forma muy barata y chapuzera de simular fisica que solo vale para simular dados.

utiliza particulas,  dos particulas forman un lado, ese lado se puede deformar, ponemos otra particula, y forman un triangulo... 

se llama "stick phisics"

aqui hay un paper :-)

http://www.teknikus.dk/tj/gdc2001.htm

lo comentan en inside3d ( un tio hizo una implementacion de esto utilizando Quake1, que no tiene ningun soporte de fisica, sino solo colisiones por BBOX que no pueden rotar, osea casi menos que cero )

http://www.inside3d.com/index.php?show=257

Esto es probablemente mucho mas asequible que un verdadero motor fisico.

Y se pueden hacer cosas como estas:
http://www.youtube.com/watch?v=YLpEU6LDy34&eurl=http%3A%2F%2Fwww%2Einside3d%2Ecom%2Findex%2Ephp%3Fshow%3D257&feature=player_embedded

[senior wapo]

Tei, as linkado el mismo artículo que había puesto yo pero enlazando a la copia en la web del autor en lugar del artículo en Gamasutra  :P

EDIT: Y si no es la web del autor da igual, es el mismo artículo de Thomas Jacobsen.

[Tei]

Tei, as linkado el mismo artículo que había puesto yo pero enlazando a la copia en la web del autor en lugar del artículo en Gamasutra  :P

EDIT: Y si no es la web del autor da igual, es el mismo artículo de Thomas Jacobsen.

Estaba en el trabajo y no me lei todo el hilo. Vaya, pues que poca variedad de informacion... aunque supongo que mucha gente habra leido el paper ese y le habra gustado.

De todos modos la otra sugerencia, de tener una animacion de datos y reproducirla, igual es mejor.  Incluso si nos ponemos chapuzas, igual se puede hacer artificialmente un "path" jugando un poco con senos y cosenos, puesto que no hace falta que unos dados choquen contra otros, y segun el angulo de camara si una esquina de un dado intersecta el plano del suelo igual no se nota. Pero vaya...   igual es una bonita oportunidad de probar los algoritmos de este señor Tomas.

[shephiroth]

Lo primero, gracias por todas las respuestas ^_^

Por lo q comentais, al final parece que va a ser mejor hacerlo de modo facil y practico, en vez del realista pero pesado.

Creo q mejor voy a dejar lo del dado para mas adelante, aun estoy muy verde en 3D. Pero el post de "senior wapo" ha sido muy instructivo. A parte de entender un poco el funcionamiento del dado, me ha hecho darme cuenta de lo diferente q es java.

Lo poco q estuve con opengl en 2D, me dio la impresion de que sigue el estilo windows, bucle infito y en cada pasada el programador decide que se pinta y que no. Pero en java siguen otra filosofía, esta mas enfocado a los eventos. Yo creo mi universo, establezaco el view, y añado objetos graficos.....aparte añado diferentes behavior, que son los q interactuan y modifican los diferentes elementos graficos.

Por ejemplo, para la colision del susodicho dado con el plano, yo añadiria un objeto grafico q representase la mesa, otro objeto q representase el dado, y añadiria un behavior que moviese el dado. A ese behavior tendría q añadirle un wakeupOnElapsedTime para la animacion, y un WakeupOnCollision para las diferentes colisiones.

Aun no he llegado hasta tal punto, aun estoy intentando asimilar los wakeupOnXXXX, pero si quereis cuando consiga hacer algo medio funcional pondre el codigo (aunque no os espereis nada profesional, soy un chapucero con las variables xDD)

El video de youtube mola, habra q echarle un ojo a las formulas.

SALUDOS ^^