Comparing 3D Performance of Godot and Unity Game Engine
Вставка
- Опубліковано 26 вер 2023
- 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. - Розваги
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.
Who is going to code their project in c++
@@mikhailhumphries not the entire project but only that part that needs the max performance
@@illya_ikeC# performs very well
@@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
@@mikhailhumphries C++ developers. It's not exactly a niche language.
One thing to note is, statically typed gdscipt can double its performance over dynamic
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
to be more fair I think you should add a multimesh test for Godot
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.
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
Very cool! Would love to see how animations or vfx affect performance with each of these engines!
Hi guys, like a lot of you asked here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
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
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.
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.
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
Awesome. Going to check it out. Thanks for doing these. @@SmartPenguins
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.
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.
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!
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
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!
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?
Thanks, I did the transform catch change and I got around 10% improvement and also here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
What about larger lands and loading them for performance?
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
Physics servers don't do much
I have not done any tests with RenderingServer but here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
What if I use Rust? for hardcore stuff, than it will be probably 2x Unity C#?
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.
Yeah I'd be interested to see if the Godot version is using MulteshInstance3D or not, and likewise whatever the equivalent is in Unity.
@@sligit Indeed, need ECS vs Multimesh (GPU)
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
@@SmartPenguins Awesome, great job on doing that thankyou.
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)
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.
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.
@@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
@@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.
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.
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
In his very first performance comparison video, he covered that hes comparing the exborted project, not the editor run version.
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
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
Godot with Jolt Physics would improve the performance ?
physics yes.
Jolt is about 5x faster than default godot physics, the lead dev said they will be making jolt the default soon
Knew jolt is good, but where do you got that 5x?@@digiross7199
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.
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)
Didn't have any luck with improving performance by enabling multi-threading but here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
Would be interested in seeing godot c# + flecs
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.
yeah, they have no any problems to utilize multiple threads, but you should do it by yourself in many cases.
Blender has benchmarks, would love to see one for godot
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.
It would be very interesting to see comparison of Godot ECS (Godex, or any other) vs Unity ECS.
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.
For optimization on 3D, 4.1 is actually faster than 3.5 in most cases.
Finally!
you should do c++ with server as someone said in the comments, to be more fair with ecs
I have not done tests with c++ but here is the Godot MultiMesh Update which compares with ECS a little better: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
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!
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 UA-camr would be up to that.
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.
Theres also MulteshInstance3D in Godot, this way we could see the diff in perfomance using GPUs in both engines.
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
Please compare Unreal c++ vs bp vs unity/godot
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.
Yes this test is unfair.
@@Afreshio I don't think it's unfair, it's just missing a counterpart to Unity using ECS IMO
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
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.
Yes, I missed that one. With that change it runs around 10% faster, thanks for pointing that out!
Wow. Godot is naturally entertaining the unity!
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.
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?
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.
@saul8510 nobody going to use c++ for their project
@@mikhailhumphries Why if that improves performance, no gc etc. If they know it , why not?
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.
Badly aged, multimesh are close, so aged like milk.
Unity OOP code is heavily unoptimized tho
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.
Here is the Godot MultiMesh Update: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
I don't think we can create a complex and massive 3D MMO like V Rising with Godot
Or author need to use all of Godot tools to compare it right!
@@yourmajesty9025 No DOTS in Godot
@@containedhurricane Godot has c++
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.
godex: i'm joke for u?
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.
Here is the Godot MultiMesh Update which compares little better to ECS: ua-cam.com/video/6BVoy7kOFxY/v-deo.html
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
it looks like godot isn't quite ready for primetime just yet, but I have faith in the devs to fix that
3:03 checked godot's lowest, but for unity showed mid performance point. nice
First 😁
Not really 😅
He is the first. @@yourmajesty9025
What I know for sure is they are terrible on switch. And surprisingly unreal is great on it.
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.
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.
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.
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.
This is not actual 3D test.
What would be a good 3D test?
This kind of tests are not very smart
why?
Agreed, we often see "comparison" done in the stupidest way.
@@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.
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.
It's funny Godot in their documentation have a "Animating thousands of fish with MultiMeshInstance3D"
Wow, this guy is pretty clueless.