I come from a Unity3D background and I have gotten used to pooling frequently used actors instead of spawning and killing them at runtime. Take projectiles for example, I am creating a game that will be spawning a pretty hefty amount of projectiles per second. In Unity I would use a projectile pool to prevent any slowdown, especially on mobile platforms. However in Unreal I can’t figure out how to do this.
I have been able to create an array with my projectiles, however I can’t find a way to activate and deactivate them as needed. All solutions I have found seem to only half work, for example making actors hidden in game seem to only affect the visibility as they are still performing their logic in the background. This would be okay for static meshes that don’t have to do anything, but as far as projectiles with blueprints I have had no luck. I have also tried disabling the actor tick and a few other nodes in combination but nothing seems to work for me.
Is pooling necessary in Unreal? Is garbage collection an issue and can it be controlled in blueprints?
A lot of the reason that pooling was needed in Unity is because they were using an older version of Mono that had a really terrible garbage collector. I can tell you that when we first made the jump from Unity to UE4 about a year ago, we brought over a lot of bad habits - things that we did because they had been necessary in Unity and we assumed we should do it here.
Fight the instinct. In most scenarios, you won’t need to do manual pooling of objects. Pooling is an optimization. Do it only if you have performance problems and even then, only do it if profiling the shows you’re spending a lot of time in allocation/deallocation.
For projectiles, and everything you can. Use physics bodies, they are optimized best.
Avoid any “on tick” events in objects that are in high amounts.
For your projectile. Add “on hit” event to them. In that event do your logic, spawn some explosion particles, and destroy projectile.
This way all logic that projectile needs to do is done once.
I did some testing with asteroids in space recently, so i have some numbers:
With constantly moving and doing on tick i could get to about 50 asteroids before fps was below 30.
When i removed on tick i could get to 100-150.
But when i added damping so they stopped all movment after about 2 seconds i could get to 500 and above.
@
I kind of figured it was likely not as important in Unreal, seeing as how any information related to pooling in Unreal is extremely scarce.
@Nawrot
I will definitely try the physics bodies as you have suggested. The on hit logic is basically the same thing I had in mind for pooling, except now I just destroy them. I can’t complain, not having to pool actors will make my life a little easier!
Personally I don’t actually agree with that … I think pooling should be the default most of the time … more hassle but in the end I have yet to see an implementation of a garbage collector that doesn’t cause issues at some point.
I quite enjoy the process of setting up pooling … You can learn a hell of a lot about array etc from it.
To each his (or her) own. It’s your app, you should write it the way you want.
But, personally, I don’t like introducing any more complexity than is necessary into my code and I don’t like having to maintain code that isn’t needed. I’ve been writing code for about 35 years, and I’ve been bitten many, many times by trying to outthink problems that haven’t happened and might not happen. Adding something like pooling to your code later in the process, when empirical data shows that it’s a good idea, is rarely any harder than doing it up front if you’ve architected your code well, and if you never need it, well… there’s a whole chunk of code that you don’t have to maintain and that can’t have bugs, and there’s time you didn’t spend writing something unnecessary; time you can use for writing other code that your game will actually need.
The longer I program, the more respect I have for Donald Knuth. One thing he said – back in 1974! – was the following:
I must say I also enjoy pooling, however I think I am going to try working without it for a while so that I can see the actual impact in Unreal for myself. I am also thinking that if I start a new project where I know I will be needing massive amounts of none stop projectiles, I’ll probably pool from the get go. This seems like a more proactive approach, rather than running into problems down the road and having to change the system.
I’m just going to play around with things a little longer, and hopefully come to my own conclusions. I really appreciate all the input!
Indeed … I don’t disagree … The simplest solution does tend to be the best one … And I do have a habit of over engineering code …
As stated though modern GC’s are a bit of a pain in any engine … And pooling does get around that (for the most part). With engines like UE and Unity its very easy to create / destroy objects on mass … Thats the problem … Great if you dont want to worry about the complexity, not so great if you cant work out why occaisionaly your game decides to come to a grinding halt for no real reason.
It would be nice to see some benchmark how much pooling (if any) improves the efficiency on different amount of objects like 50, 100, 1000 pieces.
I also come from a Unity3D background and I must say that I’ve learn too many bad habits from unity and I started to implement those right away to unreal projects also, little bit later I noticed that I’m doing something that already exists on Unreal Engine.