Low cpu usage, parallel bullet physics only one thread in a quad core?

Troubleshooting physics
1

two questions:

why there is only one physics thread “pool-1-thread-1” even if I set parallel mode?
as this is: startPhysicsOnExecutor() {... executor = new ScheduledThreadPoolExecutor(1);
1 instead of the number of cores?

why any of the java threads are at most using 60% of one core?
my overall cpu usage for 4 cores wont go beyond 50%, while in other games they go easily near 100%.
what happens is that the FPS just drops after I throw 150 spheres and watch them roll around.

any tips?

1 Like
2
  1. Because the physics update is called sequentially and not parallel. Its still on its own thread and runs in parallel to the main update loop render() method.
  2. Why would they use more power than they need? In the update loop different things happen. The CPU only has to do a few of them. So if you have 30% time doing scene preparation on the CPU and 70% time rendering on the GPU you will only have 30% CPU load.
  3. The hundreds of spheres rolling around are causing a bottleneck in your GPU, so it will run at 100% while the CPU gradually gets less and less to do while its waiting for the GPU. In AAA games people look very carefully at where the bottlenecks are and adapt the code accordingly, they don’t let 100s of spheres roll around as separate geometries.
2 Likes
3

With parallel mode physics spaces are parallel to other physics spaces and to the render loop but you can’t have multiple threads working on the same physics space. It was possible only with very old versions of bullet but AFAIK it has never been available in jme.

2 Likes
4

I fixed the code to use SimpleBatchNode (all spheres are there now).
I temporarily disabled all my code at physicsTick() and prePhysicsTick() but it was light weight and didnt change the results.

But indeed, that huge amount of simultaneous physics going on is unnecessary. The MainThread FPS and PhysThread tick per seconds were great until I reach the mark of about 125 spheres moving around! what is more than enough to play with :slight_smile:

[details=some tests results: I dont know if this could be improved, I will keep here just for the curious ones :)]initially, without the physics spheres, the MainThread FPS is about 650, and my GPU utilization goes to 35%.

With 250 spheres, the Ticks Per Second (I counted on the physicsTick()) goes from the constant 60 to 40, while the MainThread FPS goes down to 10.

I was expecting the CPU usage to increase to keep the Physics thread at 60 ticks per second, but that didnt happen.
By what you said, it seems the MainThread going as low as 10 FPS is hindering the updates at the Physics Thread, is that so?
I profiled and the most time spent are:

MainThread:

BulletAppState ... java.util.concurrent.locks.LockSupport.park (Object)	28,757 ms (47.1%)	13.9 ms (0%)

PhysThread:

com.jme3.bullet.PhysicsSpace.stepSimulation[native] (long, float, int, float)	31,783 ms (52.1%)	31,783 ms (98.8%)

Also, when the MainThread FPS goes down to 10, my GPU utilization goes down too to 4%; it seems to use more GPU processing for higher FPS at MainThread (rendering) only.

btw, I measured the GPU in linux using nvidia-settings -q GPUUtilization[/details]

good to know that, so may be I can put some stuff that would not collide (just gravitating) or that would collide far away or any other thing that doesnt interfere/hinder/limit with the player’s actions, in separate physics spaces! that will be helpful, thx!

1 Like