2
\$\begingroup\$

Imagine a robot game where robots are made of pre-built blocks. Therefore, each block is a separate GameObject, with one mesh each.

I am trying to understand the conceptual differences behind the following. Is it better performance-wise and memory-wise to have one empty GameObject representing the robot that is the parent of multiple child GameObjects/meshes (i.e. the parts from which the robot is made of), or is it better to transform all into one single joint GameObject/mesh that will be the final robot?

When I mention "understand the concept", I mean understand why each of both options have their downsides in terms of memory allocation for the mesh geometry data and also processing (cpu -> drawcalls -> gpu).

\$\endgroup\$
0

1 Answer 1

Reset to default
1
\$\begingroup\$

There is no one size fits all answer to this, as is so often the case.

Generally though, if you can precompute it, do it.

If your robot doesn't change all the time, so for example you build it and it stays the same the whole time, then what's the point of calculating all of its parts every frame. But if it does change all the time then obviously you can't get away with making all of it one big object.

You are probably aware that there are tons of things that become computationally more expensive the more objects you have, for example collision detection. So you have an interest to keep the number of game objects low(-ish).

When it comes to rendering, ideally you would want to have a VBO and IBO for your whole robot, so you can push it over to the GPU once and then just reference it forever. If instead you split your robot up into bits you will have to make a draw call for each of the bits. While the amount of drawing that your GPU ends up doing will be the same, the amount of work for your CPU to translate all of those instructions for the GPU will be much higher.

So in most cases treating it as one big object would be better. However there are cases where the other treatment might work better as well.
Computing everything you need to treat your robot as one object is relatively computationally intensive and memory heavy. (Compared to just keeping everything as a collection of blocks) So if you are in a garbage collected environment and want to minimize your memory footprint, if each time a block is changed you have to recalculate the big object it could cause a garbage collection every time and make your game lag for a frame.

\$\endgroup\$
2
  • \$\begingroup\$ Thanks for your answer. In the case of collision detection, there is no real problem if one just prunes in the broad-phase by checking the greater GameObject and not directly its parts. Also, memory-wise, having multiple-robot parts instantiated can save memory, right? So, I think the real problem here is in the draw-calls, right? \$\endgroup\$
    – Kim Shutter
    Commented Jan 26, 2016 at 8:59
  • \$\begingroup\$ For collision detection you will still have to check all the parts against one another whenever two robots get close. So if you can precompute better collision geometry for it you will gain performance there for each check at the expense of a more expensive up front computation you only do once. Yes having multiple parts instantiated can save memory since you can just refer to them. As with almost everything the devil is in the detail here. But generally if you are going for performance precompute everything you can. \$\endgroup\$
    – Nils Ole Timm
    Commented Jan 26, 2016 at 9:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .