Possible more efficient updates

[lawnjelly]

I don't know whether this is possible in gdscript with a singleton, but you may be able to make the updates more efficient:

Calling _physics_process for a large number of nodes is quite inefficient even if just a stub function, especially if physics tick rate is e.g. 60 tps. With 1000 nodes, that is 60,000 updates per second, most of which are stubs.

A more efficient paradigm might be instead to register each LOD node when added to the scenetree with a central updater, and unregister when removed from the scene tree.

The central updater could then run on a single _physics_process (or _process) and go through the list of registered nodes and update a certain number each update, calculated to give them all on average an update every 0.25 seconds.

In our example of 1000 nodes that would be:
desired updates per second = (1000 * 4)
updates per tick at 60tps = 4000 / 60 = 66.6

4000 updates per second is a reduction of 15x. In addition, you could do further approaches like reduce the update rate on far away nodes, and check them every second.

There are also a number of other optimizations which are common with collision detection, but these may well be overkill unless you had a large number of nodes.

[Calinou]

Interesting, thanks for doing this research 🙂

That said, the _physics_process() method is mostly a no-op if the timer hasn't reached its set duration yet. Therefore, I'm not sure if going through a singleton will speed things up significantly. Moreover, we want to spread the load across frames, so objects must not update at the same time.

I've thought about decreasing the update rate for far away objects as well. It should be relatively easy to do by increasing the timer threshold depending on the distance.

[SIsilicon]

I actually implemented what @lawnjelly did. It actually seems to be a better than what's currently being done. By using a "refresh threshold". The singleton updates as many LODs as it can within the specified time. This makes it extremely scalable since the amount of timed used to process the LODs never exceeds that threshold no matter how many LODs are in a given scene.