Hola a todos!!!!
 
Me está ocurriendo algo muy raro (o al menos yo lo veo asi) y no se que estoy haciando mal. Dejo un video explicandolo ya que creo que asi se puede entender mejor.
 
El caso es que dibujo unos rayos en pantalla y la posicion donde empiezan estos rayos no coincide con la posicion start que les paso en el Debug.DrawRay(). Y tampoco concide la direccion que le paso con la que visualmente se ve reflejada en la pantalla.
 
 
 
Esta función de pitar los rayos se ejecuta en una función OnAnimatorIK() por si sirve de algo. El caso es que da igual que la funcion de pintar los rayos la ejecute antes o despues de que a los huesos les aplique o no una modificacion mediante IK, ya que el problema sucede igual.
 
Dejo el video para que lo veais. A ver si alguno puede ayudarme a entender y solucionar que está ocurriendo.
 
https://youtu.be/nOsmuh4QZtU
 
Saludos y gracias de antemano

Hola, fijate que pasa si lo llamás desde lateUpdate, que si mal no recuerdo está antes de la etapa de Render y después de todo lo relacionada a la animación.

Yo también creo que sea algo con el momento de llamar la función, porque aparentemente el código está bien y si te fijas hay como un desfase, prueba a llamar la función cuando pauses el juego, quizá así coincida:
 
https://docs.unity3d.com/ScriptReference/EditorApplication-pauseStateChanged.html
 
O igual podrías probar pausando el juego y dándole al step para avanzar un frame y ver si así coincide...

puede ser loque dice @lightbug
 
pero tambien puede ser el script ejecution order....

Gracias a todos por responder!
 
Llevais razón, cuando ejecuto los rayos desde el LateUpdate van sincronizados con los huesos de la malla. Esto es una tremenda ***da para mi, porque necesito los resultados de esos calculos de dirección, (y otros calculos), entre los huesos de las caderas y sus respectivas rodillas en el OnAnimatorIK(). Para que cuando terminen esos calculos aplicarles el IK oportuno segun los resultados de esos calculos.
 
Pero parece que son erroneos.
 
En el Manual de Unity viene que la actualización de las animaciones, (si es que esto es a lo que se refiere con las animaciones del Animator), se produce en algun momento Despues del Update() y antes del LateUpdate()...
 

 
He estado haciendo algunas pruebas y el OnAnimatorIK() se ejecuta antes del Update(). No se por qué, pero no le veo sentido a que esto sea así, ya que si el OnAnimatorIK() va antes que la actualización de las animaciones del muñeco, todos los calculos para los IK´s que se hicieran en ese frame estarían mal. 
 
Pensaba que primero Unity Actualizaba las animaciones moviendo los huesos del muñeco a sus nuevas posiciones. Y despues se ejecutaba el OnAnimatorIK() para que pudieses decirle que modificase la posicion/rotacion del hueso que fuese...
 
¿Esto quiere decir que si yo tomo una posicion del hueso del pie en OnAnimatorIK() para hacer algunos calculos, esos calculos serían erroneos porque en ese frame el animator aun no ha actualizado el movimiento de cada hueso segun la animacion que tenga en este frame?
 
 
 
 

Cita de: gZone date=1513235199Si y no. No son erróneos, y sí, son de antes de actualizar el movimiento.
   
   
      ¿Lo que buscas es saber la posición final antes de que actualice la animación?
   

Si. Si te he entendido bien, eso es lo que necesito. Necesito saber la posicion que tendrán los huesos cuando actualice la animación, pero en el OnAnimatorIK() que se ejecuta antes de que se actualicen las animaciones en ese frame... jaja... parece un trabalenguas

Cita de: ftejada date=1513262423Si. Si te he entendido bien, eso es lo que necesito. Necesito saber la posicion que tendrán los huesos cuando actualice la animación, pero en el OnAnimatorIK() que se ejecuta antes de que se actualicen las animaciones en ese frame... jaja... parece un trabalenguas

Alguna idea de como abordar este problema???

Prueba a "predecir" la siguiente posición;
 

Vector3 posAnterior;
{
Vector3 vectorDelta = posAnterior - posActual;
Vector3 proximaPosicion = posActual + vectorDelta;
posAnterior = posActual;
}

 
Claro que el movimiento no es lineal pero quizá puedas usar las dos rotaciones para calcular una aproximación más exacta (?).
 
