Jump to content
UnitySpain

Aceptamos donaciones vía Paypal.

UnitySpain.com es un servicio gratuito, pero mantener la Comunidad conlleva una serie de gastos.

Fondo Anual Unityspain: Donados 15,00€ de 150,00€

  • Servidor: Dominio.com y Hosting Web
  • Mantenimiento de los Foros
  • Contenido y Servicios Extras
  • Mantenimiento para Redes Sociales

All Activity

This stream auto-updates     

  1. Yesterday
  2. Qué va. Es muy fácil. Defines las transiciones en el componente y luego activas/desactivas las cámaras y el mismo realiza la transición de una a otra.
  3. 2/4 split screen y gestión de colisiones decente, además de transiciones entre cámaras (que es el motivo por el que tengo que hacer algún cambio en cualquier caso). Pero me da miedo que al final tener una cámara detrás del coche sea supercomplicado. En fin, voy a probarlo.
  4. Considero que lo importante es: qué puede hacer Cinemachine , qué te aporta y cómo te afectaría a tu gestor de cámaras, Y en el futuro lo puedes implementar dejando el código más o menos preparado.
  5. Y entonces debería usar Cinemachine para un juego de coches con algunas cinemáticas... ¿o me escribo la cámara? Me echa un poco para atrás meterme ahora con eso, pero por otra parte, igual estoy haciendo el pringao y pierdo muchas opciones... (además, lo venden muy bien, soporta 2 y 4 split screen, y la gestión de colisiones entiendo que la hará mejor que cualquier cosa que pueda hacer yo, aunque no sea lo más importante para mí ahora mismo)
  6. ¡Ole! Pero no has dicho na... ¿Entendemos que llevas 3 horas haciendo que funcione, o ha funcionado y llevas 3 horas entretenido con la nueva versión?
  7. Our brand new project for Unity Learn is an immersive VR escape room. Explore the potential of VR in Unity and create your own experience in a simple prototype environment. Let us introduce you to working with VR in Unity – with clear learning material and engaging gameplay. Dear witches, warlocks, and wizards, You know […] The post Escape the witch’s cottage in our new VR learning experience appeared first on Unity Technologies Blog. Ver artículo completo...
  8. Resumo los puntos claves para mí, como referencia: Multiples cámaras solamente si tienen características propias del render diferentes: suponía que al final partendría ser así, pero no quería meterme en el cambio todo sin preguntar. Incluso, podrías definir estos parámetros usando ScriptableObjects y mostrarlos en el inspector: interesante idea, a no olvidar si la gestión de cams se vuelve más compleja. No te olvides de pegarle una mirada al cinemachine: gracias, siempre hay que ver alguna referencia de cómo lo hace la gente que lo ha hecho varias veces y no sé qué es lo que se usa mayormente 8-). Tenderá a ser una maquina de estados: tiene todo el sentido. Gracias de nuevo. Entre los dos me habéis respondido y ampliado el tema.
  9. Finalmente me he actualizado, específicamente a la versión 2019.2 desde unity Hub, dentro de unos momentos veré si puedo abrir mi proyecto correctamente.
  10. GDC is always our favorite time of year at Unity. It’s a chance for us to connect with creators, customers, players, and partners from around the world. Unfortunately, this year, after much thought and deliberation, we have made the difficult decision to pull out of GDC 2020. While we did not make this decision lightly, […] The post An update on our GDC 2020 plans appeared first on Unity Technologies Blog. Ver artículo completo...
  11. Claro @J Montes, yo pensaba que eran cámaras de render o layers diferentes como te decía en mi ejemplo. Si son miles y todas tienen el mismo tratamiento, entonces es más lógico como también comenta @lightbug utilizar puntos de Transforrm para ir trasladando unas pocas cámaras. Y no te olvides de pegarle una mirada al cinemachine (https://unity.com/es/unity/features/editor/art-and-design/cinemachine). Lo he utilizado para movimientos de cámara estilo "del cielo a third player" o "de third player a travelling" y es muy potente.
  12. ¿"Potente" en qué sentido? osea, ¿un componente maestro quizás? Yo he usado multiples cámaras solamente si tienen características propias del render diferentes, osea, la cámara 1 renderiza tal y tal layer, la cam 2 tal y tal, y así. Un ejemplo bien claro de esto es la cámara del gameplay y la camara de la UI (quizás la de un inventario, podría ser). Ahora, el tener varias cámaras solo por comodidad del transform no me convence, verás, es probablem que te interese solo tener multiples ángulos, otros FOVs, near/far, etc. EN ese caso prefiero usar el concepto de cámara virtual (una clase de C# con propiedades de la cámara) y luego ir interpolando (o no) los parámetros. De hecho, así es como cinemachine funciona. Quédate solo con los "Transform" de referencia, todos los "Camera" no los necesitas (si solo querés cambiar de pos/rot/fov, etc). Con la camara virtual podés meter los parámetros de interés. Incluso, podrías definir estos parámetros usando ScriptableObjects y mostrarlos en el inspector (para que se entienda, sería un equivalente a los efectos del PostProccesing Stack, que son SritableObjects también). Esto sería útil si tuvieras un número razonable de cámaras para todo el juego (que necesiten ser iguales a lo largo del juego, un ej típico sería la cámara de 1er persona, la de 3ra persona, la de top down, etc). Podés meter esos transforms ( contenidos dentro de un elemento de camara virtual) en un componente controlador de la camara (el CameraController, ponele) y de ahí pasar de elemento en elemento, con la transición que quieras. Sí, y mucho, por lo menos para mí. Te vas a dar cuenta que cuando el controller de la cámara se transforme en super sayayin tenderá a ser una maquina de estados, así que probablemente vas a terminar definiendo a estas "cámaras virtuales" como estados independientes. Un ej: Al leer la tecla "C" el estado "First Person" (actual) pasa al "Third Person". Acá podés disparar un evento "OnTransitionStart" (ponele) y sabiendo que se pasa al estado "ThirdPerson" podés usar un cierto tiempo/tipo de transición, definido en el propio estado "ThirdPerson". Una vez que la transición se haya completado podés disparar un evento "OnTransitionEnd" que diga de qué a qué estado se dio, el tiempo que tomó la transición, etc. Lo bueno es que no tenés que definir un montón de cosas predefinidas en cada cámara virtual, sino que lo manejas vos dentro de cada estado. El tiempo de transición puede ser un elemento propio del estado, como también si admite o no transición a otro "transform", si tiene un target o no, efectos ordenados temporalmente, y mucho más.
  13. Eso va a depender de la colisión en sí. El CC lo que hace es proyectar su forma y decir "movete hasta ahí", pero no la hace de manera perfecta, en algunos casos simplemente queda un poquito penetrado en el collider. Si esto pasa, es posible que la "caja" lo detecte y sea empujada (por la misma simulación de físicas). --> Es un comportamiento deseado? No, no lo es, es un efecto no deseado, la caja no debería ser empujada nunca. Así que, si no te pasa, mejor. Por qué pasa esto? bueno, por situaciones de la misma escena, la forma del collider, la velocidad del personaje, la forma del personaje, por el ángulo de incidencia, etc etc. Por ej, also similar pasa en mi character controller. Si considero los rigidbodies dinámicos (caja blanca del gif) y los habilito para la "detección de objetos estáticos" (un layermask del personaje), lo que pasa es lo mismo que en tu caso, el personaje se proyecta con capsuleCast y detecta a la caja (en el gif no se ve ningun movimiento, como debería ser). En el segundo caso, sin considerarlo como estático (es decir sin que el capsule cast lo detecte) simplemente interactura normalmente, usando las físicas (que sería un "equivalente" a usar el callback en tu caso, aunque no es exactamente igual). Otra cosa que vas a tener que tener en cuenta es que las colisiones que hagas no van a ser "perfectas", con esto me refiero a que pasa lo siguiente: Se mueve el personaje hasta la caja (pegadito a ella). Se dispara el callback Se le da una fuerza a la caja Como ves, nunca vas a estar pegado + empujando la caja, siempre va a haber un pequeño espacio, que dependiendo la velocidad y fuerza de aplicación será más o menos notable. Lo ideal sería mover también al CC luego de haber empujado la caja, pero tendrías que esperar hasta después del step físico para saber donde va a terminar esta... sí, complicado. En estos casos podés usar algo que se llama PhysicsScene para meter a la caja sola en la escena, resimular el step físico, ver donde terminará la caja, y luego ahí posicionar el CC. Pero bueno, esto lo menciono medio a laire, si estás usando el CC de Unity no tiene sentido ponerse heavy con todo esto, con el callback debería darte resultados medianamente pasables. Si tu caja fuera muy "predecible", quizás hacer a la caja kinemática pueda ser una opción viable, pero ya no estamos hablando de físicas reales ni nada, simplemente movimientos norte, sur, este y oeste, tipo un laberinto de pacman. Sin agregarle un collider a qué? al personaje? el personaje tiene un CC que es (para las físicas) efectivamente considerado como un collider especial (esto lo podés testear con un OnTriggerEnter), pero sin reaccionar a nada, es kinemático basicamente. La colisión se detecta entre un kinemático (personaje) vs dinámico (caja) y se llama al callback. Este callback brinda información (el parámetro), de ahí en más está en el programador en qué hacer con ella. Saludos
  14. Last week
  15. Oki, sí, tengo una para UI y otra para interior del vehículo... Pero no me refiero a eso, sino a esto: Tengo un montón de cámaras definidas en cada vehículo, en total son cientos, más un montón más (potencialmente miles) repartidas por el escenario (con diferentes zooms, movimientos, etc). Por una parte, necesito esos GameObjects ahí, porque son el Transofrm de "dónde está la cámara" o "a dónde apunta". Son unas decenas por vehículo, pero están desactivados. Podría calcular todas esas posiciones dinámicamente, pero no creo que esos GameObjects sean un problema. Por otro lado, me parece engorroso tener que definir ese Audio Listener y ese Post Process Layer, así como otros parámetros, por separado para cada cámara. Y siendo tantas... podría tener esa información en un ScriptableObject o en cualquier estructura de datos. Aunque me parece cómodo que estén en la escena para poder buscar las más cercanas usando el propio motor (no tengo claro cómo haré esto). La verdad hasta ahora no me ha dado ningún problema como lo he estado haciendo, pero querría poder hacer travellings y transiciones entre diferentes cámaras... Estaba pensando por tanto en tener una única cámara, con un script a mi gusto (que pueda transicionar entre dos posiciones, camerashake, fade in/out... lo que vaya necesitando), y dejar sólo GameObjects vacíos en los vehículos (para usar como referencias de posición). Y por último, como dices, un CameraManager que me permita cambiar entre "camara frontal del coche 1, cámara fija de tal calle, travelling de punto A a punto B...). Estoy muy tentado de hacer esto, creo que tendría más control ¿tendría sentido?
  16. Yo utilizo hasta 5 cámaras diferentes. Que si UI, que si el PPFX para los fondos, que si AR, que si 360, que si modelos 3D, etc. Me creé un gestor de cámaras que va activando y desactivando y aplicando los parámetros adecuados.
  17. Os parecerá una chorrada, y hasta ahora no le había dado mucha importancia pero... Recomendaríais... Usar una única cámara, con un componente potente para gestionarla, y la voy acoplando a diferentes objetos... Ventajas: más difícil equivocarme con las settings mal copiadas en diferentes cámaras, FOV, rendering... Contras: no es tan "intuitivo" como tener todas las cámaras creadas y listas en cada objeto. Usar un GameObject y cámara diferente Ventajas: simplemente activando y desactivando la cámara que me interesa, ya está en su sitio y con su script de movimiento (si lo tiene). Contras: Lo malo de esto es que cada vehículo y en varios sitios tengo cámaras, así que acabaría teniendo cientos de cámaras (si bien desactivadas todas menos una). ¿Qué recomendáis? ¿cuál sería la estrategia "estándar" sugerida por Unity y por los assets de cámara más típicos? ¿y si tuviese un asset de cámara potente (porque creo que acabaré teniendo varios controladores para las cámaras, cinemáticas, etc)?
  18. Yo también lo creo. Al final Unity no lo hace tan mal, adapta todo lo que puede automáticamente, y para cualquier fallo que veas al compilar encontrarás información en Internet. Los cambios al código se pueden hacer bastante mecánicamente (a mí me salpicaron los sistemas de partículas y algunas otras llamadas, pero no mucho más). Los cambios producidos en el aspecto pueden ser más fastidiados, pero coincido con @iRobb, tendrás que pasar eso en algún momento.
  19. Sagerao :D, pero no, he probado a recalcularlas. El shader cuenta espacio para 3 ventanas en un triángulo y 5 en el adyacente, supongo que porque mis edificios no son estrictamente ortogonales o por algún bug. De todas formas prefiero hacer esto generando coordenadas UV, al menos por ahora. Dejo aquí el progreso. Grabación de replay y "ghost car":
  20. Siempre copias de seguridad. Y haz un paso, copia, otro paso, copia. Siempre copias de seguridad. Y haz un paso, copia, otro paso, copia. Yo lo que hago es un zip del proyecto y le añado al final "v1", "v2", " v3 pre-loquesea", "v4 post-loquesea", etc.
  21. Bien, veré que puedo hacer, por si las dudas haré una copia de seguridad aparte de mi proyecto
  22. @Ezequiel Torres Antes de migrar puedes buscar herramientas en GitHub para Safe-Migrate, había una, no recuerdo específicamente que te permite migrar desde Unity 5 a 2018, donde cambio el serializado, y luego integraron el nuevo sistema de Prefabs y nuevamente necesitábamos herramientas para migrar, existen, están por algún lado del internet, no te paso link por que es inútil, es cuestión de prueba y error.
  23. l La verdad estoy a un paso de considerar borrar mis avances y empezar de 0 en las nuevas versiones de unity jaja
  24. Hombre, no sería más lógico resolver el problema de la migración, que tarde o temprano tendrás que hacer?
  25. pioj

    YourCity Racing

    Creo que estás usando la normal de la carretera, en vez del suelo de los edificios, mira lo que te digo...
  26. Estoy creando un juego en unity en su versión 2018.2.14. Mi juego no se muestra en pantalla completa en dispositivos con notch, y está limitado por el área segura de la pantalla. Sé que las nuevas versiones de la unidad tienen opciones específicas para este problema.Que son, "Iniciar en modo de pantalla completa" y "Renderizar fuera del área segura" que aparecen en la configuraciones de player settings.Pero no puedo actualizar mi unity ya que al hacerlo mi proyecto se rompe, y por ente, no tengo acceso a esas opciones.¿Qué puedo hacer para que mi juego se muestre en pantalla completa y se renderize fuera del área segura en cualquier dispositivo con notch al igual que en dispositivos que no lo tienen?Gracias de antemano.
  27. Hola @Jhonatan00_00, al parecer en el video el movimiento se debe a que el jugador se está moviendo modificando la posición directamente (CharacterController), puede existir un Physics-Step entre el movimiento y el "re acomodamiento" que genere una colisión dentro del collider de la caja que contiene el Rigidbody. En resumen, por x cantidad de tiempo el jugador está traspasando al cubo. Esto una hipótesis. Por la foto y otras preguntas ahora entiendo que el movimiento del jugador se basará en 3D, esto es muy importante, en principio te diría que elimines la posibilidad de hacerlo con Raycast, en 3D es un poco más complejo de asimilar que en 2D y sin los conocimientos matemáticos necesarios es bastante dificil lograr un buen resultado. ¿Como simular la física de contacto? Es simple, character controller utiliza un Capsule Collider para detectar sus colisiones, podrias crear un Componente que detecte y lanze un evento de colisión con todos sus contactos. public class CollisionManager : MonoBehaviour { public delegate void CollisionDelegate(Vector3 point, Vector3 normal, Transform go); public event CollisionDelegate CollisionEvent; private void OnCollisionStay(Collision collisionInfo) { foreach (ContactPoint contact in collisionInfo.contacts) CollisionEvent?.Invoke(contact.point, contact.normal, contact.transform); } } Ahora capturas el evento y compruebas si el objeto colisionada contiene un rigidbody, luego aplicas la fuerza en el punto de contacto con su normal y la velocidad del jugador (la velocidad del frame anterior). public class CharacterControllerPhysics : MonoBehaviour { [SerializeField] private CollisionManager m_collision; private void Awake() { m_collision.EventCollision += OnCollision; } private void OnCollision(Vector3 point, Vector3 normal, Transform go) { if (TryGetRigidbody(out Rigidbody rb)) rb.AddForceAtPosition(normal * PLAYER_CURRENT_VELOCITY, point); } private bool TryGetRigidbody(Transform t, out Rigidbody rb) { rb = t.GetComponent<RigidBody>(); return rb != null; } } PLAYER_CURRENT_VELOCITY debería ser el valor de la velocidad del frame anterior. Esta es la forma más sencilla de hacerlo, existen alternativas con mejores resultados pero aumentan proporcionalmente su complejidad.
  1. Load more activity
×
×
  • Create New...