- Home /
Some objects working fine at 50 fps, while other objects lagging?
My scene consists of a sphere (that is controlled by the player via touch input) and a bunch of platforms continuously moving upwards (the platforms are continuously spawned via object pooling).
At 60 fps, the movement of all the game objects is smooth. However, at 50 fps only the sphere moves smoothly, whereas the platforms have a very jerky movement.
Here's the code I'm using to control the sphere's movement:
Vector3 movement = new Vector3 (horizontal, 0.0f, 0.0f);
rb.AddForce(movement * speed * Time.deltaTime); //rb is the sphere's Rigidbody
And here's the code I'm using to control the platform's movement:
//rb is platform's Rigidbody
rb.MovePosition(transform.position + transform.up * Time.fixedDeltaTime * speed);
I always assumed that both Time.deltaTime and Time.fixedDeltaTime would make an object's movement framerate independent. So why is it that the sphere's movement is so smooth at 50 fps and the platforms' movement is so jerky? Am I not using the MovePosition function correctly?
I noticed the same effect at 30 fps. Smooth sphere movement but jerky platform movement.
They would be appearing jerky because of their relationship with each other and the scene. I'm interested as to why you are using both deltaTime and fixedDeltaTime for operations that take place in the same time scale (within the physics loop)? $$anonymous$$eeping them consistent should make the movement more uniform (and I believe deltaTime automatically adjusts itself when inside of FixedUpdate, so you should probably use that always regardless). Speaking of which, I would also make sure the physics adjustments are both within FixedUpdate so that they update with the same interval.
time.deltatime or time.fixeddeltatime has nothjing to do with smooth movement. you will need ot use the frame debugger to know what is causing that effect.
Excuse me but I believe on some cases like smooth camera movement, if you implement movement on Update
or LateUpdate
, using Time.deltaTime
as multiplier to displacement the object cover the same distance/rotation in real seconds, regardless the time that take render the camera, so will make "smooth" movement
in this case each frame is some like time samples (t0, t1, t2, t3... tn) in physics linear movement
t_sub_i_position = speed*time_between_samples
However, since we dont know where is calling that piece of code, maybe this dont apply at all, as you say.
Indeed. Smooth is a relative term, and the use of deltaTime is to maintain a constant relationship between changes in values, thus making the changes 'smooth' in a perceptual sense. However, having a different consistency across similar changes introduces its own instability, which I would imagine is (in some way) the cause of the problem here.
Answer by JonPQ · Aug 08, 2019 at 06:36 PM
does your platform need a rigidbody ? let the physics move the ball, that you are applying forces to. but for the platform, move the Transform.position. not the rb.MovePosition
I already tried transform.Translate. It didn't work. By the way, transform.position isn't for interpolating objects. It's only for changing the position.
when you tried moving using the Transform position ins$$anonymous$$d of the RB. did you remove the RB ? they might be fighting each other... manual movement and rigidbody movement. You should use one or the other not both at the same time.
Note:- if your physics timestep is longer than a frame... you will sometimes get a frame where the physics objects won't move. make sure its faster than your fps.
also try late Update. also its important when the Camera updates (if its a moving / following camera) If its a moving camera, try moving the camera's update to the LateUpdate ins$$anonymous$$d of the platform.
btw, you can totally interpolate / lerp the position of an object using Transform.position, you just lerp between your from and to positions, and set the Transform position to that.... e.g. Transform.position = Vector3.lerp(fromVector, toVector, lerp); // where lerp is 0-1
Answer by rh_galaxy · Aug 06, 2019 at 03:08 PM
You should base all physics on Time.fixedDeltaTime, and increase the rate to more than the framerate in Project settings...->Time->Fixed Timestep (set for example 0.01 for 100Hz). The physics calculation will otherwise be slightly different depending on framerate, and you probably don't want that.
Since you move the sphere each frame it works smoothly at any rate, but with the above problem. By setting fixedDeltaTime to a rate at 100Hz the error will be less between frames making the jerkiness better.
"You should based all physics in time.fixedDeltaTime" time.deltatime used in the fixedupdate would give the exact same result, but anyway, fixeddeltatime is a constant so whats the reason for using it? it has nothing to do with his issue. "increase the rate to more than the framerate in Project settings." well thats imposible, that statement is wrong and surely you should always avoid increasing fixed time value. The fps will totally depend on the machine the game is running, for one user might be at 100fps and to the other one 30 fps, never edit the fixed time step depending on the fps because would end with completly total behaviour for each user. "The physics calculation will otherwise be slightly different depending on framerate, and you probably don't want that." thats just not true, physics calculation its completly independant from framerate, doesnt matter even if the game is running at 10 fps since collision would continue to be calculated at same rate, all your statements are wrong
The fixed timestep is fixed, therefore it will be the same behavior for each user however much you change it, and I said to increase the rate, not the value. His physics calculation was based on the deltaTime and not fixedDeltaTime for the first rb, but it's unclear if it was run from Update() or FixedUpdate().
yo are saying to edit the fixed step should update more frequently than the frame rate, so, you should change the value so it updates 250 times per second in case someone is running the game at 250 fps? no. you should never increase that value unless totally needed because you are increasing the collisions calculation, the rigidbody forces, and all the physics related calculations like gravity so it would totally ruin the performance. if you believe that he is running the code in the update, using fixeddeltatime would never be a solution since it would not solve any issue, would be just a constant hurting performance, and if it was being run in the fixedupdate the time.deltatime would return the fixeddeltatime value, so it doesnt matter where it runs, changing to fixeddeltatime is not a solution
I've set the Fixed Timestep to 0.01. It didn't solve the problem. The objects move smoothly for a while and then stutters after every 5-6 seconds.
Yes, maybe some interpolation is done to move objects every frame despite the Fixed Timestep being only 50Hz default. Only thing I can say is that I have a VR game fixed at 90 FPS (vsync 11.1ms) and with Fixed Timestep set to 0.01 (100Hz), do all my physics in FixedUpdate(), only camera movement in LateUpdate() but it follows the player position that is based on physics, and everything is smooth.
Answer by Cornelis-de-Jager · Aug 06, 2019 at 09:41 PM
There is a few things you can try.
Put the code in the Fixed Update. Just good practice to put physics in movement in here.
Lerp the position of the platform
//rb is platform's Rigidbody
var move = transform.up * Time.fixedDeltaTime * speed;
platform.position = Vector3.Lerp(platform.position, platform.position + move, 1f);
well you are not lerping the position of the transform you are just assigning it, is there any advantage i cant see of using
platform.position = Vector3.Lerp(platform.position, platform.position + move, 1f);
rather than
platform.position += move;
it is the same faster and cleaner right? anyway he should simply use the rigidBody.$$anonymous$$ovePosition for testing that code since it "moves a Rigidbody and complies with the the interpolation settings", rather than just teleporting it
The advantage is its smoother. Commonly used to reduced Jittering effects over networks (I have personally used this to reduce Jittering ). Give it a go and tell me if it works for FPS as well.
well thats not posible, vector3.lerp gives a result of an interpolation between the 2 vectors, butinterpolating using 1f as an argument will ALWAYS return the end position, that is platform.position + move, so both codes are exactly thge same, it has no benefit at all the second one is cleaner and better for performance
I've been keeping all physics-based code in FixedUpdate this whole time. That didn't solve the problem.
I have also tried lerping the position ins$$anonymous$$d of Rigidbody.$$anonymous$$ovePosition. That didn't work either. I also tried transform.Translate. That also didn't work.
Any other suggestions?
you need to share some debug informaation, since rigidBody.$$anonymous$$ovePosition should be working
@xxmariofer I can tell you how to reproduce the problem step-by-step. I think you'll be surprised by how simple it is. (1) Create a cube. (2) Add a Rigidbody to the cube. $$anonymous$$ake sure it is set to Interpolate and is$$anonymous$$inematic is true (3) Add a script to the cube and in the script, just write rb.$$anonymous$$ovePosition(transform.position + transform.up Time.fixedDeltaTime speed) in the FixedUpdate function. (4) Create another script and set the target frame rate to 30. (5) Attach the new script to an empty game object. (6) Go to Quality settings and make sure that the game is at the lowest quality. (7) Go to Player settings and set Target DPI to 240. (8) If you want, go to Time settings and set the Fixed Timestep to 0.033333. (9) Finally, build and run the game on an Android device. You'll notice light jerkiness in the object's movement every now and then. If you don't, then there's probably something wrong with my phone.
Your answer
Follow this Question
Related Questions
hi-polys ??? frame lag when instantiating prefab of rigidbodys 1 Answer
MovePosition not as precise as Translate with Kinematic rigidbodies (example unitypackage included) 1 Answer
Once for all... is Time.deltaTime good or bad with Input.GetAxis? 1 Answer
Move a rigidbody when Kinematic ?? 3 Answers