1º Tomas 2 muestras del ángulo en el eje Y del objeto. BackFrame CurrentFrame
 
2º Obtener la diferencia absoluta de las muestras Math.Abs(CurrentFrame - BackFrame).
 
3º Creas tu propia fórmula para obtener un valor del 0 al 1 según el valor de la diferencia.
 
Ejemplo, suponiendo que la diferencia máxima sea 20.
 

1 - Clamp(diff, 0, 20) / 20

 
4º Multiplicas la velocidad de movimiento con el resultado del paso 3.

Cita de: nomoregames date=1578403977Supongo que buscas "suavizar" el giro, para que se vea mas natural...  ¿no? 
   
   
      si es así... probaste a usar smoothdamp.
   
   
      en todo caso, ayudaría mucho que pusieras tu código para poder ayudarte.
   
   
       
   
   
       yo también soy mas de lógica, pero aveces ni eso 

Buenos días, no he puesto ya mi código porque está todo montado de una manera que si no lo explico nadie lo entendería jajajajaj... Básicamente lo que he hecho es un joyistick virtual por medio de pivotes. Uno de ellos hace de centro del joystick y siempre mira en la misma dirección del eje Y de la cámara, mientras que el segundo pivote se mueve en las coordenadas del primero pero sumando o restando con Input.GetAxis para que según presionemos el joyistick de nuestro mando actúe igual que la palanca. Así colocando al personaje en el centro del joyistick virtual, cuando pulsemos hacia una dirección, se moverá este pivote que suma o resta con Input.GetAxis y usando Quaternion.LookRotation conseguimos que el personaje vaya hacia donde queremos. Parece difícil montarlo pero cuando se entiende es mas fácil que todas esas ecuaciones matemáticas.
 
Estoy tratando de usar smoothdamp en mi cámara, para ver si el efecto me gusta mas que slerp y si me podría servir también para la rotación del personaje, pero me da un error y no me funciona...
 
- ¿Como debería de aplicar smoothdamp?. La teoría de Unity está muy bien, pero en la práctica me da errores.
 

Cita de: lightbug date=1578410140Veo 3 formas:
   
   

1. 
            Por código: simplemente midiendo el angulo de diferencia entre el ángulo "forward" del modelo (o ficticio puede ser también) y el vector de dirección de movimiento. El truco está en que la rotación se ejecute siempre, pero no el movimiento. Este último solamente se ejecutará cuando el ángulo entre forward y dir sea menor a X.
         

      
