Blender game engine -andando–como mover el actor

blender Game Engine -andando.

como mover el actor diferentes alternativas y consecuencias.

bueno, de nuevo en Carrera. Si ya conseguís distinguir entre un actor dinámico y uno estático, y entiendes algo de las propiedades dinámicas de los materiales, no vas a tener problema en seguir esta guía.

Como escenario de pruebas, tome una caja (cubo) e invertí las normales hacia adentro (para que desde afuera sean tranparentes y nos permitan ver el contenido y sirvan de fondo) y las texturice (similar a la técnica rotoscopia), le agregue nuestro actor dinámico (a partir de ahora la nave) que por cuestiones de normalización de criterios, el adelante de la nave coincide con el eje y del objeto y visto desde arriba, el eje X apunta a la derecha del objeto. Con esto conseguiremos que mi adelante sea el tuyo también, y así.

Presupuestomo que ya sabes que es un logic brik (lb), y como agregarlos a los actores. Tanto a la nave como al cubo (que bautise suelo) tienen aplicado material, con los valores que tiene por defecto un material nuevo.

Con la nave seleccionada, entrar a la ventana del engine (el packman azul) y, que clase de movimiento queremos?

Si solo deseamos que se desplace en una dirección (por ejemplo, adelante) bastara con aplicarle una fuerza en el eje y (como es en la dirección positiva del eje, será una fuerza positiva). Observando la imagen de arriba, van a notar que el eje y de la nave no cincide con el eje y global (es hacia adonde apunta el dedo de mi hermano, no es el mío).

eso es importante cuando la l del actuador no está presionada, presionada=local no presionada=global, si esta local, la fuerza o desplazamiento (según sea el caso) se aplica en la dirección del eje del objeto, si es global, en la dirección del eje global, por defecto es como aparece en la imagen de arriba (donde escribí localy globalal costado y los ejes debajo de cada columna).

Volviendo al ejemplo, conecte un sensor keyboard(uparrou en pulse mode, los tree puntos arriba)>controlador and>actuador motion (force 10 en el eje y) consiguiendo que mi nave se desplace hacia adelante. (si no sabes cómo hacerlo, entonces busca algún tutorial más básico para aprender)

Si tu nave no se desplaza hacia adelante, o lo hace hacia otro lado, revisa el tutorial desde el principio, y verifica el eje del objeto y coincida con el frente de Mesh del mismo.

La nave se desplazara hacia adelante cada vez más rápido si mantenemos presionada la flecha arriba hasta impactar con algún objeto en su camino o caer al vacío. Lo que sucede es que le aplicamos una fuerza, un empujón, y este empujón se repite varias veces por segundo si mantenemos presionada la tecla en cuestión, para que el impulso se aplique una sola vez es necesario desactivar el pulse mode, y entonces solo dará un empujón por cada presión de la tecla. A mayor fuerza, mayor empujón que se transformara en mayor velocidad. Si en lugar de aplicar una fuerza en el eje y lo hacemos en el eje x, el desplazamiento será lateral. Probar agregando otro juego de sensor>controlador>actuador, pero con otra tecla, para seleccionar la tecla a la que responde el sensor, simplemente presionar el botón izquierdo del mouse en el renglón gris a la derecha de key e inmediatamente presional la tecla que deseamos actibve el sensor. Hay más opciones de keyboard, pero para otro tutorial.

Si aplicamos la fuerza en el eje Z, que en este caso mira hacia arriba, sucederá que, por defecto la gravedad (no de grave, sino de atracción gravitacional) del engine es de 9.8preguntasobre segundo cuadrado (en realidad la unidad la supongo yo, para que coincida con la gravedad promedio terrestre y sea más cómodo de usar), y tiene una dirección constante de menos z, es decir que todos los objetos dinámicos son afectados por una fuerza de 9.8 hacia el eje -z global (se puede modificar la magnitud desde la ventana world o la magnitud y la dirección mediante composición de fuerza en los tres ejes desde Python), retomando, si la fuerza positiva en el eje Z es menor o igual que 9.8, no observaremos diferencia, pero si es mayor a 9.8 entonces nuestro actor se desplazara hacia arriba con velocidad creciente, por ejemplo, con fuerza z = 9.9 se elevara muy lentamente al principio.

