Que tal, bueno quiero hacer un minimapa que tenga un cierto limite y que lo enemigos vengan, pero que se visualicen antes de que entren al rango de visión del minimapa..
Actualmente tengo esto..
Como se aprecia hay 2 enemigos (rojos) y yo que son visibles en el minimapa, pero hay más enemigos que no se ven.. por eso quiero saber si hay algún método o algo similar para que cuando aparesca un enemigo su punto rojo se quede al borde del minimap y que no se acerque hasta que venga hacia mí, si el enemigo se mueve el puntito rojo se debe de mover también(en el borde y si no entra en el rango de visión del minimap). Honestamente no tengo ni la más remota idea de como hacerlo.
Hola @ytinU
Si que se puede y es mucho mas sencillo de lo que parece ...
private void Update () {
GameObject [] enemigos = FindObjectsOfType (typeof (Enemigo));
foreach (Enemigo enemigo in enemigos) {
Vector3 direccion = enemigo.trasform.position - jugador.trasform.position;
float distancia = Mathf.Clamp (direccion.magnitude, 0f, radio_minimapa);
Vector3 posicion_enemigo = jugador.transform.position + (direccion.normalized * distancia);
Dibujar_Enemigo_Minimapa (posicion_enemigo);
}
}
private void Dibujar_Enemigo_Minimapa (Vector3 posicion) {
........
........
........
}
El codigo es increiblemente mejorable, por ejemplo controlar la lista de enemigos fuera de la funcion Update y que se añadan o eliminen de la misma segun vayan spawneandose o muriendo respectivamente para evitar llamar a FindObjectsOfType en cada frame ... pero lo importante es que tal como esta deberia hacer lo que buscas (puede que contenga algun error, lo he escrito de cabeza).
Para optimizar un 2% eso podes usar Vector2 en vez de Vector3.
Y porque no usar un trigger? todo enemigo que entra en un cierto radio se dibuja en el minimapa. Por supuesto el encargado de dibujar el minimapa sera un minimapa.script y tendra la lista de enemigos actuales para dibujar, y no los enemigos mandando mensajes de "dibujame minimapa!" xD
Hola @lightbug
No creo que optimices nada (ni tan siquiera el 0.01%) cambiando Vector3 por Vector2. Simplemente utilizas la clase Vector que mas te convenga segun el caso, Vector2 cuando se trata de 2 dimensiones y Vector3 cuando se trata de 3 dimensiones pero no lo haces por optimizar ... solo viendo la imagen del minimapa entiendo que se trata de 3 dimensiones.
Se podria cambiar a Vector2 pero ademas de no optimizar nada, harias el codigo mucho mas enrevesado ... despues tendrias que pasar el valor de la posicion del personaje, que esta en Vector3, a la posicion del radar en Vector2 teniendo en cuenta que no te sirve un simple casteo entre clases porque perderias el valor de z ... y siempre con la dificultad de trabajar en un sitio con 2 dimensiones y en el otro con 3 dimensiones, lo que siempre puede llevar a lios y comportamientos erraticos.
Sobre lo del trigger tampoco funcionaria porque en el mejor de los casos el radar tendria el mismo comportamiento que ya tiene : un enemigo cuando entra en un cierto radio (el del trigger) entoces se dibuja. El problema es que busca como cambiar eso, y que se dibujen TODOS los enemigos existentes aunque no esten dentro del radio, pero que mientras esten fuera de rango se dibujen en el limite del minimapa indistintamente de la distancia ... a no ser que yo lo haya entendido mal.
Ademas utilizando un trigger te encontrarias con la situacion que tu mismo dices que no es nada optima ... un enemigo entra en el trigger y entoces mandaria un mensaje de "dibujame". El codigo que he puesto iria en el script del minimapa, no del enemigo, y solo tienes una lista de los enemigos para consultar las posiciones pero que estos no intervienen en el funcionamiento del script de ningun modo.
Como decia en el momento que puse el codigo, es increiblemente mejorable ... pero ninguna de las dos cosas que mencionas mejoran el funcionamiento ni el rendimiento: la primera no ganas en rendimiento, en realidad es posible que pierdas aunque sea el 0.0001% debido a las operaciones extras que deberias hacer despues, y con la segunda cosa no cambiaria exactamente nada respecto a como lo tiene ahora.
La unica manera de optimizar el codigo que puse es creandose un gestor de enemigos que se actualice automaticamente segun vayan spawneandose o muriendo, con el objetivo de poder prescindir de la funcion FindObjectsOfType que es lo unico que consume recursos en ese codigo ... pero a parte de esa funcion, el resto son solo 3 opearciones matematicas de lo mas sencillas (sumas y restas), no se puede optimizar.
Incluso si en la escena hay un numero de enemigos fijos y no existe ningun spawn se podria poner la funcion FindObjectsOfType dentro de la funcion Start en lugar de Update y entoces ya estaria bastante optimizado (aunque no perfecto).
Cita de: Arthure date=1487670558No creo que optimices nada (ni tan siquiera el 0.01%) cambiando Vector3 por Vector2. Simplemente utilizas la clase Vector que mas te convenga segun el caso, Vector2 cuando se trata de 2 dimensiones y Vector3 cuando se trata de 3 dimensiones pero no lo haces por optimizar
No se como Unity maneja los vctores internamente, pero no creo que sea lo mismo si tenes que crear un new Vector2 y un new Vector3. De nuevo, habria que saber como se maneja el sistema. Si los tenes que refenciar como en este caso no creo que cambie nada.
Lo del vector2 era porque si es un minimapa (como el 99% de los minimapas) usas dos dimensiones para la deteccion (magnitud*cos(angulo formado)), y para trabajar suele ser mas comodo (un poquito tampoco tanto) usar u (x,y) y no un (x,y,z).
A que te referis con el "
solo viendo la imagen del minimapa entiendo que se trata de 3 dimensiones. ".? Es un minimapa medio raro entonces.
Cita de: Arthure date=1487670558Sobre lo del trigger tampoco funcionaria porque en el mejor de los casos el radar tendria el mismo comportamiento que ya tiene : un enemigo cuando entra en un cierto radio (el del trigger) entoces se dibuja. El problema es que busca como cambiar eso, y que se dibujen TODOS los enemigos existentes aunque no esten dentro del radio, pero que mientras esten fuera de rango se dibujen en el limite del minimapa indistintamente de la distancia ... a no ser que yo lo haya entendido mal.
Ahora que leo bien el quiere lo contrario jaja, en ese caso siempre se deberian dibujar, teniendo el minimapa la lista de enemigos y cuando ingresen no dibujarlos. Con el trigger o con las distancias calculadas la verdad no se si hay
LA diferencia, pero lo podes hacer andar de una forma u otra. Te digo porque he hecho algo parecido antes calculando distancias y con triggers, Va en comodidad/gustos/orden/estructuraelegida como quieras llamarlo.
Si fuera el caso antes que interprete (el erroneo) el trigger le gana por goleada al caso de las distancias ya que no realizaria calculos innecesarios para enemigos muy alejados, solo realiza el test de colisiones para una dada distancia (del motor de fisicas), obvio mientras mayor radio tenga el trigger mayor consumo. Algo parecido al caso que disparar un RayCast de mucha longitud.
Todo esto que digo es para la deteccion solamente y ver quien se dibuja y quien no, el tema del dibujo esta muy bien hecho con eso del normalize * radioMinimapa
Cita de: Arthure date=1487670558Ademas utilizando un trigger te encontrarias con la situacion que tu mismo dices que no es nada optima ... un enemigo entra en el trigger y entoces mandaria un mensaje de "dibujame". El codigo que he puesto iria en el script del minimapa, no del enemigo, y solo tienes una lista de los enemigos para consultar las posiciones pero que estos no intervienen en el funcionamiento del script de ningun modo.
Nunca dije eso, todo lo contrario, fijate que puse : "Por supuesto
el encargado de dibujar el minimapa sera un minimapa.script y tendra la lista de enemigos actuales para dibujar,
y no los enemigos mandando mensajes de "dibujame minimapa!" xD"
Un Saludo
Cita de: lightbug date=1487672157No se como Unity maneja los vctores internamente, pero no creo que sea lo mismo si tenes que crear un new Vector2 y un new Vector3. De nuevo, habria que saber como se maneja el sistema. Si los tenes que refenciar como en este caso no creo que cambie nada.
Lo del vector2 era porque si es un minimapa (como el 99% de los minimapas) usas dos dimensiones para la deteccion (magnitud*cos(angulo formado)), y para trabajar suele ser mas comodo (un poquito tampoco tanto) usar u (x,y) y no un (x,y,z).
Sobre el tema de los vectores me referia a que puedes utilizar, suponiendo que se trate de un minimapa en 2 dimensiones, un Vector2 ... pero si el juego es en 3 dimensiones los objetos, incluidos los personajes, tendran una posicion en tres dimensiones y si pasas un Vector3 a Vector2 sin realizar mas calculos perderas la mitad de los datos:
Vector2 posicion_personaje1_minimapa = (Vector2) personaje1.transform.position; Vector2 posicion_personaje2_minimapa = (Vector2) personaje2.transform.position; Simplemente con eso, dos personajes que se encontraran a 1000 "metros" de distancia en su eje Z pero a solo 2 "metros" de distancia en su eje X en la escena, aparecerian casi juntos en el minimapa ... con numeros se entiende mejor :
posicion_personaje1_escena -> (0, 0, 0); posicion_personaje2_escena -> (2, 0, 1000); posicion_personaje1_minimapa = (Vector2) posicion_personaje1_escena == (0, 0); posicion_personaje2_minimapa = (Vector2) posicion_personaje2_escena == (2, 0); Como se puede ver, sin realizar ninguna otra operacion los datos de la posicion en el minimapa no se corresponderian con los datos en la escena produciendose un comportamiento erratico. Para solucionarlo seria tan facil como hacer :
posicion_personaje1_minimapa.y = posicion_personaje1_escena.z; Pero ya tienes que hacer esa operacion extra para no ganar nada de rendimiento ... y con el gran inconveniente de que si en algun momento se te olvida hacer ese paso intermedio, tendras un error de aquellos que son muuuuuuuuuuy complicados de encontrar puesto que Unity no te indicara error por ningun lado (simplemente se limitara a hacer lo que tu le has dicho, aunque no fuera lo que tu quisieras).
Ademas, si despues tienes que realizar operaciones con cosenos y cosas "raras" de matematicas que requieren mucho mas calculo que las operaciones simples ... nunca en la vida podria ser mas optimo a nivel de rendimiento.
P.D.P. (Post Data Punto xDD) : la deteccion nunca se hace en el minimapa, radar o como se quiera llamar ... la deteccion se realiza en el "mundo real" o escena; el minimapa o radar lo unico que hace es mostrar los objetos detectados.
Cita de: lightbug date=1487672157A que te referis con el " solo viendo la imagen del minimapa entiendo que se trata de 3 dimensiones. ".? Es un minimapa medio raro entonces.
No es nada raro, un minimapa no es otra cosa que una camara que muestra cierta area de la escena (normalmente la area donde se encuentra el personaje) y donde se simplifican elementos ... algunos se omiten y otros se sustituyen, por ejemplo cuando se sustituyen los enemigos por puntos rojos.
Pero existen multitud de juegos donde el radar o minimapa es en 3 dimensiones ... aunque no me preguntes el nombre de ninguno (creo que el Ocarina, de Zelda, tenia uno en 3d), igual que no sabria decir ahora ninguno que tenga un radar en 2d ... hace siglos que no juego a juegos.
P.D.P. : No hay que confundir la vista top-down con los 2d, puede tener esa perspectiva pero tratarse de 3d ... especificamente en la imagen se observa que es 3 dimensiones por la vista de las casas (se puede ver que ademas de altura y longitud, tambien tiene profundidad).
Cita de: lightbug date=1487672157Ahora que leo bien el quiere lo contrario jaja, en ese caso siempre se deberian dibujar, teniendo el minimapa la lista de enemigos y cuando ingresen no dibujarlos. Con el trigger o con las distancias calculadas la verdad no se si hay LA diferencia, pero lo podes hacer andar de una forma u otra. Te digo porque he hecho algo parecido antes calculando distancias y con triggers, Va en comodidad/gustos/orden/estructuraelegida como quieras llamarlo.
Si fuera el caso antes que interprete (el erroneo) el trigger le gana por goleada al caso de las distancias ya que no realizaria calculos innecesarios para enemigos muy alejados, solo realiza el test de colisiones para una dada distancia (del motor de fisicas), obvio mientras mayor radio tenga el trigger mayor consumo. Algo parecido al caso que disparar un RayCast de mucha longitud.
Si fuera como tu decias, si que se podria hacer de las dos formas ... pero en este caso necesitarias un trigger tan grande como la escena entera, un sin sentido, y ademas despues tener que hacer los calculos de distancias para saber si debes dibujar en su posicion real dentro del radar (enemigo dentro del rango) o en el limite del radar indistintamente de su posicion real (enemigo fuera de rango).
No obstante yo discrepo mucho de que el trigger le gana por goleada al metodo de programarte tu mismo el algoritmo para las distancias ... en tema de comodidad esta claro que es mucho mejor el trigger, tan solo tienes que añadir un componente desde el editor y marchando, no podria ser mas facil y rapido.
Pero en cuestion de rendimiento es increiblemente mas optimo si te lo programas tu mismo que no si utilizas los triggers ... Calculando las distancias tu mismo, calculas las distancias (no tiene mucho misterio) y para el tema de hacer funcionar un radar o minimapa tienes mas que suficiente. Sin embargo, con el trigger realiza muchisimos calculos que no vas a necesitar : por ejemplo el trigger te calcula todos los puntos del objeto, en este caso seria el enemigo, que entran en contacto con el trigger.
Si el trigger devolviera simplemente un flag, se ha producido contacto o no se ha producido contacto, estaria mucho mejor a nivel de rendimiento ... pero el problema es que te devuelve un objeto con muuuuucha informacion que evidentemente ha tenido que calcular y no necesitaras para nada en este caso.
Sin mencionar una dato aun mas evidente : el trigger esta detectando de forma automatica en todo momento cualquier objeto del escenario, aunque tu luego puedas decir que con esa deteccion no haces nada; sin embargo programandote tu el algoritmo, que como puse eran 3 operaciones de matematicas sencillas, tendras un control absoluto de la situacion ... desde que objetos detectaras, hasta el intervalo de tiempo entre intentos de detectar dichos objetos (lo que se llamaria barrido si se tratase de un radar de la vida real).
"Ya se de que hacer mi proximo tutorial xD"
@lightbug tiene razon cuando dice que con Vector2 optimizas codigo, piensa que la clase vector2 no tiene que declarar variables extra para la posicion Z, sus funciones trabajan solo con X e Y, lo cual internamente es menos costoso. hice los calculos y directamente ahorra 48 bytes de memoria, e indirectamente ahorra unos 140 bytes de memoria.
Parece poco, pero cuando tienes 20 Vector2 en vez de Vector3 te ahorras tela.
Otra cosa que alcarar es que: un minimapa no se hace con trigger, ya que usar el motor de fisicas siempre es mas costoso. Lo suyo es tener una clase estatica y que cada componente actualice esa clase, luego desde otra clase recoges los datos de la estatica y los muestras en el minimapa, es sencillo.
Cita de: kingtrase date=1487678925"Ya se de que hacer mi proximo tutorial xD"
@lightbug tiene razon cuando dice que con Vector2 optimizas codigo, piensa que la clase vector2 no tiene que declarar variables extra para la posicion Z, sus funciones trabajan solo con X e Y, lo cual internamente es menos costoso. hice los calculos y directamente ahorra 48 bytes de memoria, e indirectamente ahorra unos 140 bytes de memoria.
Parece poco, pero cuando tienes 20 Vector2 en vez de Vector3 te ahorras tela.
Otra cosa que alcarar es que: un minimapa no se hace con trigger, ya que usar el motor de fisicas siempre es mas costoso. Lo suyo es tener una clase estatica y que cada componente actualice esa clase, luego desde otra clase recoges los datos de la estatica y los muestras en el minimapa, es sencillo.
Por supuesto que ahorra, tenes un float menos en la estructura, quizas metodos mas simples para calcular magnitudes (una componente menos al cuadrado , la z) y asi. Y para testearlo a full habria que poner 1000 enemigos y ver que pasa.
Es cierto, con triggers despues tenes que pedir la distancia y hacer la conversion que hace @Arthure para dibujar en el minimap, no tiene demasiado sentido en este caso.
Cambiando un poco el tema del topic y pasandose al caso inverso (interesan los que estan cerca, en un radio R) estaria bueno testear dos casos para ver los resultados y aclarar para futuros casos que conviene:
Un escenario de (los numeros re inventados!) 100x100 m2 con 100 enemigos repartidos, cada uno con su script (uno simple)
1 - con un trigger de 5m de diametro, (usas el motor de fisicas y pasas informacion de mas --> Malo)
2 - pidiendo las 100 distancias de los enemigos y verificando si son menores a 5 (100 operaciones de punto flotante + comparaciones --> Malo)
y ver quien gana jajaj.
Obvio los numeros de cantidad de enemigos y Radio influyen mucho para cada metodo. Si despues tengo un tiempito lo hago.
Gracias por sus respuestas, pero lo que quiero hacer es que cuando un enemigo que esta FUERA DEL RANGO DE VISIÓN DEL MINIMAPA aparesca en el borde, ya hice que apareciera en el minimap si estan en un rango, quiero aclarar que no tiene mucho misterio.. lo que hice fue poner una camara arriba mio para que me siga y lo que se ve como puntos rojos y el cursor(player) son quads que estan encima de estos para que la camara los renderize a ellos y no a los enemigos ni al player...Sé que se puede hacer mucho mejor, pienso que para darle un efecto '2D' tendria que hacer lo mismo con todo los objetos? no sé.. iluminenme xD.
Lo unico que te puedo decir es que no uses una camara para el minimapa... y lo hagas como se tiene que hacer (que lo dije antes)
Hola @kingtrase
Ya se que un Vector2 consume menos que un Vector3 si solo se tienen en cuenta las clases en si mismas sin tener en cuenta para que las utilices, no lo he puesto en duda porque es una obviedad ... como si te creas una clase propia que almacene 10 variables internas consumira menos que otra que almacene 20 variables.
Lo que remarcaba era que en este caso, si lo que ahorras en almacenamiento compensa luego al consumo de recursos en todas las operaciones que debes realizar. Es imposible utilizar Vector2 para trabajar con un escenario de tres dimensiones, y mucho menos sin realizar operaciones extras que no harian falta si utilizaras un Vector3 ... por ejemplo, la unica solucion que se me ocurre seria, teniendo en cuenta que un radar es plano y no se utiliza la posicion en el eje Y :
Vector2 posicion_radar = new Vector2 (personaje.transform.position.x, personaje.transform.position.z); Con esa sencilla operacion transformas la posicion del personaje en 3 dimensiones y la almacenas en una variable de 2 dimensiones, esta claro que un Vector2 ocupa menos en memoria que un Vector3 ... pero en serio crees que te ha merecido la pena ? Partiendo de la base que el Vector3 ya esta ocupando memoria indistintamente de que la utilices o no (esta almacenada en el transform del objeto), date cuenta de todas las operaciones extras que has tenido que realizar :
Crear y almacenar en memoria una variable de tipo Vector2
Inicializar dicha variable con sus valores
Acceder a la variable de tipo Vector3 y despues a sus componentes X y Z
Ademas del inconveniente que si en algun punto del codigo no tienes en cuenta que la variable Y del Vector2 no corresponde a la variable Y del Vector3 ... tendras un comportamiento erratico de aquellos chungos de localizar (no te saltara error nunca, simplemente no se comportara como tu deseas).
Pueden parecer pocas operaciones o dificil de que se produzca el error de comportamiento pero ... siguiendo con la logica, si tienes 100 personajes la situacion es poco sostenible; tendras 100 variables extras de tipo Vector2 innecesarias, que deberas ir actualizando tu manualmente (el vector3 del transform se actualiza automaticamente sin que tengas que hacer nada), y que te puede producir un comportamiento no deseado si utilizas el contenido del Vector2 como la posicion real del objeto (la Y del vector2 en realidad deberia ser la Z del vector3).
Es seguro que el Vector2 consume menos que el Vector3 ... por eso en los juegos en 2 dimensiones se utiliza el vector2 en lugar del vector3. Lo que yo decia que si se trata de un escenario en 3 dimensiones solo puedes trabajar con Vector3 a no ser que hagas un monton de operaciones extras innecesarias. Cita de: ytinU date=1487693974Gracias por sus respuestas, pero lo que quiero hacer es que cuando un enemigo que esta FUERA DEL RANGO DE VISIÓN DEL MINIMAPA aparesca en el borde, ya hice que apareciera en el minimap si estan en un rango, quiero aclarar que no tiene mucho misterio.. lo que hice fue poner una camara arriba mio para que me siga y lo que se ve como puntos rojos y el cursor(player) son quads que estan encima de estos para que la camara los renderize a ellos y no a los enemigos ni al player...Sé que se puede hacer mucho mejor, pienso que para darle un efecto '2D' tendria que hacer lo mismo con todo los objetos? no sé.. iluminenme xD.
Utiliza el codigo que puse en el primer post y despues nos comentas ;) Simplemente deberas cambiar "Enemigo" por la clase que controle a los enemigos, y rellenar la funcion "Dibujar_Enemigo_Minimapa" con la parte del codigo del script que tienes ahora mismo encargado de dibujar en el minimapa.
Un saludo
Acabo de hacer un test, dos versiones, una el metodo del trigger y otra con las distancias, sin el maximize window me ha sorprendido el de las distancias (segun el profiler) le saca como 20 cuadros (***!) pero con el maximize le gana el otro por 10 cuadros
//Con el maximize windows
Trigger: fps: 72-80
Distancias: fps: 64-67 fps
La escena es:
- 1080 esferas (static solo por prueba), cada una con dos metodos publicos, uno que la pone verde y el otro la pone roja (default)
- el objeto principal (uno para cada version)
- cada uno tiene:
//Trigger
void OnTriggerEnter(Collider col)
{
if (col.GetComponent<bola> ())
col.GetComponent<bola> ().Action ();
}
void OnTriggerExit(Collider col)
{
if (col.GetComponent<bola> ())
col.GetComponent<bola> ().NoAction ();
}
void Update () {
transform.position += Input.GetAxisRaw ("Horizontal") * transform.right + Input.GetAxisRaw ("Vertical") * transform.forward;
}
//dISTANCIAS
List<Transform> bolas = new List<Transform>();
public Transform objBolas;
void Start () {
for(int i=0 ; i < objBolas.childCount ; i++)
{
if (objBolas.GetChild (i).GetComponent<bola> ())
bolas.Add(objBolas.GetChild (i));
}
}
// Update is called once per frame
void Update () {
for(int i=0 ; i < bolas.Count ; i++)
{
Vector3 distancia = bolas .position - transform.position;
if (distancia.magnitude < 30)
bolas .GetComponent<bola> ().Action ();
else
bolas .GetComponent<bola> ().NoAction ();
}
transform.position += Input.GetAxisRaw ("Horizontal") * transform.right + Input.GetAxisRaw ("Vertical") * transform.forward;
}
Algo que nunca entendi es porque la diferencia de frames al maximizar la ventana quiza alguno lo sepa y me ilumine :)
Esta clarisimo que tener 1080 objetos cualquiera de los metodos para detectar proximidad son validos para algun numero real.
EDIT:
usando 3500 objetos el trigger gana por mucho 30fps (logico del otro metodo es mas demandante que el uso de las fisicas en este caso, se ve en el profiler), pero para numeros mas reales, unos 100 objetos me quedo con el metodo de las distancias
Hola @lightbug
es logico que con esos numeros y esos scripts sea mucho mas optimo el metodo del trigger que el calculo manual de distancias ... lo extraño es que solo haya una diferencia de 30 fps entre ambos metodos, o incluso que no se quede pillado por culpa del script de distancias.
Ten en cuenta que con el trigger solo estas accediendo a los objetos en el momento de entrar o salir del trigger sin realizar ninguna accion en la funcion Update, mientras que con el metodo de las distancias estas recorriendo los 3.500 objetos en cada frame ... aunque lo preocupante y que afecta mucho el rendimiento, es que estas utilizando la funcion "
GetComponent" 3.500 veces en cada frame (a muchos les petaria el ordenador si hiceran eso xdd). Vuelve a hacer la prueba pero realizando unas pequeñas modificaciones :
en primer lugar añade un miembro publico dentro del script bola para poder consultar el transform
public class bola : MonoBehaviour {
public Transform objeto;
private Start () {
this.objeto = this.transform;
}
public void Action () {
........
}
public void NoAction () {
........
}
}
despues modifica el script controlador para que almacene una lista con los objetos "bola" en lugar del transform de los objetos, con lo que tambien tendras que modificar la funcion Update
public class Controlador : MonoBehaviour {
private Bola [] bolas;
private Start () {
this.bolas = FindObjectsOfType (typeof (Bola));
}
private Update () {
Vector3 posicion = this.transform.position;
foreach (Bola bola in this.bolas) {
Vector3 distancia = bola.objeto.position - posicion;
if (distancia.magnitude < 30) bola.Action ();
else bola.NoAction ();
}
}
}
Haz esos cambios en los dos scripts, y vuelve a hacer la prueba pero con 7.000 objetos ... ya nos contaras la diferencia. Consumira menos mi codigo con el doble de objetos, que como tu lo hacias aunque fueran "solo" 3.500 objetos. A lo que me refiero es que es normal que haya una diferencia de 30 fps entre los dos metodos (utilizando el codigo que tenias) ... y la verdad es que me parecen muy pocos fps de diferencia despues de ver esa cantidad de llamadas a la funcion GetComponent dentro del Update.
Ok, con el nuevo codigo tuyo:
void Start () {
mainT = transform;
bolas_Comp = FindObjectsOfType (typeof(bola)) as bola[];
}
// Update is called once per frame
void Update () {
foreach (bola bola in this.bolas_Comp) {
Vector3 distancia = bola.objeto.position - mainT.position;
if (distancia.magnitude < 30)
bola.Action ();
else
bola.NoAction ();
}
mainT.position += Input.GetAxisRaw ("Horizontal") * mainT.right + Input.GetAxisRaw ("Vertical") * mainT.forward;
}
Ahora si, cero excusas, hasta hice caching del transform del propio transform del objeto principal como para "sumar" jajaj. Pero...nada, sigue todo igual, lo cual era lo que me esperaba mas o menos, y ahora me cierra un poco el tema del caching, es buen argumento no usar GetComponent todo el tiempo, antes no le daba bolilla, ahora, pregunto, si pedis referencias (punteros = direcciones) cuadro a cuadro, el valor de este no queda en memoria cache?
De verdad esperaba que hubiera un cambio, de en serio te digo, estamos hablando de (sacando v-sync y usando un fps counter) 150 vs 100 cuadros a favor del trigger nuevamente
Cita de: Arthure date=1487717803Haz esos cambios en los dos scripts, y vuelve a hacer la prueba pero con 7.000 objetos ... ya nos contaras la diferencia
En vez de 7000 puse:
Trigger (4320 objectos) = 100-105 fps distancias (2160) = 100-102 fps Datos posta! no te voy a estar mintiendo a mi mas que a nadie me interesaria una mejoria del lado de las "distancias", es un metodo mas comodo e intuitivo.
Si no me crees hace el test vos mismo y fijate.
Cita de: lightbug date=1487722662En vez de 7000 puse:
Trigger (4320 objectos) = 100-105 fps
distancias (2160) = 100-102 fps
Datos posta! no te voy a estar mintiendo a mi mas que a nadie me interesaria una mejoria del lado de las "distancias", es un metodo mas comodo e intuitivo.
Si no me crees hace el test vos mismo y fijate.
No necesito hacer la prueba, te creo y tu mismo has puesto los resultados de la prueba ... y han resultado ser los mismos que yo decia sin que tuviera que comprobarlo para "adivinarlo"
Con el codigo que habias hecho al principio y 1080 objetos el resultado eran 64-67 fps y con el codigo que te he puesto, utilizando 2160 objetos (no son los 7.000 que decia pero son el doble que antes !!!) el resultado son 100-102 fps ...
el rendimiento ha subido un 65% - 70% aproximadamente !!! si quieres optimizacion y rendimiento, a mi me parece que un 70% es una barbaridad; en realidad sabia que mejoraria mucho el resultado sin necesidad de probarlo, pero no me imaginaba que tanto ^.^
Despues una cosa importante si pretendes comparar los resultados entre los dos metodos (trigger y calculo de distancias manual) es que con el trigger puedes tener 10.000 objetos si quieres ...
pero como te he comentado en mi ultimo post, no estas accediendo a todos los objetos puesto que solo los "mani***" en el instante de entrar o salir del trigger. Lo que significa que aunque tengas 10.000 objetos en la escena, el trigger solo esta trabajando con 20 o 30 de ellos (los que activan el evento entrar o salir del trigger, que no es lo mismo que el estado de estar dentro o fuera del trigger).
En cambio con el metodo de calcular las distancias, si tienes 2.160 objetos significa que estas operando con todos y cada uno de esos objetos en cada uno de los frames ... y aun asi consigues el mismo rendimiento que con el trigger;
tu mismo has puesto los resultados de las pruebas que cantan por si mismos.
Hola @Arthure
Cita de: Arthure date=1487743421Con el codigo que habias hecho al principio y 1080 objetos el resultado eran 64-67 fps y con el codigo que te he puesto, utilizando 2160 objetos (no son los 7.000 que decia pero son el doble que antes !!!) el resultado son 100-102 fps ... el rendimiento ha subido un 65% - 70% aproximadamente !!!
No tan rapido! jaja , cabe destacar que use el frame counter de Unity (script) para los dos.
---> En la comparacion de mas arriba no use lo mismo (me refiero en el caso de accediendo cada frame con el GetComponent). Ahora tambien desactive vsync sino no me da mas de 60 en ambos casos.
Con el codigo viejo
No cambia un cuadro 100-105 fps (mas o menos).
for(int i=0 ; i < bolas.Count ; i++)
{
Vector3 distancia = bolas .position - transform.position;
if (distancia.magnitude < 100)
bolas .GetComponent<bola> ().Action ();
else
bolas .GetComponent<bola> ().NoAction ();
}
A nivel practico igual usaria el trigger por esta razon, se que uno usa muchisimo mas Update que el otro(que no usa nada) y aun asi da un performance muy buena, pero ante los numeros finales usaria el trigger. Es quiza la ventaja del sistema de fisicas que no se porque razon todo el mundo se asusta y trata de no emplear jamas. Me parece que Physx usa lo que se llaman arboles AABB dinamicos para determinar las zonas de deteccion de colision, como si fueran octrees dinamicos. Si separo los objetos demasiado, los pongo en dinamico (sin static), igual sigue ganando el Trigger (por 50 cuadros).
Claro que para el minimapa ya sea dibujar lo que esta cerca o No, jamas usaria triggers! ya que despues tenes que trabajar de alguna manera con las distancias, no tendria sentido, pero para detectar proximidad no hay quien le gane.
Cita de: lightbug date=1487758816Hola @Arthure
No tan rapido! jaja , cabe destacar que use el frame counter de Unity (script) para los dos.
---> En la comparacion de mas arriba no use lo mismo (me refiero en el caso de accediendo cada frame con el GetComponent). Ahora tambien desactive vsync sino no me da mas de 60 en ambos casos.
Con el codigo viejo No cambia un cuadro 100-105 fps (mas o menos).
A nivel practico igual usaria el trigger por esta razon, se que uno usa muchisimo mas Update que el otro(que no usa nada) y aun asi da un performance muy buena, pero ante los numeros finales usaria el trigger. Es quiza la ventaja del sistema de fisicas que no se porque razon todo el mundo se asusta y trata de no emplear jamas. Me parece que Physx usa lo que se llaman arboles AABB dinamicos para determinar las zonas de deteccion de colision, como si fueran octrees dinamicos. Si separo los objetos demasiado, los pongo en dinamico (sin static), igual sigue ganando el Trigger (por 50 cuadros).
Claro que para el minimapa ya sea dibujar lo que esta cerca o No, jamas usaria triggers! ya que despues tenes que trabajar de alguna manera con las distancias, no tendria sentido, pero para detectar proximidad no hay quien le gane.
No es que vaya tan rapido pero es que repito : en el ejemplo del trigger puedes tener 5.000 objetos en escena pero solo estas trabajando con 10 objetos, 15 tal vez siendo generosos, y encima solo durante una milesima de segundo (el instante en el que salta el evento enter o exit) ... por lo partimos de la base que tener 5.000 objetos en escena con el trigger y 2.500 con el otro metodo es un dato engañoso, porque la carga de trabajo en realidad son 10-15 objetos (trigger) frente a 2.500 objetos (calculo manual).
Aunque ganara el trigger por 100 fps, teniendo en cuenta que el calculo manual en tus ejemplos tiene una carga de trabajo del aproximadamente el 25.000% respecto al trigger ... me siguen pareciendo muy buenos datos en el que un metodo deja a la altura del betum al otro.
Para mi los componentes de Unity (triggers, characterController y tal) estan muy bien porque te facilitan enormemente el trabajo ... es decir, perfecto para los que no saben programar. Por eso digo que hoy hay tantos "programadores de videojuegos", no necesitas saber programar solo seguir un videotutorial.
Si mirasemos las empresas que hacen juegos sin ser sospechosas de tener la necesidad de seguir un videotutorial (actualmente casi todas las desarrolladoras importantes tienen como minimo algun titulo realizado con este engine) ... Cuantas crees que se limitaran a utilizar los componentes que vienen con Unity, y cuantas crees que optaran por programarse sus propios componentes ?
Al final se trata de gustos, o posibilidades, pero yo desde luego opto por programar lo que necesito de cabo a rabo con la libertad que me ofrece eso. Molestarme en programar mis propios componentes a cambio de que funcione exactamente como quiero y poderlo optimizar tanto como quiera para mis propias necesidades ? mmm bendita molestia xD Un cordial saludo
No se trata de "gustos" o facilidad para los que no quieren hacer nada y usar lo default de Unity, entendes que usar fisicas, (en este caso Physx) no es lo mismo que usar scripts? vos no estas siendo
vago por poner un collider que no podes optimizar vs hacer tus propios scripts o plugins que podes mejorar a gusto. Se trata de usar otro enfoque para resolver un problema determinado, esa es la razon de la que todos los eventos de deteccion (o casi todos) que se realizan en una escena constan de triggers (fisicas) y no de updates a fuerza bruta. Y para agregar mas si los calculos de fisicas pudieran trasladarse al GPU(SIMD) estariamos hablando de "cpu gore".
Cita de: Arthure date=1487763102Cuantas crees que se limitaran a utilizar los componentes que vienen con Unity, y cuantas crees que optaran por programarse sus propios componentes ?
Componentes puede referirse a cualquier funcionalidad del motor, claro la mayoria lo personaliza desde todo angulo posible, y me parece genial esto, pero no se ponen a escribir su propio motor de fisicas, o sus propias librerias matematicas, no tendria sentido usar Unity en primer lugar.
Cita de: Arthure date=1487763102Aunque ganara el trigger por 100 fps, teniendo en cuenta que el calculo manual en tus ejemplos tiene una carga de trabajo del aproximadamente el 25.000% respecto al trigger ... me siguen pareciendo muy buenos datos en el que un metodo deja a la altura del betum al otro.
Claro aca decis algo muy logico y verdadero, el metodo de las distancias trabaja sobre muchisimos mas objetos y logra FPS bastantes parecidos, y es verdad, tuve que incrementar demasiado el numero de bolas para que el trigger ganara "bien". Mientras que el trigger trabaja sobre muy poquitos (dependera de las zonas del Arbol de deteccion) y logra poca performance respecto a que si tuviera que trabajar sobre la misma cantidad,
Pero justamente aca esta el truco, para que queres trabajar sobre los 4000 objetos a fuerza bruta mientras podes ser mas listo y trabajar sobre una zona determinada... y lo mas importante
tener mejores resultados! (exagerando las condiciones, claro, pero asi se realizan los test).
Cita de: lightbug date=1487769717No se trata de "gustos" o facilidad para los que no quieren hacer nada y usar lo default de Unity .... Se trata de usar otro enfoque para resolver un problema determinado.
Pues ahi esta el chiste de la cuestion ... que viendo las cosas que dices, parece que no te hayas molestado en leer lo que preguntaban cuando abrieron el tema.
En mi primer post escribi una solucion al problema que planteaban, con codigo incluido (cosa que no suelo hacer) y saltaste con que se podia optimizar utilizando Vector2 en lugar de Vector3 ... podia tener su sentido pero di la justificacion de porque no se podia hacer ese cambio y tambien explique porque no ahorrabas memoria ni nada.
Y despues empezaste con la cosa de utilizar triggers y ahora dices que no importa que solo trabaje con 10 elementos aunque hayan 5.000 objetos en la escena porque asi consume menos y es de logica ...
mmm tu eres consciente que la duda (problema determinado como tu lo llamas) de la persona que abrio el tema era "Como hacer un radar que detecte TODOS los enemigos de la escena" ? No los enemigos que tiene dentro de un rango, que eso ya lo tenia hecho el ... si no TODOS los enemigos de una escena.
Premio si dices que trabajar con 10 elementos consume mucho menos que trabajar con 5.000 elementos ... pero llegados a ese punto, y puesto que tampoco responde como resolver el problema original, tambien podrias haber dicho "No pongas ningun radar en tu juego, que asi consumira aun mucho menos" xDDD
Cita de: lightbug date=1487769717Componentes puede referirse a cualquier funcionalidad del motor, claro la mayoria lo personaliza desde todo angulo posible, y me parece genial esto, pero no se ponen a escribir su propio motor de fisicas, o sus propias librerias matematicas, no tendria sentido usar Unity en primer lugar.
La respuesta esta en motor grafico ... a Unity le pudieras quitar el motor de fisicas, todos sus componentes mas basicos (terrain, los distintos componentes que extienden de Collider, rigidbody, characterController, etc) y seguiria teniendo exactamente el mismo valor que tiene ahora mismo para alguien que sabe programar. Como comentaba, no me imagino a ninguna de las desarrolladoras importantes a nivel internacional creando su juego AAA a base de utilizar los componentes o fisicas que trae incorporado Unity.
Desde luego yo no trabajo en ninguna de esas desarrolladoras de videojuegos, tampoco creo titulos AAA ... pero prefiero la libertad y personalizacion que me ofrece crearme mis propios componentes.
Imaginate tu el programador que esta en una de esas empresas cobrando un dineral cada mes, mas que una preferencia personal (que seguramente tambien), sera una exigencia. Sobre que no tendria sentido el uso de Unity si no fuera por sus componentes, fisicas o librerias ... solo hay que darse cuenta que existe una tienda donde se compran componentes que añaden funcionalidades de todo tipo (fisicas, networking, animacion ...) que no vienen con Unity y han sido programadas por terceros.
Cita de: lightbug date=1487769717Pero justamente aca esta el truco, para que queres trabajar sobre los 4000 objetos a fuerza bruta mientras podes ser mas listo y trabajar sobre una zona determinada... y lo mas importante tener mejores resultados! (exagerando las condiciones, claro, pero asi se realizan los test).
Pues me remito al primer punto del post ...
no es lo que yo quiera, el radar no era para mi y tampoco fui yo quien abrio el tema exponiendo una duda, solo me he limitado desde el principio a solucionar un determinado problema (como tu lo llamas) que expuso otro usuario del foro. Si hubiera sido para mi, habria optado por lo que yo creiese mas oportuno ... pero como alguien pregunto como conseguir cierta funcionalidad para su radar, simplemente me limito a responderle para que pueda conseguir lo que busca.
Solo imaginate que tu preguntas "Como puedo saber a que velocidad va un coche" .... y alguien te responde "Los pajaros vuelan muy alto" xDDD a que se te quedaria cara de tonto ?
Pero como decia mi abuelo que en paz descanse, y puesto que el tema ya no tiene que ver con lo que preguntaban al principio ... para ti la marrana, es mejor utilizar el trigger y detectar solo los enemigos que esten dentro de una pequeña area (aunque eso no era el problema por el que alguien abrio el tema).
Un cordial saludo
No era tanto para los enemigos lo del radar.. pero claro tampoco lo dije, lo principal que queria hacer era que en el mapa(mundo) habian puntos de spawn y dichos puntos debian de salir en el minimapa aunque esten fuera de su rango, pero como vi en la respuesta de Arthure habia un método de dibujarmapa lo que me hizo pensar deberia dibujar un minimapa? como ya expliqué lo que hice fue poner una camara arriba que me siguiera(por eso se ve 3D) y kingtrase dice que debo crear una clase estatica y con ello otras clases que actualizen los datos de la misma..Lo que me llevo a pensar.. pues deberia hacer un minimapa en 2D tal y cual dicen y no simplemente una camara que me sigua y que vea los quads de los enemigos.. además quiero que se vea un toque profesional :C, lo que me llevo a ver unos tutoriales y descargar algunos minimaps de la asset store, bueno el punto que queria decir es que la mejor pregunta que hubiera hecho era ¿Como hacer un minimapa 2D? sé que me quieren ayudar, pero es que soy tonto al no preguntar las cosas que no entiendo.
Cita de: ytinU date=1487780436como vi en la respuesta de Arthure habia un método de dibujarmapa lo que me hizo pensar deberia dibujar un minimapa?
Hola @ytinU
Que no te engañe el nombre de la funcion que puse "Dibujar_Enemigo_Minimapa". Como puedes observar en el codigo que puse, esa funcion la deje vacia con puntos suspensivos para que tu la rellenaras ... pero la funcion se hubiera podido llamar perfectamente "
Colocar_Marcador (Vector3 posicion)".
Lo importante del codigo era el contenido de la funcion Update que es donde se calcula en que posicion del radar debe ir colocado el marcador (indistintamente de si se trata de un marcador que señale un enemigo, spawner o cualquier otro elemento) dependiendo si se encuentra dentro o fuera del rango.
Para mostrar el contenido del radar hay diferentes metodos : puedes hacerlo con una camara en 3d, una camara octografica, los elementos de la UI para montarte tu propio sistema o cualquier otro metodo ... todo depende de la imaginacion y lo que quieras currartelo.
Tu optaste por el metodo mas rapido, colocar una camara y marchando ... aunque debes tener en cuenta que de todos los metodos que se me ocurren creo que la camara 3d es el que mas consuma, pero puedes conseguir optimizar simplemente haciendo que no se muestren los edificios en la camara del radar o bien cambiando las opciones de la camara y ponerla en octografica (o aun mejor, realizando los dos cambios).
Un saludo ... y perdona por el debate en tu tema.
P.D. sobre lo de utilizar clases estaticas y eso, en lo personal no te lo recomiendo ... una cosa es el metodo que utilices para manejar la informacion que aparecera en el radar (que es lo que yo te puse en el primer post), y otra cosa es el metodo que utilices para mostrar dicha informacion (que en tu caso es usando una camara).
Si al final optas por buscar videotutoriales, creo que el 99% de los casos utilizaran la camara.
Primero y principal: mis disculpas hacia @ytinU si me fui de las ramas. Espero que hayas resuelto el problema.Tenia pensado arrancar otro topic pero como ya estaba todo seteado segui en este. (No iba a perjudicar a nadie conocer los datos del test sea de paso).
@Arthure Por favor man, tomate dos segundos y retrocedé unos post mas arriba, a esto lo aclaro, y planteo realizar la prueba (que surgio del debate collider-vs-distancias) en base a mi confusion. fijate por las dudas.
- En el test que propuse el problema era "Que metodo es mas efectivo a la hora de detectar objetos a una distancia menor a x (caso arbitrario, con muchisimos enemigos bien distanciados)", no se porque saliste con lo del radar de vuelta, pense que estabamos discutiendo el test como adultos que interpretan un dado resultado. La escencia del test es mas bien informativa (incluso para mi), con este resultado no usaria jamas distancias para detectar proximidad en un caso asi. Aunque debo aceptar que me sorprendio lo bueno de la performance de estas.
(poner Luces de led multicolor aqui)
----> No queda ninguna duda que el codigo que pusiste es el indicado para resolver el problema del usuario. <----
(poner Luces de led multicolor aqui)
Salu2
-
Cita de: Arthure date=1487782370Hola @ytinU
Que no te engañe el nombre de la funcion que puse "Dibujar_Enemigo_Minimapa". Como puedes observar en el codigo que puse, esa funcion la deje vacia con puntos suspensivos para que tu la rellenaras ... pero la funcion se hubiera podido llamar perfectamente "Colocar_Marcador (Vector3 posicion)".
Lo importante del codigo era el contenido de la funcion Update que es donde se calcula en que posicion del radar debe ir colocado el marcador (indistintamente de si se trata de un marcador que señale un enemigo, spawner o cualquier otro elemento) dependiendo si se encuentra dentro o fuera del rango.
WOW funciono muy bien, ya lo habia probado antes pero cuando me encontre con el método de dibujar.. pensé a lo mejor piensa que mi minimapa es dibujado y hasta ahí llegue xD, muchisimas gracias.
Cita de: lightbug date=1487784168Primero y principal: mis disculpas hacia @ytinU si me fui de las ramas. Espero que hayas resuelto el problema.Tenia pensado arrancar otro topic pero como ya estaba todo seteado segui en este. (No iba a perjudicar a nadie conocer los datos del test sea de paso).
Cita de: Arthure date=1487782370saludo ... y perdona por el debate en tu tema.
Nada que ver, el principal problema es que el autor del post no responde y esto se fue a otro tema de optimización que aunque no lo crean son puntitos para mí. Gracias a ambos.
Cita de: ytinU date=1487784537Nada que ver, el principal problema es que el autor del post no responde y esto se fue a otro tema de optimización que aunque no lo crean son puntitos para mí. Gracias a ambos.
Gracias por entender, de nada!
