Lwjgl3: Bulletphysics Bindings

[Philoprogrammer]

Is there a way to add Bullet bindings?

[Spasi]

LWJGL does not support C++ bindings yet. See #22 and #124.

Have you tried libGDX's Bullet wrapper?

[dustContributor]

Just a heads up. Apparently Bullet 3 has a C API

https://github.com/bulletphysics/bullet3/blob/master/examples/SharedMemory/PhysicsClientC_API.h

According to Bullet 3's repo, this is a "new physics-engine agnostic C-API" that they themselves are using for creating Python Bullet bindings in the PyBullet project. According to the authors it's a more higher level API (which sounds nice!).

The API uses a client/server architecture apparently, where each "server" has their own "world" instance.

The PyBullet Quickstart Guide has some details about it.

[Spasi]

Bullet bindings are now available in 3.2.1 snapshot 7.

I'm not at all familiar with Bullet, so please consider this a beta release. Comments:

• Bullet's code base is weird, e.g. the C API is under an examples folder.
• The build process was difficult. I had to build it as a set of static libraries and link to shared a library in LWJGL. This means that custom builds will have to follow the same procedure. The LWJGL build uses the default configuration (single fp precision and no multi-threading).
• The C API is verbose and hard to use, because of the client/server architecture.
• Direct connections (b3ConnectPhysicsDirect) are tested and seem to work fine. Connecting over TCP/UDP does not seem to be possible with the C API (no way to create a server) and b3ConnectSharedMemory fails (on Windows at least).

[dustContributor]

Thanks a lot Spasi, you're the best! I'll try it out when I can, hopefully this will allow me to get rid of libGDX as a dependency at last :smile:

Do you know how the plugin thingy works? Something rather useful are the collision filter masks, which seems to be a plugin rather than in the core API.

[Spasi]

The collision filter plugin is available and the C API supports it, see:

b3CollisionFilterCommandInit
b3SetCollisionFilterPair
b3SetCollisionFilterGroupMask

I believe the plugin is loaded immediately but, if not, the following code works for me:

long cmd = b3CreateCustomCommand(client);
b3CustomCommandLoadPlugin(cmd, "collisionFilterPlugin");
long status = b3SubmitClientCommandAndWaitStatus(client, cmd);
assertEquals(b3GetStatusType(status) , CMD_CUSTOM_COMMAND_COMPLETED);
int collisionFilterPluginUID = b3GetStatusPluginUniqueId(status);
System.out.println("collisionFilterPlugin UID: " + collisionFilterPluginUID);

[dustContributor]

I'm halfway through moving my physics stuff to this C API.

So far it's going ok. It's a fair bit higher level than the base Bullet API for a few things. Like initialization is just like in your example, set a timestep and gravity and you're good to go.

Something I also think I got down is ray casting:

var cmd = b3CreateRaycastCommandInit( hnd, from.x, from.y, from.z, to.x, to.y, to.z );
b3SubmitClientCommand(hnd, cmd);
try ( var mem = MemoryStack.stackPush() ) {
    var info = B3RaycastInformation.mallocStack( mem );
    b3GetRaycastInformation( hnd, info );
    var hitsLen = info.m_numRayHits();
    if ( hitsLen < 1 ) {
        return -1;
    }
    var hit = info.m_rayHits().get( 0 );
    return hit.m_hitObjectUniqueId();
}

I'm pretty sure you don't need the "b3SubmitClientCommandAndWaitStatus" with the status check after because the direct server just works straight with the API underneath. For instance the status check underneath just checks if the command processor is connected, and the direct command processor always returns true for that.

In any case, very recently (3 days ago as of writing this) Bullet guy added the possibility of creating an arbitrary mesh with passed vertices, something that was missing from the C API. You could only create basic shapes or load one from that robot format thingy. I have no need for it now but it'll be useful later (specially for heightmaps).

Now I'm researching how to create shapes that aren't boxes. For boxes you got 3 or 4 functions, but for every other shape it seems you have to create a b3CreateCollisionShapeCommandInit and then do b3CreateCollisionShapeAddCapsule (or any other shape) on it.

I'm wondering, all of the C API seems to be using doubles, but you say you compiled it with single precision, so if I use floats in Java land, the C API casts to doubles, but then Bullet inside casts back to floats? I don't really mind, just curious.

I've been using his implementation of the PyBullet bindings as a reference, since it has all of the API implemented and used there:

https://github.com/bulletphysics/bullet3/blob/master/examples/pybullet/pybullet.c

[Spasi]

In any case, very recently (3 days ago as of writing this) Bullet guy added the possibility of creating an arbitrary mesh with passed vertices, something that was missing from the C API.

Yeah, I've noticed the new functionality, it will be added to LWJGL in the next maintenance pass.

I'm wondering, all of the C API seems to be using doubles, but you say you compiled it with single precision, so if I use floats in Java land, the C API casts to doubles, but then Bullet inside casts back to floats?

Yes, the API accepts doubles, the client/server messages carry doubles, the server converts to floats when processing the messages.

I don't have a strong opinion about the default build, I can change it to double precision if that's what users want. Alternatively, LWJGL could provide both single and double precision builds and a Configuration option that flips between the two. But then there's also the question about multi-threading (BULLET2_MULTITHREADING in CMakeLists.txt), so we'd have a matrix 2 x 2 x number of platforms/architectures we support.

I think it'd be better if LWJGL provided a sane default for game development and users that need something different could do a custom Bullet build. I just don't have any experience with Bullet and have no idea what that default should be.

[dustContributor]

Yeah, I've noticed the new functionality, it will be added to LWJGL in the next maintenance pass.

Sweet! Thanks!

I can change it to double precision if that's what users want.

Oh not at all, I am fine with single precision. At least my project is for game stuff so best performance by default sounds like the better option. I was just curious about how it worked.

I don't know if there are that many "simulation" oriented users that would want double precision in this case. At least in games I think all big engines out there use single precision. At worst they just implement workarounds to preserve the lower memory usage and single precision performance, much like renderer people do by using linear/log depth to keep their depth buffer under 32 bits.

But then there's also the question about multi-threading (BULLET2_MULTITHREADING

Ah that's true. It sucks that it's a compile time thing. IMHO I'd leave it single threaded (or whatever is the default), whoever needs the multi threaded performance probably knows how to do their custom build to suit their needs.

So in short, as it is it's perfect for my needs.

[YaaZ]

@Spasi can you tell me, how can I make a build with custom parameters, please?