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 44,01€ de 150,00€

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

lightbug

Registrados
  • Content count

    2,137
  • Joined

  • Last visited

  • Days Won

    161

lightbug last won the day on February 23

lightbug had the most liked content!

Community Reputation

668 Excellent

About lightbug

  • Rank
    Leyenda

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

1,945 profile views
  1. lightbug

    [Solucionado n_n]Problema enemigo no muere

    Mi novio y yo pensamos que si seguís preguntando casi una vez por día en lo referente a problemas con tu juego (o lo que sea que estás haciendo) vas a terminar haciéndolo solo con el esfuerzo de la gente de por aquí, así que no te conviene andar llamándonos payasos por cualquier cosa (quedate tranquila, viene alguno como vos de vez en cuando) ... quizás te convenga empezar a leerte un poco más la doc, está bien fácil. PD: Y no, justamente esto no es reddit ...
  2. Ese tipo de preguntas siempre se responde como "yyy eee mmmm eeee ... puede ser " depende de mil cosas, usá el profiler, mirá cuanta memoria de video está siendo usada, chequea cuanta memoria tiene el dispositivo X, con esto supongo que debería bastar (por supuesto se usa memoria de video para otras cosas mas). Siempre que puedas ratonear recursos y obtener resultados similares está bien, por ej usar 2k en vez de 6k, o usar 64 en vez de 128, y así, ¿Para qué usás una 6kx6k para un terrain? obviamente depende del tipo de terrain que quieras y de donde viene ese terrain (por ej de un modelo ya texturizado o del mismo Unity) por eso el terrain system está pensado para tener grandes terrenos, vs importar un modelo de afuera (no se que trucos se le pueda aplicar a este último para hacer algo similar a un terrain de motor de juegos) ¿Esos valores no son los que aparecen en la resolución máxima permitida? si es así y tenés alguna dimensión mayor Unity reducirá la textura (de forma pareja en cada dimensión) hasta que coincida el límite, es una forma linda de limitar el uso de memoria, pero obviamente el detalle se irá perdiendo, podrías probar y ver si realmente se pierde detalle. Saludos
  3. lightbug

    [Solucionado n_n]Problema enemigo no muere

    Sí, por vos lo decís? deberías ser más abierto/a, es solo un consejo (y además tiene razón).
  4. lightbug

    2018.3 vs 2018.2 u otros.

    Esto es como si querés ir conduciendo del punto A al B, un fiat 600 lo hace, también un lamborgini, ahora, querés ir de A a B a 300 kmH ? bueno el Lamborgini es lo que necesitas. Pasando a Unity es similar, querés usar el SpriteShape en tu juego, bueno en versiones < 2017.1 que no está disponible (creo), querés usar el asset de creación de escenarios que compraste en el asset store? bueno fijate que versiones soporta, todo va a en ese aspecto que te hace dar el salto, no tanto en el motor en general, todo funciona medianamente parecido. Un ejemplo que yo tuve, en 2018.1 hasta 2018.2 existe un bug con respecto a la interpolación de rigidbody, una cagada porque mi asset se basa en esa interpolación y es un bug conocido, así que en mi caso omito esas versiones para todo, puede no ser tu caso. Por dar el salto quizás me expreso mal, lo que tenés que descargarte YA es el Unity Hub, ahí vas a tener todas las versiones que quieras para probar (incluido las betas), yo tengo como 7 versiones actualmente, si quiero abrir otro proyecto con otra versión lo hago y listo (quizás sea recomendable duplicar los proyectos, por temas de compatibilidad). Incluso podés abrir varios editores de Unity a la vez. Para aprendizaje vale lo mismo casi que estés en 5 2017 o 2018, por supuesto depende de si estás usando tal feature de las físicas, te gusta tal cosa de la interfaz, te gusta el nuevo sistema de X, etc pero en líneas generales y sobre todo a la hora de aprender no es la gran cosa pasar de versiones de hace 2 o 3 años hasta las actuales.
  5. lightbug

    Problema de rendimiento en juego android

    No te conviene especular con estas cosas, usá las herramientas que Unity te brinda (el profiler), después de eso ves que puede estar causando el problema, sea gráficos, memoria, GC allocs, particulas, scripts, etc.
  6. Una mínimo tip, hacé lo del lookAt a un objeto vacío de referencia (o a un quaternion, mejor, si estás canchero) y a la verdadera rotación (la de la flecha supongo) hacele un Slerp entre la rotación de la flecha y la del objeto de referencia, así podés darle un poco de dinamismo a la flecha.
  7. y no probaste con los métodos "Load"? LoadAllAssetRepresentationsAtPath Returns all sub Assets at assetPath. LoadAllAssetsAtPath Returns an array of all Assets at assetPath. LoadAssetAtPath Returns the first asset object of type type at given path assetPath. LoadMainAssetAtPath Returns the main asset object at assetPath. https://docs.unity3d.com/ScriptReference/AssetDatabase.LoadAssetAtPath.html
  8. lightbug

    Baja muchos los fps en android con unity 2018

    Los fps no son resultado directamente de los gráficos, no es cierto que te debería llegar a lo mismo que antes. probaste haciendo una build? probaste usar el profiler dentro de editor y en una build con development + connect profiler activado? Yo tengo 2018.3 y 2017.4 y en ambos si pruebo una escena de performance que tengo (500 personajes en escena) me dan unos 30 fps, si hago lo mismo en una build 60 fps sin problemas (en realidad son 300 fps porque tengo Vsync = on). Es decir que en principio tenés el mismo overhead del Editor, quizás pasar de 5 a 2017/2018 te meta mucho de este overhead. USá el profiler, hacelo con el juego y con el editor, y subí una imagen con los resultados. Dejalo que mueva un poco, que se yo, cuando te esté dando los fps que decís pausá el juego y fijate.
  9. Jaja es que ni siquiera me fijé que hacía FindAssets, solamente me guié por el bonito nombre. Gracias por compartirlo, osea que la combinación de FindAssets + GUIDToAssetPath() hizo el truco?
  10. Es un asset así que en teoría podrías hacer eso, revisá AssetDataBase: https://docs.unity3d.com/ScriptReference/AssetDatabase.html quizas FindAssets.
  11. lightbug

    Duda Scenes

    casi seguro que ocupa menos tener todo en 1, pero no es que te ahorras gigas de espacio, estamos hablando de bytes o kilobytes probablemente. (mirá cuanto pesa una escena, un ".unity") Por el tema del contenido, no pasa eso que decís, el ".unity" o la escena que se serializa (todo a cadena de bytes y adentro) tiene info de todos los gameObjects de la escena, esta info es metadata, osea data de la data(la cruda, la que vés/necesitas en el momento, el recurso, sea audio, mesh, sprite, etc). Por ejemplo: Si tenés en escena un puente flotante que pesa 1 GB que tiene un Transform T ,meshRenderer MR y un MeshFilter MF. Lo que se va a serializar en el .unity es: el objeto "PuenteFlotante" (string) no es hijo de nadie, tiene un Transform T así y asá (position, rotation, localScale, etc), tiene un mesh renderer MR con tales opciones, y un mesh Filter MF con el Recurso asignado "puenteFlotante.fbx". Esto por si solo pesa "monedas", es probable que estés generando más basura cuadro a cuadro que lo que pesa esto. Ahora, el "overhead" (por decirlo de alguna manera) de tener 1 gran escena vs 10 escenas (se suponen idénticas) va a radicar en que estás metiendo más metadata, más cantidad de archivos, quizás metiendo algún que otro script para manejar las escenas, quizás metiendo más info en las BuildSetting para construir todas las escenas y crear los índices, pero acá no se habla de contenido crudo, es metadata. Lo que pasa luego es que si todas las escenas hacen referencia a 5 de los 27 puentes flotantes que disponés en tu proyecto, esos 5 van a la build (en teoría). -> Osea que referenciarlos mediante una escena, o 10 escenas es "lo mismo" (salvo esa posible metadata que mencioné arriba, que no es nada realmente). La ventaja de tener varias escenas radica en el manejo y libertad que tenés, podés llegar a tal punto y descargar de forma asíncrona la escena tal para liberar espacio, o poner los elementos de la UI en una escena separada (por ej el menú de pausa), y más. Osea que si querés optimizar el espacio utilizado no comiences por aquí (ni termines por aquí tampoco). Las cosas que te pueden ocupar espacio son los Recursos involucrados, Otra vez un ejemplo: si tenés los 27 tipos de puentes flotantes (no se por qué estoy con esto) que necesitas cargar en runtime via una llamada de Resoruces.Load (por qué no) y los tenés en una carpeta llamada "Resources" cada vez que hagas un build, estos recursos se van a llevar a la build final (Unity los lleva porque en cualquier momento podés decir Resources.Load y deben de estar ahí) , si cada puente pesa 1 GB bueno, supongo que el juego te pesará bastante, ni hablar de la memoria disponible que estás usando una vez los cargás en la escena, que ese es otro tema. Si tenés dudas de esto probalo, hacé una gran escena vs varias, todas referenciando a los mismos recursos, dale build y fijate la diferencia. Los "sharedAssets.assets" de la build generalmente ocupan el mayor espacio. Saludos.
  12. lightbug

    While congela Unity

    Unity funciona frame a frame, no es la consola de C, tenés que asegurar que el flujo del programa salga del Update, si por cualquier razon se queda dando vueltas dentro de un update nunca se dará la orden de rendering, ni la de actualizacion de animators, ni la de captura de inputs... basicamente rompés el flujo del Engine. En corrutinas lo podés hacer, ya que te obligan a meter un yield justamente para delegar este control de flujo y retomarlo cuando corresponda, por ej yield return new WaitForSeconds(t) vuelve a los t segundos. Resumen : tené cuidado con los while, usalos si y solo si sabés que vas a salir, y si además el efecto pasa en un frame (hablando del update). Saludos
  13. lightbug

    Unity en MAC

    Hola, creo que el SO que corre al editor no tiene nada que ver con el "target", como se le dice, podés compilar para cualquier target, pero quizás alguien que en realidad lo haya hecho te puede dar la información justa. Para esto tenés que tener lo necesario, por ej, cuando yo me descargo Unity me viene (si no toco nada) con lo necesario para hacer una build en Windows x86 y x86_x64, sobre el mismo item de la lista de plataformas (Desktop) puedo seleccionar solo windows. Si te bajás lo necesario para Mac supongo que te dará la opción para Mac, lo mismo para los otros items: WebGL, Linux, Android, etc, necesitas descargarte paquetes extras para todo el resto. revisá el UnityHUB que tiene todo automatizado, te bajás la versión X con todos los paquetes para esa versión. Un saludo.
  14. Depende de qué sea relevante o no (para muchos lo es el ECS por ej, cosa que para mi no lo es), desde lo visual el evitar tener un mosaico perfecto de pasto o arena, etc hace mucho para un negado a las texturas como yo (negado y/o haragán, pero con un buen sentido de la estética ). Suponte esta situación, estás jugando a un juego y te cruzas con la de la izquierda: "fácil, este juego lo hizo un programador, mirá el mosaico horrible y poco gusto que tiene" ... te cruzás con la de la derecha: "mmm no es lo mejor del mundo pero tiene variedad, buena fuente de textura quizás?, naa, acá anduvo algun artista seguro, o usó eso usan los jovenes de hoy en día... substance o algo así?" jaajaj. El triplanar ya es otro cantar, no me cierra por qué todavía el standard shader no tiene esta opción (aunque está en HD), tampoco hay mucho que aprender es bastante sencillo de implementar, y sí, es buenísimo.
  15. lightbug

    Ayuda con programación pls :)

    Todos tuvimos tu problema, el típico problema del static, seguro por comodidad o por falta de conocimiento en general pusiste la variable en static, pero resulta que todos usan de la misma variable, entonces cuando uno la escribe afecta a lo que los otros están leyendo. El truco (en general) está en pensar a las variables, clases, métodos, etc como objetos reales, en tu caso, ¿Por que existe una algo externo y accesible por todos que dice si alguien está en rango o no? es como si alguien te dijera que es lo que vos estás viendo ahora, que mejor que vos mismo para decir lo que vos estás viendo ahora ... se entiende? Para no darle mucha bola al código, lo que deberías hacer es que cada enemigo sepa detectar al player, esto lo podrías hacer calculando la distancia al objetivo. Según lo que se ve ahí lo estás haciendo (?): float dist = Vector3.Distance(player.transform.position, transform.position); ... si es menor a X detectado = true. Una vez tengas eso necesitas interpretar esa información y actuar, para esto te conviene hacer una simple y mega funcional "maquina de estados", en si un switch con un enum para evaluar, para este propósito va como piña. En este ej está en update pero podés hacer una corrutina tranquilamente. enum EnemyState { Idle , // o rascandose los quinotos Caminando , Persiguiendo , Mueriendo , //que se yo , etc.... } EnemyState enemyState; ... void Update() { switch(enemyState) { case EnemyState.Caminando: ////hacer lo de Caminando, por ej detectar si está o no el player en rango if( estaEnRango() ) enemyState = EnemyState.Persiguiendo; break; case EnemyState.Persiguiendo: //Hacer lo de persiguiendo // ... break; .... } } Tener if esto if el otro a la larga te va a dar problemas, con 3 if's no se ve pero cuando tengas 6 , 9 , 12 te vas a acordar de mi.
×