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
And jolt already had one, but it was not implemented because of backwards compat with godot physics I think, they talked about it on PR about things that jolt has that were not on godot but they said is for the future
@@ClockworkGearhead It's not a console, it's a game development engine. They're not going to say "SOL" to devs who may want to version bump +1 on their project.
@@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.
They have had this problem for years, where the Godot's head mother fucker thinks he can reinvent all the wheels untill the people who are actually working on that part of the engine begs him to just use the already available "wheels".
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!
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.
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.
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
It's FOSS. It was ridiculously easy to add Jolt in yourself. If you require the foundation to "officially" add it into the base system to use it, you're not cut out to be a dev.
@@psuw Almost no one begged because everyone was just adding it in on their own. Us, actual devs, don't require the foundation to implement systems to use those systems.
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
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 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
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
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.
@@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.
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.
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?
jolt already has some stuff fluid related but it was not implemented in godot because the focus is to eventually replace godot physics and not build from zero around jolt, PhysX 5.1 probably is better in many things than jolt, but even the creator of godot-jolt could not implement everything like he wanted using the plugin system godot has, so I imagine integrating PhysX 5.1 would be quite the challenge and would probably be a fork
@@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?
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 :{
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.
One of the biggest focus of this PR was to not break compatibility with Godot physics, I don't know how well this was accomplished in practice but it was a point of focus during the PR discussion repeated many times, one user even said something like "You guy broke backwards compat multiple time since 4.0, why is this time keeping it a focus?", and some of the features exclusives on jolt were not implemented on Godot to keep compatibility with Godot physics, but i'm not using Godot to know if they succeeded.
@@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.
"Godot is so slow to add things!" "Godot doesn't focus on quality, they just try to cram as much stuff in as fast as possible!" It's funny that you try to deflect that you're a "long time user of Godot" while decrying people as cultists... when your very statement tells us that your claim is likely false and that you're the actual cultist with no understanding of FOSS or Godot.
@@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.
Godot's 3D probably has a few more years before it's an alternative to Unreal for 3D. But maybe one day it'll finally be a good alternative for smaller 3D projects over Unreal.
@@TheRealAfroRick It will never overtake Unreal, but for small projects, Godot might be a viable alternative to Unreal since Unreal's size and power might be unoptimal for smaller project.
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.
Dagor engine also uses jolt, but no one cares about Dagor engine, can't find anyone using it
@@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!
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.
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?
So glad I stumbled across this! Excellent coverage and great resources, thank you so much!
Now I need a built in ragdoll system
And jolt already had one, but it was not implemented because of backwards compat with godot physics I think, they talked about it on PR about things that jolt has that were not on godot but they said is for the future
@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.
@@ClockworkGearhead It's not a console, it's a game development engine. They're not going to say "SOL" to devs who may want to version bump +1 on their project.
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.
Thanks. This is the best coverage of this change and its relevance that I’ve seen at this point
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.
They have had this problem for years, where the Godot's head mother fucker thinks he can reinvent all the wheels untill the people who are actually working on that part of the engine begs him to just use the already available "wheels".
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…😔
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!
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.
Yo, thanks for sharing, that upgrade is exactly what i was hoping for to see!
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.
dev7 also gets documentation tooltips which will be super helpful
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
We also see with Jolt balls escaping through walls...
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
Those are some amazing performance improvements
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
It's FOSS. It was ridiculously easy to add Jolt in yourself. If you require the foundation to "officially" add it into the base system to use it, you're not cut out to be a dev.
@@psuw Almost no one begged because everyone was just adding it in on their own. Us, actual devs, don't require the foundation to implement systems to use those systems.
@@psuw looked at the issue myself, thousands of lines of code involved, its not a simple switch, ya'll are incredibly spoiled.
But how much performance will be given back to fix the colliders phasing through each other?
Last time I heard it wasn't yet ready for the consoles
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
This is really good. As I understand it, the Godot physics system was never truly completed.
Yay, this along with megascans. Ue5 kitbash and customisation but ease of use like unity without runtime fees.
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
jolt physics is great, i have ported openmw to use jolt physics and that should land sometime soon hopefully too. step aside bullet :)
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
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
I had a look at yhis recently - I'm wondering what will be needed in my own engine... this might be a bit much.
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.
Jolt is awesome
First that insane 'outskirts' graphics "demo", now Jolt... can this Christmas get much better for Godot?
Segregate the activist from the community
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 TH-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.
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.
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
jolt already has some stuff fluid related but it was not implemented in godot because the focus is to eventually replace godot physics and not build from zero around jolt, PhysX 5.1 probably is better in many things than jolt, but even the creator of godot-jolt could not implement everything like he wanted using the plugin system godot has, so I imagine integrating PhysX 5.1 would be quite the challenge and would probably be a fork
@@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
FUCK YEAH
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 :{
The balls are fading through the walls... I do like jolt though
Now we need to compare the performance of the extension vs the module
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.
One of the biggest focus of this PR was to not break compatibility with Godot physics, I don't know how well this was accomplished in practice but it was a point of focus during the PR discussion repeated many times, one user even said something like "You guy broke backwards compat multiple time since 4.0, why is this time keeping it a focus?", and some of the features exclusives on jolt were not implemented on Godot to keep compatibility with Godot physics, but i'm not using Godot to know if they succeeded.
@@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.
"Godot is so slow to add things!"
"Godot doesn't focus on quality, they just try to cram as much stuff in as fast as possible!"
It's funny that you try to deflect that you're a "long time user of Godot" while decrying people as cultists... when your very statement tells us that your claim is likely false and that you're the actual cultist with no understanding of FOSS or Godot.
@@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!
Very nice. I once despised Godot, and would only use Unreal. But times are changing.
Godot's 3D probably has a few more years before it's an alternative to Unreal for 3D. But maybe one day it'll finally be a good alternative for smaller 3D projects over Unreal.
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.
@@TheRealAfroRick It will never overtake Unreal, but for small projects, Godot might be a viable alternative to Unreal since Unreal's size and power might be unoptimal for smaller project.
Herro mike!
Bepuphysics better
Igual es un disparate de rendimiento.
Wokot isnt worth it.
Incel says what?
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.
"THATS INSANE!" Sound clip should be used for trick in skateboarding game :D th-cam.com/video/KRvt_QPs8uI/w-d-xo.html