koobas.hobune.stream
enemy pooling
Hi I'm working on a little iphone game where u fight in an arena against several enemies. Now, I wondering whats the best way to save as much performance as possible.
I've read about using an object pool but I'm a bit suspicious. I have a maximum of 5 enemies on the screen and 10 different enemy types. The type is picked randomly. So I need 5 enemies of every type which ends up in 50 enemies in total, which sounds a lot.
Is it really that good to create 50 skinned meshes and deactivate them? They are still in the scene and will use a lot of memory/performance when they are deactivated. aren't they?
But will you have the 50 enemies at the same time in the scene? Because then you would be pooling only maybe 20 objects and then you reposition them when dying.
@Bovine - do you find the performance of a skinned mesh renderer (not necessarily animating) is causing a problem on mobile? I was considering a tree system where I use a single S$$anonymous$$R to place all of my dynamically repositioning trees - but I haven't tried it and don't want to if it is going to cause a problem!
Well, when the S$$anonymous$$R is first deemed to render it will do an initial Sample() which rebuilds some internal state (at least that's the name of the method we see the spike in).
If you Sample() manually on loading the scene with all your S$$anonymous$$Rs in it and just disable the S$$anonymous$$R when it's not in view, then you can turn the S$$anonymous$$R back on without incurring this rebuild. I don't know, if you had 50 S$$anonymous$$Rs in view but no animations were playing on them, whether there would be a significant overhead. I imagine that no animations would be considered when sampling and you would just end up with the bind pose, or maybe you would get whatever the previous animation left the mesh in, but if that's the case there is a cache of the previous frame's verts somewhere and so there is vertex RA$$anonymous$$ overhead for each S$$anonymous$$R.
Sorry I can't offer anything more conclusive. We have maybe 50 mobs per environment, and many, say a dozen or so, could be 'active' at any given time, all of them theoretically. Given that they are animating and may be in the frustum, I couldn't risk 50 mobs being skinned every frame, so we depth sort the NPCs every frame and for the near 5 (configurable of course) we use the S$$anonymous$$R renderer and for everything else we use a static, lower-res model, in an idle pose and have it bob about so there's the impression of movement. While not prefect, it actually works really well - I've had 30 mobs on screen and the performance was very good, even on 3G S and as importantly, the visual illusion works - your eye is drawn to that near mob that's about to bash you and your brain fills in the detail of the one bobbing about 200 feet away.
Your use-case for an S$$anonymous$$R sounds more complex. We have a prefabpool in our game that dishes out prefabs when asked for them by a string key and we use this for temporary objects and FX in the scene. If it doesn't have a spare prefab, then it will create a new one and I plan to pre-bake the scene with a sensible number. don't know if your dynamic trees scenario is a re-use issue or not?
Yeah I have 8000 trees, but each variety really only needs a few (max 50 or 60) instances to look realistic from a given viewing angle. So at present I have a system that selects the best candidates based on frustrum culling, viewing angle and distance then moves the real trees into those locations. Given each tree is potentially 2 or 3 draw calls I was considering merging all of the meshes, providing a bone for each tree and then scale and move the trees by moving the bones - therefore 2 or 3 draw calls for 60 trees.
I can't think of a reason why that wouldn't work tbh. You've one mesh with 60 bones, I guess 60 bones is a bit expensive, but you will have 1 bone per vertex for a given tree right? You could just move the bones and re-parent trees to the relevant bone position, which should also be cheap - if I'm understanding your use-case of course :D
If there are only so many alive at a given time, then your main problem is how much RAM your using. If you're on desktop then RAM not such an issue and it probably won't be a performance hit to instantiate a mob, but on mobile you will probably see a judder in frame rate. We instantiate all our mobs and may go to as many as 50, but we are on mobile so have some custom lod system to swap a skinned mesh renderer for a simple renderer on all but the nearest 5 mobs - we don't want to animate more than a few!
We also plan to sleep the majority of mobs and activate them when the player gets to a trigger location (as they'll be doing nothing until then anyway!)
We had a performance issue however with skinned mesh renderer as the first Sample() allocates resources, so we start a level with them all active, force a Sample() and then hide the ones deeper in the level.
With RAM you may find the meshes are instances too so you should profile outside the editor and see if the RAM is much different from 1 to 50.
Converted this to an answer but there's some detail in the above comments as well... if you could accept that'd be good cheers.
