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 58,34€ 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,253
  • Joined

  • Last visited

  • Days Won

    179

lightbug last won the day on September 1

lightbug had the most liked content!

Community Reputation

724 Excellent

About lightbug

  • Rank
    Leyenda

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

2,454 profile views
  1. lightbug

    StarCrash

    Muy bueno @Igor!! parece muy fluido y divertido, y como dicen todos, esos cambios de perspectiva y referencias a juegos van de 10. Además esos jefes están muy bien logrados, por lo menos de lo visto en los videos (Me recuerdan al viejo algoritmo de la viborita jaja) Ya que se están discutiendo la parte de los colores, hay cosas que me parecen que están bien y otras que no. Reconozco que falta un poco de balance de colores, ojo que es algo que ni algunos AAA consiguen, o que por lo menos lo que logran no es de mi agrado. También todo depende del estilo o estética que busques, sé que es difícil combinar sprites con elementos 3D (sean reales o simulados con normal maps). También he visto algunas superficies que no tienen un albedo bien definido pero sí un color + normal map. Aunque el relieve te ayuda bastante, la falta de un buen mapa de color base puede no mentirte lo suficiente (Ejemplo Video 1 a los 0:42). Este es un problema general que supongo todos tenemos, en mi caso se me ha hecho dificil crear una ilumincación o textura a partir de superficies sin mapas. Lo que te puedo decir (y lo más inmediato que yo modificaría) es que los colores del trail de los misiles me desconcentran mucho, es una cosa mía probablemente. EJ: Las partículas rojas-amarillas "colorean" demasiado la escena mientras que el fondo me dice que el tono en general es menos saturado. Me da la sensación de que los dos colores juntos no funcionan para esa escena. Fuera de estos detallecitos está barbaro, a darle para adelante, la parte difícil (gameplay, movimiento, AI, etc) ya está o va queriendo, te queda tocar cositas de estética/colores. En resumen pienso que podrías considerar retocar o reevaluar los siguientes aspectos: Los trails coloridos Algunos normal maps están a tope. Agregar texturas de albedo, o aunque sea textura de detalles. Theme de colores, o seguir una paleta de colores general. Si esto no es lo que buscas podés meter efectos de cámara (color grading, tonemapping, etc) también podrían funcionar. Y la última, si podés evitar las particulas con el addictive por defecto de Unity (las "Default Particles") hacelo (no se si las usas o no), es lo primero que te vende (El típico "lo hizo en Unity y no quiso pagarle a un artista" jaja). Si tenés texturas propias (no tienen que ser lo mejor) agregáselas. Saludos
  2. Kinematic 2D se puede adquirir ahora mismo en el Asset Store con un 30% de descuento, Aprovechalo! https://assetstore.unity.com/packages/tools/physics/kinematic-2d-136688 Y qué haces con los 5 dólares que te ahorras?? pues simple, los donas a Unity Spain
  3. lightbug

    ayuda

    Demasiado blurreado se ve. Hay coherencia en los colores (algo muy importante), pero los patrones son muy visibles, para que te des una idea, se ve similar a cuando cambias el nivel de mipmap de un sprite: Como un "blurreado por zonas", no un blurreado general y suave. Como dijeron arriba falta más detalle en el material (no necesariamente en la textura base), podés agregar otra textura extra para dar un poco más de vida o disfrazar el blurreado de la textura base. Un buen normal map te va a sacar del problema por mucho, pero todavía falta el detalle. Yo a la geometría la veo bien (por lo menos en esta imagen), sobretodo en las partes donde el suelo conecta con las paredes, esos lugares generalmente requieren de atención (paso de 0° a 90°). Quizás habría que "limpiar" un poco a toda la mesh para evitar bordes fuertes y demás (si es que los hay). En mi experiencia podés tener cualquier cosa delante de los ojos, pero si a eso le ponés un normal map decente (con uvs coherentes), colores base medianamente rescatables y mapa o efecto de ambient occlusion (sutil pero notable) ya estás por muy buen camino, independientemente del número de triangulos de la mesh.
  4. Es difícil contestarte sin tener algo de contexto sobre el juego, no es lo mismo pasar de una cámra a otra así nomás. sin saber que juego estás tratando de hacer (me refiero a los aspectos técnicos del mismo). El diseño de niveles es absolutamente importante para decir "usá tal cámara o tal otra". En el caso de la lateral el foco estará en el desplazamiento de izq/der (supongo), entonces los niveles deberán ser diseñados pensando solamente en una dimensión, 1D (mayormente, ponele un 1.5D, si hacemos referencia al 2.5D normalmente conocido). En el caso de la isométrica te abre al mundo 2D, el diseño de niveles será otro, el de personajes con sus animaciones será probablemente otro. Un punto importante también va relacionado con el render, vas a usar sprites o 3D falso (osea planos en 3D que simulan 2D, como el caso de Enter the Gungeon)? esto quizás no va de la mano 100% de la cámara, pero es una decisión que debés hacer antes de todo (3D falso no implica usar físicas 3D). Estás pensando usar una render pipeline? si vas al full 2D te recomiendo la nueva Universal Render Pipeline que está optimizada (supuestamente) para mobile, con su render 2D, luces, y más juguetitos. Saludos.
  5. Solamente necesitas asignar el physics material al personaje, y me parece que si tenés más de un collider podés usar directamente el material en el rigidbody2D (no estoy seguro, me parece que por esto se creó ese campo). Podés crearlo por código: PhysicsMaterial2D material = new PhysicsMaterial2D(); material.friction = friction; material.bounciness = bounciness; collider2D.sharedMaterial = material; Mezclar Transform y físicas es como darle una ametralladora a un chimpancé jaja nada bueno puede salir. Si vas a mover al personaje usando físicas podés hacerlo mediante velocidad, fuerzas, MovePosition incluso, depende del grado de realismo e interacción con el entorno, también del tipo de cuerpo que deseas mover. Usando esto el Rigidbody y el Transform se actualizan en diferentes momentos, si tenés autoSync activado cada vez que toques el Transform el Rigidbody actualiza sus datos internos (pos, rot, etc) pero esto no es recomendado en versiones modernas, donde autoSync está desactivado por defecto. Al final de cada step de simulación el resultado del Rigidbody (pos, rot, etc) pasa al transform, haciendo un mini sync entre los dos (por esto es que visualmente se puede apreciar un objeto moviendolo con físicas). En resumen, no deberías tocar el transform si querés un comportamiento físico correcto, es decir usando el motor de físicas (no necesariamente realista). Cada vez que el transform de modifica (segun el manual) se recalculan todos los colliders asociados al Rigidbody. Si querés mover algo de PosA a PosB usando las físicas podés usar position: Si es dinámico o kinemático esto lo lleva directamente a posB. Esto no responde a interpolación. rb.pos = posB; MovePosition: Si es dinámico lo lleva a posB pero reacciona a las colisiones. Si es kinemático esto lo lleva hacia posB, usando interpolación. rb.MovePosition( posB ); Velocity: La velocity de toda la vida, esto responde a interpolación también. Si es kinemático no pasa nada, pero si al kinemático se lo está moviendo (con otro método) podés leer su velocidad con "velocity." rb.velocity = ( posB - posA ) / Time.fixedDeltaTime; AddForce: Si vas a usar fuerzas la cosa es un tanto más difícil, la jodita es agregar fuerza F para llegar a una velocidad V, pero claro la fuerza necesaria va a ir variando con el paso del tiempo, para esto necesitas darle al sistema un señal de entrada e ir modificandola basado en algún tipo de control. En la rama de control se suele usar un PID para reducir el error (vDeseada - vActual) y llegar al valor deseado (el set point, o tu referencia de entrada)... muy chulo. Acá te dejo un lindo link con una implementación básica: PID Si hubiera llegado antes te hubiera puesto este vid: https://youtu.be/s7vSUk6gN3o?t=226
  6. Solo para mencionarlo, con el viejo GUI ( IMGUI) se podía calcular el tamaño exacto en píxeles de un dado GUIContent con esto: https://docs.unity3d.com/ScriptReference/GUIStyle.CalcSize.html Se que no tiene nada que ver para este caso, pero sirve para hacer lo querés en editores/inspectores y demás. En tu caso el input field deberá leer el tamaño horizontal del texto de al lado y ajustarse, en pos, ancho, tamaño de fuente, etc. El "Content Size Fitter" no lo conozco pero si hace lo que querés bienvenido sea. Con esto quizás: https://docs.unity3d.com/ScriptReference/RectTransform-sizeDelta.html
  7. Reglas no hay, pero uno de los pilares de Level Design + optimización es la capacidad de separar objetos. Si te referís a optimizar por tener varios GameObjects vs uno solo, realmente no es nada, importa más los componentes que tengan estos GameObjects, y acá es donde se da la diferencia. Voy a suponer que estás hablando del Layout de una escena, es decir las mallas sin props (puertas, mesas, floreros, muebles, etc). Con el tema de los terrains es muy difícil empatar a Unity, el Terrain System está pensado alrededor de la optimización y encima las nuevas herramientas están muy buenas, así que acá no hay mucha lucha que dar. Con el layout de edificios tampoco hay mucho problema, dependiendo de tu escena. Dicho esto tenés algunos aspectos que podés mejorar solamente separando cosas: 1 - Rendering: Acá tenés dos que se me ocurren, Occlusion culling, es decir, si mirás con la cámara para otro lado no se renderizan los n objetos, mientras que con uno solo no podés hacer mucho. Y el otro motivo es el Level of detail o LOD, con el cual podés reducir la cantidad de triangulos renderizados, poner un billboard, o incluso hacer desaparecer la mesh por completo. Si estás usando blender podés preparar tus LODs dandole al modificador "Decimate" (diezmar) que reduce la complejidad de la mesh, a mi me funciona para props y personajes. 2 - Físicas Primero el tema de los colliders, si tus objetos (dependiendo de como sean, claro) se pueden cubrir usando colliders simples o convexos, le estás facilitando el trabajo al motor de físicas por mucho. Por ejemplo, si importas una malla entera que necesita tener un meshCollider (porque requiere cierto detalle en las colisiones con el jugador) es probable que (1) debás optar por usar este MeshCollider o (2) disfrazar toda la malla con Colliders simples (casi seguro que te vayas a (1) ). Si usas un MeshCollider para la escena, cada vez que choques con algo se realizaran los calculos con toda la mesh, triángulo por triángulo (realmente no se si las físicas separan los triangulos en zonas). Si todo fuera modular o separado vos podrías determinar las mallas que necesitan "detalle" a la hora de colisionar, y cubrir con colliders simples las que no. Además, todo motor de físicas tiene su parte de detección de colisiones, constraints, solvers, y demás, pero una muy importante es la de optimización. Muchos usan una estructura de árbol (le llaman "Spatial Partitioning") para la fase "ancha" (o Broad)... Ejemplo: si un objeto A está muy lejano al personaje (en otra zona por ejemplo) el motor ni siquiera se preocupa y no emplea testea colisiones entre objA y Personaje. Si un objeto B se encuentra cerca del personaje (en la misma zona) se realizan los calculos necesarios. Te cito un fragmento del libro "Real-time Collision Detection" (Capítulo 7 Spatial Partitioning ) Recall from Chapter 2 that pairwise processing is expensive, and that the idea of broad-phase processing is to restrict pairwise tests to objects near enough that they could possibly intersect. Spatial partitioning techniques provide broad-phase processing by dividing space into regions and testing if objects overlap the same region of space. Because objects can only intersect if they overlap the same region of space, the number of pairwise tests is drastically reduced. This chapter explores three types of spatial partitioning methods: grids, trees, and spatial sorting. Todo esto se aplica al Layout o a los mismos props. Lo bueno es que no tenés que reconstruir todo (creo) si querés usar un enfoque un poco más separado o modular, simplemente hacé todo en tu software de preferencia, crea grupos con cada sección importante y exporta la malla a Unity, este reconoce toda la jerarquía de grupos y te pone un MeshCollider en cada objeto por separado (si seleccionas "Generate Colliders"). Con esto combinas la comodidad de tu programa de 3D con las posibles optimizaciones de Unity. Yo hago esto con Sketchup y resulta muy cómodo la verdad, si tal parte del nivel te gusta como prefab le das unpack y te guardás el prefab en tu proyecto. Muy lindo te quedó eso, me recuerda a los niveles de Amnesia. El monstruo que está detrás de la puerta es perturbante.
  8. Uh muy bueno @francoe1, tiene tremenda pinta. Pregunta: ¿Por qué soporta >= 2019.2? PD: Justo justo justo fuí al link de Connect y encontré un errorcito (o quizás es una imagen vieja) en la sección "Info" (de Player and Settings) --> Direaction ... te aviso por si se te pasó.
  9. Jajaj totalmente, acá el uso práctico hace la diferencia. Según Wikipedia: "In mathematics, the quaternions are a number system that extends the complex numbers." ---> a +b i + c j + d k Un número complejo se puede expresar en 2 dimensiones, una para la parte real (que NO acompaña a la "i") y otra para la parte imaginaria (que acompaña a la "i"). Entonces acá se puede decir que un Quaterion se puede expresar con 4 dimensiones. Revisando el código de Unity, un Quaterion es efectivamente un vector de 4x1,: public Quaternion(float x, float y, float z, float w) { this.x = x; this.y = y; this.z = z; this.w = w; } En el mundo matricial la multiplicación de una matriz de (M filas xN columnas ) x (I filas x j columnas): ( M x N ) x (I x J ) .... Es válida o realizable si N = I, es decir --->( M x N ) x ( I x J ) ... y el resultado tiene dimensión MxJ (Extremos) ---> ( M x N ) x (I x J ) Acá dejo un poco de código de Quaternions (sacado del código de Unity). Lo interesante es que estos valores se puede arreglar de tal o tal forma y resultar en vectores, quaternions o directamente matrices de 4x4 (ejemplo: parte las matrices que usan los shader, MVP en OpenGL, WVP en D3D , necesitan agregar una componente a la posición, de Vec3 a Vec4). Basicamente lo que hace Unity es afectar a los factores de tal forma de generar el resultado querido. Acá el operador *(Q,V) ... la regla que mencioné arriba: public static Vector3 operator *(Quaternion rotation, Vector3 point) { float num1 = rotation.x * 2f; float num2 = rotation.y * 2f; float num3 = rotation.z * 2f; float num4 = rotation.x * num1; float num5 = rotation.y * num2; float num6 = rotation.z * num3; float num7 = rotation.x * num2; float num8 = rotation.x * num3; float num9 = rotation.y * num3; float num10 = rotation.w * num1; float num11 = rotation.w * num2; float num12 = rotation.w * num3; Vector3 vector3; vector3.x = (float) ((1.0 - ((double) num5 + (double) num6)) * (double) point.x + ((double) num7 - (double) num12) * (double) point.y + ((double) num8 + (double) num11) * (double) point.z); vector3.y = (float) (((double) num7 + (double) num12) * (double) point.x + (1.0 - ((double) num4 + (double) num6)) * (double) point.y + ((double) num9 - (double) num10) * (double) point.z); vector3.z = (float) (((double) num8 - (double) num11) * (double) point.x + ((double) num9 + (double) num10) * (double) point.y + (1.0 - ((double) num4 + (double) num5)) * (double) point.z); return vector3; } Acá el operador* (Q,Q), Multiplicación de Quaternions (otras reglas): public static Quaternion operator *(Quaternion lhs, Quaternion rhs) { return new Quaternion( (float) ((double) lhs.w * (double) rhs.x + (double) lhs.x * (double) rhs.w + (double) lhs.y * (double) rhs.z - (double) lhs.z * (double) rhs.y), (float) ((double) lhs.w * (double) rhs.y + (double) lhs.y * (double) rhs.w + (double) lhs.z * (double) rhs.x - (double) lhs.x * (double) rhs.z), (float) ((double) lhs.w * (double) rhs.z + (double) lhs.z * (double) rhs.w + (double) lhs.x * (double) rhs.y - (double) lhs.y * (double) rhs.x), (float) ((double) lhs.w * (double) rhs.w - (double) lhs.x * (double) rhs.x - (double) lhs.y * (double) rhs.y - (double) lhs.z * (double) rhs.z) ); } Da miedo ... Lo importante es leer el manual y saber que hace cada método del Quaternion. Cuando apretás el botón del ascensor que hace que el ascensor funcione (para un usuario promedio), lo que importa es saber a qué piso querés ir.
  10. Si solo te importa la presentación de las medallas, diría opción O-P-B. En el caso de un podio olímpico o de carreras, el oro está más alto, en este caso el oro se ve primero (asumiendo que es más llamativo lo primero que se presenta). En muchos juegos el texto del ganador (oro) tiene los colores dorados y muchas veces alguna que otra animación llamativa y divertida, esto podría sumar más que el orden de presentación. La otra opción es presentarlos en vertical (con Oro arriba).
  11. Reglas de oro sin duda alguna, agrego una de Vectores con Quaternions muy útil: - Para rotar un vector usando un Quaternion se multiplica (en este orden): vectorRotado = quaternion * vector
  12. Sí, gracias por mencionarlo. En el tutorial utiliza 2018.3.5, creo que es debido a que el paquete se encontraba en etapa de experimentación UnityEngine.Experimental.Input. Actualmente en 2019.1 el paquete se puede usar con UnityEngine.InputSystem. El tema de las versiones y los paquetes en preview suele confundir bastante.
  13. Jaja yo hacía lo mismo, acá hice un post acerca del hack: http://www.unityspain.com/index.php?/topic/38762-unity-dark-para-versión-̶p̶o̶b̶r̶e̶-free/&tab=comments#comment-145051 Claro, no lo digo por pesado de tener el dark, sino que cuando hacés herramientas muchas veces uno omite la estética y pone un color que quede bien para el skin actual. Después te suelen mandar que no se ve nada en el Dark . Por eso uso directamente los estilos propios de Unity (gracias a la famosa tool gratis que te deja ver los Built-in styles) y que los colores los "decida el editor" cuando se necesario (aunque no es una solución perfecta). Uh muy interesante, gracias por el link. Tengo que ponerme con UIElement, hace tiempo que lo vengo dejando de lado.
  14. 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.
  15. 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.
×
×
  • Create New...