For those of you dropping into the comments about the "Clipping Balls". This is not an issue with Jolt, but the default configuration for Godot Physics. The physics solvers are different, but the settings have been optimized for GodotPhysics. Changing a few setting to optimize for Jolt will "fix" this issue, and hopefully when we do see Godot switch to Jolt as 'default', they will ship optimized configuration.
If you were to optimize the settings for Jolt Physics, probably increasing the accuracy wouldn't it also suffer a similar penalty compared to Godot physics?
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased: jolt_3d/limits/max_bodies jolt_3d/limits/max_body_pairs jolt_3d/limits/max_contact_constraints
what people don't know about this physics engine is that is going to SPEED UP all the engine, not just areas in the interactions between bodies but everything that happens in the physics process. which is HUGE performance boost.
What do you mean? all the engine? What if not the interactions of bodies is the physics engine also handling? Sorry I dont get at all what you mean with your statement. Can you give more info please?
I just seriously hope that it won't be a pain to use Jolt in Godot deterministically. I cannot stress how many avenues for multiplayer that would open. Lighter package size, distributed computing based on location/ping. Ultimate multiplayer physics sandbox possible in Godot!
You're tying your project to a third party while taking full responsibility. It needs to be adding a lot of value for it to be justifiable. For big things, like entire physics engine, renderers or entire game engines it's okay, but it's usually not wort it for small libraries.
AFAIK there is still no feature parity between Godot and Jolt but mihe and jrouw will probably make it such its a no brainer replacement. There is still work to do but it sure is promising
I know it sound strange but I preferred they improve their own physics system! By adding Jolt if that has a problem you should wait until they fix the problem Also it would be harder to add new features Jolt has its own math library and memory allocator, but Godot physics use the one in godot core which Help to integrate better to system and reduce exctuable size And many more reason ...
Except that you'd have to wait far longer for problems to be fixed in GodotPhysics, because no one was doing the work. The reality is, throughout the 4.x cycle almost everyone using Godot in 3D was using the Godot-Jolt extension, specifically because both Mihe and JRouwe have been far more responsive adding new features... mostly because noone was working on GodotPhysics.
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased: jolt_3d/limits/max_bodies jolt_3d/limits/max_body_pairs jolt_3d/limits/max_contact_constraints
It is a WIP of course, and as stated in the doc update they need to properly intergrate and optimize Jolt in Godot. That also include bringing Ragdoll physics back, etc.
Bullet physics was removed some years ago, because it just wasn't good enough for Godot. It had some major problems and inconsistencies that made it basically unusable for physics dependent games. As a replacement the Godot devs continued development of their own in-house physics. However, developing a physics engine consumed too much dev time and resources. So they started looking for a replacement. And that's where Jolt comes in.
@@umapessoa6051 I mean, it already is way ahead of any other engine when it comes to 2D... 3D still requires some work, but even so, the engine is already way beyond anything that matters for my skilllevel of game making. Sure, you can't make a ultra realism asset flip game yet, but almost everything else works quite alright.
@@XMaster340 lol, not even close to Unity on 2D and the 3D is barely workable, Bevy was released way later and the 3D is already way better than Godot.
@@umapessoa6051 Lol what? Unity 2D is literally the second worst technology you could choose for a 2D game. Right after Unreal 2D which is just 3D rendered into 2D. Unity's 2D tooling is so messed up and all over the place that I doubt most people would be able to produce even a simple 2D game without the massive community backing that Unity has. And don't get me started on pixel art games. The amount of backbending you have to do to get Unity into a state where it can display pixel perfect 2D graphics is mind boggling! Godot 2D just clicks. Everything is perfectly self explanatory and you can modularize your game way better due to the scene tree. GameObjects suck in comparison. And the best thing (for 2D)? Pixel perfect is achieved by changing a single dropdown value in the project settings.
I noticed that using Jolt as you said is able to handle more balls but the physics didnt work properly and many pass through the container boundaries. So, more speed but les quality?
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased: jolt_3d/limits/max_bodies jolt_3d/limits/max_body_pairs jolt_3d/limits/max_contact_constraints
Jolt seems cool and all but I hope Godot adds support for Nvidia PhysX 5.1 in the future. As far as I can tell Jolt doesn't have fluid simulation and PhysX 5 has crazy good fluid simulation. Also how well does Jolt physics work with networking/multiplayer?
@@natan_amorim_moraes that makes sense from a development workload perspective. I'm not talking about just buoyancy I mean Nvidia GameWorks PhysX/Blast & Flow fluid simulations with actual water simulations. So you could make a hole in a container and the water would spill out. I want to make a physics focused game with water as a hobby project. But of course there's a reason there are virtually no 3d water physics based games, it's hard lol.
@@GoblinArmyInYourWalls but does it perform well? Specifically compared to unreal engine 5? Of course UE5 will be better but by how much? Is it a massive gap or is godot-jolt respectable?
@@GoblinArmyInYourWalls I'm new to developing so I don't know how to set up a scene in two different engines and then understand how to compare their physics accuracy and performance let alone networking replication. I'm asking because I'm trying to decide which engine to pick to learn. Godolt with jolt has my interest but like I said I want to mess around with water and destruction so I have been researching if that is even possible in godot. If it isn't, which it appears to be the case based on my research, then I should probably stick with unreal and its plugins. But I want to keep an eye on godot and see if things change and so I felt like asking some questions on this video.
This is so exciting! Yesterday I found a post on your site about how multi window editor support in Godot 4 makes the editor more 'choppy' than Godot 3. Making the suggested change from the editor was so refreshing and helpful! Thanks for what you do for Godot!
@@Paruthi.618 Both of the alternatives have issues and aren't much better in terms of overall performance, probably partly due to not being officially integrated into the engine.
The Godot 2D physics is great and actually outperforms alternatives in situations I tested for my game. It doesn't have all the features of other physics engines, but you can just use those as an addon if you want it's very easy. The 3D physics of godot was just actual trash and deserves to be deleted. Everyone uses jolt already for 3D through the addon.
Ok thats great. Next the 3D graphic engine. As much as I wanted to focus on Godot I had to take my project to Flax because I just couldnt push the type of look I wanted with Godot and its lacking 3D graphics tooling.
3D graphics are made modelling software. You can model graphics, example in Blender and use Cycles to render reference image and then import stuff to Godot, and then adjust to match with reference.
I was talking modelling. When aiming photorealism, that requires photo references, using photogrammetry, calculating material values when crafting PBR materials. And when creating scene with realistic light values, full unbiased path tracing should be "truth". When importing scene to Godot, real time rasterizer like one found from Godot is optimized for gaming and lights etc. need to be adjusted, so comparing rendered references does the trick making photorealistic graphics. Rendering performance is not issue. Godot renders very fast.
@@gruntaxeman3740 rendering performance is the issue. It still has stutters and undeniable high base cost for lighting, despite being clustered shading. One of the issues is occlusion culling, each time you change occluder's visibilty, you get stutters on CPU. So you can't properly make doors that occlude anything in their closed state. Something, that 1999 game (Quake 3) could do.
@@Capewearer I've done experiments and my CPU from 2011 renders 60fps without dropping frames. I think proper way is not use occluder in doors and instead setup different rooms as different assets, and just disable/enable them when door is opened and closed. Keep occluders as static. Quake engine used PVS and that can be implemented similar way having some structure that handle visibility.
Idk if it’s just me or if it’s the Godot Jolt GDExtension, but I’ve been having a lot of issues with Jolt in my game where as GodotPhysics3D has been working flawlessly. One issue I am constantly observing bodies clipping through other moving bodies which I never experience with the Godot physics engine. Another more annoying one is that balls can’t sent to move up ramps properly with Jolt. I made a collision mesh from a quarter pipe style object mesh and it seems like once a ball hits the first inclined step, it bounces off at some weird angle instead of rolling smoothly along the ramp. With any luck, it’s just tuning errors on my part and that all goes away once 4.4 is out
I love it that Jolt is going to be the default engine in Godot. Your choosen demo is not one of the best to show the strength of Jolt. Sure, it's faster than godot physics with a lot of objects on one big pile. But the strength of Jolt is to handle a lot of small piles way better than godot physic (more realistic as a situation in a game), where Jolt can send objects to sleep and handle all the separated groups. It's a little bit annoying, that most of the Jolt tests on YT are tests with one big pile. And combined objects, where you have a collection of simple shapes defining the object (like a chair out of six boxes, for seat, back and the four legs) are handled better, too.
I see balls falling out though the bowl though so I guess Jolt is broken. Edit: Am I the only one seeing this? Look at 8:45 for example you have balls going through the physics of the bowl and falling out directly.
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased: jolt_3d/limits/max_bodies jolt_3d/limits/max_body_pairs jolt_3d/limits/max_contact_constraints
as others have said, this isn’t an issue with Jolt, it’s an issue with how the scene is currently still configured for GodotPhysics, which needs different settings from Jolt to run its best. if you change the settings to what Jolt likes, the issue should go away.
@SenkaZver "it's open source" is not an excuse for little work done for the simplest thing, what's the point of having a company managed and community software if everyone is to work on it for themselves? If that was the case then it's better for everyone to just make their own engine. Since everything is so easy for you go work on the milestones that have been sitting there for years
@@IPlayKindred people had already worked on it, sometimes it's the fact that they don't wanna merge what the community has already done until it's been a couple years, and also ignoring what the users want added and doing something a small group of people want
that was a horrible fps comparison because the jolt was obviously operating at a much lower fidelity, so you would expect it to be faster. I'm sure if you tuned the Godot ended to behave just as poorly as jolt did there with all the ball leakage it would be as fast
Even though I enjoy the Godot news myself but I'd just kindly suggest to wait for stuff to accumulate a little more, lol, very spammy lately 😅 The videos almost overlap :{
This might be an unpopular opinion but I’d honestly like to see a complete redo of the physics nodes. A major annoyance of mine is you have three majorly different physics nodes that can be moved in three different ways (AnimatedBody, CharacterBody, and Rigidbody) but if you need a body to implement features of two of them, sorry, you have to remake it completely from scratch. In Unity, a Rigidbody covers everything and includes “move and slide” style functions.
If this wasn't only for 3d this would be huge for me. I really wish that there was anything that improved godot's 2d physics; specifically the collisions
@@GoblinArmyInYourWalls I haven't seen what I need, like measured against non-realtime reference how much there are error on things and what features they cover. Plenty of tables and numbers please. There is way too much tests where someone runs same simple physics test and compare how many objects it can handle but that is not that important. I know that Bullet is enough fast, Jolt has enough good performance and based on documentation it can actually handle better cases where size difference of colliding objects are high but everything else is unknown. Like all constraints supported, is there restitution or static friction, geometry models, constraint error, collision penetration error on different frequencies. Point is that real time physics engines are approximating things to make them run fast and Bullet is known to be excellent on features, enough fast and enough accuracy. Major missing feature from Bullet is separate kinetic friction coefficient for materials. There is easily trade-offs that better performance is achieved by making some essential thing simpler and causing simulation to be less accurate so physics engine need careful evaluation from someone who can know physics enough to make fully accurate version for measurements. Accurate version can be poor on performance, like running overnight to get data using double precision.
The issue with these sort of "upgrades", it's not the library being used but how it's implemented. Godot seems to have an issue with properly integrating new features without breaking others. Quantity over quality is what I've noticed Godot aims for. Before the cultists comment, I've been using Godot since the 2.x days, it still had the same issues back then.
@@natan_amorim_moraes They should keep code fully backward compatible and only break in major versions. If something really minor is changed, like some rendering thing, that doesn't matter because they are tuned anyways and only very last phase on development. But physics is different thing. They really messed up physics. They should just stay in Bullet physics on 4.x series and switch to Jolt should be start of 5.x series as it breaks a lot, and also good idea to postpone other breaking changes to next major release. If I want to make new game, I very much consider writing own engine instead of using anything ready while everyone seems to suck on very basics. 1. Unreal engine: Bloated. Too slow iteration time. 2. Unity: Made to develop with wallet. It is just monetizing everywhere. Last time I checked there was something that everything wasn't nice text files compliant with git but it maybe better now. 3. Godot: The development is not so consistent while they do this dumb changes. I still would choose Godot from these three but I believe that drawbacks are barely tolerable. One thing why writing own game engine isn't that bad idea anymore is that Vulkan API seems to be working now so well. Sure it need to put behind interface but before AMD was just garbage on OpenGL so it makes sense to have DirectX on Windows machines. Today game developer can write interface for graphics and use Vulkan API behind that to make rendering working and optimized, and implement some native APIs later when polising. Just need to care that shaders can be compiled everywhere but there are ready solutions for that.
@SenkaZver I have no problems on that how fast or Godot adds features. Quality is also acceptable. But lets be honest about what are Godot strengths: 1. Platform abstraction. I think it is doing better job than Unreal Engine and Unity. 2. Fast iteration speed. This is where it shines too. 3. Developer friendly. Everything is like something to grab and modify if you like. 4. No risk of proprietary, like crazy licensing plans from Unity. But development need to be... predictable, and not wasting own resources or engine user resources. Godot has done smart decisions on that sense on rendering side, like focusing on OpenGL ES 2.0 and OpenGL ES 3.0, and now Vulkan because they really work and less focus on some platform specific stuff because that would be maintenance hell. Things that was questionable for me was GDScript. Like, why? I haven't go that deep on the subject but Javascript was already lingua franca back then, there was ready, highly optimized Javascript engines, tooling was already made and so on. And when porting to browser today, that could just make things simpler some cases, like exposing engine API made with C++ to Javacript and make web releases even more lightweight. Javascript is also possible to compile to wasm if needed. However, there may be something that I don't understand why GDScript was made. But those physics engine changes I understand that they should never remove Bullet. It was also dumb idea to start implementing own when there was ready physics engine so they should focus on more important matters. Even if there is interest to have own physics engine, it must be better one that was already available, and put that experimental on settings until it is ready. While I like Godot and I prefer it more than Unity, there seems to be some project management issues on Godot.
After working on my platformer for a year, I'm not excited about godot switching to a different physics engine. I've had no issues with godot's default physics engine whatsoever. Then again, I'm not spawning in 1200 balls...
Key Links
gamefromscratch.com/godot-4-4-gets-native-jolt-physics-support/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
*BlueSky*: bsky.app/profile/gamefromscratch.bsky.social
-----------------------------------------------------------------------------------------------------------
For those of you dropping into the comments about the "Clipping Balls". This is not an issue with Jolt, but the default configuration for Godot Physics.
The physics solvers are different, but the settings have been optimized for GodotPhysics. Changing a few setting to optimize for Jolt will "fix" this issue, and hopefully when we do see Godot switch to Jolt as 'default', they will ship optimized configuration.
If you were to optimize the settings for Jolt Physics, probably increasing the accuracy wouldn't it also suffer a similar penalty compared to Godot physics?
@@klaesregis7487 yes it does suffer slightly, but still nowhere near GodotPhysics.
@@klaesregis7487as would literally any other physics engine if you messed with the settings too much
"clip this ball in your face"
@@klaesregis7487 It would decrease performance, yes.
That's really cool, GDevelop is using it too.
Both open source engines using the same open source tool as their main 3D physics engine. 🎉
Totally. Using Jolt is a no-brainer, not surprised Godot folks did choose to integrate it too.
@@natan_amorim_moraes I didn't know it existed until just now
Jolt's repo has a good list of all kinds of other projects that use it! Is quite cool, and hopefully they too get some attention!
Godot physic engine history: godot physics, then bullet, then again godot phyrics, now Jolt.
Now I need a built in ragdoll system
@natan_amorim_moraes I hope to be added sooner maybe Godot 4.5
they’ll sort it out soon enough
@@natan_amorim_moraes At some point "backwards compatibility" is a crutch, not a feature.
7:45 seems like Jolt has a severe leakage problem though. Balls are coming out through the walls.
It's not a problem, it's a feature where there's X, Y, Z, Spacetime.
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased:
jolt_3d/limits/max_bodies
jolt_3d/limits/max_body_pairs
jolt_3d/limits/max_contact_constraints
I have a question i.e these physics calculation works on cpu or the gpu?
@@bmqww223 pretty sure its cpu with simd
If it's enough for Horizon it's enough for me.
what people don't know about this physics engine is that is going to SPEED UP all the engine, not just areas in the interactions between bodies but everything that happens in the physics process. which is HUGE performance boost.
What do you mean? all the engine? What if not the interactions of bodies is the physics engine also handling? Sorry I dont get at all what you mean with your statement. Can you give more info please?
Funny enough, Godot initially rejected Jolt and were saying that they will complete their own one
It would have been ok with their own, if they primary dev for that didn't quit halfway through.
@@hipflipped yep, he quit like 3 month after he started and it was incomplete for years
I think they are starting to change their tune on their stubbornness.
Finally figured out how open source works, cooperation and progress go hand in hand
@@GameUnionTV do you know why he quit? I assume it wasn't a budget problem on Godot's side?
Thanks. This is the best coverage of this change and its relevance that I’ve seen at this point
So glad I stumbled across this! Excellent coverage and great resources, thank you so much!
2:28 dev 7 already released
, he added that as a visual note
@@liefhebber6277oh yeah, I guess I missed that or maybe it was added later…😔
dev7 also gets documentation tooltips which will be super helpful
Yo, thanks for sharing, that upgrade is exactly what i was hoping for to see!
Could you take another look at the current state of Torque3D and perhaps make a short tutorial?
I just seriously hope that it won't be a pain to use Jolt in Godot deterministically.
I cannot stress how many avenues for multiplayer that would open. Lighter package size, distributed computing based on location/ping.
Ultimate multiplayer physics sandbox possible in Godot!
Idk why they don't just use more MIT libraries like this. Speeds up development and is apparently better quality than their home brew stuff.
You're tying your project to a third party while taking full responsibility. It needs to be adding a lot of value for it to be justifiable. For big things, like entire physics engine, renderers or entire game engines it's okay, but it's usually not wort it for small libraries.
That's an incredible performance increase.
AFAIK there is still no feature parity between Godot and Jolt but mihe and jrouw will probably make it such its a no brainer replacement. There is still work to do but it sure is promising
Doesn't even link to the Jolt Physics engine...
I know it sound strange but I preferred they improve their own physics system!
By adding Jolt if that has a problem you should wait until they fix the problem
Also it would be harder to add new features
Jolt has its own math library and memory allocator, but Godot physics use the one in godot core which
Help to integrate better to system and reduce exctuable size
And many more reason ...
Except that you'd have to wait far longer for problems to be fixed in GodotPhysics, because no one was doing the work.
The reality is, throughout the 4.x cycle almost everyone using Godot in 3D was using the Godot-Jolt extension, specifically because both Mihe and JRouwe have been far more responsive adding new features... mostly because noone was working on GodotPhysics.
Like several other people in the comments i am somewhat concerned with the balls diffusing trough the walls of the bowl.
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased:
jolt_3d/limits/max_bodies
jolt_3d/limits/max_body_pairs
jolt_3d/limits/max_contact_constraints
It is a WIP of course, and as stated in the doc update they need to properly intergrate and optimize Jolt in Godot. That also include bringing Ragdoll physics back, etc.
Those are some amazing performance improvements
Gdevelop also integrated jolt, but noone speaks about that.
Wait, what happened to Bullet physics?
Bullet physics was removed some years ago, because it just wasn't good enough for Godot. It had some major problems and inconsistencies that made it basically unusable for physics dependent games. As a replacement the Godot devs continued development of their own in-house physics. However, developing a physics engine consumed too much dev time and resources. So they started looking for a replacement. And that's where Jolt comes in.
@@XMaster340 now they should start doing it to everything else, then the engine can be on pair with Unity, lol
@@umapessoa6051 I mean, it already is way ahead of any other engine when it comes to 2D...
3D still requires some work, but even so, the engine is already way beyond anything that matters for my skilllevel of game making. Sure, you can't make a ultra realism asset flip game yet, but almost everything else works quite alright.
@@XMaster340 lol, not even close to Unity on 2D and the 3D is barely workable, Bevy was released way later and the 3D is already way better than Godot.
@@umapessoa6051 Lol what? Unity 2D is literally the second worst technology you could choose for a 2D game. Right after Unreal 2D which is just 3D rendered into 2D. Unity's 2D tooling is so messed up and all over the place that I doubt most people would be able to produce even a simple 2D game without the massive community backing that Unity has. And don't get me started on pixel art games. The amount of backbending you have to do to get Unity into a state where it can display pixel perfect 2D graphics is mind boggling!
Godot 2D just clicks. Everything is perfectly self explanatory and you can modularize your game way better due to the scene tree. GameObjects suck in comparison. And the best thing (for 2D)? Pixel perfect is achieved by changing a single dropdown value in the project settings.
I noticed that using Jolt as you said is able to handle more balls but the physics didnt work properly and many pass through the container boundaries. So, more speed but les quality?
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased:
jolt_3d/limits/max_bodies
jolt_3d/limits/max_body_pairs
jolt_3d/limits/max_contact_constraints
jolt physics is great, i have ported openmw to use jolt physics and that should land sometime soon hopefully too. step aside bullet :)
But how much performance will be given back to fix the colliders phasing through each other?
Jolt seems cool and all but I hope Godot adds support for Nvidia PhysX 5.1 in the future. As far as I can tell Jolt doesn't have fluid simulation and PhysX 5 has crazy good fluid simulation.
Also how well does Jolt physics work with networking/multiplayer?
It can do deterministic simulations, so it works with networking
@@natan_amorim_moraes that makes sense from a development workload perspective.
I'm not talking about just buoyancy I mean Nvidia GameWorks PhysX/Blast & Flow fluid simulations with actual water simulations. So you could make a hole in a container and the water would spill out. I want to make a physics focused game with water as a hobby project. But of course there's a reason there are virtually no 3d water physics based games, it's hard lol.
@@GoblinArmyInYourWalls but does it perform well? Specifically compared to unreal engine 5? Of course UE5 will be better but by how much? Is it a massive gap or is godot-jolt respectable?
@@Bagginsess I mean, you can test it yourself within a few minutes, godot is a small engine, like 60mb
@@GoblinArmyInYourWalls I'm new to developing so I don't know how to set up a scene in two different engines and then understand how to compare their physics accuracy and performance let alone networking replication. I'm asking because I'm trying to decide which engine to pick to learn. Godolt with jolt has my interest but like I said I want to mess around with water and destruction so I have been researching if that is even possible in godot. If it isn't, which it appears to be the case based on my research, then I should probably stick with unreal and its plugins. But I want to keep an eye on godot and see if things change and so I felt like asking some questions on this video.
This is so exciting! Yesterday I found a post on your site about how multi window editor support in Godot 4 makes the editor more 'choppy' than Godot 3. Making the suggested change from the editor was so refreshing and helpful! Thanks for what you do for Godot!
Yay, this along with megascans. Ue5 kitbash and customisation but ease of use like unity without runtime fees.
we really need a 2D physics upgrade 😂
box2D 😎
Tried Rapier ?
@@Paruthi.618 Both of the alternatives have issues and aren't much better in terms of overall performance, probably partly due to not being officially integrated into the engine.
@@Paruthi.618 From my experience. Box2D nuked pinjoints (angle limits). Rapier2D nuked raycasts (on polygon colliders). Choose your poison.
The Godot 2D physics is great and actually outperforms alternatives in situations I tested for my game. It doesn't have all the features of other physics engines, but you can just use those as an addon if you want it's very easy. The 3D physics of godot was just actual trash and deserves to be deleted. Everyone uses jolt already for 3D through the addon.
Ok thats great. Next the 3D graphic engine. As much as I wanted to focus on Godot I had to take my project to Flax because I just couldnt push the type of look I wanted with Godot and its lacking 3D graphics tooling.
3D graphics are made modelling software.
You can model graphics, example in Blender and use Cycles to render reference image and then import stuff to Godot, and then adjust to match with reference.
@@gruntaxeman3740 runtime performance still depends on Godot side. Realtime applications are more complex than bunch of prerendered images, you know.
I was talking modelling. When aiming photorealism, that requires photo references, using photogrammetry, calculating material values when crafting PBR materials. And when creating scene with realistic light values, full unbiased path tracing should be "truth".
When importing scene to Godot, real time rasterizer like one found from Godot is optimized for gaming and lights etc. need to be adjusted, so comparing rendered references does the trick making photorealistic graphics.
Rendering performance is not issue. Godot renders very fast.
@@gruntaxeman3740 rendering performance is the issue. It still has stutters and undeniable high base cost for lighting, despite being clustered shading. One of the issues is occlusion culling, each time you change occluder's visibilty, you get stutters on CPU. So you can't properly make doors that occlude anything in their closed state. Something, that 1999 game (Quake 3) could do.
@@Capewearer
I've done experiments and my CPU from 2011 renders 60fps without dropping frames.
I think proper way is not use occluder in doors and instead setup different rooms as different assets, and just disable/enable them when door is opened and closed. Keep occluders as static.
Quake engine used PVS and that can be implemented similar way having some structure that handle visibility.
8:31 there are some balls leaking through the wall, so at least godot physics had one advantage
that's definitely not a Jolt problem but a configuration problem by GFS
@@kewa_design or godot configuration...
eitherway looks like this require more configuration than godot physics
Idk if it’s just me or if it’s the Godot Jolt GDExtension, but I’ve been having a lot of issues with Jolt in my game where as GodotPhysics3D has been working flawlessly. One issue I am constantly observing bodies clipping through other moving bodies which I never experience with the Godot physics engine. Another more annoying one is that balls can’t sent to move up ramps properly with Jolt. I made a collision mesh from a quarter pipe style object mesh and it seems like once a ball hits the first inclined step, it bounces off at some weird angle instead of rolling smoothly along the ramp. With any luck, it’s just tuning errors on my part and that all goes away once 4.4 is out
I love it that Jolt is going to be the default engine in Godot.
Your choosen demo is not one of the best to show the strength of Jolt. Sure, it's faster than godot physics with a lot of objects on one big pile. But the strength of Jolt is to handle a lot of small piles way better than godot physic (more realistic as a situation in a game), where Jolt can send objects to sleep and handle all the separated groups. It's a little bit annoying, that most of the Jolt tests on YT are tests with one big pile. And combined objects, where you have a collection of simple shapes defining the object (like a chair out of six boxes, for seat, back and the four legs) are handled better, too.
I see balls falling out though the bowl though so I guess Jolt is broken. Edit: Am I the only one seeing this? Look at 8:45 for example you have balls going through the physics of the bowl and falling out directly.
I noticed this right away then looked at the original GodotPhysics3D setting just to see if it was behaving the same way which was not the case.
This is not a Jolt issue, but rather a configuration issue by GFS. The following settings should all be increased:
jolt_3d/limits/max_bodies
jolt_3d/limits/max_body_pairs
jolt_3d/limits/max_contact_constraints
as others have said, this isn’t an issue with Jolt, it’s an issue with how the scene is currently still configured for GodotPhysics, which needs different settings from Jolt to run its best. if you change the settings to what Jolt likes, the issue should go away.
I've been using jolt for about the last 5 months and it's way better
Massive, you say?
Jolt is awesome
Finally, now time for them to add what the community has been asking for a long time
they already did
@@IPlayKindred Yeah on thing after years of begging lol
@@psuw looked at the issue myself, thousands of lines of code involved, its not a simple switch, ya'll are incredibly spoiled.
@SenkaZver "it's open source" is not an excuse for little work done for the simplest thing, what's the point of having a company managed and community software if everyone is to work on it for themselves? If that was the case then it's better for everyone to just make their own engine. Since everything is so easy for you go work on the milestones that have been sitting there for years
@@IPlayKindred people had already worked on it, sometimes it's the fact that they don't wanna merge what the community has already done until it's been a couple years, and also ignoring what the users want added and doing something a small group of people want
FUCK YEAH
8:37 the ball is quantum tunneling out of the container
Happens to the best of us.
that was a horrible fps comparison because the jolt was obviously operating at a much lower fidelity, so you would expect it to be faster. I'm sure if you tuned the Godot ended to behave just as poorly as jolt did there with all the ball leakage it would be as fast
Even though I enjoy the Godot news myself but I'd just kindly suggest to wait for stuff to accumulate a little more, lol, very spammy lately 😅
The videos almost overlap :{
First that insane 'outskirts' graphics "demo", now Jolt... can this Christmas get much better for Godot?
Segregate the activist from the community
not gonna talk about elephant in the room?? there are balls phasing through the container lol
He did say he was only going to compare performance
Last time I heard it wasn't yet ready for the consoles
This might be an unpopular opinion but I’d honestly like to see a complete redo of the physics nodes. A major annoyance of mine is you have three majorly different physics nodes that can be moved in three different ways (AnimatedBody, CharacterBody, and Rigidbody) but if you need a body to implement features of two of them, sorry, you have to remake it completely from scratch. In Unity, a Rigidbody covers everything and includes “move and slide” style functions.
If this wasn't only for 3d this would be huge for me. I really wish that there was anything that improved godot's 2d physics; specifically the collisions
Now we need to compare the performance of the extension vs the module
This is really good. As I understand it, the Godot physics system was never truly completed.
I had a look at yhis recently - I'm wondering what will be needed in my own engine... this might be a bit much.
We also see with Jolt balls escaping through walls...
Shocking news! Godot has got *acceptable* performance.
The balls are fading through the walls... I do like jolt though
Hope they just add PhysX 5 support already... Jolt is nice for videogames, but not for accurate simulations.
Will never see PhysX 5 in Godot, only available in O3DE.
I would like to see some detailed comparison Bullet vs Jolt.
@@gruntaxeman3740 there are already dozens on UA-cam that do this
@@GoblinArmyInYourWalls
I haven't seen what I need, like measured against non-realtime reference how much there are error on things and what features they cover. Plenty of tables and numbers please.
There is way too much tests where someone runs same simple physics test and compare how many objects it can handle but that is not that important. I know that Bullet is enough fast, Jolt has enough good performance and based on documentation it can actually handle better cases where size difference of colliding objects are high but everything else is unknown.
Like all constraints supported, is there restitution or static friction, geometry models, constraint error, collision penetration error on different frequencies.
Point is that real time physics engines are approximating things to make them run fast and Bullet is known to be excellent on features, enough fast and enough accuracy. Major missing feature from Bullet is separate kinetic friction coefficient for materials.
There is easily trade-offs that better performance is achieved by making some essential thing simpler and causing simulation to be less accurate so physics engine need careful evaluation from someone who can know physics enough to make fully accurate version for measurements. Accurate version can be poor on performance, like running overnight to get data using double precision.
Herro mike!
you know what else is massive? that low taper fade meme is like, dude it is still massive
The issue with these sort of "upgrades", it's not the library being used but how it's implemented. Godot seems to have an issue with properly integrating new features without breaking others. Quantity over quality is what I've noticed Godot aims for. Before the cultists comment, I've been using Godot since the 2.x days, it still had the same issues back then.
@@natan_amorim_moraes
They should keep code fully backward compatible and only break in major versions. If something really minor is changed, like some rendering thing, that doesn't matter because they are tuned anyways and only very last phase on development.
But physics is different thing. They really messed up physics. They should just stay in Bullet physics on 4.x series and switch to Jolt should be start of 5.x series as it breaks a lot, and also good idea to postpone other breaking changes to next major release.
If I want to make new game, I very much consider writing own engine instead of using anything ready while everyone seems to suck on very basics.
1. Unreal engine: Bloated. Too slow iteration time.
2. Unity: Made to develop with wallet. It is just monetizing everywhere. Last time I checked there was something that everything wasn't nice text files compliant with git but it maybe better now.
3. Godot: The development is not so consistent while they do this dumb changes.
I still would choose Godot from these three but I believe that drawbacks are barely tolerable.
One thing why writing own game engine isn't that bad idea anymore is that Vulkan API seems to be working now so well. Sure it need to put behind interface but before AMD was just garbage on OpenGL so it makes sense to have DirectX on Windows machines. Today game developer can write interface for graphics and use Vulkan API behind that to make rendering working and optimized, and implement some native APIs later when polising. Just need to care that shaders can be compiled everywhere but there are ready solutions for that.
@SenkaZver
I have no problems on that how fast or Godot adds features. Quality is also acceptable.
But lets be honest about what are Godot strengths:
1. Platform abstraction. I think it is doing better job than Unreal Engine and Unity.
2. Fast iteration speed. This is where it shines too.
3. Developer friendly. Everything is like something to grab and modify if you like.
4. No risk of proprietary, like crazy licensing plans from Unity.
But development need to be... predictable, and not wasting own resources or engine user resources. Godot has done smart decisions on that sense on rendering side, like focusing on OpenGL ES 2.0 and OpenGL ES 3.0, and now Vulkan because they really work and less focus on some platform specific stuff because that would be maintenance hell.
Things that was questionable for me was GDScript. Like, why? I haven't go that deep on the subject but Javascript was already lingua franca back then, there was ready, highly optimized Javascript engines, tooling was already made and so on. And when porting to browser today, that could just make things simpler some cases, like exposing engine API made with C++ to Javacript and make web releases even more lightweight. Javascript is also possible to compile to wasm if needed. However, there may be something that I don't understand why GDScript was made.
But those physics engine changes I understand that they should never remove Bullet. It was also dumb idea to start implementing own when there was ready physics engine so they should focus on more important matters. Even if there is interest to have own physics engine, it must be better one that was already available, and put that experimental on settings until it is ready.
While I like Godot and I prefer it more than Unity, there seems to be some project management issues on Godot.
@SenkaZver your comments are always funny, my lil chap!
@SenkaZver your fanatism shows it, the fact you take the criticism like you are the guilty one. It explains why you're foaming with mouth pretty well.
Bepuphysics better
After working on my platformer for a year, I'm not excited about godot switching to a different physics engine. I've had no issues with godot's default physics engine whatsoever. Then again, I'm not spawning in 1200 balls...
Very nice. I once despised Godot, and would only use Unreal. But times are changing.
I don't see Godot overtaking Unreal, but I left Unity a few years back and I think it can eat that market steadily over the next few years.
Igual es un disparate de rendimiento.
I hope that everything works out with Redot!
Reddit's not a game engine.
Talk about ReDot sometimes.
Redot's a grift.
@@PerpetualExplosion "Grift" Ic ne knowe.
now is time for graphics 😁😁😁
FPS will rise/not move if they figure out how to not count the not visible objects :)
...they already do this. This has been built into the engine for like a decade now.
Godot has also, somehow, but not unexpectedly, made Jolt significantly worse. Collision fails, high memory usage, etc. Godot gonna Godot, lol.
Wokot isnt worth it.
Incel says what?
Zzzzz...
"THATS INSANE!" Sound clip should be used for trick in skateboarding game :D ua-cam.com/video/KRvt_QPs8uI/v-deo.html