Jump to content
Sign in to follow this  
Igor

el transform contiene el gameObject y alreves

Recommended Posts

hola, vuelvo con mis preguntas sobre "rendimiento"

tengo una duda acerca de gameobject.transform y transform.gameobject

quiero tener acceso(quiero mover), via script, otro objeto que no es el que posee el script en cuestion, y estoy dudando cual es la manera mas optima(solo quiero cambiar la posicion)

deberia almacenar la referencia al GameObject o al Transform? unas veces lo hago de una forma y otras veces de la otra... 

pongamos que quiero mover un "Cube":

que es mejor desde el punto de vista del rendimiento?

public GameObject miCubo;

//o es mejor:

public Transform miCuboTransform;

mi duda viene a raiz (como indica el titulo) de que el transform contiene el gameObject y el GameObject contiene el transform

??? wtf ???

supongo que el transform.gameObject lo que hace es buscar a su "portador", osea, el GameObject... 

entonces seria mejor solo usar como "ref" el transform?

...no tengo muy clara la gerarquia... 

ah! y encima justo acabo de leer una respuesta de @FNP en el post "Sistema Guardar/Cargar" en "Scripting" en la que justo dice que hacer todo "publico" y pasar referencias via editor es "una de las cagadas mas grandes de Unity", lo se .... pero cada vez mas no hago mas que pasar referencias via editor.... es que esa "funcionalidad" simplifica tanto las cosas... jejeje... ten en cuenta que vengo del viejo "basic" y ahi no habia "objetos"... luego tambien toque algo de c++ y java, y ahi si aprendi sobre objetos y classes, (aunque no mucho del funcionamiento "interno") ...pero para mi el editor de unity es lo mas! (simplificando trabajo, no para el rendimiento) 

ah, claro y entonces me surje otra duda, si pasar via editor es una "mierda" y usar "gameobject.find" es mas "mierda" todabia... como hago? un gameObject find en "void Start" y almaceno la "ref"?

???

Share this post


Link to post
Share on other sites
hace 54 minutos, Igor said:

ah! y encima justo acabo de leer una respuesta de @FNP en el post "Sistema Guardar/Cargar" en "Scripting" en la que justo dice que hacer todo "publico" y pasar referencias via editor es "una de las cagadas mas grandes de Unity", lo se .... pero cada vez mas no hago mas que pasar referencias via editor.... es que esa "funcionalidad" simplifica tanto las cosas... jejeje... ten en cuenta que vengo del viejo "basic" y ahi no habia "objetos"... luego tambien toque algo de c++ y java, y ahi si aprendi sobre objetos y classes, (aunque no mucho del funcionamiento "interno") ...pero para mi el editor de unity es lo mas! (simplificando trabajo, no para el rendimiento) 

ah, claro y entonces me surje otra duda, si pasar via editor es una "mierda" y usar "gameobject.find" es mas "mierda" todabia... como hago? un gameObject find en "void Start" y almaceno la "ref"?

???

No seáis tan literales, una de las ventajas y principales características de la orientación a objetos es la encapsulación y todo lo que sean las variables publicas en una clase va en contra de eso, lo suyo es tener variables privadas y métodos públicos que gestionen esas variables privadas cuando son invocados y por lo tanto, las variables no se pueden tocar desde fuera de la clase, eso le da al sistema de clases robustez y estabilidad. Luego está la vida real y meter métodos para absolutamente todo es mayormente un coñazo, yo también vengo del basic con números de linea donde no había ni siquiera funciones y el control de flujo era a base de GOTO, así que se de lo que hablas, tampoco se trata de ser mas papista que el papa, por eso no me parece un problema guardar cosas en el PlayerPrefs :22_stuck_out_tongue_winking_eye:

Lo del Find, SendMessage, etc. El problema es que es lento, no es que sea malo. Esta bien si no tienes que procesar 1000 objetos, con esa cifra ya te digo yo que la aplicación en un iPad, por ejemplo, va como el culo (probado usando el tag para buscar y activar y desactivar GameObjects).

Share this post


Link to post
Share on other sites
7 hours ago, Igor said:

tengo una duda acerca de gameobject.transform y transform.gameobject

