Comparing 3D Performance of Godot and Unity Game Engine

Ran a 3D test of my bee scene to see how Godot game engine runs.
This is the same test as I ran on Unity and Godot GDScript and C# not to long ago.

License code: SQGEJNRPSSMDMULN

Smart Penguins occasionally links to goods or services offered by vendors. Some of these may be affiliate links, meaning we earn a small commission if items are purchased. As Amazon Associate, we earn from qualifying purchases.

[krichgt]

One thing to note is, statically typed gdscipt can double its performance over dynamic

[illya_ike]

I think we should also test pure rendering performance of each engine. Most games don't really need to update thousands of objects from C# code, btw in Godot you can also use C++ for that. But every game definitely needs to render thousands if not millions of polygons with lights, shadows, textures, etc. I.e. create thousands of sphere meshes in a scene, and create camera movement around the scene, but don't attach any update script to each sphere. And we can tun on/off light, shadows, fog, etc - to see how optimized rendering engine itself.

[dmaz]

to be more fair I think you should add a multimesh test for Godot

[alek]

I sort of feel like being a Unity dev, you're doing things the Unity way in Godot. First, is there multithreading enabled? Multimesh? What about C++ in Godot? I would almost rather see a Godot developer approach this problem with their experience and have you two compare results, else it feels like trying to use a screwdriver like a hammer.

[SmartPenguins]

Thanks for all the comments!

You can find the code here:

[sharkinahat]

I'm guessing the bottleneck here is actually batching. If each fish/bee is a separate draw call it will stall the gpu pretty fast. Still this might be a valuable test since most people just starting with gamedev will do exactly as shown and will have no idea where to look for performance gains.

[BanditLeader]

This test seems like a very unfair comparison. Not only did you not use multithreading in godot, but you also didnt use multimeshinstance3d (or you did and i didnt see it?). another thing to note as well, godot has a c++ gdextension, which is said to be faster than godot c#. so maybe with multithreading, mutimeshinstance3d, and c++ it would match unity ecs.

[wiipronhi]

I've been out of the loop on Unity for a few years but just looking at that code it's not optimised and will bottleneck.

if you change that code to get the transform in the start function and then access that as a member variable in the update function you'll stop wasting as much time getting the component multiple times each frame.
If you wanted to optimise it closer to what a commercial game might do you'd use a manager pattern which modifies the bee entities in a single update rather than having each be update itself, there is known overhead in the C++ side of unity invoking C# code that is avoided that way.

The other thing that people have mentioned is that you never show the material setup and whether it has batching enabled, this makes a huge difference as the high CPU usage could simply be because the CPU is waiting for the GPU to render a single bee rather than doing all the bees in a single call (which takes the same amount of time for the GPU to render). Changing this is a single check box and would be more realistic to how a game dev would utilise this engine.

On the ECS side I see similar issues, it's a lot more efficient to schedule all the bees to move in one go rather than thousands of little jobs. I've used ECS in 2020 (much older version of Unity) to move more than 100k shapes across the screen using the same lerp technique and got 300fps on a GTX 970. That was using a completely different render technique but at the same time there were simple physics calculations being performed though I'm not sure that balances out. Either way I don't see the ECS benchmark as being particularly representative either.

I don't know how realistic the Godot setup is, never really used the engine.

Could we get clarification and possibly a retest?

[Morraak]

Very cool! Would love to see how animations or vfx affect performance with each of these engines!

[thygrrr]

Uhh, why didn't you use MultiMesh3D? That's like tying Godot's arm behind its back. I still believe ECS is faster (have a lot of ECS experience, only a little Godot experience).
The sharpness issue is definitely your config, but I don't know what your nodes/textures look like. Godot makes some "special" assumptions about filters and scaling.
Also you can potentially use the new Godot 4.x multi threading. (easier to enable than installing Unity ECS)

[alm]

Ive switched to Godot from Unity in the last week. Godot is fantastic and the switch has been seamless. Ill have to start a project from scratch but i can see myself completing it in Godot whereas Unity development had me sweating and brain fogged!

[monicaguerrero]

Godot with Jolt Physics would improve the performance ?

[mdakin]

One thing I noticed is that the code that calculates the bees position involves is relatively heavy, hypothetically after a certain amount of objects this loop could get really hot and small differences in the implementations could start messing up the numbers. What I can suggest is that find a very simple coordinate calculation method to see the performance of the engine itself as well (e.g. a linear bouncing at walls type of algorithm)

[Spartan]

Yeah as point out before, this feels and sounds too much like bruteforcing the way of Unity into Godot, while conceptual things carry over, if you want performance, you need to use the Godot things to accomplish it, like comparing it to Unity ECS isn't exactly fair when Godot has a bunch of systems to match (in fact because of the lack of dotnet runtime and efficiency of memory, you could theoretically beat the ECS with Godot using GDExtensions) the ECS if you do it right.

[TackerTacker]

Now try to get as much performance as possible out of both 2D and 3D examples and see which one wins if you don't do it the "lazy" way.
I mean you are using ECS for Unity, for Godot you could use C++, Godot also has MultiMeshes 2D & 3D which are exactly for the purpose of drawing large amounts of objects.

[markog]

Good comparison :) I saw before that typed gdscript is faster then non typed gdscript, so for te next comparison, would be great if you use typed gdscript :D

[BkKaranja]

Great Job! Is it possible to do the same tests using the Godot Servers like the RenderingServer or PhysicsServer. I think this would really make a difference for Godot but might not ultimately match up to ECS

[robotacid]

What's the difference between a Mono and IL2CPP build with Unity though? The behaviour of IL2CPP is quite different, given that in Mono floats are actually upcasted to doubles during maths operations.

[BatmanASB]

According to the Godot community, for performance critical logic you can rewrite a script in C++. I'd love to see how that compares against all of these results.

[bonecircuit]

Blender has benchmarks, would love to see one for godot