Jump to content

lightbug

Registrados
  • Content Count

    2,352
  • Joined

  • Last visited

  • Days Won

    197

lightbug last won the day on May 23

lightbug had the most liked content!

Community Reputation

790 Excellent

About lightbug

  • Rank
    Leyenda

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

2,793 profile views
  1. También podés cambiar la iluminación ambiental, si te vas a Lighting Settings podés usar diferentes esquemas (Skybox, Gradient o Color).
  2. Craaack! es buenísimo, ahora mis screenshots serán más profesionales.
  3. No te puedo creer, pensé que te había contestado y al final no jajaja. Bueno, con eso me refería a que el MoveTowards, Lerp o similar solamente te devuelven un Vector3, nada más. Sí, como bien dices, solamente el valor que indicas de destino del IK. Subí el código de última.
  4. En 2D el RaycastHit2D es el valor que retorna el método, no es un "out" como en 3D: RaycastHit2D hitInfo = Physics2D.Raycast( ...); El cómo definas un Vector3 (o 2) no es el problema, podés usar lo que quieras. Lo que sí importa es el Vector3 que pases al sistema de IK, al usar SetIKPosition( ... ). Para el ejemplo que dí antes quizás un lineCast sería mejor, lo hacés desde la posición del frame anterior a la actual. Tené en cuenta la layermask también (algunos de estos métodos 2D también usan un ContactFilter2D creo, basicamente tienen layerMask, profundidad, y más ).
  5. Nada es más exacto que hacer un raycast, te permite predecir y corregir de manera exacta donde va a parar el IK, además de que podés medir frame a frame el desplazamiento de este trigger. Podría decirse que lo podés considerar "Temporal" de alguna manera, mientras que un OnTrigger se llama en un frame y no te da ninguna data de nada. El OnTriggerEnter corre cuando haya overlap con un collider por primera vez. Ojo, es overlap, acá no se habla de contacto. Si necesitás el contacto (o más de uno) vas a tener que involucrar un rigidbody dinámico. Se me ocurren dos ahora mismo: 1. Podrías también obtener el "Closest Point": https://docs.unity3d.com/ScriptReference/Physics2D.ClosestPoint.html ... y de ahí modificar el IK en base al punto obtenido. Igual esto no tiene en cuenta el desplazamiento del IK frame a frame. 2. Podrías realizar el raycast midiendo el desplazamiento del IK frame a frame, o bien realizarlo una sola vez cuando suceda un OnTriggerEnter (vas a tener que guardar la posición vieja). En los dos casos, una vez que tengas el punto de interés modificas el peso del IK involucrado (LeftHand o RightHand) a 1 y lo posicionas en el Raycasthit.point + un offset (opcional), el tiempo que quieras. Si vas a manejar IK asegurate de hacerlo en OnAnimatorIK. Aclaro que no tengo idea como exactamente es que el brazo regresa a la posición original (por IK? un clip de animación? un blend?).
  6. Uhh se ve tremendo, buen trabajo! Los efectos están muy bien, falta un poco de sangre nada más y estaría genial.
  7. Ostia! *chin *chin hay que brindar señores, miren esos nuevos colores!!! se ven geniales, está todo más suavizado, me encanta! ... Ah si casi me olvido @francoe1 felicitaciones!!! 😃 la verdad tomaste la posta bien seguro y convencido, sinceramente te aplaudo 👏👏👏👏 hay que tener mucho valor para hacer eso. PD: woooow fui a poner un emoticón y casi me caí de la silla! ya arrancaste bien jaja.
  8. Agrego que me olvidé, la razón por la que puede o no pasar de largo un obstáculo es por el otro sync que me faltó explicar, comunmente asociado al "sync previo" o el "autoSync". Previo a cada update físico se realiza un sync, esta vez de T -> RB. Entonces se puede dar algo como esto: T -> RB (Sync) FixedUpdate: Se modifica RB Simulación Rb -> T (Sync) Update: Se modifica T --> Render Update: Se modifica T --> Render Update: Se modifica T --> Render Update: Se modifica T --> Render T -> RB (Sync) <--- Acá se lee que pasan los datos del transform al RB (notar que el RB quedó con los datos del punto 3) FixedUpdate: Se modifica RB Simulación ... acá es donde puede estar el problema (dependiendo de las propiedades del collider y de los dos pasos anteriores) Rb -> T (Sync) ────────────────────────────────────────────────────────────────────────── Acá dejo un documento interno de los devs de las físicas por si alguno está interesado en la parte del autoSync (está en inglés): Priorly, each change of a transform resulted in a synchronous update of the corresponding physics object (if present). That always happened on the main thread and could accumulate to quite a large number over the frame. That approach was easy to maintain, but the downside of always keeping the physics world in sync with the transform hierarchy was that we ended up writing to the physics engine too often, possibly updating some physics objects a lot more frequently than might be needed. One particular example is moving the root transform of a ragdoll with N rigidbodies in it (=N physics bones). Once you moved the root from script, there was a message sent to update all the child transforms down in the hierarchy. Each of those child transforms accepted the message, updated itself, and sent out another message to all the children of its own. This naturally stacked up, leading to O(N 2 ) complexity of updating a ragdoll. In order to solve that, we have introduced a mechanism of deferred physics updates. With this new approach, we don’t write the transform changes immediately. Instead, we store them in a buffer and apply at a later stage. Updates to the same transform are combined together and applied as a single update to the final pose (e.g. two updates to a transform become a single update right to the final pose in the buffer). We always sync transforms prior to running the physics simulation in order to make sure we simulate the latest poses. However, you can run the sync process manually too, using the new Physics.SyncTransforms() function. This makes sure that the transforms in Unity and the ones used by the physics engine are exactly the same. By default, we run in a compatibility mode that would automatically sync before running the operations that required the up-to-date transforms before [Para 2018.3 en adelante esto está desactivado por defecto]. That is: Before all the physics queries (e.g. Physics.Raycast, etc) Before reading data back from the physics engine directly (e.g. Rigidbody.position) Before simulating particles, if they were configured to compute collisions Before updating the camera flares effect As mentioned above, synchronising the transforms might be a costly operation so it’s recommended to avoid doing it without the need. For this reason, you can even switch off the automatic sync, via Physics.useAutoSyncTransforns.
  9. Por un lado tenés Transform (pos,rot y escala), que se utiliza principalmente para el renderizado, es decir antes de realizar el render del frame se leen los datos de este transform, se procesan en el shader (basicamente creando una gran matriz) representando en 2D (tu pantalla) un objeto ficticio en 3D proyectado (ortonormal o perspectiva) sobre una cámara dada. Como regla, asocia al Transform al render. Por otra parte están las físicas, que trabajan con el concepto de collider + rigidbody. Siempre al final de cada update físico se pasan los datos del rigidbody (pos y rot) al transform. Las físicas hacen lo suyo y a lo último actualizan el transform, así vos podés ver en pantalla lo que pasa, de lo contrario estaría todo congelado. Las colisiones y demás pasarían internamente pero no serías capaz de verlas en pantalla. Este es un resumen usando un caso en concreto, modifcando rigidbodies en fixedUpdate y modificando transforms en update: Fijate como una vez que te metés con rigidbodies, al transform solamente se le pasan los datos del rigidbody (sincronización RB -> T ) para que este renderize. PERO, el mundo del rigidbody no está enterado si luego vos modificas el transform. Siguiendo con el video de ejemplo de arriba, este es el porqué se ven esos tembleques en pantalla, transform dice "nos vamos para adelante" y el rigidbody dice "no, hay un muro adelante!" y como Update suele correr más veces que la simulación física, parece como que Update gana hasta que la simulación entra y lo tira para atrás. Por esta razón usar las físicas (es decir, usar rigidbodies) y modificar los datos del transform es contradecirte a vos mismo. El video de arriba está casi completamente mal dado, así que cuidado. En los dos primeros casos está moviendo un rigidbody dinámico usando Transform, lo cual está horriblemente mal. Entiendo si lo hizo para mostrar lo mal que está, pero lo preocupante es que en un momento dice "Este método es el que más uso", cosa que me incomoda. En el caso de la fuerza está aplicandola en Update ... se hace en FixedUpdate. En MovePosition dice que funciona como transform.position , cosa que está tremendamente mal. Funciona como rigidbody.position, que no es lo mismo (ver el diagrama de arriba). Normalmente no funciona así, esto pasa solo con rigidbodies dinámicos. MovePosition se suele usar para rigidbodies kinemáticos. También usa Update. En el de velocity otra vez usa Update. TL;DR: Si tenés un rigidbody en tu código, andá mirando a los transform con cuidado, no solo a la hora de escribirlos (que claro que está mal), sino también a la hora de leerlos. Si dentro de tu loop moviste al rigidbody (rigidbody.position) el transform no lo va a reflejar para nada, son dos conjuntos de datos separados uno de otro. Saludos.
  10. Gracias. Me parece que por esto no utilicé el scrollrect. Para detectar el final simplemente comparé la posición de los créditos con la de la máscara, cuando este valor superaba tal "y" de referencia de llamaba un evento.
  11. Yo para este asset utilicé una mask sola: Quizás un scroll hubiera sido más apropiado :'(
  12. Yo uso sketchup, las texturas que ves en sketchup van a parar tal cual a Unity, si necesito cambiar algo lo hage en Sketchup y se actualizan perfectamente. No dependen del tamaño de la cara ni nada. La otra es usar pro-builder, que hace algo similar. Si necesitas aplicar materales con texturas a objetos individuales de varios tamaños (un buen ejemplo de esto son las rocas, pero hay muchos más) quizás lo mejor sería emplear materiales "UV-free", es decir con un planar o también (más famoso) tri-planar shader lo podés hacer. Pensalo como una proyección de la textura en las caras. Si las caras (por ende el objeto) cambian de escala, el material se mantiene. Por ej, un terreno es genial para mostrar esto: Ejemplos: Rocas (de todo tipo, forma y tamaño), tablas de madera (chiquitas, grandes, torcidas, etc), escombros, terrenos enteros, etc. Pensalo, va a depender de los objetos que tengas. Si es un interior te recomiendo sketchup, pro builder , etc. Si son objetos muy variados y repetitivos quizás uno de estos shaders sea la solución.
  13. Jaajaj Seleccioná el clip, te tienen que salir en el inspector. Si es un modelo importado, claro está. Si lo estás haciendo en Unity quizás en la misma ventana de animación (ctrl+6) tengas la opción (?).
UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...