¿Los objetos de juego que se encuentran fuera de la vista de la cámara consumen recursos informáticos / móviles en Unity?

En unidad, supongamos que tengo algunos objetos de juego en mi escena que no son visibles para la cámara y que, por lo tanto, no se representan mientras el juego se está ejecutando.

¿Estos objetos de juego consumirán recursos informáticos / móviles cuando el juego se esté ejecutando?

¿Dónde puedo encontrar detalles sobre el uso como estos?

Lo que quieres es un generador de perfiles de memoria, que Unity sí tiene. Aquí: http://docs.unity3d.com/Manual/ProfilerMemory.html

Pero su suposición es mayormente correcta, si un gameObject no es visible para la cámara, no está dibujado y usa menos recursos, pero aún debe consumir algunos. El GameObject todavía existe en la memoria, incluidas todas las texturas, scripts de modelos, etc. También consume tiempo de CPU a través de los métodos Update y FixedUpdate (y varios otros descritos aquí ).

Pero, por lo general, la desaceleración principal es el dibujo, se utiliza una pequeña cantidad de tiempo de CPU para determinar que el objeto está fuera del centro de la cámara (límites), pero no se realiza ningún dibujo.

Creo que también deberías saber sobre el sacrificio de Frustrum, o la eliminación de la superficie oculta: http://en.wikipedia.org/wiki/Hidden_surface_determination

Esta es una parte importante de la optimización de un juego, porque incluso si sus objetos no están dentro del frustrum en un marco determinado (es decir, visible), todavía se lanzan algunas llamadas de dibujo (sombreadores) para ellos, lo que disminuye el rendimiento.

La respuesta corta es sí"; todo lo que esté listo para ser usado en tu juego está ocupando memoria.

La otra cosa a considerar es el costo de su velocidad de fotogramas:

5 objetos, con 5 texturas separadas, dibujados por separado requieren cambios de estado intermedios. Es posible que pueda guardar algo de memoria descargando texturas que no se utilizan.

Al cargar todas las texturas separadas en una sola textura de atlas, la huella de la memoria se arregla y ya no puede descargar una textura individual. Una vez creado, solo tiene que vincular el atlas una vez para dibujar todos sus objetos.

Otro ejemplo es un vértice simple y un buffer de índice. Si muchos de los puntos cambian con frecuencia entre visible y no, es más rápido dejar los puntos "obsoletos" en el búfer de vértices y solo cargar un nuevo búfer de índice.

Hay muchas otras ocasiones en las que es preferible un aumento en el costo de la memoria inicial a muchos cambios de estado.

Si gira su cámara, definitivamente no destruirá esos objetos a menos que sepa, esa cámara no girará para verificar ese objeto ". - Katu

Usando un desplazamiento lateral como ejemplo, si solo puede moverse hacia la derecha (el mapa solo se desplaza hacia la izquierda), cualquier objeto que se desplace desde el lado izquierdo de la pantalla se puede descargar permanentemente ya que nunca lo volverá a usar. Además, el contenido de los objetos puede cargarse a la demanda justo antes de que el objeto se desplace a la vista desde la derecha.

Muchas respuestas están considerando principalmente el aspecto gráfico de su pregunta.

El hecho es que tomarán varios recursos, y lo costoso que son en comparación con dibujar el objeto no es fijo. No es tan infrecuente como algunas respuestas implican que sus componentes realizan operaciones más costosas que el dibujo, pero puede minimizar la cantidad de recursos que utilizan. También tenga en cuenta que un GameObject ocupa una pequeña cantidad de memoria, y también lo hacen sus componentes. Los componentes también pueden estar haciendo cosas que están ocupando bastante memoria.

La forma más sencilla de minimizar el efecto de los componentes fuera de la pantalla es un sistema basado en las devoluciones de llamada OnBecameVisible y OnBecameInvisible .

void OnBecameVisible()
{
    myComplexComponent.enabled = true;
}
void OnBecameInvisble()
{
    myComplexComponent.enabled = false;
}

Por supuesto, eso es de utilidad muy limitada, ya que hay muchas ocasiones en las que querrás que un objeto fuera de la pantalla afecte el juego. Pero puede expandirse en un patrón de este tipo para un sistema de grano fino capaz de minimizar el efecto de sus cálculos más caros. Incluso algo tan simple como reducir algo como la calidad de una ruta después de la secuencia de comandos cuando el objeto está fuera de la pantalla puede generar grandes ahorros a largo plazo.

Se necesita memoria para mantenerlo vivo y actualizar su posición y otras propiedades.

Pero no consume recursos gráficos de computadora / móvil ya que no es visible.

Entonces, sí, consume recursos de memoria pero no recursos gráficos como lo hace un objeto de juego visible.

Todo lo que está en un programa consume recursos; No crees que los programas se ejecutan simplemente en esperanzas y sueños, ¿verdad?

La pregunta debería ser cuántos recursos consume un objeto de juego, y para ese fin creo que esta es una respuesta bastante sólida: http://answers.unity3d.com/questions/280455/how-much-memory-a-gameobject- consume.html

En resumen, consumen recursos insignificantes por su cuenta. Pero, ¿por qué querrías un montón de objetos de juego simplemente sentados en tu juego sin hacer nada? Al final del día, lo que realmente hace que esos objetos del juego 'hagan' es lo que causará cualquier tipo de sobrecarga, y la cantidad de recursos que requiere es mucho caso por caso.