Jump to content

lightbug

Registrados
  • Content Count

    2,393
  • Joined

  • Last visited

  • Days Won

    205

lightbug last won the day on September 13

lightbug had the most liked content!

Community Reputation

820 Excellent

About lightbug

  • Rank
    Leyenda

Profile Information

  • Especialidad
    Coder

Recent Profile Visitors

3,014 profile views
  1. Hola, en mi opinión la parte gráfica la veo algo mal (no lo digo desde la estética, eso va en cada uno), es que no me termina de cerrar el "setting" por ningún lado. Entiendo que esté saliendo el proyecto, pero hay cosas básicas que podés mejorar: Los UVs! lo más obvio quizás. Basado en la última imagen, juraría que esos enemigos son miniaturas (si fueran verde serían los soldaditos de Toy Story). Las texturas de los pisos y las paredes están todas estiradas y/o mal escaladas. Metele sombras a esos enemigos (en la imagen parecen que están flotando). Estoy 99.99% seguro que desactivaste las sombras de la spot ya que te metía una sombra por el player (debido a su ubicación), si es así, meté al player en una capa dedicada y usa las propiedades de la luz para filtrar a dicha capa. Los enemigos (al menos en la imagen) brillan demasiado, quizás te convenga usar un espacio de color "Linear" y no "Gamma". Puede que también sea algo del shader/material. Usá un Normal map para piso y paredes, esto te ayuda muchísimo. Incluí detalles de ser posible, sócalos a las paredes, pisos levantados, escombros, muebles, "cosas de laboratorio". En definitiva, buscale una estética al juego, para este "setting" me parece que algo tirando a lo Grim Dawn te iría genial: Un truco es usar el mismo terrain como suelo, te olvidas de las UVs y además podés pintar detalles encima (texturas y/u objetos). Saludos.
  2. Es imposible saber qué está fallando y cuándo lo está haciendo. Para eso tenés herramientas como el profiler, que te dice cuanta memoria estás usando, procesamiento en general (script por script, por ej podés hasta sacar cuando tarda un Raycast en procesar una order, usando Deep Profile) y más. Existen cosas generales que podés hacer, como por ejemplo: Usar un sprite atlas (o sheet?) en vez de muchos sprites por separado. Si un sprite es muy pequeño no necesita estar super detallado (alta resolución). usar físicas menos complejas donde no se requieran (si fuera el caso). Ej no es lo mismo evaluar cientos de circulos vs circulos que evaluar polígonos vs polígonos. No generar basura constantemente (por ej llamar a Camera.main o GetComponent cuadro a cuadro).
  3. Ah ok ahora tiene más sentido. De lo que sé, un prefab como asset puede tomar referencias solo de assets, por ejemplo de otros prefabs. Si querés meter objetos de la escena (o componentes de estos) no te va a dejar. Al revés sí podés hacerlo, es decir que si el prefab está instanciado o metido en la escena (tecnicamente sigue siendo un prefab, ya no un asset (?)) podés asignar cualquier tipo de referencia, de escena o cargarla desde assets. No se si podés imponerle a Unity que asigne cualquier tipo de objeto en cualquier lado. En principio no tendría sentido, ya que los prefabs (assets) van a ser compartidos durante todo el juego, si uno de ellos pierde la referencia de uno de sus objetos (por ej porque la escena cambió) sería catastrófico. El tema es que podés tener prefabs en escena, o prefabs en el proyecto, por eso no me queda en claro bien de donde a donde querés hacer lo que querés hacer. Asumo que querés asignar de escena a asset. Saludos.
  4. Hola, vos podés asignar cualquier cosa, siempre y cuando sea del mismo tipo(referencia) o derivado(podés meter un Transform en un Component, un Monobehaviour en un Behaviour, etc), desde ya que no esperés meter un Transform en un Component y operar ese component como un Transform, para eso vas a tener que hacer un "cast". Lo mismo obviamente se puede hacer mediante código ("="). GameObject y posición no tienen nada que ver, para eso tenés que acceder al componente Transform. Por si solo el GameObject no sabe donde debería estar posicionado.
  5. xD es buenardo ... la parte de los UVs, odio los UVs!
  6. Yo después de leer este hilo:
  7. Agrego otra a las que puso @francoe1, si estás dentro de un Monobehaviour podés usar un "print", hace lo mismo: // // Summary: // Logs message to the Unity Console (identical to Debug.Log). // // Parameters: // message: public static void print(object message);
  8. Puede representar también varios "if else" en una sola línea. Por ejemplo: int resultado = a > 1 ? 3 : a > 0 ? 2 : a > -2 ? 1 : 0; Es equivalente a: if( a > 1 ) resultado = 3; else if( a > 0 ) resultado = 3; else if( a > -2 ) resultado = 1; else resultado = 0;
  9. una de dos: Te falta el material (missing material). Estás trabajando en una scriptable render pipeline que tu material no es compatible.
  10. Hola, se me ocurren dos formas: 1. Usando un evento de Unity. En cada botón tenés eventos disponibles, pero solamente on click (presionar primero, luego al soltar se dispara el evento). Podés implementar algunas interfaces útiles para estos casos como las "IPointerXXXXX". Vas a tener que implementar dos, IPointerUpHandler e IPointerDownHandler. En donde querés usar el estado del botón (usé el componente "Target", en tu caso será el que tenga que ser): class Target : Monobehaviour { bool pulsado = false; public void Pulsar( bool pulsado ) { this.pulsado = pulsado; } //... } Donde esté el elemento UI, agregás este componente (lo llamé "UIButton"): //... using UnityEngine.EventSystems; //<--- public class UIButton : MonoBehaviour , IPointerUpHandler , IPointerDownHandler { public Target target; public void OnPointerDown(PointerEventData eventData) { if( target == null ) return; target.Pulsar( true ); } public void OnPointerUp(PointerEventData eventData) { if( target == null ) return; target.Pulsar( false ); } } También lo podés hacer desde el inspector, con un evento público creo. 2. La otra forma es simular un input directamente usando el nuevo input system. Para esto vas a tener que instalar el paquete del InputSystem, crear las acciones correspondientes con sus bindings (conexión entre accion y dispositivo de entrada), y agregar donde tengas el elemento UI un componente que basicamente simula uno de estos bindings (perdón no me acuerdo su nombre). Luego en tu "Target" usas el estado de esta acción. Puede sonar a mucho de golpe, si estás familiarizado con el nuevo input system debería ser fácil.
  11. Sí, desde ya. Decime, ¿Donde está tu pregunta? Porque no la veo por ningun lado. Asumo que (salvo que el admin y la reglas del foro expresen lo contrario) vos sos totalmente libre de crear X cantidad de hilos por día, y cada usuario es libre de contestar a tus preguntas con Y cantidad de post también. En lo personal me da exactamente igual, era solo un consejo.
  12. El mismo admin ni sabe de qué va el foro ...mal por vos francoe1, muy mal 🤣 A ver, otra vez este tipo de hilos, creo que por año contesto dos o tres de estos. Usar un foro se aprende (igual que conducir o tocar la guitarra), no se necesita tener "nivel" para saber preguntar o no. A mi me parece que nos estás mandando regla tras regla de lo que va a ser tu juego (un objeto A que haga X cosa con el objeto B, mismo patrón), y esperas que alguien te envíe el código en bandeja para todas y cada una de ellas. Una vez está bien, dos quizás, pero una tras otra ya denota falta de esfuerzo. Mi consejo es que te hagas un tiempo entre hilos (ponele unos 3 días, o una semana) entre duda y duda, así vas a tener tiempo de investigar bien a fondo, leer documentación, bibliografía, etc. Con suerte esas dudas van a ir desapareciendo, de lo contrario ¿de qué sirve todo esto? Y por favor tratá de que no suenen a demanda, no existe cosa más fea que leer un "Necesito esto... chau ... gracias". Espero que se entienda, lo digo con la mejor de las intenciones.
  13. Ahhh cierto, perdón. Sí, vas a tener que usar cualquier dirección del target como referencia. Por ejemplo target.forward. En vez de guardar prevRotation vas a tener que guardar el prevForward (Vector3 en vez de Quaternion): void Start() { prevForward = target.forward; diff = distance * ( target.position - transform.position ).normalized } void LateUpdate() { ... // Calculo la rotación Quaternion rotDif = Quaternion.FromToRotation( prevForward , target.forward ); // Ya calculé la diferencia de rotación, ahora actualizo prevRotation prevForward = target.forward; ... } Agrego: se puede calcular la diferencia de rotaciones así: Quaternion deltaRotation = rotationA * Quaternion.Inverse( rotationB ); Hacelo como quieras, con Vector3 o con Quaternions.
  14. Bueno, no se si te entendí bien, pero creo que simplemente buscas rotar un vector. Para eso podés aplicar alguna rotación (Quaternion) al vector deseado. Voy a suponer que tu objeto tiene un componente separado que hace de "voy a seguir a este objeto en base a la distancia que tengo a él, y además voy a rotar con él". Como el objeto va a seguir a otro, podés ir pensando en actualizarlo después de este. Esto lo podés hacer mediante ExecutionOrder (en las opciones), un atributo llamado DefaultExecutionOrder, o simplemente usar LateUpdate. En este caso uso LateUpdate: [SerializeField] Transform target = null; [SerializeField] float distance = 2f; [SerializeField] Transform target = null; Quaternion prevRotation; Vector3 diff; void Start() { prevRotation = target.rotation; diff = distance * ( target.position - transform.position ).normalized } void LateUpdate() { // El target ya se movió y rotó // Calculo la rotación Quaternion rotDif = Quaternion.FromToRotation( prevRotation , target.rotation ); // Ya calculé la diferencia de rotación, ahora actualizo prevRotation prevRotation = target.rotation; // Calculo diff rotado diff = rotDif * diff; // Posiciono este objeto en base a diff transform.position = target.position + diff; } (para rotar un vector siempre la expresión debe quedar en "sanguchito" --> Vector3 = Quaternion * Vector3 ) Seguramente haya una forma más fácil.
UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...