[SOLVED] About Object Pool

Armory Engine Logic Nodes
,
1

hi guys I have a question about (object Pool)…
As is known, the constant generation and destruction of objects creates a huge load on the game processes. So I wanted to know if I can achieve the same effect of (Pool) with the collections. (somehow I did it in a file I have) I’ll share it as soon as I find it.
but long story short, do we need an (Objec pooling node)?
like this? Object pooling node

2

Hi. The terms you’re referring to I believe are batching and instancing.

Armory supports mesh and material batching. Here’s how you can enable them:

However, both types require a bit more extra setup.

Here’s an example on how to setup/use material batching:

And here are a couple examples on instancing:

Personally, I don’t think it would be practical or even possible to create one. An object/mesh/material has to be defined to be batched or instanced BEFORE export from Blender, for either operation. Implementing a code function/method or logic node to toggle the operations on/off wouldn’t make much sense I think, as people would need to enable them before export, and toggling them at runtime in Armory would seem redundant.

1 Like
3

Ok, those optimizations I had not noticed
however, it doesn’t solve my problem.
but if a few moments ago I solved it.
the problem of “lag” that I suffered was due to the fact that when generating the objects of one (collection) I added them to another (new collection) completely new and empty through the node (add object to collection), in addition to a problem that I had with another node to check if the collection was empty, this was what generated the problem.
Anyway, thanks for the answer and clarification of doubts.
Thanks again

4

Hi,

Object pooling is a nice idea. I also think this could improve performance by a lot in case of rapid spawning and de-spawning of objects, such as bullets for example.

But what I am not sure of is if at all we need the use of collections. It is not a bad idea though. We get a reference to all the objects in the pool.

A quick correction: No, these are graphics things and not CPU object spawning/ despawning things that constitute an “Object Pool”. But these graphics things could be an additional optimization layer on top of the object pooling.

I had a bit of thought and came up with some basic “guidelines” that might work for this. First, we need to separate the rendering from the logic.

  1. The Logic Part:

  • We can have a collection as our root object. And this must always be at the world origin with no rotations and unit scale. This is to ensure the physics works.

  • The creation of the pool must not be done in a single frame. Maybe use the scheduler to smartly generate the objects in the pool through multiple frames.

  • The spawning and despawning can be then done in 3 steps:

    1. Remove all the traits (except physics).

    2. Make the object invisible so it is not rendered.

    3. “Disable” physics. So we don’t re-initialize physics each time we spawn/ de-spawn.

  1. The Rendering part:

  • Here we could have 3 levels of rendering optimization from best to not-great:

    1. Use CPU instancing if possible. When you have static and common materials. Because we use CPU instancing, we could also use the physics and logic information to render the instances. In this case, the object pool could be a set of Emptys.

    2. No instancing, but with mesh and material batching. When we have more dynamic materials, but they are still common for all the objects in the pool.

    3. No instancing and no batching. Just for when the objects need to change their materials at runtime and cannot exactly be batch rendered.

This would also pave the way for Physics based particles and other more non-linear particle systems.

1 Like