Everyone is talking about how you should test 4.0 after it's out. Instead, you should test 3.4 soon because it has 2d performance improvements. I ran a very similar test to yours and got 1303 balls before dropping below 60 FPS in 3.3.3.. The same test in 3.4 beta 4 got 3133 balls before dropping below 60.
On a separate note, BulletHell games like the ones shown in the video don't usually use full Rigid Body Physics. They are limited to _Layered One-Way Non-Continuous Collision Detection_ with simple _Convex Collision Shapes_ . Phew! That was hard to type. But what I mean is that usually interactions between the thousands of similar objects are not relevant for this type of game. The number of physics interactions in a single frame is very low, and the cost of complex physics is also eliminated. What we do have are the potential thousands of bullets, some static level geometry and more dynamic actors such as items/props and NPCs/players. The bullets collide with everything that's not a bullet, and those tend to be just a few, very rarely reaching the hundred count.
Being a Godot person and have experienced Unity in the past, I can say that Godot is more beginner friendly, as the nodes make much more sense paired with the simple GDScript language. Also, Unity takes too many resources. I had to uninstall most of my programs before I could laggily run Unity, meanwhile Godot I could immediately install with no downsides, and actually runs smooth. Edit: It's also on Steam. (Big plus)
that's not much of a surprise tho. godot's 3d current api is pretty outdated 4.0 is gonna change quite a lot about that tho however, for 2d, it's a nobrainer nowadays. Not only performance wise, but in overall terms of practicality, functionality and workflow
Probably because the problem in 3D was not only due to the Physic Engine, but I suspect for a good part, the Renderer, especially because there is no Occlusion culling (big difference). It will be interesting to run the same test in 3D without rendering the scene to see the difference.
I wasn't that shocked. I know Box2D is very mature and so is Unity. But Unity doesn't have a dedicated 2D engine. Disappointed that Unity beat Godot in one of the tests.
For all indie devs that are watching this, please do not let this stop you from using Godot for 3D. You probably would never need that many objects anyway in your 3D game as an indie dev. Godot is alright for 3D as well. Please just know the limitations of the tool that you are using and you will be fine. Godot is objectively easier to work with than Unity. Unity on the other hand has more features out of the box, but lacks features that are required for freelance work. Godot suffers from the same issue. Also Godot developer, take a look at Silent Wolf which is extremely useful for creating Godot games with a backend. Useful for freelancing.
I use Godot for 3D, although I do need to render hundreds of thousands objects simultaneously, but luckily without physics. I use multimesh mixed with particles, so far it worked fast enough.
Glad to see that the most common advice you see about Godot vs Unity (use Godot for 2D, Unity for 3D) holds up. I hear Godot 4 intends to be a big improvement all around as well. Really looking forward to see how Godot develops
Wow this has been one of the most interesting analysis I have seen, I'm glad to see that on the 2D side, Godot is quite good, I wish that when the Godot 4 version appears, you can compare the 3D approach again
would be interested in seeing how 3d and 2d physics stacks up now, considering Godot just recently released 4.0, and DOTS just recently released fully released :)
Im like 80% sure the reason unitys boxes were so squishy is because the collision type was set to dynamic instead of continuous. Fixing that would give way different results
They fall different. The unity version is accelerating with gravity. Godot isn't. That means the formula being used to describe their motion is different. Perhaps In a way that favors godot in this example. I think it's worth investigating.
Godot's unit in 2D is pixels. I think this is not true for Unity. So he likely messed up converting the units to use the same gravity in both of them. He probably set gravity to 9.81 or something as per the usual, which in Godot would be 9.81 pixels/s^2, while in unity it is 9.81 units/s^2, where one unit spans many pixels.
Thanks for doing this. Great work. I don't think bullet hell games really suffer from the 50Hz bug though as even with massive amount of bullets, you don't get that much overlap and the bullets don't try to push each other away
People focusing only on performance to compare engines are people who never finished any game. The workflow between each engines is very different and this is mostly what pulls people towards an engine or the other. As a Unity dev for years, i’m starting to lean towards Godot for the speed of of iteration. In Godot it’s so much faster to change code and test the game.
There's an Asset for Godot which replaced the Godot physics engine with Box2D. I personally haven't tried it but I'd be curious to see a comparison a new comparison.
Great work, thank you! Would be nice to see a similar comparation between Godot and Gamemaker. I'm curious about that because, even Godot being a great engine and the developers don't have to pay to use, looks to me that developers prefer to use Gamemaker to producer commercial games (considering the quantity of successfully 2D games the engine has in comparation with Godot). Could this decision be related to performance?
Nope. Gamemaker just was better advertised so more people knew that it is better option for 2D games compared to Unity. And most people don't like to learn new things after dedicating entire career to one tool. Hence why jQuery is still alive somehow.
Gamemaker performs terrible vs. pretty much any other engine, except for maybe Construct It’s just older and more famous… and supposedly more “beginner friendly”, what nowadays isn’t even true anymore
I use Unreal Engine, so I have no horse in this particular race but I do ask myself "Is there really a winner and loser to this?". Just choose the tool that fits the job, there's plenty of room for many solutions.
That's pretty interesting. Given the 3D results, I expected the 2D results to be similar, with Unity clearly outperforming Godot, especially since Unity can handle a lot more 3D objects than it wound up being able to do in 2D.
This is why I made my own physics engine, and it beats both of those by a mile (pile of 10K circles on a single thread @ 60 Hz with ~45 FPS), and I am still using a brute-force broadphase, albeit very well optimized. I also partition the world into 256m squares so float precision won’t be a problem at huge distances, which is nice having.
Honestly surprised at how much better Godot is at high-frequency physics calculation despite how "new on the block" it is. Looking forward to its 4.0 release!
I see a number of issues with your methodology, and noticed some oddities you didn't address. I'll try to give some friendly critique for your consideration 😀 Keep up the good work! The numbers are suspiciously close to some of the 3D test results. Can you try to do something to determine if there is some other bottleneck than the physics engine itself that masks the numbers (i.e. are you sure you're measuring the right thing)? I'm suspecting the object tree most of all, and the event handling especially, since physics collisions can have event handlers (at least in Unity). Idea: keep everything the same but remove the physics completely and just do a basic movement implementation that slowly accelerates downwards until it hits a set height and then stops instantly. No collision detection. This will show if/where the game engine itself starts slowing down. The framerate drops are very inconsistent, and in one test drops from the thousands to under 10 in about one second. That smells of some kind of O(n^2) or probably worse computation reaching a breaking point, which could be due to the compounding collisions caused by all the boxes being in one big pile. If that's what you were targeting on purpose though, that's fine! But it's a bit disingenuous to judge the whole physics engine based on such a particular case, and again I'm missing comparison simulations to rule out other reasons for the drops. Idea: Instead of a bin that holds all the cubes, spawn them gradually in one direction to minimize (but not completely avoid) boxes colliding with each other. The side by side comparison shows that the boxes aren't falling at the same speed, which suggests that there's still a difference between the two test implementations that may or may not make a difference. This might be just plain scale, that the Godot scene has larger boxes but is also zoomed out more, or that there are other parameters than physics framerate that should be compared, like timescale, gravity, weight/mass, air resistance, I don't really know, just speculation. Idea: This can be tested in two ways just like you've done in the video: Change stuff in the scene (size up or down) and compare to previous results in the same game engine, and change stuff to get the two game engines to either match up all possible variables and/or to produce a visually similar simulation. This might also affect the squished and jittering boxes in the Godot 60hz test, see if making everything larger (and zooming out) gives any improvements! Last, I think the comparison to bullet hell games doesn't fit the test scenario. Bullets often have constant velocity or very simple movement logic, they don't collide with each other (usually just players, enemies and destructible s by calculating distance plus world geometry which is static), and they have no geometry (just point or circles which is very fast computationally) so a full general physics simulation is overkill and most games use or make something more specialized and optimized like a particle system. So you could make another video about that, but that's not the use case you've tested in this video 😉 Hope you find my comments useful! Looking forward to your next video 👍
Thanks for the helpful insights! I agree with your point that even bullet hell games would probably not require full physics simulation and either engine would be suitable for such a game. This comparison was mainly to satisfy my curiosity as to whether Godot's 2D could hold its own against Unity2D. You also bring up a good point about the different speed of the falling bodies in Godot vs. Unity. The physical parameters (mass, accel due to gravity, etc) were consistent between the two engines, its just Godot Physics seems to require much higher gravity to match the falling speed of Unity at 9.8 m/s^2. For this comparison, I decided to keep the variables ( gravities and masses ) the same between the two engines, which results in the objects falling slower in Godot. I also tried larger collision shapes in Godot at 50Hz and still encountered the bug with large stacks of objects interpenetrating each other. Thanks again for the comment, I'll definitely take into consideration your ideas for any future comparisons!
Just a question how using GDNative will affect the performance? Will it stay the same? Shouldn't it be used in these scenarios when you have so many rigidbodies in the scene instead of GDScript or am I wrong?
Well, he is using built in physics and GDScript only to "spawn" rigid bodies. In case if anyone will try to code own physics for KinematicBody/KinematicBody2D then using GDNative or Mono over GDScript will give you huge performance boost if done right. May be even better then built in one, if you are really skilled or compromise some accuracy in a sake of more performance.
I don't see how GDNative will help much if you are using the built-in physics engines, as I'm only using GDScript to spawn the physics object (in a physics server). I did try re-writing the spawning code in C#, but saw no performance improvement so I didn't include it in the video. One area where GDNative could help is through the integration of a different/faster physics engine.
Thanks for the great video! This was the best comparison between the two engines that I've seen. You could expand it by testing both engines physics separating them from their rendering. I think that it is possible that GodotPhysics is bottlenecked by the rendering of the engine.
If I was to make a bullet hell game, I don't think I would worry too much about 2D physics performance when choosing a game engine, because my appetite for more physics objects would run out long before the engine stops being able to keep up. The game would have to look something like your little benchmark test before it makes a difference, and you almost filled the entire screen with objects. Also, the bullet hell games you showed only used the collision detection part of the engine. You don't need to run an expensive rigid body simulation hundreds of times per second to do collision detection well.
the godot project is a solid package (editor+game engine) and you can use/mod/etc... :) ... i dont know unity, because i was triying to use it but i use linux, and the "editor" is slower, the coding is in other editor, much unnecessary config... the unity can be better in one or much more areas that godot, but godot download open and OK its ready to go... extremely easy to use, and the logic scene in scene is simply and amazing, in conclusion (for my) godot as tools is much better than unity, but (for now) unity is more powerful game engine than godot
Godot allows usage of multiple physics engines. I just read they're working on box2d support and they also have choice "godotphysics" vs "bullet" in 3d already. So things might change in future.
it is strange that unity can handle more objects in 3d than 2d. in godot I also noticed that it first mostly stays the same then slowly goes down and then suddenly starts to drop in a quadrant shape, so this might also be some bug or it might be a nice space where the physics engine can be optimized.
I wonder what is limiting the physics at some point, like after few more objects everything stops drastically, i'd expect a slower drop rate. Interesting that with Godot even with double the calculations you are reaching roughly the same results, it seems there's that drastic limit in place instead of something else (certainly with more stuff to do in a frame that double cost would impact differently). I don't know if there's something in the internal data structure that is optimized to handle some max ammounts or other conditions. Maybe some tweaking in the code to arrange larger sets is possible? Another idea would be spawn the same critical number of objects in a grid pattern without them touching at the beginning, then release them and see if collisions slow them down or the speed is the same. See if larger spacing cripple less (maybe objects fall into different spatial areas in the engine and works better?). Just some ideas i'd try.
Desculpa a pergunta, mas usar ECS na Unity não deve dar um boost de FPS? ,_, não entendo bem de ECS, mas sei q isso aí faz milagres na Unity em termo de desempenho '-'
You know, Component Based Systems have far more performance than OOP, since it handles cache and memory the right way. If I remember, Godot has even a different node for rendering multiple meshes in a better performance, which should be the default way to do it. Well Godot still misses some functionalities.
I don't have any horses in this race, just a geek who's interested in the context - but I do have to say, it really feel like the Godot boxes fell in a more natural position than the Unity ones! For example. compare 5:48 to 8:18, the Unity boxes appear to have a lot more straight lines emerging ... In fairness, I don't know what to expect from the distribution of where the boxes end up, but it's that whole thing about straight lines and nature ... Either way, thanks for the video - I found it quite fascinating!
this is still a fixed amount of physics objects, what if we preload these objects? or are these already preloaded? forget what i said in the beginning, what about preloading?
Doesn't Godot run on OpenGL and Unity on DirectX? I heard Godot is switching to Vulkan in the next major release 4.0. Will that have an effect in the performance?
@@ishdx9374 It actually does. Modern APIs like Vulkan and Direct3D 12 are supported better by AMD and Intel drivers resulting in better performance on those GPUs, and generally are designed with modern GPU's hardware in mind. OpenGL was designed for hardware from the 90s. It's most evident with DOOM 2016 where Vulkan mode runs a lot better than OpenGL but looks almost the same.
I can already tell you that for this kind of benchmark, frameworks like monogame and raylib outperform unity and Godoy by a large order of magnitude (on my pc, something like 25000 sprites for unity vs 150000 for raylib and monogame)
WHY THE FRAME DROPS SO SUDDEN? 5:45 I dont understand why its not gradually decreasing like the first test. Please somebody answer would be very appreciated!
It appears, as if, Unity has some sort of easy-in animation by default (which feels good). Possibly because the generator is with in the frame, at the top. In Godot, it feels like cubes are floating (Weight lessly) down to the bottom.
1) Godot's 2D pixel detection is terrible. Its collision detection is not good, hard to use. For whatever reason the community is working on 3D instead of 2D. 2) C# should be the default rather GD. 3) You can do anything you want with Unity. Although you can be overwhelmed with learning the engine. There is a reason why people are not releasing games with it. They were should really develop the 2D functionality of GODOT.
From your experiments I may suppose, that Godot have troubles to handle 2k objects any way. Maybe custom layout in memory while using C could help. Also if you try DOTS in Unity, you may try data oriented plugin for Godot named Godex. It's in development, but still.
I have started making games with Godot since 2 weeks, before that I tried Unity and was already put off by the TUTORIAL. The reason being that Unity (in their infinite wisdom) tried to enforce dot and comma use depending on the country (in Germany we use comma as a decimal seperator), the problem was that the built-in tutorial expected you put in a decimal number, but the engine AUTO-CORRECTED it to a comma, causing it not to detect the correct value, getting me stuck.... But that wasnt the end: I found a thread in the official Unity forum where people noticed this problem, which broke their games. There was one particular developer, who complained that this broke their custom shader and caused them to lose 3 weeks of work, because nobody noticed that Unity replaced all the dots with commas in their script, which was done at compiling time. To finally put the nail in the coffin, the Unity devs then started defending their decision, despite the outcry of everyone (and ignoring that program code should always use dots and be indepentent from what the OS uses). They however never replied to the beginner, who pointed out that this broke their tutorials for everyone from a country that uses commas as a decimal seperator... I think this took them MONTHS to finally fix.... To sum up: Unity might be more performant for 3D games, but the way Unity seems to care about their devs and how much better designed the workflow in Godot seems to be, not to mention the far better license of the latter and open source nature, its hard not to got with Godot as a beginner (IMHO).
the reason why 2500 works is not just bc of a better engine. there is probably a lot of inaccuracy added just to keep the engine going smoothly. things like different collision margins. basically you aren't testing the same things if your margins aren't exactly the same
I am not a game developer, and didn't try using unity or godot ... in the end of the video with 4 tests on the same screen, I notice that unity droping object has some sort of acceleration while godot droping in fixed speed, could that affect the results?
Seems like an unfair comparison as you don't know how to optimize Unity. I love Godot, but can't help feeling like you're trying to push the "Godot is superior to Unity in 2D" narrative. They both have their strengths, but Unity without a doubt has far more resources available. There are also better examples of what Unity is capable of, while we haven't seen Godot pushed as hard. Hopefully this changes in the future.
Godot does win the usability segment by a huge margin, though. I was tired of Unity corrupting my project files, after ages of waiting for the engine to even load, and the annoyingly long recompilation of code after even the tiniest changes, before I found this 80mb engine that starts up in a matter of seconds. I mean, there's even videos of people creating short games in Godot before Unity finishes loading up lol.
The thing people don’t realize but Godot is built in GDSctipt while Unity is built in C++. Unity outperforms Godot on rendering in both 2D and 3D including how it handles physics in REAL-TIME. I’m still not happy how Unity is still slow on compiling scripts though.
unity is hard for beginners at the first time but they gave you many free asset playmaker is a strongpoint for game dev who would not like to coding , Godot good for beginner but lack of asset in long term and you need to coding .
I think both engines work great. It's all dependent on what you need your game to be. And more than likely, you won't ever need to summon this many physics bodies in one scene, regardless. Not to mention that both engines are constantly getting updates. So problems that are showing up in this video and others like it might not even show up in future versions of the programs. It's just fun to see what happens when you bring an engine to it's limit.
My first comment got deleted, prob because of the link to gh i posted. I think it is also important to mention that godot is FOSS and you can add any physics engine given enough time and experience. Take a look at extrawurst/godot-vs-rapier repo which address the issue you were talking about with collisions overlapping and giving a better perf.
What does that first test means with the 25k red blocks? Because.. not only one of them fall in a almost correct physical angle. It seems like someone was trying how many blocks he can get on screen and not how accurate the physic simulation is. Build a Steam machine, where hot air forces a cone to move over a joint. Driven through fire that heats up water. Then change the waterpot from copper to concrete. Lets see how much physic these computer programs really bring to the table. Or make a gaschamber filled with oxygen and cool it down until the oxygen goes fluid. Aside from no Information which airpressure, gravity or weight these boxes are simulatet in, it looks like these boxes are made of rubber in the second program. I dont really know what falling blocks, where most of them glitch through the ground or through other blocks, have to do with physics.. its more like how magic this can be. Usual you need an supercomputer to make exact calculations for things like this. Therefore I have a hard time follow up, what I see here.
Maya is the PlayStation Guys. The PlayStation Guys better protected Unreal. They weren't guarding Maya as well. So the XBox guys were able to get Maya. Blender is quite similar to Maya.
I’ve been using Unity for years and am still learning stuff everyday. I’ll never use another tool no matter how simple my project is or overkill Unity might feel. Simply because there’s almost no learning curve anymore. Godot is great for my son, he feels less intimidated. Unity offers ridiculous customization and project optimization options… multi-threading, scriptable objects combined with pooling and so much more. Not even taking into account the third party integrations… it’s crazy. Nobody should compare, just get busy making and let your projects requirements define the tools you use. If you’re so new, you can’t know your projects requirements then you better be using either tool. Your project should be made in a notebook with a pencil before you get into a tool. Your project should be so simple it’s boring. In this case, there isn’t a tool on the internet that won’t serve you in building your idea.
In 2d Dots can be used as wel. Ridget bodies are nice when you do not need a lot of them on screen, but especially when dealing with bullets, dots is the way to go. and Godot does not have an implementation that is able to even go that fast.
Thanks for this. I've been working on a little Metroidvania type game in godot (2d) and was wondering if I'd really have to worry about running into issues having possibly a max of 10 physics bodies going at once. I think you've solved that for me lol.
How come 2D collisions seem to be running slower than the 3D counterparts? Are things interacting more, or are there optimizations being left behind on 2D?
I don't know much about these topics. But I guess it's because the game engine doesn't render all the boxes at the same time for 3D. You know, you only need to render the objects that appear in the camera.
I'm from a Unity background and i must say that Unity plays much nicer out of the box. Colliders and physics is what you see is what you get, im battling for ages now trying to get why my objects arent behaving like i want them to in Godot. Im trying to land a player in line on a surface. Its proving so difficult to get right, nobody on groups can even help, im 1 hour away from dropping Godot like a toilet seat and heading back to Unity land.
![PURPEECH - นี่ฉันเองคนที่... (It's me) [Official MV]](http://i.ytimg.com/vi/NuhHd0hOOg8/mqdefault.jpg)
Everyone is talking about how you should test 4.0 after it's out. Instead, you should test 3.4 soon because it has 2d performance improvements. I ran a very similar test to yours and got 1303 balls before dropping below 60 FPS in 3.3.3.. The same test in 3.4 beta 4 got 3133 balls before dropping below 60.
Damn, I gotta update to 3.4
That's a massive improvement.
Lol. I can easily get a million balls in Unreal
@@wimeradus We are talking bout' 2D
@@forkerion Unreal can do it all
On a separate note, BulletHell games like the ones shown in the video don't usually use full Rigid Body Physics. They are limited to _Layered One-Way Non-Continuous Collision Detection_ with simple _Convex Collision Shapes_ . Phew! That was hard to type. But what I mean is that usually interactions between the thousands of similar objects are not relevant for this type of game. The number of physics interactions in a single frame is very low, and the cost of complex physics is also eliminated. What we do have are the potential thousands of bullets, some static level geometry and more dynamic actors such as items/props and NPCs/players. The bullets collide with everything that's not a bullet, and those tend to be just a few, very rarely reaching the hundred count.
Mh, would be interested to see a "bullet hell benchmark" in both engines now :D
Being a Godot person and have experienced Unity in the past, I can say that Godot is more beginner friendly, as the nodes make much more sense paired with the simple GDScript language. Also, Unity takes too many resources. I had to uninstall most of my programs before I could laggily run Unity, meanwhile Godot I could immediately install with no downsides, and actually runs smooth. Edit: It's also on Steam. (Big plus)
Yes, my potato laptop could barely run unity 2018, but it runs godot 4.1 compatibility mode great. Usually
@@Random006what is ur laptop requirements
@@vexyrz I had a Intel core i3, 1.7 ghz GPU or something, 4 GB of ram, 600 GB of memory. Its not really great.
I actually a bit shocked with result knowing how in 3D Unity easily outperforms Godot.
that's not much of a surprise tho. godot's 3d current api is pretty outdated
4.0 is gonna change quite a lot about that tho
however, for 2d, it's a nobrainer nowadays. Not only performance wise, but in overall terms of practicality, functionality and workflow
Probably because the problem in 3D was not only due to the Physic Engine, but I suspect for a good part, the Renderer, especially because there is no Occlusion culling (big difference). It will be interesting to run the same test in 3D without rendering the scene to see the difference.
@@fabrice1533 Occlusion culling is coming to 4.0, if remember correctly. We need to just wait and test it there.
The selling point on godot was never it’s physics engine. But the under the hoood capability
I wasn't that shocked. I know Box2D is very mature and so is Unity. But Unity doesn't have a dedicated 2D engine. Disappointed that Unity beat Godot in one of the tests.
For all indie devs that are watching this, please do not let this stop you from using Godot for 3D. You probably would never need that many objects anyway in your 3D game as an indie dev. Godot is alright for 3D as well. Please just know the limitations of the tool that you are using and you will be fine.
Godot is objectively easier to work with than Unity. Unity on the other hand has more features out of the box, but lacks features that are required for freelance work. Godot suffers from the same issue.
Also Godot developer, take a look at Silent Wolf which is extremely useful for creating Godot games with a backend. Useful for freelancing.
truth... maybe soon they will enhance their 3D physics as well
I use Godot for 3D, although I do need to render hundreds of thousands objects simultaneously, but luckily without physics. I use multimesh mixed with particles, so far it worked fast enough.
@Tonypec1974 For a AAA dev, yes. For indie devs, 3D in Godot is fine.
@Tonypec1974 I see, but I know godot. So I use godot, and it works fine.
@Tonypec1974 awesome! I don't have much time, so I work with what I know.
TOTALLY UNEXPECTED RESULTS!! Awesome video, thanks!
Glad to see that the most common advice you see about Godot vs Unity (use Godot for 2D, Unity for 3D) holds up. I hear Godot 4 intends to be a big improvement all around as well. Really looking forward to see how Godot develops
Wow this has been one of the most interesting analysis I have seen, I'm glad to see that on the 2D side, Godot is quite good, I wish that when the Godot 4 version appears, you can compare the 3D approach again
would be interested in seeing how 3d and 2d physics stacks up now, considering Godot just recently released 4.0, and DOTS just recently released fully released :)
Im like 80% sure the reason unitys boxes were so squishy is because the collision type was set to dynamic instead of continuous. Fixing that would give way different results
They fall different. The unity version is accelerating with gravity. Godot isn't. That means the formula being used to describe their motion is different. Perhaps In a way that favors godot in this example. I think it's worth investigating.
idk, i'm pretty sure they are. It looks like the space between ones at the bottom and top increase as they fall, until collision
also looks like these tests were performed on linux.
wouldn't surprise me if unity had poor Linux support.
Godot's unit in 2D is pixels. I think this is not true for Unity. So he likely messed up converting the units to use the same gravity in both of them. He probably set gravity to 9.81 or something as per the usual, which in Godot would be 9.81 pixels/s^2, while in unity it is 9.81 units/s^2, where one unit spans many pixels.
nice video and also do not forget to compere with godot 4 and unity
Thanks for doing this. Great work.
I don't think bullet hell games really suffer from the 50Hz bug though as even with massive amount of bullets, you don't get that much overlap and the bullets don't try to push each other away
People focusing only on performance to compare engines are people who never finished any game. The workflow between each engines is very different and this is mostly what pulls people towards an engine or the other. As a Unity dev for years, i’m starting to lean towards Godot for the speed of of iteration. In Godot it’s so much faster to change code and test the game.
There's an Asset for Godot which replaced the Godot physics engine with Box2D. I personally haven't tried it but I'd be curious to see a comparison a new comparison.
Also Rapier2D, which is supposed technically (although not really) than Godot's Physics engine
Enter the Gungeon is technically 3D from what I recall
Great work, thank you! Would be nice to see a similar comparation between Godot and Gamemaker. I'm curious about that because, even Godot being a great engine and the developers don't have to pay to use, looks to me that developers prefer to use Gamemaker to producer commercial games (considering the quantity of successfully 2D games the engine has in comparation with Godot). Could this decision be related to performance?
Nope. Gamemaker just was better advertised so more people knew that it is better option for 2D games compared to Unity. And most people don't like to learn new things after dedicating entire career to one tool. Hence why jQuery is still alive somehow.
Gamemaker performs terrible vs. pretty much any other engine, except for maybe Construct
It’s just older and more famous… and supposedly more “beginner friendly”, what nowadays isn’t even true anymore
interesting, thought Unity would tear it on the 2D xD
Was indeed suprising, this video didnt contain a DOTS sample unlike the 3D one tho, wouldn't that change things ?
I use Unreal Engine, so I have no horse in this particular race but I do ask myself "Is there really a winner and loser to this?". Just choose the tool that fits the job, there's plenty of room for many solutions.
true
I love the benchmarking content. Good stuff!
That's pretty interesting. Given the 3D results, I expected the 2D results to be similar, with Unity clearly outperforming Godot, especially since Unity can handle a lot more 3D objects than it wound up being able to do in 2D.
Not really. Godot 4 is way better now. Specially Jolt physics
This is why I made my own physics engine, and it beats both of those by a mile (pile of 10K circles on a single thread @ 60 Hz with ~45 FPS), and I am still using a brute-force broadphase, albeit very well optimized. I also partition the world into 256m squares so float precision won’t be a problem at huge distances, which is nice having.
Love the video! One suggestion if I may! Look towards the camera hah!
Honestly surprised at how much better Godot is at high-frequency physics calculation despite how "new on the block" it is. Looking forward to its 4.0 release!
I see a number of issues with your methodology, and noticed some oddities you didn't address. I'll try to give some friendly critique for your consideration 😀 Keep up the good work!
The numbers are suspiciously close to some of the 3D test results. Can you try to do something to determine if there is some other bottleneck than the physics engine itself that masks the numbers (i.e. are you sure you're measuring the right thing)? I'm suspecting the object tree most of all, and the event handling especially, since physics collisions can have event handlers (at least in Unity). Idea: keep everything the same but remove the physics completely and just do a basic movement implementation that slowly accelerates downwards until it hits a set height and then stops instantly. No collision detection. This will show if/where the game engine itself starts slowing down.
The framerate drops are very inconsistent, and in one test drops from the thousands to under 10 in about one second. That smells of some kind of O(n^2) or probably worse computation reaching a breaking point, which could be due to the compounding collisions caused by all the boxes being in one big pile. If that's what you were targeting on purpose though, that's fine! But it's a bit disingenuous to judge the whole physics engine based on such a particular case, and again I'm missing comparison simulations to rule out other reasons for the drops. Idea: Instead of a bin that holds all the cubes, spawn them gradually in one direction to minimize (but not completely avoid) boxes colliding with each other.
The side by side comparison shows that the boxes aren't falling at the same speed, which suggests that there's still a difference between the two test implementations that may or may not make a difference. This might be just plain scale, that the Godot scene has larger boxes but is also zoomed out more, or that there are other parameters than physics framerate that should be compared, like timescale, gravity, weight/mass, air resistance, I don't really know, just speculation. Idea: This can be tested in two ways just like you've done in the video: Change stuff in the scene (size up or down) and compare to previous results in the same game engine, and change stuff to get the two game engines to either match up all possible variables and/or to produce a visually similar simulation. This might also affect the squished and jittering boxes in the Godot 60hz test, see if making everything larger (and zooming out) gives any improvements!
Last, I think the comparison to bullet hell games doesn't fit the test scenario. Bullets often have constant velocity or very simple movement logic, they don't collide with each other (usually just players, enemies and destructible s by calculating distance plus world geometry which is static), and they have no geometry (just point or circles which is very fast computationally) so a full general physics simulation is overkill and most games use or make something more specialized and optimized like a particle system. So you could make another video about that, but that's not the use case you've tested in this video 😉
Hope you find my comments useful! Looking forward to your next video 👍
Thanks for the helpful insights! I agree with your point that even bullet hell games would probably not require full physics simulation and either engine would be suitable for such a game. This comparison was mainly to satisfy my curiosity as to whether Godot's 2D could hold its own against Unity2D.
You also bring up a good point about the different speed of the falling bodies in Godot vs. Unity. The physical parameters (mass, accel due to gravity, etc) were consistent between the two engines, its just Godot Physics seems to require much higher gravity to match the falling speed of Unity at 9.8 m/s^2. For this comparison, I decided to keep the variables ( gravities and masses ) the same between the two engines, which results in the objects falling slower in Godot. I also tried larger collision shapes in Godot at 50Hz and still encountered the bug with large stacks of objects interpenetrating each other.
Thanks again for the comment, I'll definitely take into consideration your ideas for any future comparisons!
@@MeanGeneHacks also, it seems like the fences are farther apart on unity? That could change the number of collisions, couldn't it?
Just a question how using GDNative will affect the performance? Will it stay the same? Shouldn't it be used in these scenarios when you have so many rigidbodies in the scene instead of GDScript or am I wrong?
Well, he is using built in physics and GDScript only to "spawn" rigid bodies. In case if anyone will try to code own physics for KinematicBody/KinematicBody2D then using GDNative or Mono over GDScript will give you huge performance boost if done right. May be even better then built in one, if you are really skilled or compromise some accuracy in a sake of more performance.
I don't see how GDNative will help much if you are using the built-in physics engines, as I'm only using GDScript to spawn the physics object (in a physics server). I did try re-writing the spawning code in C#, but saw no performance improvement so I didn't include it in the video.
One area where GDNative could help is through the integration of a different/faster physics engine.
@@MeanGeneHacks Thank you for your reply, good to know!
Cool test! Might try Godot, still learning Unity, but def want to specialize in 2D.
im working in a 3D game in Godot. as good as unity in my opinion
I must say, considering the simplicity of Godot, it’s worth it.
Thanks for the great video! This was the best comparison between the two engines that I've seen.
You could expand it by testing both engines physics separating them from their rendering. I think that it is possible that GodotPhysics is bottlenecked by the rendering of the engine.
If I was to make a bullet hell game, I don't think I would worry too much about 2D physics performance when choosing a game engine, because my appetite for more physics objects would run out long before the engine stops being able to keep up. The game would have to look something like your little benchmark test before it makes a difference, and you almost filled the entire screen with objects. Also, the bullet hell games you showed only used the collision detection part of the engine. You don't need to run an expensive rigid body simulation hundreds of times per second to do collision detection well.
dropping the boxes with different gravity can have an effect since boxes that "settle" will take up less processing
Agreed; however, the mass and gravity settings were the same in the two engines. Godot's physics just behaves differently at those settings.
the godot project is a solid package (editor+game engine) and you can use/mod/etc... :) ... i dont know unity, because i was triying to use it but i use linux, and the "editor" is slower, the coding is in other editor, much unnecessary config... the unity can be better in one or much more areas that godot, but godot download open and OK its ready to go... extremely easy to use, and the logic scene in scene is simply and amazing, in conclusion (for my) godot as tools is much better than unity, but (for now) unity is more powerful game engine than godot
Word! Setting up Unity in linux is painfully slow, even in ubuntu.
Godot allows usage of multiple physics engines. I just read they're working on box2d support and they also have choice "godotphysics" vs "bullet" in 3d already. So things might change in future.
it is strange that unity can handle more objects in 3d than 2d.
in godot I also noticed that it first mostly stays the same then slowly goes down and then suddenly starts to drop in a quadrant shape, so this might also be some bug or it might be a nice space where the physics engine can be optimized.
* cough cough * optimization and DOTS * cough cough *
I wonder what is limiting the physics at some point, like after few more objects everything stops drastically, i'd expect a slower drop rate. Interesting that with Godot even with double the calculations you are reaching roughly the same results, it seems there's that drastic limit in place instead of something else (certainly with more stuff to do in a frame that double cost would impact differently).
I don't know if there's something in the internal data structure that is optimized to handle some max ammounts or other conditions. Maybe some tweaking in the code to arrange larger sets is possible? Another idea would be spawn the same critical number of objects in a grid pattern without them touching at the beginning, then release them and see if collisions slow them down or the speed is the same. See if larger spacing cripple less (maybe objects fall into different spatial areas in the engine and works better?). Just some ideas i'd try.
Definitely the object collisions are slowing things down, because when the objects go to sleep, the frame rate jumps back up.
Maybe is the OOP design they choosed for the engine, OOP is not cache friendly which is important for game engines.
Desculpa a pergunta, mas usar ECS na Unity não deve dar um boost de FPS? ,_, não entendo bem de ECS, mas sei q isso aí faz milagres na Unity em termo de desempenho '-'
what i like in GODOT is it's fast to load a project in my low spec laptop, while UNITY takes forever
You know, Component Based Systems have far more performance than OOP, since it handles cache and memory the right way. If I remember, Godot has even a different node for rendering multiple meshes in a better performance, which should be the default way to do it. Well Godot still misses some functionalities.
I think he used multimeshes. If that's what you meant.
@@nullvoid3545 That's just a curiosity actually. I think that the normal Mesh node should be the same performance as the MultipleMesh node.
I don't have any horses in this race, just a geek who's interested in the context - but I do have to say, it really feel like the Godot boxes fell in a more natural position than the Unity ones!
For example. compare 5:48 to 8:18, the Unity boxes appear to have a lot more straight lines emerging ...
In fairness, I don't know what to expect from the distribution of where the boxes end up, but it's that whole thing about straight lines and nature ...
Either way, thanks for the video - I found it quite fascinating!
30% better, my guess. Edit.. well, color me surprised.
this is still a fixed amount of physics objects, what if we preload these objects? or are these already preloaded? forget what i said in the beginning, what about preloading?
I wonder why the FPS drop is so sudden. Is the engine running out of memory and switches to some kind of disk cache.
3D -Unity
2D -Godot
Doesn't Godot run on OpenGL and Unity on DirectX? I heard Godot is switching to Vulkan in the next major release 4.0. Will that have an effect in the performance?
Certainly not on Linux or OS/X :P
no, it wont, because opengl and directx as well as vulkan are only responsible for rendering
@@ishdx9374 It actually does. Modern APIs like Vulkan and Direct3D 12 are supported better by AMD and Intel drivers resulting in better performance on those GPUs, and generally are designed with modern GPU's hardware in mind. OpenGL was designed for hardware from the 90s. It's most evident with DOOM 2016 where Vulkan mode runs a lot better than OpenGL but looks almost the same.
@@dangputerz ??? Vulkan runs great on Linux
@@PySnek I meant DirectX Bro. I'm aware Vulkan can and does. I only use Linux since 1998ish except when programming.
What about Godot v4?
Not necessarily for its own virtues, but yes, it's safe to say that Godot will beat Unity now.
Can you also benchmark 2d performance for things other than physics? Like drawing 1000s sprites at the same time.
I can already tell you that for this kind of benchmark, frameworks like monogame and raylib outperform unity and Godoy by a large order of magnitude (on my pc, something like 25000 sprites for unity vs 150000 for raylib and monogame)
WHY THE FRAME DROPS SO SUDDEN? 5:45 I dont understand why its not gradually decreasing like the first test. Please somebody answer would be very appreciated!
Yes it will. Someday.
Just wait for few more updates!
It appears, as if, Unity has some sort of easy-in animation by default (which feels good). Possibly because the generator is with in the frame, at the top. In Godot, it feels like cubes are floating (Weight lessly) down to the bottom.
those should be changable on ether engine with little to no difference in performance.
It's called gravity. In Gadot it has constant speed, in Unity it is accelerated.
1) Godot's 2D pixel detection is terrible. Its collision detection is not good, hard to use. For whatever reason the community is working on 3D instead of 2D. 2) C# should be the default rather GD. 3) You can do anything you want with Unity. Although you can be overwhelmed with learning the engine. There is a reason why people are not releasing games with it. They were should really develop the 2D functionality of GODOT.
can you test this again with 4.0 ?
From your experiments I may suppose, that Godot have troubles to handle 2k objects any way. Maybe custom layout in memory while using C could help. Also if you try DOTS in Unity, you may try data oriented plugin for Godot named Godex. It's in development, but still.
My sad prediction (because I am a Godot fan): 75k in Unity.
I have started making games with Godot since 2 weeks, before that I tried Unity and was already put off by the TUTORIAL. The reason being that Unity (in their infinite wisdom) tried to enforce dot and comma use depending on the country (in Germany we use comma as a decimal seperator), the problem was that the built-in tutorial expected you put in a decimal number, but the engine AUTO-CORRECTED it to a comma, causing it not to detect the correct value, getting me stuck....
But that wasnt the end: I found a thread in the official Unity forum where people noticed this problem, which broke their games. There was one particular developer, who complained that this broke their custom shader and caused them to lose 3 weeks of work, because nobody noticed that Unity replaced all the dots with commas in their script, which was done at compiling time. To finally put the nail in the coffin, the Unity devs then started defending their decision, despite the outcry of everyone (and ignoring that program code should always use dots and be indepentent from what the OS uses). They however never replied to the beginner, who pointed out that this broke their tutorials for everyone from a country that uses commas as a decimal seperator... I think this took them MONTHS to finally fix....
To sum up: Unity might be more performant for 3D games, but the way Unity seems to care about their devs and how much better designed the workflow in Godot seems to be, not to mention the far better license of the latter and open source nature, its hard not to got with Godot as a beginner (IMHO).
@@kishirisu1268 ....dude what? You have COMPLETELY missed the point.
You must be joking, there is hardly any help in Godot, still! Unity has 10x the tutorials on youtube.
the reason why 2500 works is not just bc of a better engine. there is probably a lot of inaccuracy added just to keep the engine going smoothly. things like different collision margins.
basically you aren't testing the same things if your margins aren't exactly the same
But you know how to optimize godot and dont know how to optimize unity
A comparison of the pathfinding in 2D and 3D with godot and unity/dots would be nice!
I am not a game developer, and didn't try using unity or godot ... in the end of the video with 4 tests on the same screen, I notice that unity droping object has some sort of acceleration while godot droping in fixed speed, could that affect the results?
There is 2 physics engines in godot, I don't know if you tried both of them or not, you missed somethings in Godot Engine
I don't fully understand how Godot goes from like 7000fps to 10 by adding life 50 extra physics objects?
that's true, but aren't there many ways to also optimise it in unity?
Perdiction (Unity): Quadrat: 1600 - Circle: 1650
You forgot unity dots. This is an unfair comparison
Great video!
wow. thankyou.
Seems like an unfair comparison as you don't know how to optimize Unity. I love Godot, but can't help feeling like you're trying to push the "Godot is superior to Unity in 2D" narrative. They both have their strengths, but Unity without a doubt has far more resources available. There are also better examples of what Unity is capable of, while we haven't seen Godot pushed as hard. Hopefully this changes in the future.
Godot does win the usability segment by a huge margin, though. I was tired of Unity corrupting my project files, after ages of waiting for the engine to even load, and the annoyingly long recompilation of code after even the tiniest changes, before I found this 80mb engine that starts up in a matter of seconds.
I mean, there's even videos of people creating short games in Godot before Unity finishes loading up lol.
@@nyeeesss2424 stop running it on a 386
The thing people don’t realize but Godot is built in GDSctipt while Unity is built in C++. Unity outperforms Godot on rendering in both 2D and 3D including how it handles physics in REAL-TIME. I’m still not happy how Unity is still slow on compiling scripts though.
that not true godot is not made with gdscript, it made in c++ just like unity or unreal. Unity performs way better, in physics because of physx
@@saul8510 oh crap I’m wrong abt that. Thanks
But Godot IS free :v
I don't know you guys, but for me, that makes Godot better heh
Unity is also free and Godot can never beat unity beacuse if Godot added 3d still unity have better features and also have ar vr hdrp urp
unity is hard for beginners at the first time but they gave you many free asset playmaker is a strongpoint for game dev who would not like to coding , Godot good for beginner but lack of asset in long term and you need to coding .
I think both engines work great. It's all dependent on what you need your game to be. And more than likely, you won't ever need to summon this many physics bodies in one scene, regardless. Not to mention that both engines are constantly getting updates. So problems that are showing up in this video and others like it might not even show up in future versions of the programs. It's just fun to see what happens when you bring an engine to it's limit.
I'd be interested to see this experiment redone with godot 4 now that they have upgraded their physics engine.
@Mean Gene Hacks, great video, btw what is the title of the game at 1:28? Many thanks
Well the thing is that DOTS is an Entity Component system and ECSs are designed to be performant. There is an ECS library for godot called Godex
I'd love to see a raw 3d rendering test, no physics just tons of polygons
Given Godot is getting updated Godot 4 will provide s lot of improvements in both 2D and 3D.
@1:15 there is a game shown @the kingdoms of avalae" there is 0 info on it, google gives nothing, is there a link?
Godot 4 is officially in Alpha and it the issue mentioned on the video fixed. Would you repeat the tests with it?
My first comment got deleted, prob because of the link to gh i posted.
I think it is also important to mention that godot is FOSS and you can add any physics engine given enough time and experience. Take a look at extrawurst/godot-vs-rapier repo which address the issue you were talking about with collisions overlapping and giving a better perf.
What about using DOTS in Unity for performance in 2D?
DOTS is so powerful, with DOTS unity can win easily.
7:42 answer beat by 2000 with 60hz
is there a size difference? i can see boxes in both engines falling at different speeds, idk if that would change anything
they fall at different speeds because of the way the engines work. Gravity and mass were identical in both engines.
@@MeanGeneHacks are you certain the unit masses of both the engines are the same?
@@nyeeesss2424 Yes. Unit mass and gravity were set to the same values in both engines.
Can we get an update comparing godot 4 now?
What's that 2D shooting game at the beginning? That actually looks pretty cool.
i like godot a lot, really hoping they can nail the physics down with godot 4 and beyond
unexpected result, but I think if you writes the codes well, both of them are great.❤
now godot is optimized and much more performance are added
important correction: godot physics is not proprietary, it's free, like the rest of the engine
This is an extremely specific use case.
Seems there's missing a DOTS sample ;) Just wanted to say that Unity does have 2D physics and a 2D renderer, tho really experimental xP
Awesome investigation
Saying that Godot uses a proprietary physics engine sound very misleading.
It uses a _custom_ physics engine. It's all open-source software.
What does that first test means with the 25k red blocks? Because.. not only one of them fall in a almost correct physical angle. It seems like someone was trying how many blocks he can get on screen and not how accurate the physic simulation is. Build a Steam machine, where hot air forces a cone to move over a joint. Driven through fire that heats up water.
Then change the waterpot from copper to concrete. Lets see how much physic these computer programs really bring to the table.
Or make a gaschamber filled with oxygen and cool it down until the oxygen goes fluid.
Aside from no Information which airpressure, gravity or weight these boxes are simulatet in, it looks like these boxes are made of rubber in the second program.
I dont really know what falling blocks, where most of them glitch through the ground or through other blocks, have to do with physics.. its more like how magic this can be. Usual you need an supercomputer to make exact calculations for things like this. Therefore I have a hard time follow up, what I see here.
Maya is the PlayStation Guys. The PlayStation Guys better protected Unreal. They weren't guarding Maya as well. So the XBox guys were able to get Maya. Blender is quite similar to Maya.
I’ve been using Unity for years and am still learning stuff everyday. I’ll never use another tool no matter how simple my project is or overkill Unity might feel. Simply because there’s almost no learning curve anymore.
Godot is great for my son, he feels less intimidated. Unity offers ridiculous customization and project optimization options… multi-threading, scriptable objects combined with pooling and so much more. Not even taking into account the third party integrations… it’s crazy.
Nobody should compare, just get busy making and let your projects requirements define the tools you use. If you’re so new, you can’t know your projects requirements then you better be using either tool.
Your project should be made in a notebook with a pencil before you get into a tool. Your project should be so simple it’s boring. In this case, there isn’t a tool on the internet that won’t serve you in building your idea.
In 2d Dots can be used as wel.
Ridget bodies are nice when you do not need a lot of them on screen, but especially when dealing with bullets, dots is the way to go. and Godot does not have an implementation that is able to even go that fast.
Thanks for this. I've been working on a little Metroidvania type game in godot (2d) and was wondering if I'd really have to worry about running into issues having possibly a max of 10 physics bodies going at once. I think you've solved that for me lol.
How come 2D collisions seem to be running slower than the 3D counterparts? Are things interacting more, or are there optimizations being left behind on 2D?
I think it would be interesting to see the results of scenarios in 2D and 3D which controlled for this
I don't know much about these topics. But I guess it's because the game engine doesn't render all the boxes at the same time for 3D. You know, you only need to render the objects that appear in the camera.
Short answer, yes.
I'm from a Unity background and i must say that Unity plays much nicer out of the box. Colliders and physics is what you see is what you get, im battling for ages now trying to get why my objects arent behaving like i want them to in Godot. Im trying to land a player in line on a surface. Its proving so difficult to get right, nobody on groups can even help, im 1 hour away from dropping Godot like a toilet seat and heading back to Unity land.