Hello!

As a few people have figured it out the hard way, Godot 4 native physics is a little bit unstable in some situations. And there was even a petition 🙂 regarding returning Bullet physics back into Godot4 which as I understand has been rejected by the developers.

If anybody is interested, after struggling for about 2 weeks I've finally made Godot3 Bullet module compile in Godot4. I had to insert a number of dummy methods to just make it compile as physics_server_3d.h has no information related to what all the virtual methods are supposed to do.

Also Godot developers did excellent job renaming literally almost every single method, every single property, and every single data type. It really doesn't add reliability in the process of porting even the code I made myself from v3 to v4 not talking about something I didn't ever look into 🙂

As far as I understand, there are a few people interested in Bullet working in Godot4. The big problem is that servers/physics_server_3d.h has absolutely no documentation. And it is not clear what all numerous new methods are supposed to do. If you have any insights or willing to help, please check out the code: https://github.com/z80/ignition/tree/bullet/godot.

Please let me know.

Hello again!

I was analyzing the Godot4 physics code. There is one thing I cannot understand about RID_PtrOwner<> class. After object creation pointer is placed into RID_PtrOwner<> which in return gives them a RID (an integer). And each time when they need a pointer to the object (and it happens on every physics API call), they give RID_PtrOwner<> the rid and it in return gives back the original pointer they stored. Why not just keep the original pointer, why use a dedicated storage while holding a rid corresponding to the pointer id in the storage container? There must be some hidden logic here...

See the example below.

