How should I go about handling the performance impact from 50.000ish gameobjects in my scene?

Question

Hello, I'm currently working on a prototype for an FPS survival/base defense game. In my current stage of development, my main focus is world generation. Without going too deep into the premise, I basically randomly generate a finite world (But can be quite big), with randomly placed things like trees, stones, ores, and more. Additionally the player will place objects (Which over time can amount to hundreds or even thousands, for really long plays).

(Picture, just for reference.. and to make this post a bit colorful :P ) alt text Although all these objects are not really doing anything (They can be harvested/mined), I cannot make them static, as they will be manipulated/animated when interacted with.
Currently, I have around 15.000 gameobjects in a scene at one time, which for my mid-end PC, runs smoothly.
Upon testing with around 50.000 gameobjects, this is where I start to feel it and end up around 25-30 fps. (Should be mentioned, this is by running it in the editor)

I've not had too much need for object pooling before, but I am considering if I should move in that direction?
Basically, I have two thoughts, Either I make some object pooling system, where I keep x amount of each object in memory, and move them in view of the player, when applicable.
Alternatively, I've considered just spawning in all the objects, and simply disabling/enabling them at runtime, again based on the view of the player.

I'm basically just asking here to get some thoughts on this.
Does any of you have any input/experience with either approach?
Is there an angle here that I'm missing, which I should look into instead?

In any event, thanks for taking your time to read this :-)

Answer 1

Best Answer

Answer by Mikael-H · Jan 03 at 10:19 AM

I would evaluate if all your objects really need to be game objects. Could they live in a data structure and then be spawned as a game object when the player is near them?

If you have a tree, consider what data is needed to describe it. World coordinates, tree type etc. When the player comes near, instantiate a game object with scripts to update or use the data. When the player is not near, unspawn (and maybe put in a pool).

Add comment · Show 1 · Share

MKayJay · Jan 03 at 04:28 PM 0

Share

This is kinda what I had in $$anonymous$$d myself. I would think that a pool is probably necessary, as instantiating and destroying objects will likely be taxing at times when the player moves in and/or out of areas where there are a dense amount of objects. As for what to save, I would only need to keep track of Position, rotation, and scale, as well as the type of 'resource' and the amount of hp it has left.

I'm actually quite surprised that there are no options to at least disable gameobjects that are being culled. I know you may not always want that, but it would be awesome to you could toggle, or something.,, Maybe there's some other kind of overhead in that?

Anyways, just me going off on a tangent - Thanks for the input.

How should I go about handling the performance impact from 50.000ish gameobjects in my scene?

1 Reply

Your answer

Follow this Question

Related Questions