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.
Unity source code: github.com/smartpenguins/BeeT...
Godot source code: github.com/smartpenguins/BeeT...
You can download the executables here: www.patreon.com/posts/bee-tes...
Here is the video on Unity vs Godot C#: • Godot C# vs Unity C# a...
Here is the video on Unity vs Godot GDScript: • Comparing Performance ...
Support this Channel: / smartpenguins
My PC Build: www.amazon.com/hz/wishlist/ls...
Discord: / discord
Facebook: / smartpenguinsio
Twitter: / smartpenguinsio
Instagram: / smartpenguins
Music by: Bensound.com/royalty-free-music
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.

[@krichgt6996]

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

[@SmartPenguins]

Good point, I just tested for 10k bees and I got: 80fps for c# 65fps for gdscript with statically typed 55fps for gdscript with dynamically typed

[@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.

[@mikhailhumphries]

Who is going to code their project in c++

[@illya_ike]

@@mikhailhumphries not the entire project but only that part that needs the max performance

[@obinnaokafor6252]

​@@illya_ikeC# performs very well

[@honza970]

​​@@obinnaokafor6252Sure, but imagine a game like Vampire Survivars in late stages, where you can't see floor because everything is covered by many layers of bullets monsters and scores. That's a lot of objects. It might be worth investing into C++ for that 50%-100% boost

[@not_ever]

@@mikhailhumphries C++ developers. It's not exactly a niche language.

[@SmartPenguins]

Hi guys, like a lot of you asked here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs Thanks for all the comments! You can find the code here: Unity source code: github.com/smartpenguins/BeeTestsUnity Godot source code: github.com/smartpenguins/BeeTestsGodot

[@dmaz123]

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

[@dancovich]

Was about to say that. This use case is perfect for MultiMeshInstance2D and MultiMeshInstance3D. I would like to see how that compares to the ECS example as that is basically the spirit of this optimization - having a single job that iterates over all instances.

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@Morraak]

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

[@alek2341]

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.

[@rameynoodles152]

personally, i think he's doing a pretty fair comparison. I say this as a Godot dev thats never used Unity. Sure, there are definitely things you can do to get better performance out of Godot, but the "naive" approach is still pretty fair. I think the biggest thing he's missing is making something in Godot to more evenly compare with ECS. In Godot the scene tree is quite unomptimized still, and using the barebones Servers instead of the Scene Tree can yield a TON of performance gains, at the cost of code complexity.

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@alek2341]

Awesome. Going to check it out. Thanks for doing these. @@SmartPenguins

[@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.

[@TheIronicRaven]

I didn't know Godot has multithreading! I just started using it 2 weeks ago (we all know why) so glad to hear it can do that!

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@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?

[@SmartPenguins]

Thanks, I did the transform catch change and I got around 10% improvement and also here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@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.

[@alm5966]

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!

[@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)

[@SmartPenguins]

Didn't have any luck with improving performance by enabling multi-threading but here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@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.

[@sligit]

Yeah I'd be interested to see if the Godot version is using MulteshInstance3D or not, and likewise whatever the equivalent is in Unity.

[@chinering23]

@@sligit Indeed, need ECS vs Multimesh (GPU)

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@chinering23]

​@@SmartPenguins ​Awesome, great job on doing that thankyou.

[@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

[@mikhailhumphries]

Physics servers don't do much

[@SmartPenguins]

I have not done any tests with RenderingServer but here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@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)

[@marko95g]

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

[@SmartPenguins]

Yes, I got almost 20% faster results with typed then non typed: 80fps for c# 65fps for gdscript with statically typed 55fps for gdscript with dynamically typed

[@monicaguerrero7748]

Godot with Jolt Physics would improve the performance ?

[@saul8510]

physics yes.

[@digiross7199]

Jolt is about 5x faster than default godot physics, the lead dev said they will be making jolt the default soon

[@saulsantos4132]

Knew jolt is good, but where do you got that 5x?@@digiross7199

[@skaruts]