Retomando la fuerza en el eje y, como hasta ahora nuestra nave es un objeto no-rígido, no tendrá tendencia a rodar al rozar con el suelo mientras se desplaza (como sucede con cualquier cuerpo esférico, no olvidemos que a los efectos del engine, por lo menos hasta la versión 2.25, la evaluación física se calcula tomando la esfera que rodea el centro del objeto de radio size). Si activamos rigid body, la nave, es que está loca? Comenzara a oscilar hacia adelante y hacia atrás hasta que comience una Carrera demente por el escenario. Lo que sucedió es que, aplica la fuerza en el eje y positivo de la nave, que además sufre un Tork (fuerza aplicada para hacer girar) que proviene del rozamiento de las superficies de la nave y del suelo (como llevar un aro o barril rodando) y esta relacionado con el coeficiente de rozamiento de los materiales de los objetos. Si el suelo tiene rozamiento cero, entonces no habrá Tork, no habrá giro extraño, pero la nave no se detendrá al soltar el botón, que las fuerzas que detienen a los cuerpos en movimiento son las de rozamiento o fricción. También como amortiguación del movimiento se puede utilizar Damp. Además, si no hay rozamiento, la nave nunca podrá girar correctamente (dejemos los giros para más adelante).

Que pesado que me estoy poniendo con las fuerzas y la física, mejor cambienos a movimientos más sintéticos, simples.

Podemos desplazar el objeto en cualquier dirección con dloc (posición relativa), que aumenta o disminuye la posición del objeto en la cantidad y eje que elijamos. Estar atento con local y global. La nave se va a mover contidades exactas, y no va a tener consecuencias secundarias como inercia o giros imprevistos. Claro, tampoco conviene aplicarle desplazamientos muy grandes, ya que, al pasar instantaneamente de una posición a otra, es perfectamente capaz de atravesar paredes y actores, con resultados no deseados, además de perder la sensación de continuidad en el desplazamiento.

Y las rotaciones? O siempre vamos a mirar para, allá?

Los más listos ya se habrán fijado que tenemos casilleros drot y Tork. Adivinaron, drot aplica rotaciones en el eje (por ejemplo, si aplicamos una rotación drot en el eje Z, que es el eje que mira hacia arriba, la nave girara hacia la derecha o hacia la izquierda, en cambio si aplicamos la misma rotación al eje x, siempre local, la nave girara levantando o bajando la nariz), para que la nave gire exactamente 90 grados, la rotación deberá ser de 45 (¿) es decir, de la mitad del ángulo medido en grados, por motivos que no comprendo, esto es así.

Para Tork, es como si aplicaramos una fuerza, como si tomáramos el alambre del eje al que lo aplicamos con dos dedos y lo impulsamos como a un trompo. Y al igual que este, se irá perdiendo velocidad hasta detenerse, en función de su masa y de los factores de rozamiento.

Aun nos quedan dos filas por probar, son linv y angv, que podemos traducir como velocidad linear y velocidad angular, directamente se configura la velocidad en un eje (local o global) a lo largo del mismo o al rotar en el.

Es el podemos elegir si deseamos que nuestra nave avance continuidad, con inercia, pero a una velocidad constante, que no se incremente ni disminuya mientras la estamos aplicando. (con force, la velocidad se incrementaba a cada instante, no aplicabamos una velocidad sino una aceleración). Tenemos además la opción de que si incremente la velocidad linear a la existente precionando el botón add a la izquierda de la fila linv.

Y lo mismo podemos acotar respecto de angv, aunque sin la opción add.

Mejor que decir es hacer.

Vamos a algo practico que nos permita apreciar diferencias.

Si nuestranave se encuentra en la situcion de tener que sortear una rampa para avanzar en su peligrosa misión.

vamos aintentar primero aplicando una fuerza y positiva a nuestro actor dinámico nave de masa 1 y size 1, con el rozamiento en 0.05 tanto para el material de la nave como para el escenario y la rampa.

Pero que paso? Nuestra nave comienza a avanzar lentamente, timidamente intenta la rampa, y retrocede. Un fracaso, la aceleración de 1 es insuficiente para alcanzar la velocidad de escape necesaria para subir toda la rampa, y finalmente la ley de gravedad gana, en rojo el reto, en verde el resultado.

con fuerza 2 no creo que logre, mejor probemos con fuerza 3.

(que apurado estoy, ni siquiera edito bien las imágenes.)

