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.

                  Given the position of the developers, I see the only way to make a module from Bullet. We are waiting for the correction of the error that does not allow this. I hope they fix this at least soon. Until this happens, I beg the Z80 to support us with new versions with corrections and not give up this good cause. You are saving the community at this difficult time.

                  a month later

                  Hello everyone!
                  I've just fixed a bug in Bullet physics support for Godot4 and upgraded to the most recent 4.0.3-stable except two files viewport.h/viewport.cpp which in some of my projects make viewport texture to not work.

                  Please find the code snapshot and windows-64bit binaries here https://github.com/z80/ignition/releases/tag/commit_cd4f85694.

                  • Xanz replied to this.