I recently switched from jME 3.0 to the current trunk version of jME 3.1.
Immediately after switching I noticed a massive lag/stutter when moving objects, but only when VSync is turned on or when the frame rate is fixed to 60 fps through the AppSettings class. I can reproduce this issue with a minimal test case (= a box moving from left to right). I also can see it in the Lemur demo when dragging a box around with the mouse.
As soon as I deactivate VSync everything works fine (fps >1000 ;-)).
Also: If I disable VSync and fixed frame rate, and simply add “Thread.sleep(16);” to the simpleUpdate() method of the application no lag/stutter is noticeable. The frame rate remains at 61 fps.
Now I realize that VSync and Thread.sleep(16) are two completely different things. I’d expect VSync to work better than a simple Thread.sleep(), though. But as a matter of fact it works a lot worse right now. And only since switching to jME 3.1.
While investigating the problem I logged several hundreds “tpf” values of the simpleUpdate() method calls. The tpf values don’t look very good. I’d expect tpf values of exactly 0.0166, with a deviation of maybe +/- 0.002. That’s completely not the case. I see values ranging from 0.001 to 0.045. The tpf values are basically all over the place. About 95% are around 16.66, though.
I already made sure it’s not a garbage collector problem, although jME seems to create some unnecessary objects for each frame rendered even for the most basic scenes.
Is this an already known issue? I neither found a forum entry nor an issue in github, but may overlooked something.
Does it happen with a simple scene with just rotating the camera, or is this effecting Lemur only? Also, please post the log output from running the application (so we know what OS / GPU / etc has the issue).
I just updated my drivers, which improved everything a lot.
There are still stutters about every 2-3 seconds, where about ten tpf values reach values of up to 0.05s. But all in all it’s got a lot better now.
Sounds like your are garbage-collecting a lot. You can run with verboseGC on to see… but a long pause every 2-3 seconds indicates a full GC happening.
Maybe you somehow create a lot of garbage? You can try increasing your heap size (don’t forget to increase direct memory size too or you will hurt yourself later).
For this graph I altered jME’s demo application “HelloLoop” so the blue box moves around. The box movement is still stuttery after my driver update, but not as severe as before.
I’ve had a simmilar problem in my game:
After upgrading jme to 3.2+ the forward motion of all my objects was fine for a couple of seconds then suddenly just stopped. Rotation due to torque still was ok. So a flying plane or missile went from full speed to full stop and kept turning on the spot (the rest of the simulation was smooth) and then forward motion slowly started again (although the debug output stated that the velocity was still the same, also fps and forces). With VSync disabled, the problem was less noticable.
I do this now during app init and everything seems fine again - maybe it helps:
physicsState.getPhysicsSpace().setMaxSubSteps(0);
When I switched to 3.3 it was with JBullet and now I siwtched to Minie 4.3.0 - same with both implementations. The drawback I noticed: on 1980x1200 Fullscreen, the physics get really slow when looking into the sun (with light scattering filter). It’s not jumpy, it slows down the whole simulation with maxSubSteps = 0.
I had a similar issue that only happened on native bullet and not jbullet. It was related to physics step times that were almost-but-not-quite the same as frame times.
