I don’t even know if you noticed, but unity’s rigid body had their collision enabled against each other, which is amazing, considering that godot couldn’t even handle 1750 with collisions off. Unity much preferably won by a lot.
And this isn't even with the even more optimized Unity.Physics package option Unity now has that can work using the DOTS system. Someone did a test a while back here a year ago: ua-cam.com/video/U6idEdIEsa0/v-deo.html And I'd imagine it would only be even more performant now.
Well that is true you can see there is a very clear trig sine-wave artifact in unity3d box simulation. By displacing boxes initially you reduce the number of collision checks per stack
@@phycogsmithomniscience309 that analogy seems to imply Unity has less utility, when that's not true at all. Unity is a jack of trades where you're free to do what you want with ease, and now with their DOTS you can also achieve extremely high performance despite using a managed language to program. So you're getting the best of both worlds, easy to manage and iterate code with high performance and a vast array of official and community tools. And industry leading multi-platform support on top of it.
One thing I notice in your Godot tests is the bodies clump and intersect a lot. Couldn't that also in part lead to many more collision checks than in the Crisis and Unity demos? Also, as Groud mention, I'm curious to see what's the performance like when you don't use nodes, as their ease of use generally comes at a performance cost. We've done physics benchmarks here with areas, and the frame time gets divided several times when using direct calls to the physics server over using Area2D nodes. Although the difference may not be as big with RigidBody nodes perhaps.
Thanks for the comments and great observation by the way. The reason there was "intersection" was I accidentally had the mesh size at 2x2x2 and the collision extents at 0.5, giving me a collision box size of 1x1x1. So the mesh was twice as large as the collision shape. All the placing of the boxes were done based upon the collision shape size, so other than looking a bit ugly, there was no performance difference when fixing the mesh sizes, so I didn't bother redoing the godot tests. I do plan on next looking at Godot with a PhysicsServer instead of using nodes and will compare that to the Unity equivalent of using DOTS Physics to get rid of the GameObject overhead in Unity.
I've used Unity for many years and Godot for nearly 2 years now, and while I much prefer Godot to use, it's actually enjoyable to use, rather than fighting unity to get it to do what I want. BUT I have no doubt that Unity is the much more advanced, mature engine and I know that upsets a lot of godot users but it's just a fact. I think Godot has the greatest potential though. I would still recommend any skill level in game dev to take up Godot, it being so open, growing really fast and they're adding languages rather than taking them away, it's the future of software and we're seeing a shift, I'd rather jump onto something embracing freedoms than keep the old buisness models that focus on greed
Focus on one language is better than adding many languages with half assed support imho. Unity learned that lesson long ago (that's why they focus on C# now) and Godot will learn the same lesson too in a few years, hopefully soon enough before they waste too many resources with all their language "support"
I agree with @R1PFake. I personally use unity, but I hope that godot is successful just to give unity some pressure. But, with the amount of languages godot is adding their going to have the same lesson that unity got, where the more languages you had the harder it gets to add new features. I’ll be interested to see what happens.
You should make the collisions more similar. Most of the godot physics lag is caused by touching objects chain colliding. In the other examples the way they drop/explode do not create similar stacks of colliding objects.
Well... Since Godot has got 2 or 3 physics engines, you've used only Unity's default one. What about unlocking full power of Unity and implement DOTS system? Trust me, Unity will handle more than 60k of these cubes.
No, unfortunately it will not. Running physics where bodies interract with each other in a complex way is not the same as shooting bullets where you just change location on a path. DOTS (as in ESC, Jobs and Burst) has nothing to do with physics itself, at leat atm. Physics on DOTS is coming in the future, but I really doubt it will be that much more performant. If early tests are any good, it can be 1.5 - 2 times more performant in some cases. Also ESC as a concept and Jobs as multithreading can be implemented in anything really.
@@MPG42 Yes, but the increase for 60fps was less than 2 times. The fact that Unity in DOTS handles 50k objects at once witout crashing is all cool, but it is not about physics, but handling and rendering entities vs gameobjects. Obviously everything influences your fps and if this is your point then I agree, but if we talk about pure physics, then DOTS per se only marginally increases your performance.
You should try the same test without using nodes, but instead by calling the physics and rendering servers directly. For this kind of tests, this should bring a significant performance improvement. The node system has always been more about ease of use than performances, and their instantiation is thus generally costly. So the same way we do not suggest to use Sprite2D nodes for a bullet hell game, si would not use nodes here for such a test.
Thanks for the suggestion! I'm already working on a follow-up video where I compare exactly what you suggested (Godot PhysicsServer) vs Unity DOTS Physics.
0.9 friction, 0.4 bounce and 400 in physics jitter fix and i was able to run 4k cubes all the way down, but the lagging started a little bit after that. ( i posted a pic on git ). Good video btw, i did a similar test video about a year or two ago :D
Check out Part 2 ( ua-cam.com/video/-vvxBWVXxe4/v-deo.html ) where I compare Unity DOTS Physics to a Godot standalone PhysicsServer. What is your prediction, will minimizing the overhead of Nodes (Godot) and GameObjects (Unity) help performance? Will Godot be able to overtake Unity's performance or will Unity just extend it's performance lead?
Godot won't even come close. After my tests, DOTS physics is about 3 times faster than regular Unity physics (although it varies a lot depending on the use case but in general it's at least 3x faster). And that's only regular DOTS physics. Unity also has Havok backend for DOTS which is about 2 times faster than DOTS physics. (again, varies a lot on the use case but in general it's at least 2x faster).
I would also love to see this tested against the Unity PhysX integration from Nvidia (Unity's built-in PhysX integration has threading issues and is generally slower) which also supports GPU simulation.
Hey well put together analysis! When you said "Let me open this in Godot 4.0" I had a big HOLDUP moment thinking I missed the big release or something hah. Godot's obviously not quite at the performance level of bigger players but its future potential is truly limitless and I'm definitely excited for it!
Interesting comparison but here are a few thoughts: - all your tests were a mixed bag of rendering and physics calculations, for true results you should disable rendering - I wonder what sleep mode setting you have configured for the Godot (if it has any at all) but when cubes rest on top of each other their contact detection and simulation should get turned off and increase performance not the other way around!
Unity seems to have precalculated the forces applyed in a stack and applys some trig sine wave to the stack this reduces collisions witch is the most costly. I would like to see a simulation where you are pushing boxes down a road that would be a hard case to optimize for.
I think Godot takes fps drops from it's graphics. I've tried Godot 3 for just testing reasons. (Note: I've an old GPU, but supports DX11) Just by making 3D terrains and placing few trees, Godot started lagging a lot. Where, I've made a lot of games in Unity, with 3D models, rigs, audios etc. Bigger than the Godot scene. Unity don't lags with those all, where Godot lags with that small scene. Sorry Godot, that's why I don't use Godot for 3D. I use Godot for 2D and Unity for 3D. (I would use 3D for Unreal. But my PC has low-end GPU)
you can't say it handles 700 or 1000 well, if all cubes are overlapping with each other (are inside other cubes - means physics is not accurate in the first place!)
The frame drops on unity I would bet is because of the rendering though. You are getting 20k+ batches. Try instancing those cubes and checking how it performs too.
Man, it's a great video But... Mouse clicking noise at the end of some of your recordings isa bit sad Been youtuber, I have the same issues and solution I've found is to either put your mic in the other direction than your mouse or use keyboard shortcots (if you have a silent keyboard)
Not only is the unity physics engine faster but it appears way more accurate in the simulation. The “rigid” body objects in gadot don’t accurately interact when they hit the other blocks as evidenced by the very small pile result in the end no matter the number of blocks.
Your final thoughts are a bit counter-intuitive; you say that because godot is open source, we can continue to expect updates. But if volunteers don't feel like contributing to those improvements there won't be updates. Unity on the other hand is (optionally) paid software, so as long as someone pays them, there's a guarantee for updates and improvements.
Godot also has a budget coming from donations and support from companies using Godot in production, albeit smaller than Unity's, but there still core development team, not enthusiasts only.
@@MeshVoid While it's true that godot has a small budget that supports a partially varying arrangement of core contributors, those when hired (or even those like juan who are part of the core-core) tend and are expected to work on very specific topics which is not comparable to commercial software support. It would be cool if this came with a maybe future popularity gain of godot, so one could actually use it commercially while not being forced at times to be a c++ developer too, knowing the insides of the engine to support oneself. But for now it's just realistic to not expect guarantees there from godot.
Fair criticism. I really should have gone into a bit more on what I see as the benefits of Godot being open source, namely that the community has much more say in the development of updates than with a closed source engine where the company decides what to focus efforts on. Having said that, if the community decides additional resources need to be allocated to Physics, I think there is a much better chance of that happening with Godot than with Unity.
So, f.e. Adobe software being a billion dollar company must be producing absolutely bug free and fun to use software which makes all users happy and they are fixing bugs even years after release (*cough* Flash *cough*)
Godot is blender 2.0 . it started out rough , but will finish strong . also.. not to peg on other devs.. but i don't know why i would need more than 500 objects all in collision with each other at once
@@italofreitas221 also, I said practical use case scenario and making a GTA5 level game for one guy at his home is not practical at all, it is next to impossible.
That's an overgeneralization. Every millisecond counts. This shows more computation time will end up being taken by physics, leaving less breathing room for other areas of the game. And if you're targeting mobile for example, performance becomes extremely crucial unless you're making a simple 2D game or something with no real physics.
@@etaashmathamsetty7399 not in the public versions, 5.0 should have soft body support but they are taking their sweet time to release it. Amd FEMFX is what I use with physx currently.
The PhysX in Unity does not use the GPU because they wanted to ensure it works on any system, otherwise it would be restricted to Nvidia users. It is entirely on CPU. And Unity even has a new Physics system they built themselves that performs many times faster than the one in this video... ua-cam.com/video/U6idEdIEsa0/v-deo.html
Unity has better looking ui and tech than Godot but Godot maybe much better to help you finish a good game as long as it's not too taxing. You want to try to get yourself better and finishing a project. Agodot might be better for that. If your a tech beast then yeah unity is there too. You can always switch between the two depending on what your trying to do. 3 year proj then yeah go with unity. But Godot give you more room to get familiar with the concepts. Assuming people are starting out with software dev.
Unity's performance on 3D was so far ahead of Godot, that I didn't bother exporting the Unity project in this video; however, when comparing Unity DOTS vs Godot Physics Server in part 2, I used the exported projects in both cases.
Unity physics engine is cursed Fire ray through moving rigid body Passed through rigid body Fires rigid body too fast Passes through Do anything with rigid bodies Dies
Then stop using the default options. You can turn on prediction and more accurate calculations. It's performance mode by default and you tweak things to the accuracy you need. There are a plethora of settings to fine-tune the behaviour. The ray will not pass through a rigidbody though unless you fired the ray *from inside the collider*, then in that case if you expect that to happen, turn on "Rays hit Backfaces".
@@invertexyz I literally didn't fire the ray from withinside the collider, that doesn't make any sense. I've never had issues firing rays at moving rigidbodies with any other game/physics engine. Sure throwing a rigid body at fast speeds will fucking clip through the wall, but a fucking ray, like come on. Ray casts are supposed to be the most simple shit.
@@albingrahn5576 That's only half true, the paid plans are there all along and there are features you don't get if you don't pay, it's not FORCED until you maake over 100k a year, but it is a paid piece of software
@@picster you got a point, but i'll will hope that Godot will be the best engine even if it does not get that much performance updates i am happy cause who needs 9 million sprites in thir game walking around :)
Even when it was performant, I couldn’t help but notice that the Godot cubes were constantly clipping into eachother
I address this in part 2.
I don’t even know if you noticed, but unity’s rigid body had their collision enabled against each other, which is amazing, considering that godot couldn’t even handle 1750 with collisions off. Unity much preferably won by a lot.
And this isn't even with the even more optimized Unity.Physics package option Unity now has that can work using the DOTS system.
Someone did a test a while back here a year ago: ua-cam.com/video/U6idEdIEsa0/v-deo.html
And I'd imagine it would only be even more performant now.
Well that is true you can see there is a very clear trig sine-wave artifact in unity3d box simulation. By displacing boxes initially you reduce the number of collision checks per stack
yeah unity won. that doesn't mean im using it lol. Yeah your car runs faster.. sure.. that doesn't mean i can't use my truck
@@phycogsmithomniscience309 that analogy seems to imply Unity has less utility, when that's not true at all. Unity is a jack of trades where you're free to do what you want with ease, and now with their DOTS you can also achieve extremely high performance despite using a managed language to program. So you're getting the best of both worlds, easy to manage and iterate code with high performance and a vast array of official and community tools. And industry leading multi-platform support on top of it.
@@phycogsmithomniscience309 I see.
One thing I notice in your Godot tests is the bodies clump and intersect a lot. Couldn't that also in part lead to many more collision checks than in the Crisis and Unity demos?
Also, as Groud mention, I'm curious to see what's the performance like when you don't use nodes, as their ease of use generally comes at a performance cost. We've done physics benchmarks here with areas, and the frame time gets divided several times when using direct calls to the physics server over using Area2D nodes. Although the difference may not be as big with RigidBody nodes perhaps.
Thanks for the comments and great observation by the way. The reason there was "intersection" was I accidentally had the mesh size at 2x2x2 and the collision extents at 0.5, giving me a collision box size of 1x1x1. So the mesh was twice as large as the collision shape. All the placing of the boxes were done based upon the collision shape size, so other than looking a bit ugly, there was no performance difference when fixing the mesh sizes, so I didn't bother redoing the godot tests.
I do plan on next looking at Godot with a PhysicsServer instead of using nodes and will compare that to the Unity equivalent of using DOTS Physics to get rid of the GameObject overhead in Unity.
I've used Unity for many years and Godot for nearly 2 years now, and while I much prefer Godot to use, it's actually enjoyable to use, rather than fighting unity to get it to do what I want. BUT I have no doubt that Unity is the much more advanced, mature engine and I know that upsets a lot of godot users but it's just a fact.
I think Godot has the greatest potential though.
I would still recommend any skill level in game dev to take up Godot, it being so open, growing really fast and they're adding languages rather than taking them away, it's the future of software and we're seeing a shift, I'd rather jump onto something embracing freedoms than keep the old buisness models that focus on greed
Focus on one language is better than adding many languages with half assed support imho.
Unity learned that lesson long ago (that's why they focus on C# now) and Godot will learn the same lesson too in a few years, hopefully soon enough before they waste too many resources with all their language "support"
I agree with @R1PFake. I personally use unity, but I hope that godot is successful just to give unity some pressure. But, with the amount of languages godot is adding their going to have the same lesson that unity got, where the more languages you had the harder it gets to add new features. I’ll be interested to see what happens.
True Dat
You should make the collisions more similar. Most of the godot physics lag is caused by touching objects chain colliding. In the other examples the way they drop/explode do not create similar stacks of colliding objects.
Well... Since Godot has got 2 or 3 physics engines, you've used only Unity's default one. What about unlocking full power of Unity and implement DOTS system? Trust me, Unity will handle more than 60k of these cubes.
Definitely!
This sounds like Goku going super saiyan 3000
No, unfortunately it will not. Running physics where bodies interract with each other in a complex way is not the same as shooting bullets where you just change location on a path. DOTS (as in ESC, Jobs and Burst) has nothing to do with physics itself, at leat atm. Physics on DOTS is coming in the future, but I really doubt it will be that much more performant. If early tests are any good, it can be 1.5 - 2 times more performant in some cases. Also ESC as a concept and Jobs as multithreading can be implemented in anything really.
@@uatihb ua-cam.com/video/U6idEdIEsa0/v-deo.html 50k cubes at 15 fps
@@MPG42 Yes, but the increase for 60fps was less than 2 times. The fact that Unity in DOTS handles 50k objects at once witout crashing is all cool, but it is not about physics, but handling and rendering entities vs gameobjects. Obviously everything influences your fps and if this is your point then I agree, but if we talk about pure physics, then DOTS per se only marginally increases your performance.
You should try the same test without using nodes, but instead by calling the physics and rendering servers directly. For this kind of tests, this should bring a significant performance improvement.
The node system has always been more about ease of use than performances, and their instantiation is thus generally costly. So the same way we do not suggest to use Sprite2D nodes for a bullet hell game, si would not use nodes here for such a test.
what would you suggest 2d for bullet hell games? curious
@@gillesroudiere541 very interesting article. Thank you for sharing
Thanks for the suggestion! I'm already working on a follow-up video where I compare exactly what you suggested (Godot PhysicsServer) vs Unity DOTS Physics.
@@gillesroudiere541 thank you so much let me save it on UA-cam playlist, big thanks.
@@gillesroudiere541 actually very good article thanks once again 👍👍
Wow, I had no idea there was such a difference in physics performance between Unity and Godot. Thanks for the comparison!
0.9 friction, 0.4 bounce and 400 in physics jitter fix and i was able to run 4k cubes all the way down, but the lagging started a little bit after that. ( i posted a pic on git ). Good video btw, i did a similar test video about a year or two ago :D
Check out Part 2 ( ua-cam.com/video/-vvxBWVXxe4/v-deo.html ) where I compare Unity DOTS Physics to a Godot standalone PhysicsServer. What is your prediction, will minimizing the overhead of Nodes (Godot) and GameObjects (Unity) help performance? Will Godot be able to overtake Unity's performance or will Unity just extend it's performance lead?
Godot won't even come close.
After my tests, DOTS physics is about 3 times faster than regular Unity physics (although it varies a lot depending on the use case but in general it's at least 3x faster).
And that's only regular DOTS physics. Unity also has Havok backend for DOTS which is about 2 times faster than DOTS physics. (again, varies a lot on the use case but in general it's at least 2x faster).
I think Godot will have a chance to redeem itself. Without the overhead of the nodes, its got to be faster!
hi, you should compare the collision system with the rigidbody in unity vs godot, in my opinion godot needs to improve a lot in the collision system.
I would also love to see this tested against the Unity PhysX integration from Nvidia (Unity's built-in PhysX integration has threading issues and is generally slower) which also supports GPU simulation.
Dont forget to test Havoc physics integration, its 2-3x times faster compared to unity dots physics
STOP REMINDING ME SAD MEMORYS!
YOU ARE IN OUR HEARTS BRACKEYS!
Btw good video!
He's back and had put out a Godot video.
Hey well put together analysis! When you said "Let me open this in Godot 4.0" I had a big HOLDUP moment thinking I missed the big release or something hah. Godot's obviously not quite at the performance level of bigger players but its future potential is truly limitless and I'm definitely excited for it!
Welldone !!
This is very informative video !
Thank you !!
Hope this gets updated to reflect Godot 4 + Jolt engine
Great job at comparing the performace! This video deserves a like
Thanks a bunch for the ccomparison
Right now I'm only interested in simple 3D, so I think Godot's 3D is satisfactory for my needs right now. But that will likely change a year from now.
Let's see how Godot 4 will be. It should greatly increase performance
Wow great video, i just subscribed in case you do more comparison between engines.
Could you do an updated video comparing Godot 4 please
Interesting comparison but here are a few thoughts:
- all your tests were a mixed bag of rendering and physics calculations, for true results you should disable rendering
- I wonder what sleep mode setting you have configured for the Godot (if it has any at all) but when cubes rest on top of each other their contact detection and simulation should get turned off and increase performance not the other way around!
very good comparation
Why your Godot example has no collisions between cubes each other?
He explained in another comment that they do, but the hitboxes were accidentally set smaller than the models.
0:40 Hey, bullet is the physics Skyrim uses.
Can you do some tests on the Hazel engine? I think the full version is only for patreon supporters though
As a kid, I was addicted to Crysis 2 physics videos
Unity seems to have precalculated the forces applyed in a stack and applys some trig sine wave to the stack this reduces collisions witch is the most costly. I would like to see a simulation where you are pushing boxes down a road that would be a hard case to optimize for.
I think Godot takes fps drops from it's graphics. I've tried Godot 3 for just testing reasons. (Note: I've an old GPU, but supports DX11) Just by making 3D terrains and placing few trees, Godot started lagging a lot. Where, I've made a lot of games in Unity, with 3D models, rigs, audios etc. Bigger than the Godot scene. Unity don't lags with those all, where Godot lags with that small scene. Sorry Godot, that's why I don't use Godot for 3D. I use Godot for 2D and Unity for 3D. (I would use 3D for Unreal. But my PC has low-end GPU)
I'm working un Unity only. Why cubes fall inside each other in godot?? Is it ok??
Its because he is using MultiMesh I think
@@juanmanuelcostello9510 This is really weird if rendering have influence on physics.
мультимешь не юзал, но в моих подобных тестах кубики не сливались
@@mypaxa003 Reading on reddit I found that the author misplaced the collitionshape on the cubes there fore that issue
@@dedm0zaj тогда получается дело как раз в мультимеше.
you can't say it handles 700 or 1000 well, if all cubes are overlapping with each other (are inside other cubes - means physics is not accurate in the first place!)
The frame drops on unity I would bet is because of the rendering though. You are getting 20k+ batches. Try instancing those cubes and checking how it performs too.
Now compare against PhysX 4.1 or 5.0 if, also Unreals Chaos Physics.
comparing godot to unity is like comparing unity to UE
Man, it's a great video
But... Mouse clicking noise at the end of some of your recordings isa bit sad
Been youtuber, I have the same issues and solution I've found is to either put your mic in the other direction than your mouse or use keyboard shortcots (if you have a silent keyboard)
Noted and thanks for the tips! Will make improvements in the next video.
@@MeanGeneHacks have a good one!)
Great video ! Godot to the moon 🚀
Not only is the unity physics engine faster but it appears way more accurate in the simulation. The “rigid” body objects in gadot don’t accurately interact when they hit the other blocks as evidenced by the very small pile result in the end no matter the number of blocks.
He replied to another comment saying he had the colliders scaled down by 50%
I wish if you tried to export the unity scene and see if you can push it even further.
But never the less great video
You are correct. I'll make sure to do an apples-to-apples comparison in the next vid. Will export both Godot & Unity.
@@MeanGeneHacks awesome
Can't wait
You should add Stride engine to that comparison
Maybe you can update this but 2022? o.o
How does a small increase make the performance so horrible? Like 1500 vs 1750 rigid bodies with bullet physics?
You don't need to use multimesh because rigidbody objects is a dinamic object.
crysis in intro
hell yeah
Your final thoughts are a bit counter-intuitive; you say that because godot is open source, we can continue to expect updates. But if volunteers don't feel like contributing to those improvements there won't be updates. Unity on the other hand is (optionally) paid software, so as long as someone pays them, there's a guarantee for updates and improvements.
Godot also has a budget coming from donations and support from companies using Godot in production, albeit smaller than Unity's, but there still core development team, not enthusiasts only.
@@MeshVoid While it's true that godot has a small budget that supports a partially varying arrangement of core contributors, those when hired (or even those like juan who are part of the core-core) tend and are expected to work on very specific topics which is not comparable to commercial software support. It would be cool if this came with a maybe future popularity gain of godot, so one could actually use it commercially while not being forced at times to be a c++ developer too, knowing the insides of the engine to support oneself. But for now it's just realistic to not expect guarantees there from godot.
@@Flavelius I know =)
Fair criticism. I really should have gone into a bit more on what I see as the benefits of Godot being open source, namely that the community has much more say in the development of updates than with a closed source engine where the company decides what to focus efforts on. Having said that, if the community decides additional resources need to be allocated to Physics, I think there is a much better chance of that happening with Godot than with Unity.
So, f.e. Adobe software being a billion dollar company must be producing absolutely bug free and fun to use software which makes all users happy and they are fixing bugs even years after release (*cough* Flash *cough*)
Godot is blender 2.0 . it started out rough , but will finish strong . also.. not to peg on other devs.. but i don't know why i would need more than 500 objects all in collision with each other at once
Please do compare with UE4 or UE5
Try unreal engine 5 vs unity physics
Forgot to enable dynamic batching in unity
do one with unreal
This type of videos are mostly for flexing the engine's power, in practical use case scenario any engine would be able to handle any game.
I mostly agree with you. In part 2, I draw the same basic conclusion.
So i could use game maker to create gta 5?
@@italofreitas221 yes. Its probably possible.
@@italofreitas221 also, I said practical use case scenario and making a GTA5 level game for one guy at his home is not practical at all, it is next to impossible.
That's an overgeneralization. Every millisecond counts. This shows more computation time will end up being taken by physics, leaving less breathing room for other areas of the game. And if you're targeting mobile for example, performance becomes extremely crucial unless you're making a simple 2D game or something with no real physics.
Unity.. 😱
Godot should stop trying to reinvent the wheel and just use bullet.
unity uses a subset of havok in dots atleast right?
Havok is an optional plugin for dots. The default is unity physics.
@@MeanGeneHacks iirc the unity physics got help from the havok team though
May be UE4 show better result? :D
What about o3de
I don't know why everyone thinks it's pronounced godoh when it's spelled Godot
still waiting for 4.0
i considering using phsyx for my engine, then I saw this and thought that bullet physics is fine
It's fine, but it's not as good... It's not like you have to pay money to use phsyx, and it's quite easy to setup.
@@warvstar does physx have soft body support
@@etaashmathamsetty7399 not in the public versions, 5.0 should have soft body support but they are taking their sweet time to release it. Amd FEMFX is what I use with physx currently.
I always thought my PC just sucks
very cool video,
wondering how unreal engine will perform
There shouldn't be any big differences compared to Unity. Both uses Nvidias PhysX physics engine.
@@aleksihiltunen7063 thought unreal engine would be better
This explains my games issue... -_- damn it godot... get your shit together.
unity use physX, it more poweful then other Physic Engines... and PhysX can calculate on video card...
The PhysX in Unity does not use the GPU because they wanted to ensure it works on any system, otherwise it would be restricted to Nvidia users.
It is entirely on CPU. And Unity even has a new Physics system they built themselves that performs many times faster than the one in this video...
ua-cam.com/video/U6idEdIEsa0/v-deo.html
I compare Unity DOTS vs Godot Physics Server in part 2: ua-cam.com/video/-vvxBWVXxe4/v-deo.html
Unity has better looking ui and tech than Godot but Godot maybe much better to help you finish a good game as long as it's not too taxing. You want to try to get yourself better and finishing a project. Agodot might be better for that. If your a tech beast then yeah unity is there too. You can always switch between the two depending on what your trying to do. 3 year proj then yeah go with unity. But Godot give you more room to get familiar with the concepts. Assuming people are starting out with software dev.
wait! i not understand? where is 1000 cubes on godot? they not have form after drop! why they in godot in intersect? this no physics in godot!
Please watch Part 2 where I explain this: ua-cam.com/video/-vvxBWVXxe4/v-deo.html
Ah yes, testing performance in editor instead of a built project. Big brain time.
Unity's performance on 3D was so far ahead of Godot, that I didn't bother exporting the Unity project in this video; however, when comparing Unity DOTS vs Godot Physics Server in part 2, I used the exported projects in both cases.
Godot is a fun open source project, but I do not expect it to reach the performance of professional engines
Try and do this experiment in blender :D
To optimize Unity further, use DOTS physics.
Thanks for the suggestion! I'm working on a follow up video that will compare Unity DOTS to a Godot standalone PhysicsServer.
me can't even run100 bodies:
Funny to watch
res
Unity physics engine is cursed
Fire ray through moving rigid body
Passed through rigid body
Fires rigid body too fast
Passes through
Do anything with rigid bodies
Dies
Then stop using the default options. You can turn on prediction and more accurate calculations. It's performance mode by default and you tweak things to the accuracy you need. There are a plethora of settings to fine-tune the behaviour.
The ray will not pass through a rigidbody though unless you fired the ray *from inside the collider*, then in that case if you expect that to happen, turn on "Rays hit Backfaces".
@@invertexyz I literally didn't fire the ray from withinside the collider, that doesn't make any sense.
I've never had issues firing rays at moving rigidbodies with any other game/physics engine. Sure throwing a rigid body at fast speeds will fucking clip through the wall, but a fucking ray, like come on. Ray casts are supposed to be the most simple shit.
I can make the same argument for Unity3D. Since Unity3D is a paid software, they can afford to hire research and engineering experts.
it's only paid if you make more than $100k per year from the game you made (and at that point, $400 is nothing)
@@albingrahn5576 That's only half true, the paid plans are there all along and there are features you don't get if you don't pay, it's not FORCED until you maake over 100k a year, but it is a paid piece of software
No engine can beat Cryengine in performance. You can only beat it in being user friendly.
Lol, let godot 4.0 come first
@@shwetanksingh2156 comparing things that not exist yet to things that are trusted and proved is not really working 🙄
@@picster you got a point, but i'll will hope that Godot will be the best engine even if it does not get that much performance updates i am happy cause who needs 9 million sprites in thir game walking around :)
1. Godot pro
Unity noob
my question is
unity vs opengl
Unity looks better too 😂
Cool to see they're actively making their engine worse lmao
rip godot
2 different open source physics engines? Unity isnt open source...