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!