Unofficial updated builds for Bullet ~ v2.86.1 & kinematic fix

Builds and usage here: https://riccardobl.github.io/jme3-bullet-builder/ (for linux, osx and windows)


UPDATE: The master branch now contains updated bindings for bullet 2.86.1 and a fix for kinematic rbs. Built in jmonkeyengine-master-2017-08-09.3+

3 Likes

Hi.

Memory leak using multiple parallel physics spaces (native bullet) I have this problem probably because I use two physic spaces. And I read that -DBT_NO_PROFILE=1 fix this problem. But I literally have no idea how to recompile it.
Or… can you make a build with this param if it makes no harm? :smiley:

Can you give any advice?

Hi, from that repo with updated builds, this one jmonkeyengine-master-3.2c should have BT_NO_PROFILE=1 IIRC.

1 Like

Thanks! I will try out.

Okay. I tried jmonkeyengine-master-3.2c . Thanks for it. It works much faster than native library from 3.1b . And game is no longer crashes after 15 minutes.

I still have memory issues but I figured out it is because of https://i.gyazo.com/38bc7013b40d7b731153a1250ce429a6.png PhysicsCollisionEvent objects size constantly growing.

UPDATE . Finally found how to solve the issue.
Adding physicsSpace.distributeEvents(); after physicsSpace.update(); makes everything work okay.

3 Likes

Nice find! PR it if you haven’t already

You mean Pull Request? It’s not needed. My first problem was connected with using bullet without BT_NO_PROFILE. And jmonkeyengine-master-3.2c fixed it. After it I found another problem PhysicsCollisionEvent . It wasn’t connected with any natives or jme source code. I just had to add physicsSpace.distributeEvents() in my own code after physics space update.

Mhh, actually I think this might be an issue in the bindings:

Render is called before the update:


    public void render(RenderManager rm) {
        if (!active) {
            return;
        }
        if (threadingType == ThreadingType.PARALLEL) {
            physicsFuture = executor.submit(parallelPhysicsUpdate);
        } else if (threadingType == ThreadingType.SEQUENTIAL) {
            pSpace.update(active ? tpf * speed : 0);
        } else {
        }
}

If it’s executed with parallel, the physic update is enqueue to the executor, then the apstate update is called

public void update(float tpf) {
        if (debugEnabled && debugAppState == null && pSpace != null) {
            debugAppState = new BulletDebugAppState(pSpace);
            stateManager.attach(debugAppState);
        } else if (!debugEnabled && debugAppState != null) {
            stateManager.detach(debugAppState);
            debugAppState = null;
        }
        if (!active) {
            return;
        }
        pSpace.distributeEvents();
        this.tpf = tpf;
    }

From here distributeEvents() is called, but at this point if we are using parallel there is no guarantee that the phyupdate has been already completed by the executor, i think this might be the issue.

I’m not sure tho, when i’ll come back working with physics i’ll check this

I don’t use bulletAppState in that case. Actually, I found the solution after checking bulletAppState code.

My problem is just relevant for people who use PhysicsSpace manually (serverside in my case) without any AppStates. BulletAppState includes distributeEvents() in its update() method but PhysicsSpace isn’t by its own.

3 Likes

Great find! Gonna go check my serverside physics… pretty sure I didn’t do that.

updated

This is all normal. Distributing the events should only happen during the normal update. This is exactly BECAUSE of parallel mode which would normally cause the events to be spewed out during render.

1 Like