I was about to say "they can't, the project is supposed to be fully open-source." Because, you know, Nvidia. But I looked it up just to double-check, and wow, that's like one of the only open-source projects Nvidia has ever published. At least that I've seen.

I believe you misread the quote; they're not using PhysX.

No, I read it right. I was saying that I was about to explain why, but my explanation turned out to be incorrect, to my surprise.

However, they say:

> That said, Godot 4.0 introduces the ability to bind custom physics engines at runtime (without recompiling Godot) via GDExtension, so it’s perfectly possible for the community to integrate other engines such as PhysX, Jolt, or Box2D if need to be.

I'm liking this work on GDExtension. It'll make Godot a lot more capable just on its own.

But they are only mentioning PhysX as a reference for a high quality phsyics engine.

The only tried to integrate Bullet.

Isn't PhysX hardware accelerated only with CUDA? In that case it would make sense for Godot to avoid it even if it's open source, becasue it's targeted for Nvidia.

ianal but it could be a licensing thing. PhysX is BSD3 and Godot is MIT.

Care to elaborate?

Godot is still experimenting with Physics engines, rolling back to more primitive homebrew solution. The original statement was straightforward.

Ofc, that's just 1 aspect of the engine. There are numerous bugs in the IDE for 2d, which I have encountered. Also, the asynchronous event system quickly becomes cumbersome as a project grows. Ordering becomes important, for which there is no amount of control in Godot (dealing with mouse events, for example). This leaves every developer to implement a stateful dashboard, of sorts, to ensure events are handled in the correct order. This then leads to nondeterministic delays, etc.

I will assume a high-end, state of the art physics engine is a must have for any AAA game.

Not really. There are whole genres where physics isn't really a thing (RTS, card games, turn based strategies). Even where there are physics, they don't need to be complex, just fast. Most fps games, for example Fortnite, don't really use complex physics stuff like joints, and most don't even have fast moving objects.

Most games basically just have rigidbodies. Some cinematic-ish AAAs have fancy cloth simulation or something, but even that is usually prebaked I think.

Why? What commercial game is physics-heavy?

Most commercial games have scripted character movement (every FPS, RPG, strategy games, basically almost every genre) and the only physics objects are random falling objects that don't affect gameplay... Cloth simulation, cool but can be faked and doesn't affect gameplay. Ragdolls, only really used when characters die and again, can be faked.

So name a single AAA game that actually uses proper physics for anything gameplay related?

KSP2, Breath of the Wild, Portal/Portal 2, Red Faction, basically every VR game (HL: Alyx definitely qualifies as AAA).

I agree it's not all that common but they are definitely out there. As for whether you could build those with Godot's engine I have no idea.

I think that list just emphasizes the parents point. The majority of games are getting by without dedicated physics sandboxes.

Zelda: Breath of the Wild? HZD? Anything with vehicles? This is a pretty unhinged take

Most AAA game engines have both ways to bake in physics _and_ to use the exact same system, real time. If you work with Unreal Engine, you use the same tool to get your cloth physics and you can just click a button to bake it and replay it. And this applies to... everything in the engine.

Moving outside of your editor absolutely blows, and the less you do it, the better it is. Unless the alternatives are thousands of times better (nothing comes close to Substance Painter, and tools like Houdini still do some things better than internal tools for example. And of course, well, 3D modeling is still a hellscape of zbrush and Maya.), you just stay in with your tools. Nothing sucks more than having yet another editor and needing to have a pipeline to keep everything in sync.

It's not about needing crazy physics calculations directly in your engine (although your particle system being affected by it can do cool things), it's about not having to deal with yet another tool that fixes one problem and brings in 20 more.

Also, as said, the days of fully scripted movement are pretty much gone. There's physics interactions any time you have vehicles involved unless you want to feel it slide around and feel like crap, for example.

Fortnite, GTA, RDR, apex, PUBG? I mean, scripted games are way less popular than they used to be. And I actually can't think of more than a couple major games without some sort of physics.

> This is a bit of a red flag if one of their goals is for the engine to be used on AAA games.

As much of a red flag as say Unreal? Who also dumped both Bullet and PhysX.

The solution where you can plug your own engine in is perfect. None of the physics engines are good enough for all games as all engines have discovered. Better to have something simple and in house for 80% of games who need only the basics and then let you bring your own engine.

Unreal by the way doesn't even let you do that anymore. PhysX support is being removed entirely in 5.