class GodotPhysics
{
RID_PtrOwner<Object> object_owner;

GodotPhysics::create_object()
{
    Object* obj = godotnew(Object);
    RID rid = object_owner.make_rid(obj);
    return rid;
}

Object * GodotPhysics::get_object( RID rid )
{
    Object * obj = object_owner.get_or_null( rid );
    return obj;
}
};

    z80 Maybe you'd better post such question in a discussion/proposal on Godot github repository, there is bigger chance a dev sees it an reply.

    My guess is either it's some storage made for something no longer in use or, worth, a misunderstanding (which would be unbelievable at this level but who knows ?) about pointer and object, the author thinking the function will have to deal with a full instance of a class pass by value in functions/methods instead of a mere pointer as it is, in such case, it could makes senses to do that... I'm not even sure because the id will be use anyway to acquire the object itself.

    This more looks like a useless indirection. Anyway, it's a good opportunity for discussions and challenge actual architecture.

    • z80 replied to this.

      JusTiCe8 Actually, after thinking for a while, I believe, I see the reason. This RID_PtrOwner<> with some stretch of imagination is somewhat similar to using std::weak_ptr<>. I.e. if the object has been deleted and removed from this RID_PtrOwner<> container, requesting object by its rid returns nullptr. And using a single container for multiple small objects somewhat makes sense as there is just a single memory usage for one RID_PtrOwner<>. In contrast, using std::weak_ptr<> per each pointer creates bigger overhead...

      Ok, after a few more days and tons of bad language it actually works now!
      See the video:

        z80 Great ! It would be nice to add some tests using the concave mesh issue discussed a while ago as well as your unstable joints issue.

        By the way, regarding this issue, Unity also suffer from weird issues (looks like some force gain momentum with time then grow exponentially and makes everything explode in KSP), I think it would be much better to automatically "weld" parts together into a single collider mesh so the physics engine only have to deal with a single entity and not a bunch of parts stuck together with bad glue and duck tape. Especially regarding the gameplay added value for such poor model, IMHO, it doesn't add much but cost a lot of annoyance and performance issues.

        Finally, do you have some compile editor ready to use ? It would be great (don't forget to tweak the version as well !)

        • z80 replied to this.

          JusTiCe8 Great ! It would be nice to add some tests using the concave mesh issue discussed a while ago as well as your unstable joints issue.

          Yes, that's in the nearest TODO list.

          JusTiCe8 looks like some force gain momentum with time then grow exponentially and makes everything explode in KSP

          That's side effect of using speed-based constraints and simulating bodies separately via Newton/Euler equations. Bullet actually has generalized coordinates-based Largrange equations to solve this issue perfectly. It's called Featherstone method. It's located in \godot\thirdparty\bullet\BulletDynamics\Featherstone. It's not yet supported by Godot though.

          The poor man's today alternative is simulating all connected pieces as a single rigid body 🙂

          JusTiCe8 Finally, do you have some compile editor ready to use ? It would be great (don't forget to tweak the version as well !)

          Sure, here you go (the url leads to the game page, I couldn't come up with anything better to hosting it there):
          .

          For now version is the commit SHA256:

            z80 It could be interesting, if interface to both Bullet and new Godot native physics engine are the same or very compatible, to provide both implementations of Ignition so it could help comparing both and devs could also identify what they need to do to at least reach Bullet level engine.

            For the download, why not use release on github directly ? I've never used it yet myself so I can't help.

            • z80 replied to this.

              JusTiCe8 why not use release on github directly ?

              Ah, it's dumb as usual. I wasn't able to find "draft a new release" button. Github says "At the top of the page, click Draft a new release".
              It turned out, it's not at the top, it's on the right 🙂 Here is the github release download url godot.windows.editor.x86_64_7aca0f70.zip.

              Ok, just tried it in the real game.

              First, on positive side, when switched to Bullet, the physics doesn't blow up anymore! That's a win!

              On the negative side
              1) Even though concave mesh collision shape is created, I can see it with Debug/Visible Collision Shapes check box. But for some reason collisions don't happen. Bodies fly right through.
              2) Even though joints are created, they don't work for now. Constructions just fall apart when pushed.

              The return of bullet physics in Godot 4 is one of the biggest achievements along with the introduction of Vulcan. Is it possible to make a module for Godot? This will please many developers. Not everyone will want to install a separate build or compile it, a module will allow you to distribute your work throughout the community. In any case, I want to thank you. This gave hope to our studio to stay on Godot in the future, as we decided to switch to another engine due to physics.

              • z80 replied to this.

                Engardium

                Engardium Is it possible to make a module for Godot? This will please many developers. Not everyone will want to install a separate build or compile it, a module will allow you to distribute your work throughout the community. In any case, I want to thank you.

                Great idea, thank you! I know they've changed binary modules design process a lot but didn't look into it yet. I'll check what it takes to make a module out of Bullet physics server...

                Engardium Bad news.

                I've been trying to convert it to GDextenstion. I've checked out godot_cpp.git 4.0.2-stable tag which corresponds to 4.0.2-stable godot current version.

                The obstacle I've encountered is G6DOFJointAxisFlag enum in Godot : : PhysicsServer3D and godot_cpp : : PhysicsServer3D do not correspond to each other. G6DOF_JOINT_FLAG_MAX is not defined in godot_cpp as well as a few other enums.

                So, I guess having Bullet physics as a GDextension binary plugin is delayed... For now only the built-in version is available.

                I've created an issue: https://github.com/godotengine/godot-cpp/issues/1104. Will see what happens...

                If it matters, I've created a separate github repo for porting Bullet to GDextension.

                Engardium My personal favorite quote in the conversation is "By giving Godot users no other way, it's forcing evolution for the best, with some pain along the way."

                I would just add "Or it makes Godot users switch to Unreal and give up Patreon support" 🙂 Which is indeed evolution for the best in some sense 🙂

                Awesome, thanks for making the integration! I, for one, can't wait for an additional Physics library option other than Godot's Physics for 3D.

                Also be sure to check Godot Jolt which is a GDExtension in progress for Jolt in Godot. It's almost fully working. So you also might get ideas from the code, if needed: https://github.com/godot-jolt/godot-jolt

                • z80 replied to this.

                  alfredbaudisch Also be sure to check Godot Jolt which is a GDExtension in progress for Jolt in Godot. It's almost fully working. So you also might get ideas from the code, if needed: https://github.com/godot-jolt/godot-jolt

                  Yea, thanks for the hint! I'm aware of Godot-jolt. It's absolutely great!

                  In the case of making a GDextension out of Bullet it seems like it's a bug in the command "godot --dump-extension-api extension_api.json" which is supposed to generate all the API. Specifically for PhysicsServer3D it doesn't export several enums which are needed for Bullet to work. The devs have already assigned it a bug flag, see https://github.com/godotengine/godot-cpp/issues/1104.

                  @"alfredbaudisch"#p110287 oh but notice how I just said "with Bullet/Jolt" and not Godot's Physics itself 😬

                  Absolutely! IMHO it's much less of a pain to rely on something tested. Despite of all the arguments the devs' position 1) claim lack of contributors and at the same time 2) developing custom physics engine from scratch still does not line up in my head 🙂

                  ive also found physics unreliable in godot 4. some collisions just dont get correctly detected.
                  is this because of godot physics? if so, is bullet physics so much better?

                    DJM is this because of godot physics? if so, is bullet physics so much better?

                    Bullet is battle-proven, with many shipped titles.

                    GTAIV and Read Dead between them:

                    Bullet is an open-source 3D physics library produced by Erwin Coumans, featuring rigid and soft body physics, 3D collision detection and multiple 3D modelling/animation software plugins. The library has been incorporated into the Rockstar Advanced Game Engine, which has been used by Grand Theft Auto IV and Red Dead Redemption.