Which is faster?

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

hehehe - there are even more things to consider:

With option 2, like you mentioned - does your AI lend itself to being part of a pool?

http://forum.unity3d.com/threads/34582-Stop-wasting-memory-recycle-your-objects!

(no idea if the code is good)

With Option 1, how much can you reduce the effect of a non visible AI - slow down updates to e.g. 1 a second, disable physics, rendering etc.

The AI handles either method just fine - that’s not a problem. What is the issue is the processing cost attached to having objects in memory even if they’re not used at the current point. I realise that if they’re off-screen, they’re culled anyway, but in order to establish if they’re not viewable from the main camera, surely there’s a chunk of vertex processing that needs to go on with them anyway? If they’re not there, then their geometry wouldn’t be considered for camera rotations and all of that core pipeline stuff, so surely there’d be a processor saving?

I’m primarily concerned with the rendering of the scene. I want to use as few draw-calls as possible (as ever) ensuring that the graphics performance is absolutely as good as it can be.

The other (happy) side effect of method 2 is the fact that this would remove a degree of overhead from just the processing of the AI. With method 1 and 50 AI, even if 40 of them aren’t actually doing any processing, you still have to check if they’re working, which is an overhead that doesn’t exist with method 2.

The problem is that, without writing some pretty specific tests (or writing the code to implement method 2 in the game), I’m at a loss as to which is likely to work out faster, hence the question. :slight_smile:

FPS wise option 1 may be faster. Although it has the side-effect of using more memory from the get go, as you said yourself.

In the end though you answered yourself, try both ways while looking deep and hard at the profiler stats and figure out the pros and cons of each method.