GameObject siempre contiene un único transform, por lo que mediante un transform podes obtener un único Gameobject, (relación bidireccional). Por eso siempre mi duda de que cachear el transform no tiene efecto, podrías llamar a "transform.position...." sin necesidad de cachearlo, incluso he hecho pruebas y no cambia nada. Disitnto para otros componentes y los malditos GetComponent.

7 hours ago, Igor said:

que es mejor desde el punto de vista del rendimiento?

cuando llamas a transform estas llamando la referencia del objeto transform (clase), cuando llamas a gameobject.transform estas llamando a la referencia del gameObject en cuestión, y de ahi su transform, supongo que no tenes casi nada de impacto, no estas "obteniendo componentes", estas simplemente llamando a un miembro obligatorio y que debe existir en dicho gameObject (sin Nullreferences). Yo lo pienso asi, si vas a administrar objetos, cambiarles nombre, borrarlos, crearlos, etc--> usa gameObjects, si vas a moverlos, rotarlos, enparentarlos, etc ---> usa transforms, además de que el código queda mucho mas legible.

7 hours ago, Igor said:

ah, claro y entonces me surje otra duda, si pasar via editor es una "mierda" y usar "gameobject.find" es mas "mierda" todabia... como hago? un gameObject find en "void Start" y almaceno la "ref"?

Si vas a usar un FIND lo mejor es usarlo al principio, tene en cuenta que no encuentra objetos desactivados, (en un public GameObject sí los podes meter) y que depende del nombre, y de la cantidad de objetos en la escena, para mi tiene muchas más desventajas, pero si lo vas a usar lo mejor es hacerlo al principio.

Si tenes un buen esquema general no es necesario usar finds.

No creo que "pasar por editor" sea un mierda, hay cosas que desde el punto de vista del diseño/funcionalidad quedan mucho más cómodas referenciarlas por inspector.

"pasable por inspector" significa que unity serializa el campo de interés, generalmente los public ya están serializados, pero podes tener algo asi:

[SerializeField] GameObject GO;

y elegirlo por inspector también.

No va en rendimiento, el inspector ---> Diseño/Comodidad, esto es el foco. Aunque si conoces los Scriptable Object el número de los campos del inspector que uno normalmente usaba en sus objetos se reduce drásticamente. Esto si puede estar asociado a aspectos del rendimiento, sobre todo si en cada objeto estas teniendo la misma referencia a un prefab, una y otra vez, cuando podes tener una base de datos que ya la tenga.

 

Share this post


Link to post
Share on other sites
hace 2 minutos, FNP said:

yo también vengo del basic con números de linea donde no había ni siquiera funciones y el control de flujo era a base de GOTO, 

jeje que recuerdos...

@gZone gracias, si, era como pensaba... 

hace 4 minutos, lightbug said:

si vas a administrar objetos, cambiarles nombre, borrarlos, crearlos, etc--> usa gameObjects, si vas a moverlos, rotarlos, enparentarlos, etc ---> usa transforms, además de que el código queda mucho mas legible.

lo solia hacer asi

gracias por la esplicacion

Share this post


Link to post
Share on other sites

Evidentemente si vas a tocar cosas relativas a posición o escala es mejor guardar el transform directamente y si vas a activar o desactivar es mejor el GameObject. De todas maneras, no creo que afecte demasiado al rendimiento utilizar uno y otro, ya que hacer gameObject.transform no creo que necesite demasiado procesamiento...

Share this post


Link to post
Share on other sites

Hola @Igor, en realidad el titulo del tema esta equivocado ... ni el transform contiene el gameobject, ni el gameobject contiene el transform.

La clase GameObject puede referenciar al transform (que es el unico componente obligatorio) pero no es que lo tenga guardado; para que te hagas una idea, cuando haces gameobject.transform es como si fuera una manera simplificada de gameobject.GetComponent<Transform> y la prueba esta en que consume muchos mas recursos realizar gameobject.transform dentro del Update, por ejemplo para realizar un cambio de posicion, que no si guardas el transform en una variable y cambias la posicion mediante dicha variable.

