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.
    3 months later

    z80 Hi appreciate you working on this, I've managed to pull out the Bullet Physics stuff from your repo into the latest builds for Godot for my own project however I noticed an odd issue with the implementation.

    The capsule colliders seem to not be working correctly, They seem to apply an additional invisible barrier that doesn't seem to show in the debug collisions. It was pretty easy to get this to repeat I also built your instance of the engine just in case it was limited to just my version and it seems like the issue is present in both. I'm guessing this is something to do with margins since the collision debug seems to show the capsule scaled correctly etc.

    Steps I did to see this issue:

    • Create a basic scene with some cubes that fall and can be pushed by a character body.
    • Create a basic character movement script to move left right back forwards.
    • Move around the scene and you will see that the cubes are pushed by an invisible force, attached to the capsule.
    • You can also see its limited to just capsules as by simply changing the collision shape to something else such as cylinder the issue is gone.
    • Swap to using Godot Physics, Issue is not present and collision applies normally and as expected with capsule collider.

    Any ideas on how to solve this issue? Also is there any updates on moving this stuff to GDExtensions it seems like your bug report hasn't been updated in awhile?

    • Xanz replied to this.

      Xanz I actually managed to fix this issue but posting the solution in case anyone else is attempting to use the implementation.

      So there is two issues, In Godot 4 the default capsule orientation is upright rather than aligned along the Z axis. Since the implementation uses the code from Godot 3.5 the alignment is still aligned to the Z axis instead of upright. You can fix this in the bullet code so that instead of creating and returning a BtCapsuleShapeZ you return a BtCapsuleShape, This will fix the alignment issues and the strange invisible force.

      Alongside this another issue encountered is that the capsule height is no longer aligned with the debug widgets heights and just the general capsule height as it seems like Godot 4 expects that to be the exact height. This causes an issue as bullet expects a half height(This is just knowledge from implementing bullet in a custom engine so could be slightly incorrect but seems to resolve this issue).

      This will cause issues with capsules appearing like they are floating or just general strange height related issues. To solve this simply divide the height received in the CapsuleBulletShape::setup method by 2(You could do this earlier in the callstack but it seems like a sensible place to do it as it keeps it within the bullet module). This will give you the half height which is what bullet expects.

      Good luck to anyone else using this!

      • z80 replied to this.
        6 days later

        Xanz
        Sorry for the bug! And thank you so much for the detailed explanation of the fix! That's awesome! Is there any place I could pull the changes from? If not, I'll try to follow your instruction. Thank you again!

        Xanz
        Ok, I've changed it from

        btCapsuleShapeZ *ShapeBullet::create_shape_capsule(btScalar radius, btScalar height) {
        return bulletnew(btCapsuleShapeZ(radius, height));
        }

        to

        btCapsuleShape *ShapeBullet::create_shape_capsule(btScalar radius, btScalar height) {
        // Bullet expects half height.
        return bulletnew(btCapsuleShape(radius, height*0.5));
        }

        It seems like it does the job. Thank you again for the bug detection and how to fix instruction! That's open source in action!

        The code with the fix applied: https://github.com/z80/ignition/tree/bullet_godot_4_1bf56109f6

        Code snapshot and binaries for Windows: https://github.com/z80/ignition/releases/tag/bullet_godot_4_1bf56109f6

        • Xanz replied to this.

          nice stuff.
          Good to see there is another alternative to vanilla engine physics.(The other alternative is jolt3d)
          No offense intended, but the physics3d in 4.0 is a piece of ****, especially performance and stability wish. A few convex shapes with like 50 vertices colliding each other will cause the physics time jumping from 16ms to 1000+

          13 days later

          The question, so far, is theoretical. If I want to use physics and AI in my project at the same time, do I have to compile the engine myself, including them there?

            Tomcat From what I understand If they are all GDExtension plugins that are provided in pre-compiled(linked library) form then in theory you shouldn't need to compile anything though you have to make sure the versions of each including godot itself match up.

            If however one or more of the things you are looking to use takes the form of a module then it needs to be compiled into the godot engine itself far as I'm aware.

              Megalomaniak If however one or more of the things you are looking to use takes the form of a module then it needs to be compiled into the godot engine itself far as I'm aware.

              Yeah, that's what I have a question about, since Jolt has an extension version, but the listed modules do not.

              a month later
              21 days later

              Upgraded Bullet physics in Godot to 4.2-stable.
              Source: https://github.com/z80/ignition/releases/tag/godot_4.2_stable_4767fbb521
              Windows binaries: https://github.com/z80/ignition/releases/download/godot_4.2_stable_4767fbb521/godot-4.2-stable-4767fbb5214.zip

              It was 8 months since the first Bullet physics port to Godot 4. And while I regularly upgrade it to up-to-date version I really see no Godot native physics changes besides of a couple of lines here and there. I'm not sure about everybody else's projects but in my one it was exploding since the very first Godot physics and keeps exploding now.

              Does anybody know if they consider their physics to be mature and stable? Did they abandon their physics and gave up? Is Godot slowly dying?

                z80 Is Godot slowly dying?

                Talks about the death of Godot have been going on since the beginning of engine development. πŸ˜ƒ The engine is being developed, but they don't emphasize physics yet, probably not enough people. The fact that the physics is not perfect, the developers know:

                Important remarks:

                Going forward on the development roadmap for Godot 4, Godot Physics is an area that will continue to receive ongoing effort. Further performance optimization is in store, and you may still encounter a few kinks we’re aware of that will be ironed out in future releases.

                Do you plan to support GDExtension?

                • z80 replied to this.

                  Tomcat Do you plan to support GDExtension?

                  It's currently a built-in module like in Godot3. I am porting it each time a new version is released. I tried to make it a plugin but Godot native didn't export a few enums which were in use in Bullet physics. I hope they've fixed it, I haven't checked the status of Godot native for a while. I might take another attempt to make it a binary module.

                    z80 I might take another attempt to make it a binary module.

                    That would be excellent! There are other useful modules that are not yet implemented as GDExtension:

                    • Supporting GDExtension in the future, once it matures.

                    Trying to use them in one project becomes difficult.

                    14 days later

                    z80 Sorry didn't see these replies until now! Glad that the bug information was helpful, good to see this is still progressing. I think I implemented the half height stuff in the capsule init function but ultimately it will be the same result. Deterministic physics engines are so important for physics heavy games and networked games. Its really strange to see major engines moving away from them.

                    • z80 replied to this.

                      Xanz Sorry didn't see these replies until now! Glad that the bug information was helpful, good to see this is still progressing. I think I implemented the half height stuff in the capsule init function but ultimately it will be the same result. Deterministic physics engines are so important for physics heavy games and networked games. Its really strange to see major engines moving away from them.

                      Thank you so much again for finding the issue with the capsule shape!

                      Can the Godot custom physics phenomenon be a result of the confidence of knowledge curve, see the picture attached? The phenomenon of the confidence spike near the origin might be a driving factor in making a decision to implement a custom physics engine. I find myself consistently falling into this problem πŸ™‚

                      17 days later

                      Hi, I tried to use your Bullet port (which I highly highly appreciate) and I got this message:

                      While spawn_body() looks like this:

                      The error message is referring to the last shown line (body.instance... etc.)
                      This line is not doing anything at all because of this.

                      • z80 replied to this.