Better Godot physics with Jolt - Part 2
HTML-код
- Опубликовано: 1 окт 2024
- Link to part 1: • Switch to Jolt: the ne...
In this video, I expand on the Godot benchmark tests that I did in the previous video comparing these two game physics libraries: Godot Physics and Jolt. Does separating objects that can collide with each other help to improve performance? What exactly is the purpose of moving physics computation to a separate thread? What happens if we create the cubes using PhysicsServer instead of nodes?
☺ Support the channel:
Any donation is gratefully received, thank you!
- Via my website: davidserrano.i...
- Via RUclips's Super Thanks (⬆ Button labeled THANKS above ⬆)
🔔 Subscribe:
Subscribe to my channel to see more videos like this:
www.youtube.com...
📖 Useful resources:
- Benchmark project used in this video:
github.com/svp...
- Godot Jolt:
github.com/god...
- Games footage by Godot Engine (creativecommon...
• Godot Engine - Desktop...
🔵 Follow me:
Find out about my latest videos and publications:
davidserrano.io/
/ davidserranoio
hashnode.com/@...
dev.to/svprdga
mastodon.socia...
---
Godot logos are licensed under Creative Commons Attribution 4.0 International: creativecommon...
"Nissan Silvia S15 Custom" (skfb.ly/oLGzy) by blakebella is licensed under Creative Commons Attribution (creativecommons....
Some B-Roll clips are provided by Videezy: www.videezy.com
Music credits:
Cinematic Documentary | Majestic by Alex-Productions |
• Cinematic Documentary ...
Music promoted by onsound.eu/
Track: Infraction- Just Evil
Music provided by Infraction No Copyright Music
Spotify: spoti.fi/3FqoNJ6
2:50 I wonder if the script's calculations were too heavy to make much of a difference in FPS between the physics engines? I don't know much about this stuff, just curious.
5:58 the thing here is: multiplying the matrixes limits the fps to ~20. So it dosent really matter, what the physics are doing.
The idea was to be able to find out if it was possible to perform physics calculations in another thread, in such a way that a matrix multiplication process would not affect it.
yeah, but the problem is you're binding the cpu up regardless what the physics engine is doing, so moving the physics to another thread might make physics run better (more accurately) but it will have no effect on the thing you're measuring (fps) because what you're doing on the main thread alone will cause the fps to drop more and more as you add nodes. It seems like for this particular thing fps isn't a great metric
@@aranasaurus Mmmh I see, thanks for the clarification!
At 6:56 - why are you still creating a new renderingserver instance and material for each cube? By my understanding, this means each cube is a draw call. Creating many materials especially should be considered expensive. In this circumstance you should be using instanced rendering (multimesh in Godot) because you need to render thousands of identical cubes with only minor per-instance data (transform and color, for which to have effect make sure you enable Vertex Color > Use as Albedo and Is sRGB in your material)
Thanks for the feedback, I will take it into account in future similar tests!
The Jolt integration doesn't currently support running on a separate thread, so it shouldn't make any difference to perf. If you check the output in the editor it gives you this message:
src\spaces\jolt_space_3d.cpp:86 - Running on a separate thread is not currently supported by Godot Jolt. Any such setting will be ignored.
My doubt is. Those cubes are being instantiated at runtime? If so, this probably interferes in the results. It would be better to use object pooling.
What is object pooling?
It's a technique to improve performance by avoiding the creation or destruction of objects while the game is running. It's commonly used in bullet hell games. Instead of creating or deleting the bullets when needed, thousands of bullets are created at the beginning and are kept to be used and reused when needed.
Look for object pooling in Google if you want to know more about it and when it's a good idea to use it.
I'm guessing it means Instantiate however many cubes you need right at the start and then slowly add them to the scene so the instantiation cost isn't interfering. @@shindig9000
@@shindig9000 Object Pooling is a process to improve performance by avoiding the creation and destruction of objects (which is usually pretty costly). To do this, you have a pool of objects that you take from when you need a certain object and then when you are done with the object, it returns to the pool. Because you are reusing objects, you avoid the creation/destruction overhead (though you take a slight hit in memory).
Particle systems make heavy use of object pooling.
e.g. You have a object pool of 10 Bullet objects.
Your character fires a gun, so the game requests a Bullet from the object pool and then sets it's values and adds it to the world.
An enemy fires a gun, so the game requests a Bullet from the object pool and then sets it's values and adds it to the world.
One of the Bullets hit a wall, so the game removes it from the scene and returns it to the object pool.
The other bullets hits an enemy, so the game removes it from the scene and returns it to the object pool.
If the pool is empty when an object is requested, the pool will create new objects and add them to the pool
@@Oshroth
Ah, thank you for the reply.
Is this something that happens on the back end or is this something that the user is supposed to set up or has some kind of control over?
u try rapier physics ar consider use
The hyper fixation on the physics performance (from ALL parties) makes me worry about the future of Godot. Neither game makers, nor game players, especially care that you can run 2500+ cubes in the system before a drop in framerate, when you can only run up to 1000 in the other. What DOES matter is that the player could stack one cube on another and jump onto of the collection without the game spazzing out and yeeting them into the stratosphere. This is exactly why removing Bullet was widely regarded as a bad move.
Edit: It's also worth noting that the removal of Bullet was largely a political move, not a technical one.
Strongly disagree. It's correct that you don't have to run so many objects at once but games tend to have a lot of stuff going on as they scale. You aren't only going to be running physics on the main thread, it'll be a load of stuff (even when you go off-thread, you'll always have to synchronize at some point). Ideally you want physics to have as little impact on the game's performance as possible.
Also, this isn't the case for every game, but sometimes there just is a lot of physics stuff happening. Like if you are simulating constraints on a lot of vehicles in some sort of driving game, that'll be a concern pretty fast. Think buoyancy / soft body collisions also. That's not easy.
Bullet was removed because the developer just wasn't interested in supporting what godot needed. This is extremely important if it's going to be relied upon in a game engine. Even with jolt development accommodating game engine-specific requirements, it still lacks a lot of features.
Oh and also, don't really see a problem with adding stuff that has good performance as an option? Godot physics won't be going away for a good while, if ever. If you need it, I don't see why there's a problem with high performance at little development expense.
@@SirTZN From your last paragraph, sounds like you don't understand what actually happened, or maybe I'm wrong?
From what I understand, they didn't simply add another physics engine. If that's all it was there would be zero problem. They *replaced* Bullet with Jolt in Godot 4.0. Critically, Bullet no longer works in Godot 4.0 without cumbersome 3rd party workarounds last I checked.