From a performance perspective, which one of these actions would maintain a better frame-rate over the course of the game?
Objective
50 NPC objects in the scene, up to 30 visible at any one time.
Version 1
Generate all 50 objects during the Start() function, but keep them out of camera view, and put them in visible positions when required.
Version 2
Move position markers in the scene, then instantiate new objects whenever the marker comes within the camera cone. Destroy them when the marker goes outside of the camera view cone.
My current process is version 1, but I’m concerned with the fact that this takes up a sizable amount of memory, and the geometry is still likely to be processed, even though it’s not displayed. The process for managing the execution or otherwise of the scripts attached to each of the NPC’s still needs to be completed too (if (Obj.isActive) etc for each of the 50).
The reason I shyed away from version 2 was because of the processor overhead I assume is present for the instantiate function. I notice it a little when explosions are spawning, but this is loading in all the textures associated with the explosion, where I could get around that with the NPC’s by still spawning one of each unit type off-screen and just using Instantiate to clone them. As there would be no texture loading, and it would simply be a case of duplicating the mesh and scripts, this certainly sounds like it should be quicker, which is why I ask the question.
I realise I’m likely to get the answer “try it and see”, but the problem is that it’s going to be quite a fundamental change in the structure of the engine to a game that I want to finish asap, so I don’t really have the time to burn with trying it out only to find that the original way I was going it was better.
Thanks in advance for any replies!
SB
An object pool (version 1) should give you better performance, since the overhead of creating and destroying objects can be considerable and tends to trigger frequent garbage collections if you do it on a regular basis. You may want to maintain a separate object pool for each different NPC unit type. For example, if you have ten unit types but you know that only three of each type will be visible at any time then you need only allocate 30 objects overall and then reuse NPC instances that have “died” whenever you need a new one.
what is the best way to manage a pool of objects out of curiosity? list?
As always, is there any way in the future, that you might provide to speed up instantiating and killing objects (like giving us greater control over instantiating and for example avoid garbage collections)?
For complicated objects, even one object in an empty scene takes a long time to instantiate and the disabling whole object of multiple meshes takes equally long.
Or is Unity just a great tech demo for casuals with no documentation to speak of and we have to use workarounds (like the one you suggest) to make it work - and the good things are there hidden for the people who buy the source code?
instantiation can’t be any faster. looking up files on the file system, loading them and binding the texture on the gpu just takes its time.
the only thing you can do is make is slower, so you can spread it over frames and make it cause less “straight performance hit”
Multithreading in unity core would solve all of these problems.
Also, even in current situation, caching of the objects or preparing them is some way to allow cloning by simple copy would surely speed things up. And if Unity cannot, they might release these parts of source code, to allow clever people to take a shot at it.
To suggest we should recycle objects like this ourselves instead of having it like a low level function managed by unity internally is …normal. Oh I am sure, Unity devs are busy. Preparing latest console port instead of things, people will use.
Multithreading isn’t going to change it.
Asset Bundles are already loaded through background threads, the halt upon binding the texture (when you first see them) is still there and the initial compressed audio caching halt too.
The only way to overcome those is stream in far smaller datapackets / smarter basically which works against what most want “I ask and you load” responsiveness and can, at least out of my view, not be overcome without UT implementing streaming into the engine itself instead of relying on the emergency U2 solution AssetBundles (developped for Nickelodeons MMO Fusion Fall ) in an otherwise unstreamed technology