Jump to content
UnitySpain

Leaderboard


Popular Content

Showing most liked content since 08/17/2019 in all areas

  1. 5 likes
    Buenas, si alguien lo recuerda, este juego lo empece hace mucho, lo deje abandonado y no pude resucitarlo al tratarse de versiones tan antiguas de Unity. Actualmente estoy haciendo un reboot, de momento y a modo de demo técnica, os muestro este pequeño video de ejemplo:
  2. 4 likes
    https://connect.unity.com/p/spriteanimator-2d-tool Completo sistema para trabajar con Sprite Sheets Visitar en Assets Store https://assetstore.unity.com/packages/tools/sprite-management/spriteanimator-153405
  3. 3 likes
    Es un pequeño juego 2D creado para la JAM de UnitySpain. Tienes que guiar al personaje por el bosque hasta que llegue a casa. El juego es tranquilo, se trata de ir encontrando los diferentes caminos y esquivar los peligros que se encuentra como los lobos o las lanzas. Creo que le dedique mas o menos unas 16 horas, y estoy contento con el resultado, tanto que me quedo con el proyecto para irlo evolucionando poco a poco, ya ire compartiendo los cambios y los "improvements". Cualquier idea, o crítica, que querais aportar sera muy bienvenida. Por ahora esta disponible en itch.io: https://uadla.itch.io/way-home
  4. 3 likes
    Hola soy James Roman, tengo ya varios años trabajando con Unity, y actualmente trabajo en una compañía como desarrollador de experiencias en Realidad Virtual. Y tengo ya bastante tiempo trabajando en VRLAB. Puedes verlo desde aqui. ¿Que es VRLAB? Es básicamente una colección de componentes para interacciones en VR usando Oculus, me he enfocado bastante en las armas ya que creo que es una de las cosas mas divertidas de probar en la Realidad Virtual, he incluido diferentes tipos de armas, escopetas, armas automáticas, revolver, arco y flecha, espadas. También diferentes tipos de recarga para estas armas, puedes cambiar manualmente el cargador a cada arma cuando este se agote, recargar usando diferentes tipos de gestos como en dead and buried, puedes recargar el revolver haciendo un giro rápido con la mano. - Armas - Como ya he mencionado he trabajado bastante el tema de las armas con un completo sistema de armas, varias armas ya incluidas (Escopetas, revolver, Automáticas), puedes tomar las armas existentes como base para crear las tuyas, o crear nuevas armas desde 0. - Completo Sistema de Interacción - También posee un completo sistema de interacción, muy extensible, puedes tomar objetos, interactuar con objetos, mover palancas, botones etc, crear animaciones de interacción diferentes para cada objeto, y diferentes comportamientos incluso para cada mano. - Arco y Flecha - Posee un arco realista con el cual puedes lanzar flechas, puedes tomar una flecha de tu espalda o simplemente tomar una que ya hayas lanzado, estas se pegan a los demás objetos de una manera bastante realista. - Diferentes Modos de Recarga - Posee diferentes formas para poder recargar las armas, puedes cambiar el cargador una vez que este se haya acabado, o simplemente realizar gestos con la mano como en dead and buried para recargar tus armas o simplemente tener munición infinita. - Sistema de Combate Cuerpo - En VRLAB puedes tomar un par de espadas y luchar contra los enemigos, los cuales responderán correctamente a las físicas, ademas de eso puedes golpear a los enemigos con tus armas, como con el arco o una escopeta si no tienes munición. - Botones y Palancas - Botones y palancas que responden correctamente a las físicas, desde las distancia puedes activar una palanca con un disparo o simplemente lanzando un objeto. - AI - Aunque el fuerte de este asset no esta en la AI, he añadido unos ejemplos bastantes interesantes y extensibles para trabajar con estos mismos. - Character Controller y Teleport - Tienes diferentes formas de moverte en VRLAB, la mas común quizás moviéndote alrededor con el joystick o usando un sistema de teleport muy parecido al de roborecall. Todo esto en prefabs bien organizados listos para tomar y soltar en la escena, con montones de posibilidades de modificación mediante el inspector, de igual manera me he esforzado para crear un código legible y placentero a la vista, así que si quieres simplemente entrar y mirar como esta hecho todo, y aplicar tus propias modificaciones mediante código, no debería ser muy difícil para alguien que tenga ya su experiencia con Unity. - Futuras Actualizaciones - - Añadir nuevas armas, entre ellas un lanzacohetes. - Sistema de inventario, para que puedas cargar varios objetos a la vez. - También cabe destacar que me gusta roborecall, y quizás añada algunas de sus funciones, entre ellas la posibilidad de tomar balas en el aire y devolverlas a los enemigos. - Luego simplemente escucharlos a ustedes y seguir mejorando. Dejo nuevamente el link al assetstore aqui, si lo pruebas no dudes en dejar un review para seguir mejorando, y si quieres contactar conmigo directamente puedes escribirme a james@unity3dninja.com finalmente los dejo con algunos vídeos cortos mostrando distintas funcionalidades.
  5. 3 likes
    Acá les dejo un excelente tutorial ( en tres partes ) a modo de introducción al nuevo Input system. Uno de los mejores que vi, los demás videos parecen copy+paste, además de que todos ponen las expresiones lambda sin ni siquiera saber que hacen (o por lo menos da esa sensación). Parte 1: introducción y Setup Basicamente de Input.GetKeyDown(KeyCode.w) a keycoard.wKey.isPressed Parte 2: Binding y Composite Acá explica como se pueden especificar bindings (conexiones entre acciones y dispositivos físicos) visibles en el inspector. Un "Composite" es lo mismo pero para con más de un binding. Parte 3: Input System Asset Se migra todo lo expuesto en la clase a un Asset propio del nuevo sistema, con la ventaja de setear varios ActionMaps (por ej uno para un menu, otro para gameplay, etc) con sus acciones y sus bindings.
  6. 3 likes
    @Rootet en tu script hay cositas que están bien otras que están mal, por ej: 1) Update para inputs, FixedUpdate para físicas: if (Input.GetMouseButtonDown(1)){ if (corriendo){ } else{ rigi.velocity = new Vector2(velocidad * 1.25f, rigi.velocity.y); } } En update, estás modificando una velocidad, cosa que debés hacer en FixedUpdate, esto se lee como "Si apreto el botón derecho y corriendo es false la velocidad X es el 25% más grande" y esta actualización sucede en un solo cuadro, no cuadro a cuadro. Además si la velocidad es un 25% más grande se supone que corriendo ahora debe ser true pero no, se setea true si apretás el otro botón (en FixedUpdate). ───────────────────────────────────────────────────────────────────────────────────────────────────── 2) Quién es responsable de corriendo? if (Input.GetMouseButtonDown(0)){ if(corriendo){ if ((enSuelo || !dobleSalto)){ sonido.Play(); //Empujón hacia arriba //Opción 1. Metodo up de Vector2 rigi.AddForce(Vector2.up*fuerzaSalto); //Otra opción //Aplicamos una fuerza de 0 en X y de fuerzasalto en Y //rigi.AddForce(new Vector2(0,fuerzaSalto)); if(!dobleSalto && !enSuelo){ dobleSalto=true; } } } else{ corriendo=true; NotificationCenter.DefaultCenter().PostNotification(this, "PersonajeEmpiezaACorrer"); } } Cuando apretás el botón izq y no está corriendo se da la primer vuelta (el else), es decir que se pone corriendo = true. En el siguiente cuadro GetMouseButtonDown no se dispara (por razones obvias) entoces el "if(corriendo)" no se da. Sí se va a dar el "if(corriendo)" en el proximo click. Además, ¿quién pone corriendo en false? Y volviendo al punto 1, solo si corriendo es falso la velocidad aumenta. Una vez que diste click izquierdo corriendo nunca vuelve a false (?). Puede ser que me haya olvidado de algo, muchas veces contesto a la ligera. ───────────────────────────────────────────────────────────────────────────────────────────────────── █████████████████████████████████████████████████████████████████████████████████████████████████████ Podés resolver el problema parcheando if's y demás, pero te diría que de entrada la estructura es muy confusa para una tarea tan simple, tomalo como una oportundad de mejora y experimentá con una nueva, que tenga más lógica y sobretodo que alguien externo al código lo vea y lo entienda al instante, pensá que esto es un salto y una funcionalidad de correr, practicamente no es nada. La lógica que te recomiendo para una mezcla Update + FixedUpdate en un platformer (y con cualquier personaje) es la siguiente (seguramente hay cosas que no definí, solo una idea muy por arriba): // inputs - esto expandilo a todas las inputs que estás esperando, lo mismo con ejes // En este ejemplo está solo correr "Run" (que elegí la leftShift) bool runPressed = false; bool runReleased = false; bool running = false; bool isGrounded = false; void Update() { // Update puede pasar 100 veces más rápido que FixedUpdate (50 fps por default), así que // todos los KeyDown se acumulan, no se setean, así no perdés ninguno en el camino // por acumular me refiero a usar una simple OR runPressed |= Input.GetKeyDown( KeyCode.LeftShift ); runReleased |= Input.GetKeyUp ( KeyCode.LeftShift ); } void FixedUpdate() { //Detectar suelo, determinar direcciones de movimiento, ángulos, etc // Por supuesto acá es donde decís "suelo = true o false" isGrounded = IsGrounded(); // el vector objetivo cuadro a cuadro, no necesariamente el aplicado Vector2 targetVelocity = Vector2.Zero; // bien general un "if( suelo ) .... if( isGrounded ) { //Todo lo que pasa si y solo si el jugador está grounded // en este caso la input a evaluar es run así que if( runPressed ) { running = true; targetVelocity.x = ... } else if( runReleased ) { running = false; targetVelocity.x = ... } } else //Todo lo que pasa si y solo si el jugador NO está grounded { //en el aire no puede correr running = false; targetVelocity.y = ... } //Una vez determinado el estado se aplica el vector obtenido a la velocidad (de la forma que quieras). rb.velocity = ...(dependiendo de targetVelocity) // IMPORTANTE --> Resetear inputs, FixedUpdate ya las usó runPressed = false; runReleased = false; } Animación y movimiento poco tienen que ver, si no ves los efectos en pantalla tratá de exagerar los valores, en vez de 1.25f poné 5f. Igualmente creo que sí, desde el animator podés setear la velocidad del clip (revisá las referencias de Animator o google más rápido), aunque no recuerdo, estoy completamente seguro que para el sistema Legacy (viejo) se puede hacer, pero con el componente Animation. Saludos
  7. 2 likes
    Buenas gente! Bucando información sobre como importar eficientemente audio para android he encontrado este articulo que seguro que os sirve de utilidad, a mi me ha servido para despejar muchas dudas: https://blog.theknightsofunity.com/wrong-import-settings-killing-unity-game-part-2/ Saludos
  8. 2 likes
    Cuando se ejecute tiene que existir como mínimo un suscriptor. No se inicializa ni se crea. Ya estás enviando parámetros distintos. Envías this.name por ejemplo, que será distinto en cada objeto (a menos que les hayas puesto el mismo nombre, aunque a nivel de instancia será distinto). Deberías mirarte el tema de eventos y delegados en C#, ya que es mucho más potente y ordenado. Al principio es complicado de entender aunque cuando lo consigas te darás cuenta de la potencia que tiene. Un vídeo de ejemplo. Hay muchos:
  9. 2 likes
    @lightbug, sí efectivamente. Solo si está corriendo puede aumentar la velocidad y nunca vuelve a false, hasta que se cae o toca una bomba (fin de juego). Muchas gracias por la ayuda, lo del script para leer inputs es una gran idea. Gracias Antonio, en ello estoy. El ejercicio me pide que use el GetMouseButtonDown. Ya casi lo tengo. Muchas gracias por el aporte Si, es muy buena solución, aunque pienso que nos piden algo mucho más sencilo. Gracias por contestar Buenas a todos, al final lo solucioné de la siguiente forma: En la parte del Update solo añadí lo siguiente: void Update() { if (Input.GetMouseButtonDown(0)){ if(corriendo){ if ((enSuelo || !dobleSalto)){ sonido.Play(); //Empujón hacia arriba //Opción 1. Metodo up de Vector2 rigi.AddForce(Vector2.up*fuerzaSalto); //Otra opción //Aplicamos una fuerza de 0 en X y de fuerzasalto en Y //rigi.AddForce(new Vector2(0,fuerzaSalto)); if(!dobleSalto && !enSuelo){ dobleSalto=true; } } } else{ corriendo = true; NotificationCenter.DefaultCenter().PostNotification(this, "PersonajeEmpiezaACorrer"); } } if (Input.GetMouseButtonDown(1)){ velocidad *= 1.25f; animator.speed *= 1.25F; if (corriendo){ } else{ rigi.velocity = new Vector2(velocidad * 1.25f, rigi.velocity.y); } } } Al componente Animator, también le añado el mismo aumento de velocidad y ya funciona y se nota más al pulsar el botón derecho. Era sencillo, una vez que ves la lógica bien. Aunque m e quedo con lo del script para los imputs ;) Muchas gracias a los que habéis dedicado unos minutos en ayudarme.
  10. 2 likes
    Un app se distingue de otra por el package name al compilarla. Puedes llamarla como quieras mientras no incluyas nombres o marcas comerciales.
  11. 1 like
    Toma mucho tiempo por la escritura del archivo .log. El problema es que se está utilizando un FileStream esto hace una llamada a GC y un retraso en el ciclo. La solución sería implementar tu propia consola de LOG con un buffer corto y sin un log persistente.
  12. 1 like
    Estéticamente sería un buen creepy-pasta si además le añades algún trasfondo misterioso y detalles escabrosos. Buen trabajo.
  13. 1 like
    Muchas gracias. Voy a ver a que piso voy xD
  14. 1 like
    No necesitas conocer la teoría sobre Quaternions. Solamente las reglas a aplicar. Realmente, nadie sabe lo que son
  15. 1 like
    En otro post (no de este topic) ya lo comenté. Pongo la copia: Olvídate de hacer rotaciones con los ángulos. Solo los Quaternions te van a servir. Las 3 reglas básicas de oro: - Para sumar rotaciones, se multiplican dos Quaternions. - Para restar rotaciones, se multiplica un Quaternion por el Quaternion.Inverse del otro. - No asignes nunca el valor 0 a un eje de una rotación. Réstale el offset inicial de rotación para mantener el eje fijo. Y en el caso particular del gyro es importante recoger el offset inicial, ya que puede estar en cualquier estado que no será el que te interese. Saludos
  16. 1 like
    ¡¡¡Por fin lo solucione!!! Al final desactive la opción de x86 (que por cierto en la version de Unit 2019 aparece ya como deprecated) hice el AAB y ya pude subirla sin problemas, me dio un aviso indicando que algunos dispositivos no podrían instalarse mi App (por el tema del x86) pero ya me dejo. Estuve leyendo que la arquitectura x86 para movil hace tiempo que intel dejo de desarrollar procesadores y hay poquisimos dispositivos con esa arquitectura el ultimo movil fue el ASUS' Zenfone 2 del 2015 Espero que le sirva de ayuda a alguien con el mismo problema.
  17. 1 like
    Yo por suerte puedo vivir con el skin light. Aún así suelo hacer lo de modificar la secuencia de bytes en el ejecutable para tener el skin pro y de esa manera al menos poder probar que mis herramientas se ven bien con ambos skins, aunque debo decir que ese hack cada vez es menos efectivo. No sé la razón, pero sospecho que el Unity Hub podría tener mucho que ver. En cualquier caso y por si te sirve de consuelo, hay gente buscando la manera de "abusar" del nuevo sistema de personalización vía hojas de estilo que Unity introdujo con su "maravilloso" UIElements para tener un skin pro "legal". Aquí os dejo un interesante hilo (que a su vez lleva a otros muchos hilos) con los progresos realizados: https://forum.unity.com/threads/editor-skinning-thread.711059/
  18. 1 like
    Si, en cuanto ha empezado a flotar la pelota hacia arriba me he dado cuenta, pero me ha servido para detectar que cuando el dispositivo android estaba del revés, la pelota no caía, y para ello he añadido este código: float gradosY; gradosY = Input.acceleration.y; if (gradosY < 0) { Physics2D.gravity = new Vector2(-Mathf.Cos(angulo), -Mathf.Sin(angulo)) * Gravedad; } else { Physics2D.gravity = new Vector2(-Mathf.Cos(angulo), Mathf.Sin(angulo)) * Gravedad; } Muchas gracias
  19. 1 like
    En Ohter Settings ya has marcado en Target Architecture ARMv7 y ARM64?
  20. 1 like
    Diría que el Awake se dispara antes de que hagas el respawn del player y por eso no lo encuentra. Prueba a cambiar el Awake por un Start que se ejecuta después o asigna el player sin buscar el tag desde el respawn del player al bulletmanager. Otra opción es tener estados en el player y si este está muerto, que los enemigos no interactúen en vez de quitarle el tag. Esta me parece la mejor.
  21. 1 like
    Recién he probado la beta y esto un 80% convencido (aclaro, no he metido ninguna de mis tools para verificar compatibilidad), el flat le queda muy bien y a nivel íconos hicieron un gran trabajo. Como soy pobre tengo el skin light de la dark no puedo opinar, me jode las pelotas que todavía los de Unity crean que la gente compra Pro para tener el skin (y sí, va a terminar siendo por esto si siguen así), eso demuestra la madurez de los directivos de fondo. Con respecto a la UI todavía hay cositas que no me agradan, pero eso es por el mismo estilo flat, por ejemplo muchas veces omito algo porque todo se ve tan igual y plano. A nivel de Editor han metido muy buenas opciones, lo de la view camera me parace genial (aunque no se si esto ya estaba), también lo de las tools de escena, el hover sobre los elementos también ayuda. Espero que el nuevo sistema de Inputs se integre, aunque creo que lo van a dejar para 2020. En la beta que probé hay errores muy básicos, por ejemplo das a "New Folder", la crea, pero no deja el foco sobre el nombre (cosa de escribir el nombre de la carpeta), uno tiene que ir y renombrarla cada vez. Otro error grave, cuando creas un nuevo script, antes podías escribir el nombre y la clase se renombraba, ahora se genera un "NewBehaviourScript" y arreglátelas como puedas. No miento, perdí como 45 minutos tratando de ver que estaba pasando, y claro, el error era lo que decía el cartel, pero después de estar 12 años creando clases quién iba a pensar que de golpe decidieron cagarla con el nombre. Como puede ser que versión a versión tengan los mismos errores?? esto se corrige una sola vez y listo, pero Unity se las rebusca para generar nuevos bugs una y otra vez, es increible. Seguro para el lanzamiento oficial todo esto se corrige, y seguramente la UI va a recibir iteración tras iteración de re-diseño, lo cual está bien, recuerdo el primer prototipo mostrado por los devs en el foro oficial y daba calambres, este está muchísimo mejor en comparación.
  22. 1 like
    joder... pues que pintaza los dos, que lastima no acabarlos, pero me imagino que debe ser una carga de trabajo bestial.
  23. 1 like
    Para VR Cardboard. Se publicará en Android/iOS en Septiembre de 2019. https://www.youtube.com/watch?v=BVv9WwLauZI https://www.youtube.com/watch?v=aUI9X622Yzw El audio tiene algunos lapsus. Luego vendrá la versión editada de promo. Es más enseñar el proyecto a nivel de Unity. Saludos
  24. 1 like
    Buenos días, perdón que escriba aquí mi duda, pero no me dejaba seleccionar ningún otro campo. Quería hacerles una consulta, estoy haciendo una app sencilla de realidad aumentada en mi trabajo. quiero reproducir video y mostrar algunos modelos 3D. El punto es que cuando pongo los vídeos se tildan un poco, o la reproducciones sale cortada por momentos, que podría ser? La causa es la especificación técnica del teléfono tengo un huawei p9 lite? Adjunto un video, saludos. SVID_20190827_103627_1.mp4.mp4 SVID_20190827_103627_1.mp4.mp4
  25. 1 like
    Aquí tienes un tutorial que me gusta. Síguelo y tendrás una base para continuar y entenderlo todo mejor:
  26. 1 like
    Os voy a contar una pequeña historia que igual os suena: A principios de 2012 tres amigos de toda la vida nos juntamos con la idea de desarrollar videojuegos y, a base de tomárnoslo en serio y dedicarle tiempo, conseguimos que aquella cosa llamada Unity medio hiciera lo que queríamos lograr. El resultado, después de casi 3 meses de trabajo, fue Vitrun, un juego que diseñamos inicialmente para móviles, pero que acabó siendo publicado en la Mac App Store con un éxito relativo dado que Apple lo promocionó y llegó a estar en el puesto 1 de la lista de los más vendidos en varios países incluyendo España. Fueron días felices, pero después pasó lo que -por desgracia- suele pasar en este tipo de historias. Las ventas empezaron a bajar a partir del segundo mes y a partir de ahí cuesta abajo y en picado hasta llegar a un punto en el que vimos claramente que el negocio no era sostenible: Si bien éramos capaces de hacer videojuegos de cierta calidad, nos faltaba mucho en la parte de marketing. Intentamos algunas cosas, pero con absolutamente ningún resultado y claro, al final lo vimos tan complicado que nuestra motivación por hacer videojuegos acabó por esfumarse (casi) del todo. Así que no mucho después, a principios de 2013, cada amigo decidió tomar un rumbo diferente, quedándome yo al frente del estudio para desarrollar un proyecto completamente diferente a partir de una prometedora herramienta interna que comencé a programar para intentar reducir nuestros tiempos y costes de desarrollo. Ese proyecto acabaría llamándose GameFlow y si tenéis curiosidad podéis encontrar un poco de información en este hilo. ¿Qué pasó con Vitrun? bueno, pues lo típico también. Quedó abandonado y eventualmente lo retiramos de todas las tiendas... Y así, en forma de proyecto Unity 3.5 había estado "congelado" hasta que este mes (o sea, 7 años después de su lanzamiento original) me propuse recuperarlo del olvido para tenerlo por fin disponible para Windows (porque nunca llegó a estarlo en aquellos tiempos) y bueno, también para ya de paso quitarle el polvo y actualizarlo un poquito. El resultado es un juego simple pero tremendamente adictivo, así que tened cuidado porque engancha ;) Nada más, espero que lo disfrutéis. La descarga del juego es gratuita, por supuesto: https://evasiongames.itch.io/vitrun
  27. 1 like
    Normalmente el código que circula como ejemplos por internet no contiene control de errores, ya que se centran en la funcionalidad de la tarea a explicar. Un vídeo rápido sobre try/catch que en los procesos de I/O es importante.
  28. 1 like
    muchisimas gracias iRobb!!!
  29. 1 like
    Mírate este tutorial. Es un código sencillo y te servirá de base:
  30. 1 like
    La verdad es que queda bastante bien, da una idea de cuanto falta para la meta, un estilo kickstarter. Una pregunta: ¿Es posible meter las noticias o el Feed en uno de los paneles laterales? Cosa de cliquear e ir directamente al link (no al topic), por ej con las últimas 5 noticias. Ah mira vos, tiene sentido, era sabido que el Admin y los mods se daban puntos ellos mismos jajaja. Sí, la verdad que están bárbaros, seguramente muchos de los importantes sean "under the hood", siempre se valoran. La galería me encanta, aunque todos los links me dan error. El foro de buenas practicas también me parece genial, aunque siento que el formato blog quedaría mejor, de todos modos la idea es muy buena. Ya que está pregunto, hace unos días me metí a un Topic X y descubro que era capaz de seleccionar la respuesta correcta, siendo que nunca respondí (además de obviamente no ser el autor del Topic). Ahora mismo no recuerdo el topic, pero probé con otros y no pasa lo mismo. ¿Este problema fue notificado? Quizás tenga relación con este punto : " Se ha corregido y vuelto a activar el plugin de Best Answer, para que los elijan qué respuesta es la mejor para resolver un problema. (pulsad la V a la izquierda del post, dónde el autor...) "
  31. 1 like
    Con la 2018.4 ya puedes compilar en 32/64. No hace falta ir a la última y que te aparezcan otro tipo de problemas debido a la versión.
  32. 1 like
    Te voy adecir unas cosas que puede ser te ayuden mucho si todavia no lo has solucionado. Primero sigue cualquier tutorial de esos de un minuto y medio de como exportar a 64 bits, en los que explican las casillas que hay que pulsar y demas. PAra la gran mayoria eso no es suficiente . Quita todo plugin estilo GameAnalytics, Facebook SDK y demas. Actualizar al ultimo Unity. Y despues bajate eel anterior(Unity 2019.1.14f1). A este Unity quitale la carpeta del "gdk" y sustituyela en el Ultimo Unity actualizado ya que la de este ultimo está corrupta. YA deberia funcionar. A mi y mucha gente se le ha solucionado asi el tema de poder exportar a 64 bits. Si todo te va bien a la primera pues perfecto.
  33. 1 like
    Me gusta que me hagas esa pregunta Pues le crearía un Canvas en root de ScreenSpace Camera. Le asignaría la cámara VR. Le colgaría un panel de un tamaño de 200x200 por ejemplo. Ajustaría la distancia con plane distance para que me quede donde quiero y hala! Ni transforms ni rotations. Recuerda ajustar el canvas scaler. Con esto tendrías un UI sencillito para info que te servirá para empezar. Si quieres el menú fijo en uno de los ejes (y por ejemplo), asociado a position y rotation del player que entiendo que tiene la cámara pues: - Crea un gameobject en root y lo llamamos menú. - En el start toma el offset de la rotation respecto al player. rotation.player - rotation.menú (mira lo que puse sobre las Q's) - Luego en el update (posiblemente otro tipo de update) del menú asignas la position.menú del player. Y creas un q con el eje x de la rotation del menú, eje y con la rotation del player y z con la rotation del menú y la asignas a la rotation del menú + el rotation offset que obtuviste en el Start. Esto hará que el menú se mueva en todos los ejes menos en el eje y. Lo mismo para otro. Si asignas la rotation.menú directamente con las del player + el offset, el menú estará sincronizado con todos los ejes de rotation del player. En este caso, al estar las rotations sincronizadas, el menú siempre estará apuntando al player sin tener que hacer nada, ya que los dos rotan al unísono.
  34. 1 like
    Hola, creo entender que te falta que instales Android? Si es eso, debes ir al lanzador que tengas, si es de la propia versión de Unity o como dice @iRobb si instalaste desde Unity Hub, que es un multilanzador propio. Me da que no tienes instalada la plataforma Android. Saludos. Aqui pudes ver si lo haces desde UnityHub:
  35. 1 like
    Son varios aspectos, pero sin ver como has montado las Uvs es dificil ser más preciso. Básicamente el problema que tenías es normal. Cuantos más objetos tengas en un mapa de de uvs mas resolución necesitará para que no haya pérdida de calidad. No estoy muy seguro de si te voy a explicar algo que ya sabes, pero me curo en salud explicándolo por si acaso. Si por ejemplo quisieses una pared larguísima muy detallada y pretendieses hacer la textura al completo tendrías un gran problema. Asumiendo que es un juego en primera persona y juegas en un monitor 1920 x 1080 en cuanto te acerques y la pared ocupase todo tu monitor, necesitarías al menos un mapa de 2048 x 24048 para que no hubiese pérdida, Si la pared en cuestión ocupase unas 5 pantallas estaríamos hablando de que necesitas en tu textura al menos 9600 px de ancho (1920 px x 5) Obviamente esto no tiene ningún sentido. Necesitarías un mapa de varios miles de píxeles para poder montar una pared larga, así que la solución es tilear la textura. Hacemos una textura repetible y conseguimos el mismo efecto, reduciendo el coste. Entonces, una vez entendido esto. ¿Porqué es mejor utilizar assets separados para montar el nivel? Pues hay varias respuestas. Como has visto, la mejor solución para grandes texturas es tilearlas, ¿es la única forma de hacerlo? No exactamente. Para hacer este ejemplo, se podría hacer de cuatro formas diferentes, te las dejo de lo que me parece el más optimo al que menos, y te voy explicando el porque: 1. Prefab de fragmento de la pared y repetirlo en el editor: Te permite reeditar el nivel, cosa importante de cara al diseño. Es mucho más fácil tirar pruebas y encima es el consumo más reducido. Unity gestiona de forma diferentes los prefabs y al instanciarlo consume menos recursos que mallas independientes entre sí. 2- Hago la pared completa y un único material y uso su tiling: En este preciso caso la mejor solución, aunque dependiendo de lo que tengas que hacer estarás más limitado que de la primera forma. 3. Hago la pared completa y depliego las uvs en cinco partes superpuestas sobre la textura repetible: Te generaría el mismo efecto pero pierdes capacidades. Vas a añadir más consumo y encima te limita la edición dentro del motor. 4.Hago un supermapa de 20000K para toda la pared: RIP ordenador. Conclusión: El workflow de montar el nivel en el propio motor siempre es el más acertado. En el campo profesional, los artistas que se encargan de generar los assets no tienen porque ser precisamente quien los monte, pero aunque fuese así, sigue siendo el mejor. Tener la capacidad de montar el nivel, probarlo, hacer y deshacer dentro del mismo motor te ahorrará muchos quebraderos de cabeza ante cambios posibles. De cara a la optimización como te comenté también es mejor. Si hablamos de casos aislados da igual, pero siempre va a consumir menos 100 instancias de un prefab que 100 mallas independientes completamente iguales.
×
×
  • Create New...