Continuing the discussion from Oto is shaking while moving:
I found that people in the community had encountered shaking problems long ago when they were using ChacterController or BetterChacterController. I found that in this discussion, a solution was proposed, that is, calling the two lines of code in SimplerUpdate () or before the update of the physical controller object can solve the jitter problem. In example, I added these two lines of code to testbettercharacter and found that the jitter was really gone. 
Has anyone ever run testbettercharacter? Moving characters on my computer is very shaky.
That thread is ancient. You shouldn’t call updateLogicalState(), etc. directly.
…it’s also probably not really fixing the problem but only making it less visible.
Looking at the example code, my first guess as to the problem would be this line:
Does the jitter also happen if you lock the view?
Thank you. As you said, after pressing “Return Enter”, we locked the view point and no jitter appeared, but strangely, I fixed the camera directly in the world to observe the monkey movement. After trying to move for countless times, there would still be jitter. Later I changed it to call directly in update. betterController.update (tpf); It will be better. Although bulletappstate provides a single thread mode, there will still be jitter problems. In addition, not only bettercharactercontroller, but also charactercontroller and VEHICLECONTROL have jitter problems. Is this caused by physical engine encapsulation or camera capture?
simpleUpdate() runs before EVERYTHING. So if simpleUpdate() does any synching of the camera to any spatial that is updated by a control (like physics characters, etc.) then it’s guaranteed to be off by at least one frame… maybe two. So you’ll have jitter.
The camera node on its own is a child of the character and so should always update after the character and everything should be fine.
As to your other stuff, I don’t understand the setup enough to point to where the jitter could be. You should not call update() directly as it may screw other things up… it should only be used by super-experts who have detailed knowledge of the engine to know when it’s a good idea.
…it shouldn’t be required in any of these cases if the scene is setup properly.
2 Likes
Thank you. My test is TestBetterCharacter.java , I just set the lockview variable to true manually, let the camera observe the world fixedly, and then the monkey walks around in front of the camera, repeat n times, check carefully, there will be jitter.
I really hope that the minie physical library can improve these situations by encapsulating them internally. It may not be very friendly for a fool to set camera node lock object to improve jitter… 
It’s not the camera lock that fixes the jitter… it’s working around the buggy super buggy bad shouldn’t be there because it’s wrong and super buggy code in the TestBetterCharacter example that’s wrong and shouldn’t be there.
This line:
…is a bug. And shouldn’t be there. It will certainly 100% cause jitter.
It should be done much later. Like in simpleRender().
As it is currently, it’s looking at the object where it was and not where it will be. It’s looking at the object location of the previous frame.
1 Like
Is it possible this is poorly documented and was supposed to be used in a tutorial or something?
Why would this be there is what I am wondering.
Thank you. I understand what you mean. You mean that the camera will vibrate when it is observed between the front and back frames. If you lock the viewpoint directly, it will reduce the jitter by 90%. However, if you observe carefully and move repeatedly, there will still be slight jitter, which may be caused by the physical engine or other places. Strangely, I call directly in simplerUpdate (). controller.update (TPF); jitter again reduced. 
If the camera position is locked properly to the object position then there will be NO (0 none, nada, none, 0) jitter between the camera and the object. Not 90%, 100%.
If you mean some other kind of jitter then I don’t know what to say and I don’t have time to run the demo locally right now.
OK, thank you for taking the time to answer my question. However, I think some examples need to be modified, otherwise for learners, they often need to go to the community for help. I’m just making suggestions, thank you again.
Yes, there is a bug in the example. I don’t know how much clearer I can be about that.
Anyone from the community is welcome to fix the bug.
2 Likes