Godot vs. Unity in 2D: Who will win?

in our last godot versus unity performance comparison we looked at relative 3d physics performance and the various optimizations that are available for both engines namely a standalone physics server for godot and dots physics for unity [Music] [Applause] well if you haven't yet watched my last videos on 3d performance go watch them now but godot was a little bit slower in 3d physics all right a lot slower in 3d physics but wait you say i've received dozens of emails from you asking to compare unity2d to godot 2d in physics performance many of you stating that godot is better optimized for 2d games in physics than unity is this really true in this video we are going to compare the 2d physics performance between unity and godot 2d performance in a game engine is often overshadowed by 3d performance but there are many game genres where 2d physics performance is critical many indie games take the 2d route rather than dealing with 3d a popular genre are bullet hell games at any given time you may have several hundred or even in some cases thousands of 2d physics objects on screen at once sometimes they need to collide with each other and at other times we only care about collisions between the bullets and the player or objects in the scene regardless we are going to push both godot and unity to its breaking point and find out how many simultaneous 2d physics objects and interactions each engine can handle before breaking down so the first thing we need to do is set the godot physics frame rate to 50 hertz to match unity's fixed physics time step so that we can have an apple to apple's comparison and we're off we're running a 50 hertz physics frame rate with no optimizations all the physics objects are instantiated as nodes on the scene tree and no special considerations for batching the draw calls are being made this is the simplest and most naive implementation that one could write let's see how many 2d physics objects godot can handle before dropping below 10fps [Music] and at 50 hertz godot was able to handle 1517 objects on screen but you may have noticed a problem if we zoom in it becomes obvious that there's a lot of interpenetration between the objects what's going on on github we find issue 2092 which identifies the problem godot has with overlapping and shaking rigid body 2ds at low physics frame rates one of the workarounds offered was setting the physics rate to 180 hertz i found other commenters who said that most of the inter penetration went away at 140 hertz and above with the downside being higher cpu usage to maintain such a frame rate i found that setting the physics rate to 100 hertz fixed most of the jittering for me so let's try it again at 100 hertz and here we are at 120 hertz with no optimizations i've also lowered the time between spawns to speed things up a bit let's see how many 2d boxes godot can handle with no special optimizations before it breaks down and finally godot breaks down and drops below 15 fps at 1822 boxes but can we do better just notice all those nodes being placed on the scene tree we potentially have overhead from thousands of nodes could this be slowing things down let's try using a physics server to handle the 2d physics objects without having to have the nodes populate the scene tree while we're at it let's use multi meshes to optimize the draw calls the godot documentation even suggests that when handling large numbers of 2d rigid bodies you should consider using a physics 2d server to optimize your game here we are running the physics 2d server version with multi-threaded 2d physics and multi-meshes drawing the sprites this should give us the best case performance figures so that we can compare with unity and we drop below 15 fps at 1993 boxes we gained about 170 more physics objects on screen with our performance optimizations for completeness let's see what effect if any a circle collision shape has on the performance when compared to a rectangle shape using the same optimizations in godot and we can clearly see that a circle collision shape barely has any performance ramifications managing 1952 objects versus 1993 for a rectangle shape now let's compare this to unity so let's recap where we are right now godot uses a proprietary physics engine known as godot physics for 2d collisions we found that at physics rates less than 120 hertz there's an issue with having large stacks of physics objects and godot that causes inner penetration and a performance drop we had to raise the physics rate to 120 hertz to work around this issue in godot at the cost of some more cpu cycles we also saw that the overhead of the nodes in the scene tree in godot has a minimal but measurable impact on performance by rewriting the code to use a physics server and multi-meshes we gain a little less than 10 in performance in our benchmark godot is able to simultaneously display 1729 boxes at 50 hertz and 1993 boxes at 120 hertz physics rates it's likely the lower performance we see at 50 hertz is due to all the inner penetrations caused by an issue with godot physics before we take a look at unity pause the video and write your predictions in the comments below unity was able to outperform godot and 3d physics by an order of magnitude do you think the same will hold for 2d will box 2d physics and unity outperform godot physics in 2d if so by how much comment below so here is unity at 50 hertz immediately you can notice that box 2d does not suffer from the same inter penetration issue at lower physics rates that godot does in the end at 50 hertz unity is able to manage 1895 physics objects 166 more than godot but the boxes appear a bit squishy at this low physics rate let's push it to 120 hertz and see how unity does amazingly unity struggles much more than godot at 120 hertz and eventually taps out at 1 150 physics objects this is 843 fewer 2d physics objects than godot is able to handle incredible are these the results you expected and here are all four benchmark runs simultaneously on the top row we have the 50 hertz runs with godot on the left and unity on the right and the bottom row are the 120 hertz runs with godot again on the left and unity on the right [Music] what's immediately noticeable is the bug that affects the godot 50 hertz run i wonder how much faster godot at 50 hertz would be if this bug were fixed fortunately the github issue has it slated to be fixed in godot 4.0 let's hope it gets back ported into godot 3. [Music] here are the final results godot is almost 60 faster than unity at 120 hertz physics frame rates unfortunately due to a bug in godot physics 2d our 50 hertz results are worse than otherwise expected i would expect the doe to significantly outperform unity at 50 hertz in scenarios where large amounts of physics objects are not stacked on top of each other this means most bullet hell type games could benefit from a lower physics frame rate in godot without having to worry about the bug while performing better than unity i hope you enjoyed this quick dive into 2d physics performance on these two awesome game engines if so please like and subscribe so i can keep developing new content for you

Channel: Mean Gene Hacks

Views: 98,979

Keywords: godot, unity, performance, 2d

Id: GPgkW0h4r1k

Length: 10min 25sec (625 seconds)

Published: Tue Aug 03 2021

Reddit Comments

[u/InSight89]

Had no idea Unity was that bad at 2D physics. Curious to know why it's so much worse than 3D physics given 3D physics requires a lot more computationally intensive calculations.

Might also be worthwhile checking out Unity's 2D physics using DOTS. I haven't tried testing 2D physics myself with DOTS but I did manage to get 200,000 sprites moving around with playable framerates.

Regardless. Just goes to show that Godot is quite capable when it comes to 2D. Here's hoping Godot 4.0 proves competitively capable when it comes to 3D.

[u/Jeremy_Thursday]

Always love comparisons like this, thanks!

[u/golddotasksquestions]

Unexpected.

Good stuff! More of these please!

[u/my_lesbian_sister_gf]

Interesting results, i always knew unit was shit with 2d physics and always found to be hell to work in 2d with it, but i didnt knew godot was so much better in that regard

[u/merouses]

Oooh thats a very interesting comparison! Im curious actually if unity has a same problem I found in godot's physics though, if you have a great number of rigidBodies that don't actually collide with each other in their collision layer/masks, you still take a performance hit if many of them overlap each other. I was doing a bullet hell tool and when I ditched rigid bodies to implement my own physics or use the physics server I actually gained performance in this case, managing around 2200 bodies VS ~1800 (iirc) prior to the change.

[u/xix_xeaon]

So basically, Godot has similar 2D and 3D physics performance: 1500 - 2000 squares/cubes at most. 2D is a bit more performant but clearly something other than the third dimension is limiting performance. (And 2D requires more than double frame rate (120hz) to even work.)

Unity has similar performance to Godot for 2D - except it actually works at 50hz. But for 3D it handles up to 7000 - 8000 cubes inside the editor. Why does it not simply use the 3D physics and locks the third dimension? Who knows.

If Godot fixes the interpenetration bug it might be able to compete with Unity for 2D, only because Unity hasn't been bothered to optimize 2D anywhere near what they could.