koobas.hobune.stream
The question is answered, right answer was accepted
car seems to slightly lag or 'hickup' when moving
I have this 3D car model and I'm using code to rotate the wheels and move the car along, pretty simply as it really just needs to 'run on a rail' type system. Here's a short video demonstration of what the car does: https://youtu.be/W0PE-7bjx6o You can see right as it starts to move it 'skips' and then does it a couple more times right before the end.
Here's the little bit of code that rotates the wheels and moves the whole car.`public void MoveForward() {
foreach ( Transform l_Wheel in m_Wheels )
{
l_Wheel.Rotate( new Vector3(speed, 0, 0 ), Space.Self );
}
transform.Translate(Vector3.forward * speed * Time.deltaTime);
}`
I tried adding Time.deltaTime to the wheel rotation as well but that had no impact. I also have this running within a LateUpdate function if that matters any. The only thing that I've noticed is that if I print out the wheels' rotation (in Euler angles) sometimes the Y and Z rotations jump to 180 for a few frames. Not sure why this happens or if that might be what's causing the skip. Can't really seem to tell if they line up in term of timeline. Any help anyone can offer is greatly appreciated.
if theres nothing else in that scene, then swap the LateUpdate for a FixedUpdate, and change deltaTime to fixedDeltaTime
otherwise, open the profiler (window > profiler) and watch whats happening in the list when you play in edit mode. If you ferret around in the huge listings of everything that runs the game, you should find something thats dragging a big process spike.
Sorry, edited from what I wrote before because I very stupidly forgot to try it under FixedUpdate and now it seems to run smoothly (which is weird 'cause I'm sure I tried that before...but then again, stupid)
Why would using FixedUpdate make it run smoothly? Is it because it runs at a set framerate? Thanks for the help.
fixedupdate is the physics time step - which is found in the Time manager. its by default 0.02 - so thats exactly 50 updates per second.
lateUpdate and Update are directly process at the screen refresh rate (not monitor refresh rate unless vsync is set to true), so anywhere between 1 fps and 1000 frames a second is entirely possible. lateUpdate the at the end of the frame process stack, update is at the start of each frame, so you'll get way out of wack updates. the delay might be something as simple as some other process co$$anonymous$$g online in the background, when you press play, which meaks that the movement steps. thats because you have a time.deltaTime multiplier in there, so the distance will be correct over time, but the frame display can show hops. So sticking movements into fixedupdate will make them process every physics frame at a set interval. its not always recommended though, its dependent on what your moving
https://docs.unity3d.com/ScriptReference/$$anonymous$$onoBehaviour.LateUpdate.html https://docs.unity3d.com/ScriptReference/$$anonymous$$onoBehaviour.FixedUpdate.html
