Just had a very interesting eureka moment, without the animations, the FPS jumps pretty significantly, it almost double, so it looks like that's what I'm going to have to look at optimising the most is how the animations are being played through the code, will need to have a look at these methods when I'm in a better mood for it. The animations seem to be confirmed as hitting the performance the most.

I wonder if there's something I can do about the way the navmesh is dealing with the code? I'll have to have a look at that video again myself.

So really the conclusion is that instead of doing multi-threading it would be a better idea to see if there's a way I can instance the animations that my villager has to make everything run smoother instead of the GPU trying to render everything all at once? No wonder I'm regularly hitting 30fps.

Edit: I'm also seeing that I guess having however many agents all on screen at once will mean that it's simply not possible to play the game above 60fps except if someone happens to have a really powerful PC which is interesting, will have to look at how much I can tweak things.

    MartinSenges Maybe there's also a need to swap out a crowd villager entity with an individual villager entity during gameplay (and back of course).

    That would be my first go-to as a solution to try for this.

    Lethn So really the conclusion is that instead of doing multi-threading it would be a better idea to see if there's a way I can instance the animations that my villager has to make everything run smoother instead of the GPU trying to render everything all at once? No wonder I'm regularly hitting 30fps.

    So don't play bone animations for any characters that aren't visible to the player at all. Pause the animation playback. This might not even be limited to characters outside the view frustum but also characters simply too far to be clearly discernible on screen. Also characters sufficiently far away from the camera/player vision can probably utilize lower FPS animations. Less bones per skeleton should be less demanding but also less keyframes per animation track and lower fps. Try and take advantage of a combination of these.

        Let me think more on how to actually implement all of this, would this be similar to object pooling? I have the villagers wondering about as 'background characters' almost until they're interacted with through whatever action the player takes? I think just because of the nature of this game it will probably be a performance hit no matter what I do. If for instance the player decides, yeah I'm going to set the whole village on fire the villagers will need to be interacted with as I have panicking animations and so on as well, lots to consider.

        Maybe have the villagers object pool at a certain distance like with the occlusion culling to ease off the rendering? No sense wasting processing power on something very far away the player can't interact with anyway. Just thinking about what I could do to implement this relatively quickly.

        Instant FPS jump with this method, I reckon I can squeeze more FPS out now, that's fantastic, thanks for the advice guys, the signals of the visibility notifier make it so that I don't even have to rely on any complex tagging to make sure I've got the right nodes. I will also potentially have to have a look at object pooling among other things to see if can get more going. I feel like it's worth pointing out, the villagers will die of old age naturally among other things, this scenario of mine with every village being filled with 100 villagers per village is a worse case for optimisation but I want to make sure it's all running fairly smoothly regardless and I'm aiming for a steady 60fps I think.

        At the very least I think this will be a fun game you can really push the limits on with your hardware if you really want to have a ton of villagers at once just for the lulz which I find interesting. The most basic optimisation I'll go with is a global villager count slider so that player can tweak the numbers themselves according to their PCs.

        cybereality It's a duplication of the same models with the same motion. But what's needed is individuality in a crowd.

          Yes, but you can have like 10 or 20 real characters in the front, and then fake ones in the back, people might not notice.

            cybereality An army of imposters, real sus. 🤨 But yeah, that's probably the lowest resource demand achievable I recon.

              cybereality Yes, but you can have like 10 or 20 real characters in the front, and then fake ones in the back, people might not notice.

              In Cyberpunk 2077, I believe there are more than 20 models of inhabitants, and the dubbing models are very visible. AXYZ design (anima) approach seems preferable to me. Let there are much less people (only hundreds, not thousands), but the eye will not cling to repetitive models. However, it is necessary to understand how they did it.

                Yes, Cyberpunk 2077 can have at least 100 characters, but it's still taxing, and their engine is honestly a lot more advanced than Godot.

                  I'm going to start re-implementing my game mechanics from Unity now that I've sorted out the main issues of look direction and radius based wondering so I'll start optimising based around what happens there and post some updates for you guys on the main by the gods thread.