Ahora cambiemos a dloc. Borremos el valor de force y escribamos en dloc (columna y) 0.10, es decir, que avance un décimo de Blender unit (un cuadrado Blender de la grilla cuando esta mide 1)

y probamos el resultado. Fracaso estruendoso.

La nave avanza hasta la rampa lenta y constante, pero al llegar no puede subir más que unos milímetros miserables y retrocede acobardada (gráfico ídem del fracaso con force 1). Lo que sucedió es que la nave avanza un décimo de unidad (en este caso un décimo de su propio size o radio), lo que en el plano le representa avanzar a velocidad constante, cada iteración (o instante del engine) avanza idéntica distancia. Pero al avanzar sobre un plano inclinado, se agrega al avance horizontal una fuerza hacia abajo y atrás por la acción de la gravedad, en este caso mayor me cantidad de desplazamiento que el avancé, no olvidemos que el engine continua evaluando al actor, aunque lo que le aplicamos fuera un desplazamiento y no una fuerza. Por esto, si estaría en el vacío caería como cualquier otro actor dinámico con el adicional del movimiento en el eje y (la componente de ambas acciones).

Para no extenderme el lector podrá en este punto estudiar la alternativa de aumentar dloc y probar linv por su cuenta y riesgo, variando magnitudes para ver que sucederá en cada caso.

Voy a tocar muy brevemente ahora el tema de.

Subir la rampa, saltar el pozo.

Primero establescamos el escenario. En las mismas condiciones que veniamos manejando hasta ahora, pero con un foso de tres unidades de ancho. Si caemos, nunca nadie volverá a saber de nosotros (en un espacio virtual, existen los agujeros sin fondo, tengan mucho miedo. Si no lo toman en cuenta en un juego y no tienen tecla de abortar, la caída será eterna en serio)

configuramos linv en x=0.0 y=4.5 z=4.0.

Y el salto al precionar la tecla uparrow será exitoso, se puede probar con force para obtener un resultado similar, con la componente de dos fuerzar perpendiculares, se obtiene una resultante (suma de vectores, se puede hacer con lápiz y papel).

Pero lo que me preocupa es que fue demasiado fácil, les aseguro que olvidamos algo.

Probemos de nuevo solo que precionemos varias veces la tecla de saltar, o activemos el pulse mode (da lo mismo). Vaya, la nave salta y salta en al aire, ya no necesita tocar tierra y el peligro de caer por los pozos es casi nulo, lo que arruinara nuestro juego de principio a fin. Como evitarlo? Ya mismo aporto una alternativa al salto compulsivo

Agregamos un sensor touch y conectarlo al controlador and existente. Configurar el casillero ma (material) con el material del suelo (en este caso los bloques del suelo están con dicho material, es conveniente que todo lo que sea pared tenca asignado otro material para que ella nave no trepe por las paredes), y convendría asignar un botón para avanzar y otro para saltar.

resalte todo lo que debemos tener en cuenta: la tecla con la que se activa el sensor, si al mantener precionada la tecla la activación se repite (pulse mode), el material que debe estar tocando la nave al momento de presionar la tecla de saltar para que efectivamente aplique un impulso hacia arriba. Por separado el impulso hacia adelante, y cada logic brik con su nombre, para poder saber que función cumple (esto se puede volver muy confuso, hay que desarrollar criterios, normas y documentación que nos permitan mapear el trabajo realizado). Ahora se puede avanzar y saltar en forma independiente, y solo saltara cuando la condición tecla de saltar este presionada al mismo tiempo que la nave este tocando el material suelo. Practica practica practica etc.

, y hasta la próxima.

cjd (Claudio Javier Dobniewski)

claudiojd@indicom, com, ar

.

Miniaturas adjuntas
Blender game engine -andando--como mover el actor-1.jpg   Blender game engine -andando--como mover el actor-2.jpg   Blender game engine -andando--como mover el actor-3.jpg   Blender game engine -andando--como mover el actor-4.jpg   Blender game engine -andando--como mover el actor-5.jpg  

Blender game engine -andando--como mover el actor-6.jpg   Blender game engine -andando--como mover el actor-7.jpg   Blender game engine -andando--como mover el actor-8.jpg   Blender game engine -andando--como mover el actor-9.jpg   Blender game engine -andando--como mover el actor-10.jpg  

Imágenes adjuntadas
Blender game engine -andando--como mover el actor-11.jpg 

Ver más sobre el tema y los comentarios en el foro