Bulk Animation process questions

Question

I'm creating a bullet-hell type of game and I am trying to optimize the basic enemies at most cause those will be present by the hundreds in the screen.

I had noticed that changing the animation from process to physics process had a great impact on performance, from my understanding it's because 1000 calls to process to animate was slowing down the FPS thus changing to a fixed 60 ticks per second process had a positive impact on the fps.

Following this logic I started to wonder about the possibility to set the animation of those entities to a process happening for example 24 ticks every second because the enemy animation does not impact any hitbox or physics process, it's just an mesh animation that would work fine being updated 24 times per second.

So my question consists in:

• Should I create a custom process like the physics process that runs 24 times per second instead of 60 of the physics?
• Can I achieve a similar result in any other way?

Woolridge

Answer 1

How did you determine how many _process() calls you get per second?
How do you update your mesh animations? To speed it up, set thing in a way that delegates as much per-frame work as possible to native code.

Quipster

Answer 2

I did not quantify the calls of _process but by its definition it is called as often as possible instead of a fixed rate like the _physics_process, its from what i understood from the docs:
https://docs.godotengine.org/en/stable/tutorials/scripting/idle_and_physics_processing.html

And when i had a fps issue spawning many entities with a Animation Player i tried changing it to _physics_process and had a positive impact on the fps.

So i simply changed the Animation Player process type to physics_process and called animation_player.play("animation_name") on ready.

And i've noticed that you can set it to Manual, using advance() to go further the animation.

So i was trying to think in a way that i could have a loop called in a fixed rate for example 24 ticks per sec and in this loop call the advance() method to update the animation.

Woolridge

Answer 3

The worst thing you can do is to set AP's process mode to manual because in that case you need to run a script that calls advance() every frame. Ideally you'd want to completely eliminate the need for _proces() or _physics_process() callbacks in your scripts.

Second thing, idle processing (and consequently _process()) will typically run every frame, so limit your frame rate to that of the refresh rate of the monitor by enabling vsync in project settings. This is enabled by default.

So if vsync is enabled and AP's process mode is set to idle, the native code will update the animation in sync with monitor's refresh rate (typically 60 fps). If you want to lower this, set the mode to physics and lower the physics tick rate in the project settings to whatever rate you wish to have. Note that all physics stuff in your project will then run at that rate.

The gist is, doing stuff from script process callbacks is the least performant way to update.

Quipster

Answer 4

in sync with monitor's refresh rate (typically 60 fps).

As the owner of the 240 Hz monitor, this is painful for me to read. 😿

The question arises — is there any sense in testing the game's workability at different monitor frequencies?

Can I achieve a similar result in any other way?

If you are confused about physics performance, you can try alternative physics models:

1. Bullet
2. Jolt

Or you may find this article helpful Animating thousands of objects.

Anchusin

Answer 5

As the owner of the 240 Hz monitor, this is painful for me to read

That's why they decoupled physics tick from frame rate, so simulations can be run at lower temporal resolutions.

Quipster