2. 
            Por estados del animator + root motion: basicamente los giros de personaje y los desplazamientos son animaciones que pueden o no estar "centradas" (me refiero a que el modelo puede moverse hacia cualquier lado --> https://kybernetikgames.github.io/animancer/docs/examples/locomotion/root-motion/root-motion.gif)). Dependiendo del ángulo del punto 1 se dará un estado u otro (generalmente se suele enviar este ángulo como una variable a un Blend tree, de acá se determina el clip resultante). Entonces si el angulo es menor a un valor se dará el clip de movimiento, si no se dará el giro.
         

      
3. 
            No haciendo nada : Muchas veces queda bien y pro no hacer nada, en mi caso juego con la velocidad del Slerp para ver como queda (esto junto a la velocidad de caminar/correr). Ej:
         

   

       
   

La primera opción es la que he comentado en un mensaje anterior que no servia, porque da un problema y es que en cuanto estés en movimiento, si quieres rotar al sentido contrario, el personaje deja de avanzar porque no se cumplen las condiciones de que los dos ángulos coincidan, entonces no sirve. La segunda opción la tengo que estudiar porque puede ser una solución, ir jugando con animaciones y trayectorias, pero no es sencilla y es mas para un juego con mucho mas realismo. Creo que con menos trabajo se solucionaría.
 

Cita de: francoe1 date=15784108791º Tomas 2 muestras del ángulo en el eje Y del objeto. BackFrame CurrentFrame
   
   
      2º Obtener la diferencia absoluta de las muestras Math.Abs(CurrentFrame - BackFrame).
   
   
      3º Creas tu propia fórmula para obtener un valor del 0 al 1 según el valor de la diferencia.
   
   
      Ejemplo, suponiendo que la diferencia máxima sea 20.
   
   

1 - Clamp(diff, 0, 20) / 20

   
      4º Multiplicas la velocidad de movimiento con el resultado del paso 3.
   

Lo mas probable es que la solución sea una ecuación, lo que pasa es que no termino de entender las matemáticas y aunque tenga la solución delante de mis narices si no le veo la lógica no la entiendo... Me da que esta va a ser la solución pero no termino de entenderla.
 
Voy a seguir leyendo los comentarios y aprendiendo a ver si logro entender lo que me están explicando y soluciono el problema.

Un saludo.

Buenas tardes Lightbug, acabo de observar que para mover a su personaje utiliza Character Controller. Yo estoy usando un Rigidbody y tengo entendido que el Rigidbody calcula las físicas mientras que el Character Controller no y que por eso para un juego tipo plataformas es mejor utilizarlo por esto de saltar, etc, pero realmente viendo el vídeo que ha subido todas las físicas, etc funcionan perfectamente, e incluso el personaje rota bien.
 
- ¿Por que ha utilizado el Character Controller y no el Rigidbody para mover a su personaje?, ¿que ventajas tiene?.
 
Saludos.

Cita de: Jhonatan00_00 date=1578477158si quieres rotar al sentido contrario, el personaje deja de avanzar porque no se cumplen las condiciones de que los dos ángulos coincidan, entonces no sirve
   

Si estás constantemente acortando la diferencia de ángulos en algún momento se va a dar que esta diferencia será menor, incluso si pegás el giro de 180.
 

Cita de: Jhonatan00_00 date=1578485926Buenas tardes Lightbug, acabo de observar que para mover a su personaje utiliza Character Controller. Yo estoy usando un Rigidbody y tengo entendido que el Rigidbody calcula las físicas mientras que el Character Controller no y que por eso para un juego tipo plataformas es mejor utilizarlo por esto de saltar, etc, pero realmente viendo el vídeo que ha subido todas las físicas, etc funcionan perfectamente, e incluso el personaje rota bien.
   
   
      - ¿Por que ha utilizado el Character Controller y no el Rigidbody para mover a su personaje?, ¿que ventajas tiene?.
   
   
      Saludos.
   

Primero y principal, con respecto al tema del giro, no hace la diferencia, podés usar cualquiera de los dos.
 
En el video no se usa CharacterController, ese fue el nombre del asset que escogí. El personaje del video es un rigidbody dinámico con rotación bloqueada (físicamente hablando), el cual fue programado casi meticulosamente para que se mueva así (sobretodo para los benditos steps). Podría ser tranquilamente un rigidbody kinemático también (totalmente controlado por un script).
 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
El personaje kinemático usa un rigidbody en modo kinemático. El CharacterController es una implementación de Unity de un kinemático, copiando la implementación de Nvidia. En internet existe un guerra, a ver quién puede hacer esto o aquello, el Kinemático es mejor, el dinámico es mejor, y así hasta el fin de los tiempos. Este CC es muy preciso, vos le decís "movete de la pos A a la B" y el personaje (basado en sus reglas internas de slope, steps y collide&slide) se moverá colisionando con el mundo de manera continua (no discreta) hasta llegar a B o C (nueva pos resultante). En la sig imagen, discreto arriba, continuo abajo:
 

 
Super improtante: la detección de colisiones se debe implementar de cero usando Raycast, spherecast,capsulecast, etc
 
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Por otro lado el dinámico usa un rigidobdy dinámico con rotación bloqueada (usualmente). Hay formas y formas de usar un RB dinámico. Muchas veces te van a decir que ni se te ocurra cambiar la velocidad directamente de un rigidbody porque estás pisando su comportamiento base, y es cierto. En este caso es conveniente usar Fuerzas, estas se traducen a velocidades y estas últimas finalmente a posición, así las físicas se encargan de determinar todo por vos. Además tenés detección de colisión "gratis", tu único trabajo es mover el rigidbody. El personaje del video no hace esto último, hace rb.vel = Valor , y yo de fondo modifico este valor según mi propia gravedad, velocidad de movimiento, impacto externo (de otros rigidbodies), etc. Por esta razón se ve "snappy" y super preciso.
 
 
 
En resumen es un dinámico que se mueve como un kinemático (o también un kinemático con detección de colisiones y físicas gratis).
 
Saludos

Buenos días, he estado estudiando sobre lo que me han explicado ustedes en los comentarios y he podido llegar a la conclusión de que existen muchísimas formas de conseguir el mismo resultado, unas mas complejas que otras, pero todas igual de válidas.
 
Acabo de encontrar la solución al problema pero a mi modo, que es mas sencillo de entender porque usa la lógica y no tanto las matemáticas que las soluciones que me han propuesto:

Como dije en un comentario anterior, mi personaje rota hacia donde tiene que ir en relación a la cámara porque hay dos pivotes (GameObject vacíos) que actúan conjuntamente a modo de Joystick virtual. Mientras el pivote central está en la posición donde se situa el personaje y tiene la misma rotación en Y que la cámara, el pivote de dirección se puede mover con referencia a la posición del pivote central. Así el personaje siempre sabe hacia donde tiene que rotar, que será hacia la posición donde esté situado el pivote de dirección. Esta solución tuve que idearla igual que la del movimiento a mi modo, porque nadie en todo Internet da la forma de poder hacer girar el personaje en relación a la cámara sin saber hacer antes un cohete espacial para la Nasa.
 
Para avanzar, el personaje simplemente corría hacia delante de tal forma que como ya estaba mirando hacia la dirección donde tenia que hacerlo el movimiento era correcto, iba hacia donde queríamos, pero ya saben cual era el problema, que al rotar lentamente como ya empezaba a correr giraba como un coche en lugar de girar y luego avanzar, de tal forma que he tenido que seguir estrujándome los sesos hasta encontrar la mejor solución y al final estaba delante de mis narices y no la veía. La solución es simplemente que el personaje se mueva independientemente a la rotación que tenga y en relación a la cámara. Sabiendo en que lugar está situado el pivote de dirección, ya no solo podemos usarlo para que el personaje rote hacia el, si no también para que se mueva trasladando las coordenadas del personaje hacia las que tenga el pivote.
 
¿Cual es el problema?. Estoy usando un Rigidbody porque es mucho mejor para las físicas y las colisiones que el CharacterController y me encuentro con que para mover correctamente un Rigidbody no se usa transform.position ni transform.rotation, si no fuerzas como pueden ser rigidbody.velocity, etc y estoy hecho un lío, se mueve temblando continuamente y me da problemas.
 
- ¿Cual seria la mejor forma de mover o trasladar un vector a otro usando fuerzas para el Rigidbody?.
 
- ¿Como movemos y rotamos un RigidBody de la mejor manera para que no de problemas?.
 
Un saludo!!.
 
 
 
 
 

El "efecto" que estas buscando es el mismo que el de Super Mario 64, lamento comentarte que existen múltiples problemas matemáticos a solventar, primero vamos a diferenciar los dos tipos.. 
 

1. 
      La dirección del jugador en el eje FORWARD es relativa a la camara.
   


2. 
      La dirección del jugador en el efe FORWARD es absoluta a la camara.
   

En la forma (1) vas a tener que ver la diferencia angular absoluta sobre el eje Y entre la cámara y el jugador.
 

float diff = Mathf.Abs(cam.angle.y - player.angle.y);

 
Teniendo la diferencia puedes crear el comportamiento necesario para compensar la rotación con el movimiento.
 

player.angle.y = Mathf.Lerp(player.angle.y, cam.angle.y, lerp_time);
if (diff < 2)
MovePlayer();

 
Esta explicación es la que te dimos anteriormente, a diferencia que se intenta crear un valor "factor" para que la rotación no sea constante.
 
 
 
En la forma (2) vas a tener que ver la diferencia angular absoluta sobre el eje Y entre la cámara y el "Joystick Target" -
 
¿Que es "Joystick target"?

Esto es un Vector que predice la posición futura del jugador en función al valor del joystick y la posición actual.

 
 

Vector3 joystickTarget = player.position + joystick.axis;

 
¡Importante! - los AXIS del Joystick siempre se deben normalizar, para evitar una velocidad 1.5 en los movimientos diagonales.
 
 
 
Ahora deberias tomar la diferencia angular entre el FORWARD del player y el valor de joystickTarget.
 

Vector3 angle_joystick = (josytickTarget - player.position).normalized;
Vector3 angle_diff = angle_joystick - player.forward;

 
Y a partir de acá se vuelve a repetir los pasos para la forma (1).
 
Esto no soluciona el problema al 100% en Super Mario 64 la cámara se "AUTO AJUSTA" detrás del jugador mientras este se mueve, por lo cual faltaría la implementación de la compensación de la cámara.
 
¿Los saltitos de rigidbody solo son perceptibles en la ventana "GAME" o tambien se ven dentro de "INSPECTOR"?

Debería de sacarte esta duda por que podria ser un error en el comportamiento de seguimiento de la cámara, tal como para las físicas se utiliza FixedUpdate para la actualización de la posición y rotación de la cámara se recomienda utilizar LateUpdate.  
 
 
 
Los códigos no funcionan son solo ejemplos.

Buenas noches Francoe1 y gracias por responder, voy a tener que estudiar paso por paso todo lo que me ha explicado en su comentario porque son muchas cosas y tengo que ir desmenuzando todo para ver si lo entiendo al 100% y logro solucionar el problema, pero muchas de las cosas que me ha explicado si que las entiendo y ya están solucionadas en mi proyecto, aunque claro, usted tampoco ha visto un gameplay y no sabe exactamente que es lo que me falta por hacer...
 
La cámara no es exáctamente la del Mario 64, es mas bien como la del Zelda Ocarina Of Time, porque en Mario 64 la cámara no sigue siempre un patrón si no que va cambiando según la zona del escenario del juego mientras que en Zelda si sigue un patrón de comportamiento fijo, aunque esta misma cámara también la podemos ver en mil juegos de Nintendo o incluso de Play Station como en el Spyro the Dragon o cualquier otro titulo plataformero y no se por que todo el mundo la llama "la cámara del Mario". 
 
La camara ya se "recoloca" detras del personaje conforme va girando, aunque no hace eso exactamente si no que sigue con la mirada al protagonista mientras se mueve a derecha o izquierda dando la sensación de que rota para recolocarse detrás, aunque no lo hace. No me da ningún problema, es la rotación del personaje que avanza a la vez que rota haciendo un arco lo que quiero mejorar. Si quiero puedo solucionar el problema haciendo exactamente lo que hacen en Mario 64, porque solo tendría que aumentar la velocidad de rotación y ya está. En Mario 64 si estamos mirando al frente y rotamos hacia la cámara se reposiciona en un frame, directamente aparece mirando a la cámara y punto, así solucionan el problema mucho mas fácil (que hay que ver como nos calentamos la cabeza hoy día para hacer detalles que antes ni existían y los juegos de antes les dan mil patadas a los de ahora).
 

Cita de: francoe1 date=1579106246 
   
   
      ¿Los saltitos de rigidbody solo son perceptibles en la ventana "GAME" o tambien se ven dentro de "INSPECTOR"?

      Debería de sacarte esta duda por que podria ser un error en el comportamiento de seguimiento de la cámara, tal como para las físicas se utiliza FixedUpdate para la actualización de la posición y rotación de la cámara se recomienda utilizar LateUpdate. 
   

Los saltitos me los da cuando estamos jugando, tanto en la ventana del inspector como en la de Game... además no estoy usando ni FixedUpdate ni LateUpdate, yo lo meto todo dentro de void Update... Aunque creo que el problema es que no estoy usando bien la forma de mover al personaje por medio del Rigidbody. Estoy usando rigidbody.velocity = new Vector3 (...); para el salto y  rigidbody.MovePosition para que busque recolocarse en la posición del pivote de dirección que he creado para que se mueva hacia donde queremos. Me parece que debería de usar rigidbody.velocity para todo, para el salto, avanzar, etc... o en todo caso rigidbody.AddForce... o no lo se, ¿por que hacen tantas funciones para mover objetos?. 
 
En fin... que al final terminaré copiando paso por paso el tutorial de movimiento relativo a la cámara (aunque no lo entienda, como hace casi todo el mundo) y problema resuelto, pero no me gusta hacer las cosas copiando y pegando, si no aprendiendo y a mi manera porque si no siento que el juego no es mio, ni tengo idea de nada... con decir que modelados, animaciones, texturizado y todo es mio al 100% y que no he cogido ni un solo recurso de Internet, ni Script... nada... solo un script del foro, del compañero Igor que es un shader que me ha creado el para poder usar en Unity 4 (que en esta versión no viene implementado cuando en las mas nuevas si) que sirve para poder hacer texturas con brillo solo en algunas zonas y no lo considero un recurso porque es algo que los Unity nuevos hacen.
 
Voy a descansar un poco por hoy que tengo la cabeza loca entre el trabajo y el juego.

Un saludo y de nuevo gracias.

Buenos días, sigo tratando de solucionar el problema y no es nada fácil. No porque yo no entienda algo de lo que me han explicado (porque me he puesto a estudiar y aplicar todo) si no porque mi cámara tiene un comportamiento que no es igual al comportamiento que tiene por ejemplo la cámara del videotutorial y por tanto el movimiento del personaje no reacciona igual.
 
En el vídeotutorial se toma como referencia a la cámara para que se mueva el personaje (que es lo mismo que si lo solucionas de la forma que ha explicado Francoe1 de coger la posición del personaje + joystick.axis porque siempre tendremos que tener en cuenta también el angulo Y de la cámara) y en el tutorial funciona porque la cámara es estática, pero ¿que pasa si la cámara va siguiendo al personaje y rotando a su vez?, que la posición hacia donde se tendría que mover el personaje iría rotando, lo que produce un efecto de deslizamiento lateral al moverse a derechas o izquierdas que no queda nada bien y no me sirve.
 
La única solución creo que es como ha explicado Lightbug (Fancoe1 en otro comentario también me ha dicho que esta es otra solución también): Midiendo la diferencia en angulos entre el angulo del personaje y el angulo al que debe de tomar, para indicar que hasta que esa diferencia no sea menor a X, el personaje no comience a avanzar. Después usando la velocidad del personaje podemos determinar si una vez esté ya corriendo queremos ampliar esa diferencia de angulos para que no se pare, anularla o hacer lo que queramos, aunque no queda tampoco demasiado profesional.
 
Como dice el amigo Lightbug:
 

Cita de: lightbug date=1578496230En el video no se usa CharacterController, ese fue el nombre del asset que escogí. El personaje del video es un rigidbody dinámico con rotación bloqueada (físicamente hablando), el cual fue programado casi meticulosamente para que se mueva así (sobretodo para los benditos steps). Podría ser tranquilamente un rigidbody kinemático también (totalmente controlado por un script).
   

El rigidbody no rota, está bloqueado y la rotación se hace por kinematics, osea animaciones. Creo que es la forma en que los desarrolladores profesionales lo hacen, porque de otra manera con una cámara que te sigue y rota de la manera que la mía es imposible solucionar el problema si no es haciendo esto de las animaciones o con lo de la diferencia entre los ángulos que no queda demasiado bien tampoco.
 
Si se me ocurre algo mejor lo postearé.
 
Un saludo.

@Jhonatan00_00 te estás complicando demasiado por algo simple.
 
1º Deberías resolver el problema de la dirección relativa, esto es simple, unity tiene un función TransformDirection que permite transformar direcciones locales a direcciones globales.

Sabiendo esto te darás cuenta que para que la dirección del AXIS sea relativa a la cámara deberias transformar su dirección.
 

Vector3 axis = new Vector3(Input.GetAxis("Horizontal"), 0, Input.GetAxis("Vertical"));
axis.Normalize();
axis = cameraTransform.trasformDirection(axis);

 
Ya puedes utilizar axis como vector de dirección relativo a la camara.
 
2º Ahora deberias tener un look target, esto seria, posición actual del jugador más dirección
 

Vector3 lookTarget = playerTransform.position + axis;

 
Con esto puedes empezar a crear la lógica de ángulos que comentamos arriba, para comparar los ángulos deberias sacar la diferencia entre playerTransform.forward y axis.
 

Vector3 angleDiff = axis - playerTransform.forward;

 
Ahora tenes los 3 valores necesarios para la lógica.. 
 

if(Mathf.Abs(angleDiff.y) < 5)
  playerTransform.Translate(axis * speed * Time.deltaTime);
playerTransform.rotation = Quaternion.Lerp(playerTransform.rotation, Quaternion.Look(lookTarget, Vector3.up), 15 * Time.deltaTime);