![]() |
Attention | Topic was automatically imported from the old Question2Answer platform. |
![]() |
Asked By | jarlowrey |
This question is the top Google result for “godot pool”, but offers no real details.
I understand GDScript does not garbage collect, and thus there won’t be intermittent pauses due to GC. However, pooling can still be useful if you are creating a lot of objects at once: a large enemy wave, a massive amount of bullets, various visual effects, etc.
Is pooling a good idea in Godot? And if so, how can you ‘reset’ an objects state when selecting it from a “dead” pool? How can you ensure it does not draw processing power when dead?
My gut is to remove them from the scene tree to prevent unneeded processing, and adding them back in should mostly reset state due to calling _ready
again. Though that won’t reset any class vars that don’t use onready
.
Edit: Trying various ways of making a node remove itself from the scene is giving lackluster results. It feels like Godot is not built with pooling in mind, even though it seems like it would be essential for good performance.
Not a solution but a question really. What if the objects are pooled “off-screen” - is godot smart enough not to waste cycles processing them because they’re not visible?
Just wondering if there’s any performance penalty in removing and then re-inserting the objects into the scene tree.
SleepyTom | 2018-04-04 06:59
The term “engine” has lost its meaning for many developers. They tend to think that an engine was “that UI that you see when you open Unity”, but that’s not the case. An engine is a library that has the purpose of filtering out information that is irrelevant to the result before sending it to the graphics card / sound card / network device / physics solvers. So yes, Godot is an engine, so it is culling objects that aren’t on screen.
That doesn’t mean however that these objects didn’t “waste cycles”, since their location offscreen means that they don’t need to be processed by the graphics card, but they still exist in your game world, so their scripts will still be called. Instead of putting them off screen remove them from the tree. That will keep them in memory but tell the engine to completely ignore them.
Warlaan | 2018-04-04 08:08
I’d call what you’re describing there Warlaan a rendering engine, while a game engine is a rendering engine plus probably a physics engine, a sound engine, etc, all glued together as consistently as possible.
Norgg | 2023-06-05 21:00
I would agree if I had mentioned graphics specifically, but I explicitly said “graphics card / sound card / network device / physics solver” because I didn’t specify if I was talking about a graphics / rendering engine, a sound engine, a network engine or a physics engine.
The “filtering out” is what all of these have in common, it’s just that the criteria are different. A sound might be filtered out because it is too far away, even if it is in view of the camera, while a physics object might be filtered out because it is not moving, regardless of the position.
But yes, a game engine is basically just a combination of the above.
Warlaan | 2023-06-07 10:19