It wouldn't. First because he's not using any physics. He's just moving the bees toward points. So there's nothing Jolt could do to improve it. But then also because the physics are usually not the bottleneck. In this case the bottleneck is probably the rendering (or GDScript's speed). If it's the rendering, what could help is using MultiMeshInstances, and an overseer class to handle all the bees, rather than each bee handling itself.

[@Rogueixpresents]

What about larger lands and loading them for performance?

[@kennethferland5579]

CPU bottlenecking may be due to differences in how random is implemented in engines. Recomend you call 2 random points for each object when it is created and then travel between them which will eliminate the repeated calls to random and give a more pure rendering test.

[@indierusty]

What if I use Rust? for hardcore stuff, than it will be probably 2x Unity C#?

[@FinaISpartan]

Would be interested in seeing godot c# + flecs

[@bonecircuit9123]

Blender has benchmarks, would love to see one for godot

[@hatiko8227]

It would be very interesting to see comparison of Godot ECS (Godex, or any other) vs Unity ECS.

[@muuubiee]

Hm. Is there no easy way to do multi-threading in godot? Since the logic is so simple, this would be very simple to do this parallelized. Although, since everything is so simple (only a few bytes of data per object/entity, the cache should have no problem pre-fetching this for either), you wouldn't expect much of a difference between ECS/DOD and OOP.

[@yuryzhuravlev2312]

yeah, they have no any problems to utilize multiple threads, but you should do it by yourself in many cases.

[@illya_ike]

I'm wondering if it will change something if you have one C# script in the root node with a loop that updates all bees instead of having C# script attached to every bee node. Also I hope Godot project is exported to a binary - not run from the editor.

[@user-gv3kr6uf7g]

Ofc it will 100%, every script is a call, the tricky thing is if your loop is super big than it would freeze, better way is to have one array of objects and one script to modify transorms, but execution is split in several consecutive frames

[@rameynoodles152]

In his very first performance comparison video, he covered that hes comparing the exborted project, not the editor run version.

[@npatch]

Question for the ECS, I haven't worked with it a lot, but it seems to me that there are component versions for both 2D and 3D stuff which auto-convert. That said, is this project doing this auto-conversion, or is it just using Jobs to transform the objects? Because it's not apparent.

[@npatch]

Seems like SpriteRenderers are not supported by Entities Graphics, so technically you don't use ECS or at least not fully. Not sure how this works. You are either using Jobs api on its own wtihout Entities, or if you are using Entities, it's only for half the stuff. Which makes sense why ECS with 3D is very performant.

[@wiipronhi]

@@npatch you can use the Jobs API without entities but I don't think that was happening here because the result was never collected to be put back into the monobheaviour transform. I don't think enough was shown to get a good idea of what the project setup looked like

[@npatch]

@@wiipronhi I know you can use Jobs without Entities, I've done so before. I just haven't used Entities enough to recognize if it's done properly or not. I agree with the latter though. So long as there's not a github link we can't truly know. Still, it would make sense if the 2D "ECS" still did not perform well, seeing as the rendering part is not supported.

[@yuryzhuravlev2312]

Official soluton from Godot devs to replace ECS it's implement a few hot function in C++ or Rust. Please make this test as well it's should be very interesting! Thanks!

[@saul8510]

you should do c++ with server as someone said in the comments, to be more fair with ecs

[@SmartPenguins]

I have not done tests with c++ but here is the Godot MultiMesh Update which compares with ECS a little better: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@borob.5168]

Which Godot did you use? 4.1.1 or 3.5.3? Cause 4.1.1's 3D engine is still in sort of an alpha state. However, 3.5.3 is more stable.

[@Cadaverine1990]

For optimization on 3D, 4.1 is actually faster than 3.5 in most cases.

[@yourmajesty9025]

Finally!

[@vast634]

I dont know if those results can be extrapolated to actual games, where many more meshes, textures and behaviors are running at he same time. And an optimized detail does not have so much impact. It would be interesting to make a more realistic "playground" representing many 3D games, with lets say 40 different PBR textured assets (random free game assets) in a more complex imported 3D level mesh, some of them running physics, and a few agents using a nav mesh and running skeletal bone animation. A shadow casting sun. And then in ACES color space and some common post processing like bloom and AO on top. The camera flying in a circle around to test things like culling. I think the average FPS would be more representative of actual 3D game performance. It could even be extended to setting up the same scene in Unreal. Maybe some KZbinr would be up to that.

[@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.

[@Afreshio]

Yes this test is unfair.

[@TackerTacker]

@@Afreshio I don't think it's unfair, it's just missing a counterpart to Unity using ECS IMO

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@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.

[@Afreshio]

Theres also MulteshInstance3D in Godot, this way we could see the diff in perfomance using GPUs in both engines.

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@Pix256]

Please compare Unreal c++ vs bp vs unity/godot

[@spam.stuff.things]

You would get better Unity C# script if you would optimize the code. The most basic thing: do not access a property multiple times inside a body of a method. For this purpose you can cache the bees transform for entire class.

[@SmartPenguins]

Yes, I missed that one. With that change it runs around 10% faster, thanks for pointing that out!

[@GeorgeNoiseless]

The power of Data Oriented Design! Not a surprising result and one that can hopefully be improved on Godot's side by an introduction of an ECS of their own. There seems to be a Community script (Godot-Stuff ECS) to that effect, although it allegedly doesn't focus on performance. Worth a test?

[@saul8510]

godot core uses DOD in it servers, and it proven that godot c# is more performant than unity c# , it just beaten by ECS , and also he didn't try on c++ with gdextension and servers.

[@mikhailhumphries]

