This is a stress test of a project I've been working on for a good few years now, thanks a bunch to the Godot community, you guys answering my questions about navmesh and rotation/vector maths has been particularly helpful. I've been converting everything over from Unity to Godot and I'm now almost at the point where I can start really showing off the mechanics but easily the most fascinating thing so far has been doing the stress tests. I have been really impressed with Godot's performance so far but of course I'll need to do more setting up with my other mechanics and start having proper playtesting sessions đŸ™‚ Unity was something that would struggle a lot with their equivalent of 3D labels/sprites and it would lag like crazy for some reason so I had to write code to adjust for that. Hopefully I'm not getting excited too soon but it seems that I may not have to worry too much about that in Godot but I will give people the option of hiding my 3D villager statuses so it doesn't get in the way if people don't want to see it.

https://odysee.com/@Lethn:3/By-the-gods-100-villager-stress-test:7?r=9uVBCUZNktJFSny4AurVAhURKecvDwFD

If you guys have specific questions about what I'm up to feel free to ask, I'm going to also be looking at doing a proper write up for how to set all of this up because boy is Godot a fussy creature when it comes to navmesh baking and agents.

The main premise of the game is you are simply a God and you use your hand to interact with everything within the game world within your influence, expand villages by building houses and your influence will expand as well. You then capture other villages by impressing the villagers in them doing good/evil actions.

Lethn What are the results of the stress test? In my opinion, 100 such characters should not stress the comp. There seems to be a very simple collision, if I'm not mistaken. A thousand would have been questionable…

    Tomcat Interesting you should mention that, when I started going 300+ Godot immediately started chugging, I'm going to be exploring multi-threading for optimisation, alternatively I may need to revisit how I'm executing the code.

    I think for retro graphics like that you should be able to have a few hundred characters (or more on a higher end system).

    The issue is likely the transparent box (or text, depending on how you are rendering it) and/or the debug line drawing.

      I'll experiment with that today thanks, it's interesting how so instantly there's a performance drop with Godot, worse comes to worse I can stick with my original plan and keep all of the 3D Labels/Sprites disabled and have them enable only when you mouse over the villager one at a time.

      Unfortunately hiding my status windows entirely didn't make a difference to performance, looks like I'm going to have to look at implementing multi-threading, it is worth pointing out that while I kept the poly count very low for these villager models they do have 20 something animations in stock and they're all playing a walking animation at the moment constantly.

      I don't think it has anything to do with the poly count or graphics, because that looks like a fairly light load.

      If it wasn't the transparency, it may be the skinning on the characters. I'm not sure if this is on the CPU or GPU, you might have to check that.

        cybereality Would you mind explaining how to check that or pointing me the right way? Very new to optimisation and such because I've been just specifically studying navmesh on Godot since that was annoying me the most đŸ˜ƒ I've seen the profiler which looks interesting and helpful but that's about it.

        https://docs.godotengine.org/en/stable/tutorials/performance/gpu_optimization.html

        It has something to do with this, but to be honest I'm not exactly sure how it works.

        https://github.com/godotengine/godot/pull/40313

        It may be that 100 characters is too much for Godot, as I have not tested it specifically. But a good PC should be able to handle it (like in other engines).

        I haven't done enough character work to tell you the steps specifically.

        Interesting, since you mentioned draw calls specifically I had a look at the debugging stuff in Godot again while it was running, I'm getting about 3fps - 4fps with this setup.

        extra info on my hardware for reference:

        CPU: Ryzen 5 2600
        GPU: Nvidia Asus 1660 Super 8gb
        RAM: 16gb

        I may need to have a look at tweaking view distance among other things as well and poke at the LOD settings now because I bet that will have a fairly dramatic effect.

        4,600 draw calls sounds crazy, that scene does not look that complex.

        So it looks like there is a material change for each object drawn, which doesn't sound right. The terrain should only be a few materials (depending on how you broke it up) but the characters all look identical and should be able to share resources.

        You can try using instancing, but I am not sure if that works with animation, or if they need to be playing the same frame. But 500 material switches for that scene is way too much.

        Baffling, may need to have you guys take a look at my local villager hierarchy and see if anything could be setting if off in that case, you're right though that the villagers themselves aren't complex and neither is the landscape that I've made so I'm going to have to do some digging to see where I've potentially gone wrong.

        A bit random as well but part of why I switched this project over from Unity to Godot is it will be a great case study of how to do a fairly sizeable game in Godot so I'm of course trying to document everything and post up my progress as much as possible. This should also show people what Godot is capable of and we can really put the engine through it's paces rather than have people potentially ignorantly snubbing it because it's mostly only been used for small 2D games so far.

        So polygon count is not really a problem anymore. You can easily draw millions or tens of millions of polys, even on budget hardware.

        It's mostly down to shader complexity and material switching. If you are using the standard material, then the shader should not be an issue. But having too many materials, is a huge problem.

        Because the objects have to be batched by material, to minimize the state changes, and that way multiple objects can be drawn in one draw call. So the material switches and draw calls are somewhat related.

        I'm not sure how Godot handles it, especially if each character has multiple objects and/or materials inside. But I have to imagine they thought about this, and there is some way to optimize it.

        I've just never got that far with animated meshes, most of my work has been with static scenes, so I am not 100% sure how to do it in Godot.

        We may need to poke around and ask people who may know more on that front in that case, it's really odd though because the materials in the scene aren't that many and they're incredibly simple and low res on purpose because I wanted to try making a fairly large sandbox god game which can run on lots of hardware.