Del mismo modo, el Transform tampoco contiene el GameObject ... lo que cualquier componente (Transform, Collider, o cualquier script realizado por ti) puede referenciar a su gameobject de manera similar a como sucede con la clase GameObject que puede acceder a su transform.

En resumen, que lo que tienen las clases GameObject y Transform son getters para referenciar a su transform o gameobject respectivamente, pero no los tienen almacenados de ningun modo.

Edited by Arthure

Share this post


Link to post
Share on other sites

Estos son los números de mi test:

  • Get Component : 5.81 ms
  • gameObject.transform: 4.30 ms
  • transform : 3.36 ms
  • transform (catched) : 2.32 ms

Asi que... a catchear siempre! y a evitar GetComponents en runtime

 

 

 

Edited by lightbug

Share this post


Link to post
Share on other sites
1 hour ago, lightbug said:

Estos son los números de mi test:

  • Get Component : 5.81 ms
  • gameObject.transform: 4.30 ms
  • transform : 3.36 ms
  • transform (catched) : 2.32 ms

Asi que... a catchear siempre! y a evitar GetComponents en runtime

Uy, se acerca bastante a un GetComponent! No me lo esperaba.

Share this post


Link to post
Share on other sites
hace 10 minutos, TheBullet said:

Uy, se acerca bastante a un GetComponent! No me lo esperaba.

ah pero metele mas componentes y veras como sube por las nubes

Share this post


Link to post
Share on other sites
hace 13 horas, gZone said:

De más rápido a más lento ...

  • Transform (cacheado) 1.374779
  • Transform 1.756747
  • gameObject.transform 2.152893
  • GetComponent 2.379752
  • gameObject.GetComponent 2.767935

* muy interesante hacer benchmarks, suelen aparecer sorpresas (sobre todo en comparativas entre plataformas)

 

hace 16 horas, lightbug said:

Estos son los números de mi test:

  • Get Component : 5.81 ms
  • gameObject.transform: 4.30 ms
  • transform : 3.36 ms
  • transform (catched) : 2.32 ms

Asi que... a catchear siempre! y a evitar GetComponents en runtime

 

muchas gracias, voy a modificar todos los scripts de mis proyectos, a "catchear" todo, jeje:6_smile::91_thumbsup:

o al menos todo lo que se "ejecute" varias veces(por existir multiples instancias del objeto, o por estar la "llamada" dentro de un "bucle" for o similar)

esta claro que lo mejor es almacenar todo en variables

quiza suba un poco el uso de memoria (en ejecucion)

y esto supongo que se aplica a todo....

porejemplo en un script de movimiento(que sea algo complejo) no haces mas que repetir por todos los lados "noseque * Time.deltaTime;" 

supongo que sera mejor guardar deltaTime en un "float" y usar ese float para los calculos.... 

Share this post


Link to post
Share on other sites

jejeje, podemos convertirnos en los "sheriffs"!!! 

los programadores con el codigo mas rapido del oeste

Share this post


Link to post
Share on other sites
7 hours ago, Igor said:

porejemplo en un script de movimiento(que sea algo complejo) no haces mas que repetir por todos los lados "noseque * Time.deltaTime;" 

supongo que sera mejor guardar deltaTime en un "float" y usar ese float para los calculos.... 

Interesante:

No catcheado: 1.24 ms

Catcheado: 0.25 ms

:50_open_mouth::50_open_mouth::50_open_mouth:

 

Share this post


Link to post
Share on other sites

mmm Quiero entender que el guardar el valor de deltaTime en una variable para utilizarla es en plan ironico, medio en cachondeo ... pero como en los posts posteriores han continuado con la "broma" y en un tono serio, de hacer pruebas y tal, ya no se que pensar :2_grimacing::2_grimacing::2_grimacing::2_grimacing:

en cualquier caso, siendo bien pensado y creyendo que era un chiste, mejor nos reiremos ... por lo menos que si alguien lee eso y no tiene muy claro lo que esta haciendo, no tenga el presentimiento de que esta correcto y se sienta tentado a hacerlo JAJAJAJA.

Share this post


Link to post
Share on other sites
Sign in to follow this  

UnitySpain © Todos los derechos reservados 2020
×
×
  • Create New...