​@saul8510 nobody going to use c++ for their project

[@saulsantos4132]

@@mikhailhumphries Why if that improves performance, no gc etc. If they know it , why not?

[@rameynoodles152]

From what I understand, the Godot "ECS" is to bypass the scene tree system and use the underlying servers. The scene tree is currently a large bottleneck.

[@saulsantos4132]

Badly aged, multimesh are close, so aged like milk.

[@lee1davis1]

Wow. Godot is naturally entertaining the unity!

[@petersmythe6462]

Crazy that Unity visual scripting lags with 100 entities. That's really some script performance. Scratch runs at a native frame rate of 30 instead of 60, but I wonder if even Scratch has that bad performance.

[@Spartan322]

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.

[@SmartPenguins]

Here is the Godot MultiMesh Update: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@Bankoru]

Unity OOP code is heavily unoptimized tho

[@mrkcur]

Do be honest, I don’t care about this kind of test of many instances of the same object. Of course ECS will crush this test, it’s a perfect use case. But ECS isn’t actually very useful in practice. I mean, it’s nice if are making an RTS game but I am not. I tried implementing ECS in my last game and ended up reverting everything because there was almost no benefit. It only made the code harder to work with.

[@containedhurricane]

I don't think we can create a complex and massive 3D MMO like V Rising with Godot

[@yourmajesty9025]

Or author need to use all of Godot tools to compare it right!

[@containedhurricane]

@@yourmajesty9025 No DOTS in Godot

[@yourmajesty9025]

@@containedhurricane Godot has c++

[@rafae5902]

Thanks for redoing it! It makes NO SENSE for Godot to better than Unity, specially in 3D. The tests you did before were kinda pointless, as you were comparing Unity's 3D rendering to Godot's 2D rendering. I expected Godot's 3D to be much slower. Doing this kind of tests with Stride engine would interesting.

[@SmartPenguins]

Here is the Godot MultiMesh Update which compares little better to ECS: kzbin.info/www/bejne/bHO5oKxtoLR5rrs

[@jaddd]

unity more good in 2d and 3d godot have big problem in textures every texture in game game will be slow u should make all ur object in one or 2 texture and that not ok for a game

[@the-guy-beyond-the-socket]

3:03 checked godot's lowest, but for unity showed mid performance point. nice

[@KENISEG]

godex: i'm joke for u?

[@joshua42777]

it looks like godot isn't quite ready for primetime just yet, but I have faith in the devs to fix that

[@chrismcpherson7582]

These tests are extremely misleading and IMO I think you should take the advice give by the comments here and remake these videos using the new information Youre not actually doing it the right way. You're ignoring Multimesh rendering and thats like a slap in the face to see these graphs when i know full well how wrong they are. You taking advantage of Unity ECS but making Godot perform worse on purpose by not doing it the way it should be done Not hating you in anyway, i respect the science here but I think you should have done a bit more research before making this video.

[@SmartPenguins]

Yes, I know, I have not made anything in Godot yet to make a fair comparison with Unity ECS. I'll try set that up when I have time.

[@rameynoodles152]

In addition to MultiMeshes like many have said, I think you need to look into "Server Optimization" (search that in Godot Docs). Server Optimization might be a more direct replacement for ECS.

[@RiccardoBocci]

What I know for sure is they are terrible on switch. And surprisingly unreal is great on it.

[@ghostweas]

First 😁

[@yourmajesty9025]

Not really 😅

[@saulsantos4132]

He is the first. @@yourmajesty9025

[@skilletborne]

Ah, so this is what people mean that Godot has bad performance Absolute nonsense XD In what situation will there be anywhere near that many scripted objects in a scene at a time???? Barely even warrants optimization.

[@WyMustIGo]

Wow, this guy is pretty clueless.

[@gameprogramming6550]

This is not actual 3D test.

[@SmartPenguins]

What would be a good 3D test?

[@rumariomusic]

This kind of tests are not very smart

[@zxc13x]

why?

[@hipflipped]

Agreed, we often see "comparison" done in the stupidest way.

[@stasanisimov1387]

@@zxc13x because if you need to visualize a bunch of bees, you wouldn't be running 10000 monobehaviours in unity, coz it would be stupid, and you would be using multimesh/instanced mesh/whatever it's called in godot. Both engines have their ways to optimize a task like that. I mean, you could just unity particles for that, and unity is capable of rendering at least tens of thousands of particles on mobile, probably hundreds of thousands on pc.

[@chinering23]

GODOT: MultiMesh provides low-level mesh instancing. Drawing thousands of MeshInstance3D nodes can be slow, since each object is submitted to the GPU then drawn individually. MultiMesh is much faster as it can draw thousands of instances with a single draw call, resulting in less API overhead.

[@chinering23]

It's funny Godot in their documentation have a "Animating thousands of fish with MultiMeshInstance3D"