jBullet almost 9 years outdated

Thank you everyone for the clarifications.
I personally would love to see OpenCL supported. I am running into performance issues on the CPU for server side physics, and if I can offload that to a GPU with OpenCL that would help a lot.

1 Like

What collision shapes are you using?

It is not so much the type of physics we are using (we have a variety of different shapes, but a lot of MeshCollisionShapes, and are working on getting GImpactCollisionShapes running, not very efficient, but we need accurate collision detection), but the shear number of objects I am running physics calculations on. At any given time I have between 20 to 50 physics spaces, each with 1,000 to 10,000 objects. We are just limited by the amount of performance we can squeeze out of a CPU, but we have a lot of potential GPU capacity. I assume that by utilizing opencl we can take some of the load off the cpu.

2 Likes

Some of Bullet’s early OpenCL tests had ~100k rigid bodies on the GPU at ~20 FPS on a GPU that’s fairly old by modern standards.

You should see a massive performance increase by moving those calculations to the GPU.

2 Likes

That would be awesome.

1 Like

Per the whitepaper linked below, OpenCL support exists only in Bullet 3.x, not Bullet 2.x:
bullet3/GPU_rigidbody_using_OpenCL.pdf at master · bulletphysics/bullet3 · GitHub

I haven’t scoped out the transition from Bullet 2.88 (what Minie uses) to 3.x in detail, but it appears nontrivial. Also, I haven’t found evidence of any Bullet 3.x releases; I suspect the code is still experimental and not ready for production.

I’ve decided not to pursue OpenCL right now.

4 Likes

@sgold thank you for taking the time to look into it, I appreciate it. I will just have to keep an eye out for when 3.x is released :wink:

Edit: I just found this: Release date of bullet 3.0 ? · Issue #556 · bulletphysics/bullet3 · GitHub
A little depressed about it. Looks like they are no longer perusing OpenCL support…

1 Like

It may be of help to explain what it is you’re actually doing. It’s possible that there may be a more efficient way of doing it. I’m not saying there is, but if we knew what you were doing we might know.

1 Like

Hello @jayfella, I am working on a server-side high accuracy physics system for large scale multiplayer VR simulations. We are attempting to handle semi-accurate haptics, which is very intensive. These simulations are used for training personnel in real world situations that would be hard to do actual training for (an example is like rebuilding a jet engine, or training facility operators how to shutdown a plant). For these simulations we need to have a very large number of small objects with moving parts, and we need to allow multiple users and other objects to interact with them. The system works just fine, but we are just running our servers into the ground with the load. We have a cluster of GPU servers and would love if we could take some of the load off the CPU and run the calcs on those.

EDIT: I should clarify that our current work around is to break the simulations into lots of small simulations that get stitched together and to run them on separate servers.

2 Likes

…which to me, is the right answer in the end no matter what.

1 Like

All it would take is one person with the time, skills, and inclination to push the project forward. Perhaps you’re that person, or can become that person.

I wish, but I am far to busy to take on something like that. On another note, I noticed that NVIDIA PhysX is now opensource (BSD)? Releases · NVIDIAGameWorks/PhysX-3.4 · GitHub

Also noticed some talk about it over at LWJGL…

I have never done a JNI binding before, but I am curious as to if it would be doable to bring in PhysX support to jme3.

1 Like

Totally possible. And it’s been done:

My JMonkey year 2016 - little essay

1 Like

JNI is like wrapper functions. you can do everything with it. the only problem is that you need convert params like jInt as int(its just casting) but some of like jString require functions to change param to cpp related data type.

you also need clear this variables at the end, to avoid memory overflow. (there java garbage collector cant work magically like in java itself)

im not master of it, but already made 2 apps that mix c and java.

1 Like

Just a heads up regarding JNI, Project Panama will be next generation replacement to JNI
http://openjdk.java.net/projects/panama/

I think it is what LWJGL guys are aiming for LWJGL 4.

4 Likes

They should rather finally release lwjgl3 for arm, so it runs on raspberry pi’s :smiley:

1 Like

Nice that there seems to be effort going into that. Seems to based on the JNR experiment from a few years ago.

Do they document anywhere approximately when this might land? I’ve always found the OpenJDK site to be a bit opaque…

I don’t know about release date. Seems they have not announced a due date for it yet.

Just a note, there is an issue over at LWJGL for PhysX: PhysX bindings · Issue #124 · LWJGL/lwjgl3 · GitHub

3 Likes

Stumbled upon a fork jbullet. Maybe someone will be useful. jbullet

1 Like