Hi guys I was trying to create an app where I could move an object across a room, and I thought of 2 ways of doing this , one with the arrow keys of the keyboard which is stable but a little boring and the other one with a drag and drop action, so I thought I should use and arcRotate camera with the arrows key movement so the camera target would move along with the object , and that I should use a free camera with FPS setting for the drag and drop so it would be like you walking around the room freely and draggin the object wherever you want, and everything works like I wanted except for one little thing, and its that when im using the FPS freeCamera, the ground, walls and object seem to be twitching, like if an earthquake was hitting the scene , so the overall appearance of the app looks terrible and I havent beeen able to fix this thing.
I know its got something to do with applying gravity to the Freecamera and giving it a ellipsoid mesh that keeps it above the ground at a certain height but I dont know how to solve this issue. the other thing is that I ve seen other examples that use FPS Freecamera and dont present this problem but I dont know how they do it. like this one example : Babylon.js - Heart demo
their FPS camera dont twitch the scene like mine, why not ? and how not ?
Can you guys help me spot my error ? I made a repro so you can see what happens:
it only happens with the FreeCamera ,when you change to arcRotateCamera it doesnt happen.
@sebavan @bghgary @mawa @shaderbytes guys you re always so helpful , do you care to take a look at my rookie problem ?
The logic should be key down initiates a move , the move is then handled by the engine on the engines update cycle , then on key up you stop the move.
Currently you are trying to move it based on the rate at which the key event is fired when you hold a key down , which is incorrect and causing the stutter
3 Likes
oh also , i have not done this myself in babylon but in other engines, even once using the engine updates , you should probably use deltatime in your calculations to ensure the same rate of movement , otherwise the users FPS can affect the movement speed.
1 Like
ArcRotateCamera’s alpha / beta angles has smoothing built-in using inertia. FreeCamera position does not. That is perhaps why it’s fine for ArcRotateCamera and not FreeCamera. Like @shaderbytes says, you probably don’t want to do the update in the handler of the DOM events. Instead, it’s better if you remember the state of the keys and update during the render loop or similar. And like @shaderbytes says you want to take the deltaTime into account in case the FPS is not consistent. One option is to use a decay function to smoothly reach the target. This function is deltaTime aware and will do the right thing regardless of the size of deltaTime. Change the factor param to specify how fast you want to reach the target.
2 Likes
ohh you re right about the key movement @shaderbytes, your logic makes it smoother , I think you could even hold 2 keys and get both movements with that logic right , but i think we have a misunderstanding here guys ahahah while your recommendations are really appreciated and correct , cuz I should and will do that , thanks. When I used the term FPS I meant first person shooter not frames per second , my problem isnt with the keys movement , that was just to let you see how the app is all good with the ArcRotate camera , but if you click “Tab” the app will change to the freecamera which has this lines , im sure you will recognize them :
// Gravity enabled for the freecamera and collisions for both
freecamera.ellipsoid = new BABYLON.Vector3(1, 2.4, 1);
freecamera.ellipsoidOffset = new BABYLON.Vector3(0, 2.4, 0);
scene.gravity = new BABYLON.Vector3(0, -0.981/60, 0);
scene.collisionsEnabled = true;
freecamera.checkCollisions = true;
freecamera.applyGravity = true;
if you dont recognize it, its from here : Camera Collisions | Babylon.js Documentation
this lines are to make the First Person Shooter experience with the freeCamera, but look how it looks when you move that camera in my scene :
you see the corner of the room ? the left side of the crate too, like if the meshes were overlapping but its not the case cuz I know for the arcrotate that they are not touching each other. you can see for yourself on the repro using the “tab” key.
So this is the thing that is bugging me. do you guys have any insights on this matter ? thanks for your help guys
Note: I realized the gif I used is not so clear on showing the problem due to the resolution but please just try pressing “tab” on the repro and move arround the camera , look at the room corners and the box when is next to the wall.
This is because of this line you added:
freecamera.minZ = 0.0001;
This will reduce the precision of the depth buffer a lot because it has to be able to handle very small numbers. Removing this line or setting it to something more reasonable fixes the problem.
@bghgary damn you re right , thats it I commented that line and it wont do that anymore , Im sorry that must ve been a line I picked from that documentation example. that was a quick solution to a silly mistake, sorry that I didnt spot it earlier and really thankful for your help guys. 
problem solved !
If this line is in documentation, we probably should fix it. 
I think you have modified that documentation example since I last visited it, I remember it having a split canvas with the one on top being the First person shooter freeCamera and the one below being the arcrotate camera looking at the freecamera like Third person shooter, and it had like 2 grounds at different height so the camera could fall to the below ground. now its not the same example. so i think this line is not there anymore.
1 Like