Moving the physics to a different thread didnt do anything because its the only expensive task the cpu is doing. If you had all the cubes have simple AI for example, running the AI and physics simultaneously could have huge performance gains over same thread execution
This brings a lot of hope, because 1.- There's a lot of room for Godot's performance to improve and now that it is getting much more attention things should start to get better quicker. and 2.- Seeing how an external open source solution can be integrated and work seamlessly into Godot's current design paradigm (thank's to the job the awesome developer who made it possible). Thank you for making this video.
The cool thing about Godot, seems like because it’s so extensible, it can be improved without updating the engine core while also providing a single target for developers. Imagine a nanite virtualized geometry clone
@@C0SSTY Would that be real time tesselation? It is where you remove or add triangles in an area of the mesh. I am not too keen on its features, but it sounds like what this is.
I think the reason why running it in a separate thread didn't do anything noticeable for you is because the only thing this application is doing is physics. If you wanted to see the affects, you could maybe add some dummy process in a script and then check the difference. IE. Have a while loop in _process that always runs for 30 ms (forcing the game to a maximum of 30 fps). Theoretically the physics will be heavily impacted unless running them in a separate thread. Also, thanks for sharing, I might check out Jolt!
Ran this test on my machine and got similar results to you. Both started at 60 fps. For Godot3D, there was a tremendous drop in framerate to an average of about 19 fps by around 830 cubes. For Jolt, there was solid 60 fps until about 2000 cubes, but the only severe drop to sub-30 fps was by around 2500 cubes.
Nice video! As far as I know, the execute in separate thread as it says will give the physics engine it's own thread. In cases like yours where you are doing practically nothing other than physics calculations each frame anyways it doesn't matter, but if you were to say have path finding and other such computationally demanding tasks running on your main thread at the same time it could give you a significant boost in performance.
Great introduction to Jolt. I'm delighted that Godot allows for integrating these systems relatively easily. It's definitely something I would like to try in my own game someday. Very good job. 😎
The seperate thread performance wasn't noticeable because instead of replacing THEN with AND SIMULTANEOUSLY it was the same in both since the update code was basically nought, thats also why threaded physics was a bit worse, because its prepping and applying the stuff from a second thread without having any savings to make up for it.
@DavidSerranoIO it will probably create it once, but every physics update it has to prepare everything before sending it to the dedicated thread, then update everything when it's done, it's not much overhead because the actual calculations are being done on the second thread but because there wasn't a lot going on the overhead outweighed or cancelled the tiny saving. As soon as you start doing stuff in the main thread the savings will outweigh the overhead and you'll see better performance, I think someone else might have said it a bit better 😅
Also a community member is working on bullet as a plugin too should some users want to keep using it. I think it's already in a usable state though I'm not sure if it supports all it's past features yet.
Nice video! I'm actually doing a similar benchmark recently. A word of caution: the Jolt plugin for Godot doesn't not support Android and iOS yet, which could be a dealbreaker for a lot of devs.
i feel like it would have been more instructive to display the fps on a chart over the time/number of cubes instead of going for the average value, generally speaking averages dont mean anything, whereas number of physics items interacting with each other is an important metric when making a physics based game...
I hope Godot devs take the same approach for rendering. I think this could be hard to accept for Godot devs because rendering is a key point of a game engine and Godot has improved a lot. But some users would prefer to plug in a custom renderer to go on using Godot with different visual results.
It would be cool if it was possible, so someone could for example implement something like AMD's open source Capsaicin real-time renderer in to Godot, or something like that.
You mean like a modular system where you just plug in features? That's how it should be IMO, with templates with plug-ins for standard things and beginners. Unreal Engine is kind of like that but it's templates are for a few specific things. You still have to spend time unplugging the features you don't want.
Maybe. Unity made that mistake with their multiple Render Pipelines, and it just comes off as a garbled mess with way too many compromises on any given pipeline.
Nice video, I tried the default physics engine and the godotphysics3d; however, both was causing lag whenever running the current scene. The jolt seems to be working out great and if it's better when it comes to fps, then thats even better in my eyes
Jolt is even more performant than shown in this video. Godot devs should make Jolt as Godot module, not as addon, is has to be a part of official engine release.
Unfortunately, the weakest part of Godot Physics (3D Softbody) is implemented in Jolt but is not yet implemented in Godot-Jolt. Godot Softbody 3D is unusable. Hopefully we get high performance 3D SoftBody options soon!
Does Jolt get rid of the stuttery movement from move_and_slide/collide ? I have a simple arcade game with a ball and it just isn't smooth moving. Like I'd need to add interpolation to smooth it out and that is tricky considering I am using bounces, vector math functions and move_and_collide. I am working on the same project in Unreal Engine, and it is much smoother there.
I'm curious if the FPS drop in Jolt was more because of hitting the limits of Godot's renderer than because the physics themselves were bogging down. Not sure if there's a good way to get around that (maybe spawn physics objects without a mesh component and update the positions of the instances in a multimesh node to follow them? But looping through the multimesh instances and updating their positions would probably get pretty costly too)
One big gain with Jolt is how it can decide work over threads. But to so do, it needs the physics objects not to all be in one pile. But more like how it more often appear kn games. Multiple piles here and there, and a bunch of stray objects. If you think Jolt seems good now, if you test those scenarios, it will be waaay better.
@@DavidSerranoIO yes. Like imagine sets of rag dolls, a set of a shelf with things on it, a table with things. A stack of boxes. If there are islands of such things that the engine can detect as separate, Jolt will be able to fully parelalize them. So if you have 16 cores, it can runs 16 of those groups at the same time as 1, as it is fully parallel and without dependencies.
well as soon as i tried jolt my player no longer snapped weirdly to even slight slopes, and didn't get stuck on walls so this defientely a massive improvement :D
I'm no expert in threads, so take what I say with a big pinch of salt, but I think maybe moving the physics to a separate thread only improves performance if your main thread is already overloaded and slowing things down. I mean, doing all the work in a single thread doesn't do anything for performance. So since the physics computations are still all in a single thread, it will perform the same. I think what helps performance is when you break up the workload into several threads, reducing the total time it takes to compute the entire thing. So, taking the physics away from the main thread may help if the main thread is overloaded. Someone correct me if I'm wrong, but that's the way I understood it. (Of course there are other uses where threads can help performance, like background loading, or running subprocesses without halting the main one.)
Regarding CPU threads on Windows. You can use Multimedia Class Scheduler Service (MMCSS) to alter scheduler priority of a single thread. Very useful for repetitive task that must run very quickly for a short amount of time and repeat indefinitely. Stuff like filling audio/video/screen buffers before audio/graphics cards read it in the next cycle. It makes a huge difference in performance because Windows will run your task more often and at more stable intervals. The tradeoff is it will give you lower amount of compute time per slice.
For a fast game engine you would have multiple threads of different priority and you would assign core affinity manually. There are lesser known factors to consider. Capturing all available compute resource and making them spin until you need them will help a lot. It prevents other processes from taking CPU and it ensure it's available very fast when you need it. Think of it like a dragster spinning its wheel until it's ready to hit the start button. There's a bit of an arms race between the operating system which wants to limit ressources and the game engine which wants to capture them.
you should check the profiler to see what else is impacting performance. for example, i remember that many years ago, microsoft anounced that directx 12 draw call performance would be 5x faster than directX11, i didnt understood much about it so i concluded games would be 5x faster, but that is not how things work at all. that just means that, an better way to look at this, goes like this: 32 miliseconds per frame (30fps), you debug your dx11 game and see that 20 miliseconds are wasted on draw calls, and the remaining 13ms are everything else, that means that if you port the game to dx12, those 20ms should become 4ms , and if you sum that with everything else you get ~16ms per frame, that is pretty much 60fps, so you game should now run at 60! in other words, in that scenario you would get up to twice the original perfomance, not 5x more! if an layman (like i was) see the info that dx12 drawcall performance is 5x faster, he might interpret it as: i will be able to pick this game that runs at 12fps on my computer and run it as 60fps! but the truth is, even if the game is ported to dx12, he will see just an small increase in performance, in my example he would get twice the performance and 24fps is playable for some people, but the issue is, my example was an ideal scenario where most of the time to render each frame was doing draw calls. er... sorry for the long explanation >.> anyway, your benchmarks are usefull, but we should look at the profiler to have an better guess of what is happening, it seems that godot physics is really ineficiente, it has 2x less performance, maybe 3x, maybe even more! or maybe something else is happening such as occlusion culling, since the position of each object is completely different using different physics calculations. anyway, this jolt physics seems more realistic, so even if we disconsider performance it might be usefull.
Of course perfomance is important in physics, but I'm more interested in how realistically objects behave. Do you think that GP or Jolt has an advantage in that regard, or are they the same? I like Jolt based on both performance and realism, but a problem I have with it is that it adds like an extra 50mbs to both the project and the build. Unless if that 50mbs is Jolt code and nothing more, this is something I dislike.
Your test seems problematic without a lid to your saucepan. I don't think it effects the results too much but its not too desirable sending cubes out of the pan constantly
Yes, it is a detail to improve for future benchmarks. In any case, I would say that the computation of those cubes continues to occur even if they leave the screen.
I would say that the initiative to incorporate Bullet into Godot 4 has not yet been completed, right? In fact, I read about someone who wanted to implement it but I don't even know if the project has started.
For the godot physics test, did you instance rigidbody nodes on the scene tree, or did you use the physics server directly? Cause that will make a huge difference and is what they recommend in the documentation
In this case I am creating the rigid bodies from GDScript and adding them to the node tree. In any case, the idea is not to test the general physics performance of Godot, but to compare Godot Physics with Jolt, and in both cases I am using the same methodology.
Fantastic highlight for such an important element gamedev/Godot's overall ecosystem! Sub it is then. And if you perhaps read this comment, a question: Could Flutter possibly benefit from a Godot integration package? For adding some light 3d elements to 2d apps/games.
Thank you! And yes, I read all your comments :) As for your question: I'm not sure... both engines have completely different graphics pipelines, I'm not an expert in these topics, so I wouldn't know how to answer you. But in any case, what I am sure of is that with enough work in Flutter, now that Impeller will be the new default rendering engine, you can surely achieve powerful light effects. The only issue is whether there will be the desire to do so given that although Flutter has Flame, it is not a famous engine in the world of video game development.
I do not think so. What is acting here is the physics engine (a library in C++), the instrumentation of the cubes, whether you do it in GDScript or C# I don't think it matters, since I don't think it barely affects performance.
Which CPU did you used in demo？Both Godot physics and Jolt look underwhelming. 🤔 Jolt run 60Hz with only 2721 cubes in such a simple scene is ridiculously inefficient (when compared to PhysX/Havok many years ago).
Yep. But it's not...up to par. Now that the work of this Horizon studios engineer is up for public as Open Source, they should just take it, and run with it. He clearly knows what he is doing much better than the guys that were cobbling together Godot's new physics (while also trying to build a bunch of other features). I think Juan even proposed it soooo...
As far as I know, Jolt is for 3D. In the case of 2D, I don't know how the physics state is right now in Godot 4, but it is certainly a good thing to review.
@@DavidSerranoIO Hmm, I guess that makes sense in a way, when you say it increased by that much. Otherwise 100% of 42 is 42, so 31% more would seem odd to end up being 97.... but alright
There was Visualscript in Godot 3, iirc it's interpreted into gdscript which is already an interpreted language and the workflow was nowhere near blueprint's finesse (I can't remember it well enough to give an example)
The visual programming language is no longer supported in Godot 4 as far as I know. However, GDScript is a very accessible language designed for beginners. I recommend it to you.
@DavidSerranoIO I did! And I figured out the error. You cannot have any collision shapes with any dimensions that equal 0. My floor had no height, neither did some other collisions. Jolt needs a non zero value whereas godot physics don't care
This benchmark probably gives much better results in Unity, even comparing it to Jolt. In any case, we all know what Unity developers face these days...
I've seen some similar videos and the unity physics was about 25% more performant than Jolt. I've moved to Godot and Jolt will do perfectly for my needs.
There is a video testing exactly that..IIRC with Godot physics, Unity has 4x higher number. Then switch to Jolt physics, Unity has 2x higher number. So essentially Jolt doubles the physics number, therefore shortening the gap to Unity from 4x to 2x.
@@DavidSerranoIO Yes! And there is A proposal for replacing Godots 2D physics with it much like the proposal for adding Jolt. It looks like there are A few points where both jolt and box2d differ from Godot Physics, but the maintainers of the respective addons and the devs working on the physics themselves seem willing to change some things around to help integration. I expect Jolt to be worked on first given the official maintainers seem more interested, and Jolt is closer to feature parity with Godot Physics than box2d. But without A developer for Godot Physics 2D either, I expect that the Box2d proposal will continue to be worked on.
@@MrXlee1967 Box2d was a bit buggy for me, if you're willing to just use a orthocam and use characterbody3d I personally find that Jolt is buttery smooth. Granted I'm working on a HD2D game (oh wait, can't use that term ^O^, I guess I'll coin the term Hi-Fi2D) so obv using 3D, just look at dungeon quest 3 remake or octopath traveler and you'll get the idea.
Godot Physics is totally unusable now, ported my physics based Vehicles from Godot 3 (Bullet) to v4 and it is a mess... exploding physics parts not implemented features...
Good news, but a very bad benchmark technique, even for a "non-exhaustive" benchmark. Do YOUR research! -> vsync on, so all the data collected before fps drops below 120 is worthless and skews the results -> especially since Godot-Jolt was held back at 120 fps for a much, much longer portion of the test than Godot-Physics, reducing its average by a lot! -> Godot-Physics ejected a lot of cubes from the pan (probably also pushed many out through its bottom), meaning it wasn't calculating as many cubes -> you probably had Godot's "jitter-fix" on at its default value of 0.5, it should be 1.0 or 0.0 for benchmarking (depending on what you wish to benchmark) -> Godot-Jolt readme explicitly says they don't support godot multithreading yet Better technique would have been: Pick a number of cubes, wait for all of them to spawn, then average the FPS over a period of a fixed number of revolutions of the paddle. Jitter Fix must be set to 0 for this test. Set a high physics frame rate, e.g. 240, for better precision in performance measured.
You equated the 131% uptick in average fps entirely to Jolt as if Jolt is 131% faster than Godot Physics, but this is invalid. There is a lot Godot is doing that is not physics, which is the same for both tests. So if the total framerate is 131% higher and Jolt is the only difference, Jolt must have performed > 131% faster. It would be more interesting to look at the amount of time saved (nanoseconds per frame or so) when switching to Jolt vs Godot Physics.
@@DavidSerranoIO I am making a FPS and the decals for bullet holes would follow the player instead of being attached to the world, and the raycast would refuse to work
Gotta love how there's like 100 'tutorials' and "showcases' of this, but none show how to install the danm thing so i had to go and read the github, neat.
the fact that you need to switch a third party physics engine and hope they keep maintaining it on the future is the one red flag any serious developer team needs
Yes tho most every other engine is using a 3rd party physics engine heck only recently did unreal even make their own physics engine in house after using physX
Well, it's all a matter of resource investment. In reality many pieces of software we use today have dependencies on other third-party libraries. Let's hope that Godot Physics can catch up one day.
How is it a red flag? Unity uses third party physics too (box2d). Even horizon forbidden west used jolt. also jolt is open source with MIT license, so you don't need to hope they maintain it since anyone (with the right knowledge of course) can fork and maintain it. Also also, Juan has said jolt will become the official 3d physics engine for godot (with box2d being official for 2d physics)
I see..., I suppose there are cases in which it will be necessary to do a refactor, in complex games changing the physics engine is not as easy as changing a switch and having everything work as before.
![[DRAGON BALL LEGENDS REVEALS ＆ STUFF] LEGENDS FESTIVAL 2024 Special Edition Part 2](http://i.ytimg.com/vi/af0phKxitX8/mqdefault.jpg)
👉 Watch the second part of the video to continue exploring the physics system in Godot: ruclips.net/video/Kq8M3S50LNs/видео.html
Moving the physics to a different thread didnt do anything because its the only expensive task the cpu is doing. If you had all the cubes have simple AI for example, running the AI and physics simultaneously could have huge performance gains over same thread execution
Oh I see, thanks for the explanation!
Moving physics to multiple threads would have an effect though
@@Boxing_Gamer It doesn't seem to have any effect, as I show here: ruclips.net/video/Kq8M3S50LNs/видео.html
This brings a lot of hope, because 1.- There's a lot of room for Godot's performance to improve and now that it is getting much more attention things should start to get better quicker. and 2.- Seeing how an external open source solution can be integrated and work seamlessly into Godot's current design paradigm (thank's to the job the awesome developer who made it possible). Thank you for making this video.
I agree with you, thx for watching the video!
The cool thing about Godot, seems like because it’s so extensible, it can be improved without updating the engine core while also providing a single target for developers. Imagine a nanite virtualized geometry clone
Seeing something like nanite in Godot would be incredible...🤤
I read somewhere that something similar to nanite is coming to Godot in update 4.2. Idk if it's true.
@@C0SSTY Would that be real time tesselation? It is where you remove or add triangles in an area of the mesh. I am not too keen on its features, but it sounds like what this is.
They redid the new system and replaced GDnative with GDextension to make it easier to integrate and extend the engine.
I think the reason why running it in a separate thread didn't do anything noticeable for you is because the only thing this application is doing is physics. If you wanted to see the affects, you could maybe add some dummy process in a script and then check the difference. IE. Have a while loop in _process that always runs for 30 ms (forcing the game to a maximum of 30 fps). Theoretically the physics will be heavily impacted unless running them in a separate thread. Also, thanks for sharing, I might check out Jolt!
Mmh yes that makes sense, I'll try to make the change to test it!
4:57 Test Godot Physics
6:17 Test Godot-Jolt Physics
Omg - just tried it for my prototype, feels like a brand new game! So much better
Ran this test on my machine and got similar results to you. Both started at 60 fps. For Godot3D, there was a tremendous drop in framerate to an average of about 19 fps by around 830 cubes. For Jolt, there was solid 60 fps until about 2000 cubes, but the only severe drop to sub-30 fps was by around 2500 cubes.
it's like you read my mind, this is exactly what I needed right now, very helpful video, I'm definitely gonna use godot-jolt in my project
Thanks for watching the video!
Nice video! As far as I know, the execute in separate thread as it says will give the physics engine it's own thread. In cases like yours where you are doing practically nothing other than physics calculations each frame anyways it doesn't matter, but if you were to say have path finding and other such computationally demanding tasks running on your main thread at the same time it could give you a significant boost in performance.
Great introduction to Jolt. I'm delighted that Godot allows for integrating these systems relatively easily. It's definitely something I would like to try in my own game someday. Very good job. 😎
Thanks! ;)
The seperate thread performance wasn't noticeable because instead of replacing THEN with AND SIMULTANEOUSLY it was the same in both since the update code was basically nought, thats also why threaded physics was a bit worse, because its prepping and applying the stuff from a second thread without having any savings to make up for it.
I see, then the problem is a bit in the management of the creation and lifecycle of the additional thread, right?
@DavidSerranoIO it will probably create it once, but every physics update it has to prepare everything before sending it to the dedicated thread, then update everything when it's done, it's not much overhead because the actual calculations are being done on the second thread but because there wasn't a lot going on the overhead outweighed or cancelled the tiny saving. As soon as you start doing stuff in the main thread the savings will outweigh the overhead and you'll see better performance, I think someone else might have said it a bit better 😅
Jolt solved my projectile clipping problems immediately. Great plugin!
It is certainly very promising!
Very interesting, thanks for the video! It would be very interesting to see the performance difference of raycasts in both physics engines as well
Thanks for the suggestion! Noted on my list of video ideas ;)
I wouldn't mind the guys at godot focusing on their own physics, as long as we can have jolt as a plugin
I get the feeling that that's a bit of the idea, considering how seriously they are taking the proposal to adopt godot-jolt as an "official" plugin.
Also a community member is working on bullet as a plugin too should some users want to keep using it. I think it's already in a usable state though I'm not sure if it supports all it's past features yet.
Competition is good because you can go with the winner & it shows the devs there's room for improvement
Nice video! I'm actually doing a similar benchmark recently. A word of caution: the Jolt plugin for Godot doesn't not support Android and iOS yet, which could be a dealbreaker for a lot of devs.
Yes, totally true, I should have warned that in the video too. Good point.
Godot Jolt merged support for Android and iOS on 2023-11-05.
Godot 4.2+ only.
thank youu, keep it up with more godot tutorials!!
Thx for watching the video!
Juan has been saying on twitter about potentially having jolt be the main physics engine, so that'll be interesting
Yes, I think it would be good for Godot if Jolt was the default engine.
i feel like it would have been more instructive to display the fps on a chart over the time/number of cubes instead of going for the average value, generally speaking averages dont mean anything, whereas number of physics items interacting with each other is an important metric when making a physics based game...
Additionally, FPS is a non-linear measurement so when measuring performance milliseconds per frame is better.
Thanks for the feedback, it's a good idea. If I find enough time I will try to create that graph and share it.
That's awesome. Behavior with Jolt seems a lot better thab today's default version. Thanks for sharing.
You're welcome ;)
I hope Godot devs take the same approach for rendering. I think this could be hard to accept for Godot devs because rendering is a key point of a game engine and Godot has improved a lot. But some users would prefer to plug in a custom renderer to go on using Godot with different visual results.
It would be cool if it was possible, so someone could for example implement something like AMD's open source Capsaicin real-time renderer in to Godot, or something like that.
You mean like a modular system where you just plug in features? That's how it should be IMO, with templates with plug-ins for standard things and beginners. Unreal Engine is kind of like that but it's templates are for a few specific things. You still have to spend time unplugging the features you don't want.
Maybe. Unity made that mistake with their multiple Render Pipelines, and it just comes off as a garbled mess with way too many compromises on any given pipeline.
Nice video, I tried the default physics engine and the godotphysics3d; however, both was causing lag whenever running the current scene. The jolt seems to be working out great and if it's better when it comes to fps, then thats even better in my eyes
Wow! It's the good choise for Besiege style game!
What happened with the plans for Vulkan, though?
Anyone know?
Thank you for this valuable information. It is much appreciated.
You're welcome!
Great video, no crap, subscribed! :)
Thx!
great video
Thanks!!
Jolt is even more performant than shown in this video. Godot devs should make Jolt as Godot module, not as addon, is has to be a part of official engine release.
Yes, at least until Godot Physics works just as well.
Very interesting experiment. thanks for the demonstration
No problem! Thanks for watching the video!
Thanks for this video! Very usefull
Thanks!!
Unfortunately, the weakest part of Godot Physics (3D Softbody) is implemented in Jolt but is not yet implemented in Godot-Jolt. Godot Softbody 3D is unusable. Hopefully we get high performance 3D SoftBody options soon!
Does Jolt get rid of the stuttery movement from move_and_slide/collide ? I have a simple arcade game with a ball and it just isn't smooth moving. Like I'd need to add interpolation to smooth it out and that is tricky considering I am using bounces, vector math functions and move_and_collide. I am working on the same project in Unreal Engine, and it is much smoother there.
I'm curious if the FPS drop in Jolt was more because of hitting the limits of Godot's renderer than because the physics themselves were bogging down. Not sure if there's a good way to get around that (maybe spawn physics objects without a mesh component and update the positions of the instances in a multimesh node to follow them? But looping through the multimesh instances and updating their positions would probably get pretty costly too)
thats actually amazing, thanks for this tutorial
You're welcome! :)
Thankyou! ❤🔥
You're welcome!
One big gain with Jolt is how it can decide work over threads. But to so do, it needs the physics objects not to all be in one pile. But more like how it more often appear kn games. Multiple piles here and there, and a bunch of stray objects.
If you think Jolt seems good now, if you test those scenarios, it will be waaay better.
I don't know if I just understood you, you mean creating something like "groups" of many objects with space between them?
@@DavidSerranoIO yes. Like imagine sets of rag dolls, a set of a shelf with things on it, a table with things. A stack of boxes. If there are islands of such things that the engine can detect as separate, Jolt will be able to fully parelalize them. So if you have 16 cores, it can runs 16 of those groups at the same time as 1, as it is fully parallel and without dependencies.
The main problem with jolt is that it is not thread safe, this is what I read from their wiki page
I have to upgrade my game to Godot 4 to get this physics engine. I need it. But I have couples Tween animation to convert.
well as soon as i tried jolt my player no longer snapped weirdly to even slight slopes, and didn't get stuck on walls so this defientely a massive improvement :D
Jolt wiped the floor with the default physics.
While jolt cubes didn't go crazy I could've sworn I saw one faze through the floor
I'm no expert in threads, so take what I say with a big pinch of salt, but I think maybe moving the physics to a separate thread only improves performance if your main thread is already overloaded and slowing things down. I mean, doing all the work in a single thread doesn't do anything for performance. So since the physics computations are still all in a single thread, it will perform the same. I think what helps performance is when you break up the workload into several threads, reducing the total time it takes to compute the entire thing. So, taking the physics away from the main thread may help if the main thread is overloaded.
Someone correct me if I'm wrong, but that's the way I understood it.
(Of course there are other uses where threads can help performance, like background loading, or running subprocesses without halting the main one.)
Regarding CPU threads on Windows. You can use Multimedia Class Scheduler Service (MMCSS) to alter scheduler priority of a single thread. Very useful for repetitive task that must run very quickly for a short amount of time and repeat indefinitely. Stuff like filling audio/video/screen buffers before audio/graphics cards read it in the next cycle. It makes a huge difference in performance because Windows will run your task more often and at more stable intervals. The tradeoff is it will give you lower amount of compute time per slice.
For a fast game engine you would have multiple threads of different priority and you would assign core affinity manually. There are lesser known factors to consider. Capturing all available compute resource and making them spin until you need them will help a lot. It prevents other processes from taking CPU and it ensure it's available very fast when you need it. Think of it like a dragster spinning its wheel until it's ready to hit the start button. There's a bit of an arms race between the operating system which wants to limit ressources and the game engine which wants to capture them.
you should check the profiler to see what else is impacting performance.
for example, i remember that many years ago, microsoft anounced that directx 12 draw call performance would be 5x faster than directX11, i didnt understood much about it so i concluded games would be 5x faster, but that is not how things work at all.
that just means that, an better way to look at this, goes like this:
32 miliseconds per frame (30fps), you debug your dx11 game and see that 20 miliseconds are wasted on draw calls, and the remaining 13ms are everything else, that means that if you port the game to dx12, those 20ms should become 4ms , and if you sum that with everything else you get ~16ms per frame, that is pretty much 60fps, so you game should now run at 60!
in other words, in that scenario you would get up to twice the original perfomance, not 5x more!
if an layman (like i was) see the info that dx12 drawcall performance is 5x faster, he might interpret it as: i will be able to pick this game that runs at 12fps on my computer and run it as 60fps!
but the truth is, even if the game is ported to dx12, he will see just an small increase in performance, in my example he would get twice the performance and 24fps is playable for some people, but the issue is, my example was an ideal scenario where most of the time to render each frame was doing draw calls.
er... sorry for the long explanation >.>
anyway, your benchmarks are usefull, but we should look at the profiler to have an better guess of what is happening, it seems that godot physics is really ineficiente, it has 2x less performance, maybe 3x, maybe even more! or maybe something else is happening such as occlusion culling, since the position of each object is completely different using different physics calculations.
anyway, this jolt physics seems more realistic, so even if we disconsider performance it might be usefull.
Of course perfomance is important in physics, but I'm more interested in how realistically objects behave. Do you think that GP or Jolt has an advantage in that regard, or are they the same?
I like Jolt based on both performance and realism, but a problem I have with it is that it adds like an extra 50mbs to both the project and the build. Unless if that 50mbs is Jolt code and nothing more, this is something I dislike.
Your test seems problematic without a lid to your saucepan. I don't think it effects the results too much but its not too desirable sending cubes out of the pan constantly
Yes, it is a detail to improve for future benchmarks. In any case, I would say that the computation of those cubes continues to occur even if they leave the screen.
Wait, the only thing I have to change is switch physics engine? No new code? Sounds awesome, I'll try it out in my project
Yes, just change the physics engine, and then check that everything still works as it should.
Do you think this could work better with my RigidBody3D helicopter?
Hi David. How does this physics engine deal with objects which change size and shape over time?
Hello, I have not yet had the opportunity to test this specific case, it would be necessary to investigate it.
Just discovered The Mirror platform. Wondering if they utilize this ao?
What game is this @ 0:19?
It's a Unity demo: ruclips.net/video/9ADpYQIQg1w/видео.html
What about comparison of Jolt and Bullet?
I would say that the initiative to incorporate Bullet into Godot 4 has not yet been completed, right? In fact, I read about someone who wanted to implement it but I don't even know if the project has started.
For the godot physics test, did you instance rigidbody nodes on the scene tree, or did you use the physics server directly? Cause that will make a huge difference and is what they recommend in the documentation
could I ask what you mean? I think I only instance rigidbodies in the scene. Is there another way?
In this case I am creating the rigid bodies from GDScript and adding them to the node tree. In any case, the idea is not to test the general physics performance of Godot, but to compare Godot Physics with Jolt, and in both cases I am using the same methodology.
@@DavidSerranoIO A comparison of this test and this test but in a physics server Would actually be really interesting.
@@Faunarr Good feedback, I'll write it down!
@@DavidSerranoIO
Fantastic highlight for such an important element gamedev/Godot's overall ecosystem! Sub it is then.
And if you perhaps read this comment, a question: Could Flutter possibly benefit from a Godot integration package? For adding some light 3d elements to 2d apps/games.
Thank you! And yes, I read all your comments :) As for your question: I'm not sure... both engines have completely different graphics pipelines, I'm not an expert in these topics, so I wouldn't know how to answer you. But in any case, what I am sure of is that with enough work in Flutter, now that Impeller will be the new default rendering engine, you can surely achieve powerful light effects. The only issue is whether there will be the desire to do so given that although Flutter has Flame, it is not a famous engine in the world of video game development.
Does anyone know how to make jolt physics work with VR? im having issues.
For what kind of game do you need to simulate the physics of 1000 entities?
So with C# decoupling that's coming, will it be possible to optimize all this even more?
I do not think so. What is acting here is the physics engine (a library in C++), the instrumentation of the cubes, whether you do it in GDScript or C# I don't think it matters, since I don't think it barely affects performance.
Which CPU did you used in demo？Both Godot physics and Jolt look underwhelming. 🤔 Jolt run 60Hz with only 2721 cubes in such a simple scene is ridiculously inefficient (when compared to PhysX/Havok many years ago).
I have an old machine, it's an i7-8750H with a GTX 1070 mobile.
Is it possible you could compare godot default vs jolt with this same test scene on android phone ?
Yeah! I'm writing it down for possible future videos.
Can you do a tutorial about joint2d in godot bcs in dont found hinge joint how can i simulate it
Didn't they rewrite the physics system for godot 4, is it still bad?
Yes, there is still work to do...
Yep. But it's not...up to par. Now that the work of this Horizon studios engineer is up for public as Open Source, they should just take it, and run with it. He clearly knows what he is doing much better than the guys that were cobbling together Godot's new physics (while also trying to build a bunch of other features). I think Juan even proposed it soooo...
@@verendale1789 thx!
How about 2D physics? I assume it might be different relative results.
As far as I know, Jolt is for 3D. In the case of 2D, I don't know how the physics state is right now in Godot 4, but it is certainly a good thing to review.
Well I guess it not easy to maintain those modules and update them.
No...for such a small team it is quite an achievement that they have pushed the engine as far as they have, it is certainly something admirable.
Why do all of the physics look so "slowmotion" like even when running at 120fps?
maybe cause these cubes are so big
Maybe it's because of the video encoding, I think it's at 24 FPS...
7:23 131%? 97/42 ~ 2.3095, so you mean about 231%?
No, 131%. 97 FPS compared to 42 FPS represents an increase of approximately 130.95%, rounded to 131%.
@@DavidSerranoIO Hmm, I guess that makes sense in a way, when you say it increased by that much. Otherwise 100% of 42 is 42, so 31% more would seem odd to end up being 97.... but alright
Is there a system like unreal blueprint programming system in godot?
There was Visualscript in Godot 3, iirc it's interpreted into gdscript which is already an interpreted language and the workflow was nowhere near blueprint's finesse (I can't remember it well enough to give an example)
@@myavatargotsnowedon9156 I see, thank you ;)
The visual programming language is no longer supported in Godot 4 as far as I know. However, GDScript is a very accessible language designed for beginners. I recommend it to you.
@@DavidSerranoIO I don't know, if it is not supported I couldn't use it
I wonder which is faster, Jolt or Bepu 2
Jolt itself is capable of scaling with multiple cores, does the Godot port do this?
switching to jolt physics broke every single collison box I had in my project... no collision is detected rip
Wow, I hope you had a backup of the project before making the change 😅
@DavidSerranoIO I did! And I figured out the error. You cannot have any collision shapes with any dimensions that equal 0. My floor had no height, neither did some other collisions. Jolt needs a non zero value whereas godot physics don't care
Is Jolt only for 3d?
As far as I know, yes, it's for 3D only.
Rather than making Jolt an official plugin, they just need to work together to make Jolt the official GodotPhysics engine.
Is jolt compatible with web, android or iOS?
Pretty good benchmark, but it's better to make it with ucapped fps
Thanks, good point!
Can you please compare it unity?
I want to know what is the comparision with unity.
Unity, having been around for longer, probably runs better. With that said, Unity has been a dumpster fire recently so.....
This benchmark probably gives much better results in Unity, even comparing it to Jolt. In any case, we all know what Unity developers face these days...
I've seen some similar videos and the unity physics was about 25% more performant than Jolt. I've moved to Godot and Jolt will do perfectly for my needs.
Unity is faster but not only because of the physics. The base engine performance does affect the libraries too.
There is a video testing exactly that..IIRC with Godot physics, Unity has 4x higher number.
Then switch to Jolt physics, Unity has 2x higher number.
So essentially Jolt doubles the physics number, therefore shortening the gap to Unity from 4x to 2x.
if it schedules physics on a e-core using that single checkbox that would be bad and make a lot of sense on why its worse
does it have 2d functions?
Use Box2D for 2D and Jolt for 3D, never use Godots default physics...
Is there any plugin for Box2D ??
@@DavidSerranoIO Yes!
And there is A proposal for replacing Godots 2D physics with it much like the proposal for adding Jolt.
It looks like there are A few points where both jolt and box2d differ from Godot Physics, but the maintainers of the respective addons and the devs working on the physics themselves seem willing to change some things around to help integration.
I expect Jolt to be worked on first given the official maintainers seem more interested, and Jolt is closer to feature parity with Godot Physics than box2d.
But without A developer for Godot Physics 2D either, I expect that the Box2d proposal will continue to be worked on.
@@DavidSerranoIO is it worth doing a 2d test? vs box2d? thanks for the vids and the feedback your making
@@MrXlee1967 Box2d was a bit buggy for me, if you're willing to just use a orthocam and use characterbody3d I personally find that Jolt is buttery smooth. Granted I'm working on a HD2D game (oh wait, can't use that term ^O^, I guess I'll coin the term Hi-Fi2D) so obv using 3D, just look at dungeon quest 3 remake or octopath traveler and you'll get the idea.
Godot Physics is totally unusable now, ported my physics based Vehicles from Godot 3 (Bullet) to v4 and it is a mess... exploding physics parts not implemented features...
Yes...have you tried it with Jolt?
this videos script is written like a school paper that was to short.
very good
Good news, but a very bad benchmark technique, even for a "non-exhaustive" benchmark. Do YOUR research!
-> vsync on, so all the data collected before fps drops below 120 is worthless and skews the results
-> especially since Godot-Jolt was held back at 120 fps for a much, much longer portion of the test than Godot-Physics, reducing its average by a lot!
-> Godot-Physics ejected a lot of cubes from the pan (probably also pushed many out through its bottom), meaning it wasn't calculating as many cubes
-> you probably had Godot's "jitter-fix" on at its default value of 0.5, it should be 1.0 or 0.0 for benchmarking (depending on what you wish to benchmark)
-> Godot-Jolt readme explicitly says they don't support godot multithreading yet
Better technique would have been: Pick a number of cubes, wait for all of them to spawn, then average the FPS over a period of a fixed number of revolutions of the paddle. Jitter Fix must be set to 0 for this test. Set a high physics frame rate, e.g. 240, for better precision in performance measured.
Thanks for the feedback!
You equated the 131% uptick in average fps entirely to Jolt as if Jolt is 131% faster than Godot Physics, but this is invalid. There is a lot Godot is doing that is not physics, which is the same for both tests. So if the total framerate is 131% higher and Jolt is the only difference, Jolt must have performed > 131% faster.
It would be more interesting to look at the amount of time saved (nanoseconds per frame or so) when switching to Jolt vs Godot Physics.
Jolt just completely failed in my fps
Why do you say it?
@@DavidSerranoIO I am making a FPS and the decals for bullet holes would follow the player instead of being attached to the world, and the raycast would refuse to work
What is a game there? ruclips.net/video/BKNIgHjJ6p8/видео.html
looks so cool
It's a technical demo of Unity: ruclips.net/video/9ADpYQIQg1w/видео.html
Suenas español y no se porque xd
Por qué será? 😂
@@DavidSerranoIO No si ya se notaba ya 😂
Gotta love how there's like 100 'tutorials' and "showcases' of this, but none show how to install the danm thing so i had to go and read the github, neat.
Already did B)
the fact that you need to switch a third party physics engine and hope they keep maintaining it on the future is the one red flag any serious developer team needs
Yes tho most every other engine is using a 3rd party physics engine heck only recently did unreal even make their own physics engine in house after using physX
Well, it's all a matter of resource investment. In reality many pieces of software we use today have dependencies on other third-party libraries. Let's hope that Godot Physics can catch up one day.
How is it a red flag? Unity uses third party physics too (box2d). Even horizon forbidden west used jolt. also jolt is open source with MIT license, so you don't need to hope they maintain it since anyone (with the right knowledge of course) can fork and maintain it. Also also, Juan has said jolt will become the official 3d physics engine for godot (with box2d being official for 2d physics)
The vast majority of game engines that have anything more advanced than shape overlap, use third party physics engines.
i tried jolt and it destroyed my projectile physics. My shotgun fires with flat capsules and my pistol which uses get_collision point to aim broke
I see..., I suppose there are cases in which it will be necessary to do a refactor, in complex games changing the physics engine is not as easy as changing a switch and having everything work as before.