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

Antonio

Registrados
  • Content Count

    188
  • Joined

  • Last visited

  • Days Won

    5

Antonio last won the day on June 26

Antonio had the most liked content!

Community Reputation

181 Excellent

2 Followers

About Antonio

  • Rank
    Asiduo

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Eso suena incluso mejor Jardem. me alegro que te haya salido el efecto.
  2. Como ha dicho Pioj, los colliders de unity no se pueden llevar a Blender. Lo que puedes hacer, es abrir el tractor en Blender (imagino que el tractor, tendrás un prefab, pero en algún lugar tiene que estar el modelo también, puede que un .obj o un .fbx, ambos archivos se pueden importar directamente en blender), y una vez tengas el tractor ahí crear polígonos para que hagan colliders, y luego exportar ese modelo de vuelta a Unity y usarlo como colliders poniéndole el componente Mesh Collider. Aunque ¡ojo!, los colliders y las físicas son partes que más rendimiento consume en los motores de videojuegos, mientras los colliders sean más complejos (más vértices, es decir, más caras y más polígonos) pues más tiempo necesita para comprobarlos. A B En el caso A, requiere menos pasos para verificar si el cuadrado azul está tocando el cuadrado rojo. Mientras que en el caso B, se requieren muchos más pasos para ver si el cuadro azul está tocando la figura roja. Esto quiere decir, que si vas a hacer algún polígono de colisiones para el tractor, este polígono debe ser tan low poly como se pueda. Si puedes usar cubos de Unity para ello, perfecto, si necesitas algo más preciso (un shooter, o si es importante la forma para las físicas, etc...) entonces crea un mesh para el tractor en blender, lo importas a unity y lo usas con el mesh collider (que para eso está). No hace falta que te preocupes de la textura, puedes literalmente borrar el componente del "Mesh Renderer" puesto que no necesitas que el objeto se dibuje durante el juego. Pero eso, para colliders "low poly".
  3. La cámara esa sencilla del CamaraPlayer public class CamaraPlayer : MonoBehaviour { public float mouseSensitivity = 10f; public float dstFromTarget = 2f; public Vector2 pitchMininMax = new Vector2(-40, 85); public float rotationSmoothTime = .12f; Vector3 rotationSmoothVelocity; Vector3 currentRotation; float yaw; float pitch; public GameObject PLAYER; public Transform target; private void Awake() { PLAYER = GameObject.FindGameObjectWithTag("Player"); target = PLAYER.transform; } void LateUpdate() { yaw += Input.GetAxis("GiroHorizontalCamara") * mouseSensitivity; yaw += Input.GetAxis("Mouse X") * mouseSensitivity; pitch -= Input.GetAxis("MovVerticalCamara") * mouseSensitivity; pitch -= Input.GetAxis("Mouse Y") * mouseSensitivity; pitch = Mathf.Clamp(pitch, pitchMininMax.x, pitchMininMax.y); currentRotation = Vector3.SmoothDamp(currentRotation, new Vector3(pitch, yaw), ref rotationSmoothVelocity, rotationSmoothTime); transform.eulerAngles = currentRotation; transform.position = target.position - transform.forward * dstFromTarget; } } Está usando el valor yaw (que irá desde -infinito hacia +infinito aunque en la práctica, es de -360 a +360), es un ángulo que usas después para ponérselo a la Y en el transform.eulerAngles. En este código, ese ángulo se modifica moviendo el ratón, pero si tuvieras un enemigo, o un objetivo específico al que apuntar la cámara, lo que necesitas es hallar el ángulo para que apunte a ese punto. De modo que si tienes la X y Z de la posición del enemigo... En ese código que tienes después de hacer la rotación, simplemente mueve la cámara a la posición del jugador y da unos pasos hacia atrás, luego según veo yo no haría falta hacer más modificaciones para el asunto de la rotación. Para el pitch, la idea es igual, pero usando la distancia y la altura (Y) en lugar del X y Z. (Si haces algún enemigo volador pues puede que lo necesites, pero ten cuidado de aplicar también la línea del clamp o puede que la cámara empiece a dar vueltas raras y a ponerse bocabajo). Otra cosa sería cuando hallar el yaw mediante trigonometría y cuando mover el yaw mediante el ratón, se puede hacer dos cámaras, o también podrías poner alguna variable Transform para el "objetivo" de la cámara, si es igual a null, moverla con el ratón, si es distinto de null, hallar el yaw con la fórmula.
  4. Hola Jardem. No tengo ningún script así a mano, pero sin duda veo seguro la necesidad de programar un poco para que ese efecto ocurra. La idea que me viene a la cabeza es la siguiente: - Creas un trigger, un cubo o un cilindro y lo pones donde esté el tornado. Este objeto le creas un script, para que cuando la bola entre ahí, pues empiece el efecto. - En el script, al ser un trigger, puedes usar las funciones de trigger en vez de la Start y Update de siempre. Las funciones de trigger que me refiero son las siguientes: OnTriggerEnter: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerEnter.html (Se dispara cuando el collider de la bola entra en el trigger) OnTriggerExit: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerExit.html (Se dispara cuando el collider de la bola sale del trigger) OnTriggerStay: https://docs.unity3d.com/ScriptReference/Collider.OnTriggerStay.html (Se dispara en cada frame mientras el collider de la bola esté dentro del trigger) Depende de como sea el script de control de la bola, puede que tengas que hacer contrarrestar más cosas o menos, pero con esas funciones deberías poder tener algo más de control. - Si por ejemplo, el controlador de la bola es el rigidbody estándar de Unity, pues podrías hacer que en el OnTriggerStay, la bola recibiera una fuerza que la mueva. (El vector de dirección de la fuerza, podría variar con el tiempo, quizás la Y sea siempre hacia arriba, pero la X,Z podría estar cambiando dependiendo del ángulo para que la bola vaya recorriendo un círculos mientras está dentro del tornado , las fórmulas trigonométricas creo que serían las siguientes: Dado el ángulo "A" y el radio "r" X = cos (A) * r Z = seno(A) * r La función para mover la bola debería ser AddForce en el OnTriggerStay, aunque no recuerdo qué modalidad habría que ponerle en el "ForceMode" (A penas uso el Rigidbody :( ) https://docs.unity3d.com/ScriptReference/Rigidbody.AddForce.html https://docs.unity3d.com/ScriptReference/ForceMode.html (Yo creo que "Force" debería valer, pero prueba con los 4 por si acaso).
  5. Puedes usa distintos layers para los triggers y para los colliders de los muros.
  6. Hola Megadok Si usas las físicas de Unity rigidbody, pues sí, el valor mass y el drag que menciona iRobb podrían ayudar en ese aspecto. Hace un par de semanas hice una pequeña escena jugando con esos componentes, puse una pelota que botaba constantemente entre dos rampas, y una cápsula que movías con el teclado. - Si la masa de la pelota, era superior a la de la cápsula, la pelota empujaba la cápsula al chocarle. - Si la cápsula tenía más masa que la pelota, esta no empujaba si no que rebotaba también como si chocara con otro objeto sólido. Aunque tuve dos problemas, 1º Estos valores tenían se veían afectados también por la fuerza con la que se mueve el objeto. Se podía dar el caso de que cuando la cápsula tuviese más masa que la pelota, a lo mejor la pelota si tenía poca fuerza, no podía mover la cápsula, pero si esta venía con mucha fuerza, sí podía mover la cápsula un poco, esto se podía evitar aumentando mucho la masa de la cápsula, aunque siempre pasará lo mismo, mayor fuerza -> más masa es necesaria para que no le afecte... Entiendo que en un juego, se supone que las fuerzas están más o menos controladas, no es que ninguna fuerza vaya a descontrolarse... pero en fin, más baja o más alta, siempre habrá una "frontera". 2º El otro problema es que quizás la pelota no podía empujar a la cápsula, pero la cápsula sí podía empujar la pelota. Por lo que no sé si eso es lo que realmente quieres en tu juego (que los enemigos no empujen al jugador, pero el jugador sí empuje a los enemigos. Ó viceversa). Tal vez incrementando el drag podría ayudar a esto. (aunque tendrás que modificarlo cuando quieras mover al personaje o puede que el drag también impida que el personaje se traslade...) /-----------------------------/ A mi se me ocurren 2 opciones. 1º en vez de usar el sistema de físicas de Unity, hacer los personajes con character controller, este componente también tiene una función Move y reacciona ante los colliders, pero no aplica tantas fuerzas físicas como el rigidbody (aunque eso significa que hay que programar más). 2º usando el sistema de físicas, pero poniendo un trigger alrededor de los enemigos de modo que cuando el jugador entre en ellos, la velocidad de las físicas en el rigidbody pase a ser [0,0,0]. Necesitará pulirlo, especialmente para que no se quede atascado dentro (por ejemplo, que el "bloqueo" solo se ponga si el movimiento se está realizando en la dirección dónde está el enemigo). Me gusta más la 1º, pero supongo que depende de la clase de juego que estés haciendo. O_ò
  7. A mi se me ocurre crear un par de capas (layers) para el jugador, una que efectivamente detecte las colisiones con el entorno, y otra que traspase dicho entorno. y activar dichas capas mediante código cuando entre o esté dentro de ciertos triggers. (Supongo que no querrás que "siempre" que pulse la tecla abajo, atraviese el suelo, esto sólo lo hará en ciertas plataformas ¿no? O_ò, puedes marcarlas con un trigger). Lo importante es que las capas una no interactué con la física (para que pueda atravesarlas), esto puedes gestionarlo en el panel de físicas (Edit -> Project Settings -> Physics) En esta por ejemplo, Layer 3 no detecta las colisiones con Layer 1 y 2, mientras que Layer 2, no detecta las colisiones con Layer 1 (ni Layer 3).
  8. Sí, algunos roles de programador dependen más de empresas grandes que realicen su propio engine (como Electronic Arts y su sistema de iluminación por voxels para su motor Frostbite) o empresas especializadas que realicen su propia tecnología (como los programadores de NVidia y el empuje que están dando con lo del ray-tracing). Hay roles más generales en el sector de los videojuegos que sí podría facilitar la entrada al mundillo. Entre los que cité, creo que lo que más ilusión me hace es el de inteligencia artificial, también tengo esa asignatura este mismo año así que a lo mejor me ayuda a aclararme.
  9. Un año nuevo, un curso nuevo, la profesora hablando del portfolio, nos ha recordado como el trabajo de fin de curso debemos enfocarlo a lo que queremos hacer en el futuro pues según ella, ese proyecto será el que perfile nuestra carrera en la industria... Dejando dramatismos a parte. Me preguntaba, como programador, ¿Qué alternativas hay?. Muchas veces en los eventos, nos dice los veteranos, "Tú céntrate, hazte profesional de un área" y tal. (Algo muy opuesto a los indies que por narices deben aprender un poco de todo para sacar el proyecto adelante), estará conectado las dos cosas? Bueno, echándole algo de imaginación, supongo que puede haber: Programador gráfico. (Que escriba shaders, ya sean para materiales o de post procesamiento). (Me gusta, pero ¿tanto como para dedicarme a ello 40 horas semanales?) Programador de iluminación. (Admito que les tengo mucho más respeto ahora XD ) Programador de menús (Alguien tendrá que hacerlos...) Programador de IAs (¿Podría estar bien?) Programador de físicas (Un compañero tiró por aquí, aunque a mi no me hace ni fu ni fa... O_ò ) Programador de mecánicas? (El movimiento del personaje, los ataques, disparadores? ) Programador de redes (Para las funcionalidades online y actualizaciones) Programador de sistemas? (Alguien que lleve un control más general de la estructura del proyecto, el ejecutable y que también se encargue de adaptarlo a las distintas plataformas de juego?) Programador de herramientas. (Me parece una lata programar herramientas, pero la verdad es que después es muy útil poder usar editores, conversores y tal...) No sé, ¿Me he dejado alguno? Yo creo que parte de lo que me gusta del desarrollo de videojuegos, es la creación de escenarios, ¿Es eso competencia de los programadores? (El año pasado con el grupo de la universidad, sí, sin duda, lo mismo en las game jam, pero no sé si en las empresas formales esa tarea está más destinadas a los artistas (creo tendría sentido así). ¿Hay alguien que pueda compartir alguna experiencia que de perspectiva a este asunto?
  10. Hola Rootet. Mirando el código, veo que hay un problema con tu actualización de la velocidad. En el Update, estás mirando si pulsas el botón del ratón, entonces actualizas la velocidad a "velocidad * 1.25f", pero también, una instrucción similar está siendo llamada en el siguiente frame y poseriores, en FixedUpdate, y esa está utilizando sólo "velocidad". No he probado tu código, pero creo, que esto puede llevarte al problema de que el cambio de velocidad no se llega a ejecutar realmente, que lo que ves al moverse, puede que sea el resultado del FixedUpdate. Tal y como lo veo yo (un poco por encimilla @_@) El personaje empieza quieto, el rigidbody no se mueve (ni en FixedUpdate ni en la llamada del ratón). Se pulsa el botón del ratón, el personaje sigue sin moverse en ese frame, como la variable corriendo era falsa, el personaje no se mueve todavía, pero la variable "corriendo" se activa. En el siguiente frame, la variable corriendo ya está activada, así que el velocity del FixedUpdate ya está en movimiento, pero el velocity del ratón ya no se activa, porque la función "GetMouseButtonDown" sólo da verdad en el frame (o ciclo) en que el botón pasa de no estar pulsado a estar pulsado, (que era el ciclo anterior por el que se activó la variable corriendo, pero ahora en este nuevo ciclo, el botón ya está pulsado y sigue pulsado, luego GetMouseButtonDown vuelve a ser falso). De modo que si el cambio de velocidad venía por esa línea, creo que no funcionará. Una manera rápida de arreglarlo es en vez de usar GetMouseButtonDown, utilizar simplemente GetMouseButton, su función es la misma, sólo que esta siempre se activa mientras el botón esté siendo pulsado, mientras que GetMouseButtonDown y GetMouseButtonUp, sólo se activan en los momentos de transición. (Son bastante útiles, pero quizás no en esta situación). Otra posibilidad, es cambiar el valor de la variable velocidad cuando haces la activación de la variable corriendo. Tutorial arriba, tutorial abajo, me parece que es buena idea intentar hacerlo por ti mismo, es una buena práctica para aprender a resolver y racionalizar los problemas. Ya habrá tiempo de pulirlo.
  11. Entonces, entiendo que toda la historia de los Assets Bundles está obsoleta, ahora este nuevo sistema de Addressables es en teoría el camino a seguir para distribuir un juego en múltiples paquetes de contenido. Bueno, ya sea uno u otro, estoy a cero, de modo que supongo que no me importará aprender este nuevo, aunque lamento que al buscar tutoriales sobre implementación de DLC sólo me remitan a los Assets Bundles. @_@ En fin, paciencia, el cambio habrá sido por una buena razón... XD
  12. Saludos Arganthamer Igual que has creado listas para guardar la posición y rotación, creo que puedes crear también listas para guardar y cargar esos datos particulares. (Una lista que guarde el tipo de bloque qué es y acudes a ella a la hora de cargarlo, si es un bloque de fuego, le guardo el valor 1, si es de aire le guardo el valor 2, y al cargar pues mires, es un valor 1, es un bloque de fuego, cargas el prefab y la textura correspondiente). Sobre como comprobar el tipo de bloque qué es, entiendo que la diferencia es un tipo de script particular, sí, la idea de poner los if - else if para comprobar cada tipo de script podría ser una forma que funcione, aunque a mi no me gusta mucho.... >_< También está el switch case, pero es que yo creo que esta situación se podría solventar mejor mediante la práctica del polimorfismo. El plan que propongo sería crear un script base para los bloques, que sea como el padre (¿"bloque.cs"?), y luego, los scripts hijos que tengan las particularidades de cada bloque. ("bloque_fuego.cs", "bloque_hielo.cs" etc...). El script padre, tendría todas esas variables y funciones que son recurrentes en todos los hijos, (también podría hacer uso de las funciones virtuales, pero bueno, mejor que no me vaya por los cerros de Úbeda ahora mismo). No sé, supón que todos los bloques tienen una vida, que llegada 0 el bloque se destruye, da igual si es fuego, hielo o lo que sea, todos tienen vida, pues ese dato iría al código padre. También creo que iría muy bien una lista Enum que sea la que diga que tipo de bloque será (los códigos hijos serán los encargados de inicializarla). Luego, los códigos hijos, heredarían el código padre, (por lo que todos tienen el valor vida, y todos tienen acceso a la variable tipo, luego al empezar el código fuego, entre sus primeras acciones es decirle a la padre, "ey, que yo soy de fuego") pero cada script, pues tiene además sus particularidades (los bloques de hielo tienen variables y funciones de deslizamiento... los bloques de fuego tienen variables del daño que provocan... etc...) Cuando creas un bloque, no pones el script padre, pones el script hijo que sea, pero por herencia, todos tienen ese script padre (e inicializan la variable tipo del padre), luego a la hora de guardar y cargar, no preguntas si tiene la clases hijos que pueden ser muchas, si no que preguntas directamente por la clase padre. En vez de preguntar ¿tiene el script "Bloque_Fuego"? , si , es de tipo bloque fuego no, ¿tiene el script "Bloque_Hielo"?, si, es del tipo bloque hielo no, ¿tiene el script "Bloque_Tierra"? si, es del tipo bloque tierra no, no es un bloque.... Pues preguntas ¿tiene el script Bloque? Sí - pues mira su variable tipo. No- pues no es un bloque. (Puedes crear dicha conexión padre-hijo llamando el script padre en la declaración del hijo. public class Bloque_Base : MonoBehaviour { enum TipoDeBloque {SinDefinir ,Hielo, Fuego, Tierra}; TipoDeBloque _tipo; //Esta variable se puede leer desde los tres scripts } public class Bloque_Hielo : Bloque_Base //Esta clase hereda la clase Bloque_Base, que a su vez, hereda también la clase MonoBehaviour de Unity { float Deslizamiento; //Esta variable sólo se puede leer desde este script } public class Bloque_Fuego : Bloque_Base //Esta clase hereda la clase Bloque_Base, que a su vez, hereda también la clase MonoBehaviour de Unity { float Dolor; //Esta variable sólo se puede leer desde este script }
  13. Saludos. Sobre la creación del botón, puedes hacerlo 3d o 2d. Si optas por el 2d, puedes crear el UI button y configurarlo para que ejecute la función al pulsarlo. https://docs.unity3d.com/ScriptReference/UI.Button-onClick.html Si optas por el 3d, puedes usar por algún raycast que detecte el botón con un collider. Sobre importar objs, hace faltan instrucciones para leer-escribir archivos, estos archivos se pueden abrir y leer con normalidad como cualquier otro archivo de texto. Un ejemplo de como se harían en Unity. Teoría de archivos: http://www.programacionenc.net/index.php?option=com_content&amp;view=article&amp;id=69:manejo-de-archivos-en-c&amp;catid=37:programacion-cc&amp;Itemid=55 Ejemplo en Unity: https://support.unity3d.com/hc/en-us/articles/115000341143-How-do-I-read-and-write-data-from-a-text-file- Lo 3º sería usar la información del archivo para ir recreando el mesh, no estoy muy seguro de como se crea el mesh en unity, cuando hice el importador de obj para OpenGL y Directx, allí tenía práctica y acceso a los buffers de datos que mandaba para renderizar. Pero en Unity no tengo eso así que de momento estoy en blanco. Aquí hay un ejemplo de creación de mesh en Unity https://unity3d.com/learn/tutorials/projects/procedural-cave-generation-tutorial/creating-meshes Parece que carga los vértices y las caras en un objeto Mesh (predefinido en Unity) pero veo que le faltan las UV (los valores vt del .obj) y los normales tampoco los coge del archivo (pero llama a una función RecalculateNormals que está dentro de la clase Mesh. Imagino que resolverá el asunto de los normales ahí dentro. O_ò
  14. Sip, el brillo es intencionado, el shader que usa el cuerpo es el standard (specular), ahí está usando una textura para el brillo specular, esta textura es casi negra pero tiene ruido, pero luego en el canal alfa está la textura del gloss, pero sobre todo los labios que están a más de 200. (Y luego está el mapa de normales que también tiene los labios exagerados adrede para que el brillo se manifieste con más normalidad por ahí, y no por la barbilla ni dentro de la boca). No es realista pero intentaba recrear una diferencia de material entre piel y labio. Tal vez el "arco de cupido" de los labios si está muy exagerado e intente levantarlo un poco. Malinterpreté lo del ambient oclusión, se me había venido a la cabeza el efecto de cámara no la textura en sí. El Fuse da una textura de una textura de ambient occlusion, es prácticamente blanca con algo de sombreado en el cuello, entre los dedos y bajos los brazos, además de oscurecer los orificios de la nariz y oídos (vamos, lo que le falta a la imagen de la izquierda), pero ya está, es muy básica, tengo que buscar como hacer AO textures que puedan mejorarlo, (a parte de crear las sombras para las ropa). El body mask, es una textura es una textura blanca y negra de baja resolución donde su canal alpha, se utiliza para indicar en qué partes se aplican los secondary maps, es decir los microbumps. Ahí la estoy usando para que los microbumps no se apliquen a los labios, ojos y pelo. El microbump que estoy usando ahora mismo se supone que es de piel, pero no lo he conseguido muy bien, el modelo tiene una textura normal de ruido que se repite por todo el cuerpo (en las zonas blancas del body mask) pero era una textura rápida y cutre que hice y a parte del detalle, esta no se ve mucho. Está ahi, se ve si se acerca la cámara y hay luces fuertes apuntando, pero en general es algo que se podría mejorar. (Es mucho más importante en las prendas, para reforzar un bordado o un material porosa).
  15. Gracias por comentar. Creo que el efecto del postprocesamiento "Color Grading" si ha dado buen resultado, retocando un poco para cambiar el color, añade más contraste y saturación a la piel pero sin quemarla mucho, y sin tener que cambiar el color de la textura, no esperaba tanta diferencia en la piel. El ambient occlusion no lo noto tanto en el personaje, (si alejo la cámara, si se ensombrece más el cuello y los sobacos, pero de una manera un poco descontrolada O_ò, normalmente un ambient occlusion leve lo suelo emplear más por el escenario, queda muy bien para dar variedad y crear sombras en las esquinas. La nariz la he reducido muy poco, cuando lo vista y lo vea con algún otro pj, ya podré hacer más comparaciones, de momento creo que todo el perfil puede que esté demasiado alargado, o tal vez no tanto. El asunto de las cejas, efectivamente las he separado también en una nueva capa, pero creo que el resultado no vale tanto la pena (o es que no lo he hecho muy bien), las cejas se ven oscuras por el postprocesamiento, y al estar en un nuevo materia, también están un poco más acentuadas (no comparten el brillo del material de la cara), pero la verdad es que no noto mucha variación entre las nuevas y las antiguas. Sin embargo, creo que el cambio más notable han sido los ojos. Les he hecho varias cosas: Le reduje el smoothness a las corneas para que el brillo sea más grande, creo que mejoró un poco y el brillo se veía dese más distancia (dependiendo de la iluminación claro) En Maya, le puse también una capa extra debajo de los párpados con un degradado de sombra, creo que eso es lo que le ha dado mucha más profundidad a los ojos. también le giré las pestañas un poco y se las alargué, creo que ayudan a perfilar el ojo y nuevamente, poder distinguirlo desde más distancia. En la textura de la cara no he cambiado el color de la piel (eso fue el postrpocesamiento) pero sí le he oscurecido un poco los párpados superiores. En eso si me he quedado más contento. :3 Supongo que si le pongo animaciones ahora también luciría mejor, pero de momento le tengo hecho un lio con el rigging de la boca y las mejillas (el riging de las comisuras siempre me ha parecido una de las partes más complicadas @_@). (Izq, con las textura del Mixamo fuse, Centr como estaba al empezar este tema, Det, la versión actual).
×
×
  • Create New...