Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
In unity, let us suppose that I have some Game Objects in my scene that are not visible to camera and so are not rendered while the game is running.
Will these Game Objects be consuming computer/mobile resources when the game is running?
Where can I find details about usage like these?
What you want is a memory profiler, Which Unity does have. Here: http://docs.unity3d.com/Manual/ProfilerMemory.html
But your assumption is mostly right, if a gameObject is not visible to the camera it is not drawn, and it uses less resources, but it still must consume some. The gameObject still exists in memory, including all the textures, models scripts etc.. it also still consumes CPU time through the Update and FixedUpdate methods (and various others described here).
But usually the major slowdown is the drawing, a small amount of CPU time is used to determine that the object is outside the camera frustum (bounds), but no drawing is done.
I think you should also know about Frustrum Culling, or hiden surface removal: http://en.wikipedia.org/wiki/Hidden_surface_determination
This is an important bit of optimising a game, because even if your objects are not inside the frustrum at a given frame (i.e. visible), some draw calls (shaders) are still launched for them, therefore decreasing performance.
The short answer is "yes"; anything that is ready to be used in your game is taking up memory.
The other thing to consider is the cost to your frame-rate:
5 objects, with 5 separate textures, drawn separately require state-changes in-between. You may be able to save some memory by unloading textures that aren't used.
By loading all of the separate textures into a single atlas texture, the memory footprint becomes fixed and you can no longer unload an individual texture. Once created, you only have to bind the atlas once to draw all of your objects.
Another example is a simple vertex and index buffer. If many of the points frequently toggle between visible and not, it is faster to leave the "stale" points in the vertex buffer and only upload a new index buffer.
There are many others times where an increased up-front memory cost is preferable to many state-changes.
If you rotate your camera, you definitely will not destroy those objects unless you know, that camera will not rotate back to check on that object." – Katu
Using a side-scroller as an example, if you can only move to the right (the map only scrolls to the left), any object that scrolls off the left side of the screen can be permanently unloaded since you will never use it again. Additionally, content for objects can be demand-loaded right before the object scrolls into view from the right.
A lot of answers are mainly considering the graphics aspect of your question.
The fact is they will take up various resources, and how expensive they are compared to drawing the object isn't fixed. It's not as uncommon as some answers implied for your components to be making more expensive operations than drawing does, but you can minimize how many resources they use. Also keep in mind that a GameObject takes up a small amount of memory, and so do it's components. The components may also be doing things that are taking up a fair bit of memory.
The simplest way to minimize the effect of off-screen components is a system based on the OnBecameVisible and OnBecameInvisible callbacks.
void OnBecameVisible()
{
myComplexComponent.enabled = true;
}
void OnBecameInvisble()
{
myComplexComponent.enabled = false;
}
Of course, that's of very limited usefulness since there are plenty of times when you'll want an off-screen object to affect the game. But you can expand on a pattern of this sort for a fine-grained system capable of minimizing the effect of your most expensive calculations. Even something as simple as reducing something like the quality of a path following script when the object is off-screen can result in big savings in the long run.
It takes memory to keep it alive and update its position and other properties.
But it doesn't consume computer/mobile graphic resources since it is not visible.
Anything that is in a program consumes resources; You don't think programs run on simply hopes and dreams, do you?
The question should be how much resources does a game object consume, and to that end I think this is a pretty solid answer: http://answers.unity3d.com/questions/280455/how-much-memory-a-gameobject-consume.html
In short, they consume negligible resources on their own. But why would you want a bunch of game objects just sitting in your game doing nothing? At the end of the day, what you actually make those game objects 'do', is what is going to cause any sort of overhead- and how much resources that requires is very much on a case by case basis.