Por otro lado le he echado un ojo a la api y hay una función que parece que reproduce la animación en un momento dado, igual podrías probar a llamar esa función, tomar las posiciones de los huesos y hacer los cálculos, aunque vete a saber cómo tire eso, que igual no cambia la posición de los huesos hasta el siguiente frame...

Cita de: juanma_teso date=1513554548Prueba a "predecir" la siguiente posición;
   
   

Vector3 posAnterior;
{
Vector3 vectorDelta = posAnterior - posActual;
Vector3 proximaPosicion = posActual + vectorDelta;
posAnterior = posActual;
}

   
      Claro que el movimiento no es lineal pero quizá puedas usar las dos rotaciones para calcular una aproximación más exacta (?).
   
   
      Por otro lado le he echado un ojo a la api y hay una función que parece que reproduce la animación en un momento dado, igual podrías probar a llamar esa función, tomar las posiciones de los huesos y hacer los cálculos, aunque vete a saber cómo tire eso, que igual no cambia la posición de los huesos hasta el siguiente frame...
   

Gracias juanma_teso!!
 
Podrías decirme como se llama la función que indicas? es que yo estuve buscando algo asi y no recuerdo bien si es que no la encontré o no supe utilizarla. Y sabiendo el nombre voy mas directo para ver si es la que yo busqué
 
 
 
Un saludo
 

Cita de: gZone date=1513561458No lo termino de ver... ¿podrías detallar un poco el... para qué necesitas saber la posición final antes de que actualice la animación?
   

Bueno es algo complejo de explicar escribiendo... Digamos que lo que quiero conseguir es tener un sistema IK para que los pies se adapten a las irregularidades del terreno(que yo lo tengo perfectamente integrado), pero con la caracteristica de que si tienes un rigidBody en tu character sea capaz de subir escaleras de manera "limpia" y precisa sin que el collider sea un problema.
 
Tengo varias ideas de como conseguirlo, pero me he encontrado con este problema de imprecisión en los datos que tengo para hacer los calculos correctos. Esto no me permite poner en practica esas ideas de manera precisa ya que los datos con los que trabajo no son correctos despues en pantalla.
 
 
 
Digamos que la forma mas adecuada que encontré para hacer el IK de las piernas respecto al terreno, es el de coger la posicion, de los hueso de turno, que tienen por la animacion en ese frame, (que supuestamente yo creia que era la posicion final de los huesos en ese frame y no la del frame anterior), y restarle esa pocición a la de la posicion actual del character... Con eso obtengo los datos para poder posicionar el IK de los pies en cualquier momento.
 
Cuando se trata de posicionar los pies con IK parece que funciona perfecto. Pero como necesito tambien hacer calculos para saber como deberia de ir desplazando tambien la propia posicion del character, al subri escaleras por ejemplo, pues estos datos son imprecisos debido al problema de que hago los calculos en realidad con la posicion de los huesos pero del frame pasado... Yo necesitaría saber donde iria la posicion axacta del hueso en el frame dado mediante su animacion y en base a esos datos de posicion, hacer los calculos necesarios para ver en que posicion deberia ir el character...
 
 
 
Lamento si no me he explicado con claridad pero es algo lioso de escribir...
 
Saludos

Cita de: ftejada date=1513638173 Digamos que lo que quiero conseguir es tener un sistema IK para que los pies se adapten a las irregularidades del terreno(que yo lo tengo perfectamente integrado), pero con la caracteristica de que si tienes un rigidBody en tu character sea capaz de subir escaleras de manera "limpia" y precisa sin que el collider sea un problema.
   

Léase "Assassin's Creed y demás parafernalia de IK", etc etc etc.
 
Yo recomendaría usar 2 rays en cada pie: Uno para el alcance/distancia contra el objeto o pared, y otro justo en la planta (hacia abajo) para el choque de la planta del pie contra el suelo.
 
Como no sé qué le pica más al motor en calcular esas cosas, igual sería más eficiente unificar esos 2 rays en un solo SphereCollider para cada pie, y usar los métodos de Physics para encontrar cada punto de interés (contacts, normals, y bounds, vaya..)
 
 
 
De todas formas, haz uso de las guías y los tutoriales típicos de youtube sobre el tema: