Question Movement of player character affected by unknown factors despite using Time.deltatime

I've been working on my project for a couple years independently and this would be my first time being completely stumped with an issue. I recently moved everything over to the new input system and now my movement script doesn't work as before when rotating and moving the character. I'm not entirely sure its input system related as I also have real-time lights and recently added this garage asset to my scene:
https://imgur.com/a/BRmCkOK


I'll try to explain the behavior best I can but basically, as pictured, when you are looking from the blue circled locations towards the red circled area, the rotation and translation speed has a drastic change in velocity. Now, naturally this would be addressed with using Time.deltatime (tried fixed dT as well) as a multiplier on the movement vector across frames. I'm updating my movement in fixedUpdate as well. However, the issue persists despite these fixes working in previous instances. The problem is MUCH more of an issue on mouse inputs.

I also notice when looking in the blue region - my graphics utilization goes up to max 90% despite nothing on screen except for an abyss. when looking at the red areas my gpu usage goes DOWN to 50%. I see no change in cpu utilization
The red location has many trigger colliders, dynamic lighting, etc...
the blue location is an endless abyss

Im using post processing - the behavior persists when it is on or off

dynamic lighting seems to play a big role in it - but the problem persists regardless, just to different extents.

here is an example of my codes movement:

Code (CSharp):

1.   UD += 5 *Time.deltaTime * speedV * Aelav / (accelerator);            
2.                 FB +=5 * Time.deltaTime * speedH * ((Ahor * -1f * Mathf.Sin(y * Mathf.PI / 180)) + (Aver * Mathf.Cos(y * Mathf.PI / 180))) / (accelerator);
3.                 LR +=5 * Time.deltaTime * speedH * ((Aver * Mathf.Sin(y * Mathf.PI / 180)) + (Ahor * Mathf.Cos(y * Mathf.PI / 180))) / (accelerator);
4.                 LastMove = transform.position;
5.                 transform.position = new Vector3(LR, UD, FB);

My input actions:

Code (CSharp):

1.  
2. public void OnMove(InputAction.CallbackContext context)
3.     {
4.         MoveVec = context.ReadValue<Vector2>();
5.     }
6.     public void OnLook(InputAction.CallbackContext context)
7.     {
8.         LookVec = context.ReadValue<Vector2>();
9.     }
10.     public void OnElav(InputAction.CallbackContext context)
11.     {
12.         elev = context.ReadValue<float>();
13.     }

Hardware: (Ryzen 9 3900X, 64GB of DDR4 3200MHz, GTX 1070)
Now despite having a project that otherwise works exactly how i've expected, it's absolutely infuriating my basic character movement is now giving me an issue...lol
Thanks for any help

I would like to note there is a 10x fold change on both cpu and render from <1ms to >13ms I guess this works out to like above 700fps but then it drops to the 70 range during this test.

 

Awesome! I hope you are using source control!!! I use git... it saves my butt from errors all the time.

Make a clean break where your input is and see what's coming in values-wise, see if it matches what you used to get with the old system.

In general with these sorts of "why doesn't this work the same" type questions, to isolate and help gain more insight into your problem, I recommend liberally sprinkling Debug.Log() statements through your code to display information in realtime.

Doing this should help you answer these types of questions:

- is this code even running? which parts are running? how often does it run?
- what are the values of the variables involved? Are they initialized?

Knowing this information will help you reason about the behavior you are seeing.

 

I definitely keep older versions when I make a milestone.

However this comes down to not being sure what is causing this. being it input system, lighting, or some other outside thing.

I've even just finished converting movement to purely physics based - rigid body, forcemode.velocitychange, adding torque and forces etc. SAME problem though much less pronounced.

I've even tried tuning the event system variables for input system "Move repeat rate" and delay such that it should be faster than a single frame. At this point - the best I can do is generate a list of frame times and inputs per frame, though not something i can do with the debug logs - with it being a potentially per frame issue.

The other thing noted is:
- for translating: the speed gets slower in the red zone
- for rotating: the rotational speed gets FASTER in the redzone
Mind you this is with the same exact value management such as having the input system call the public methods, settings move vectors and then making the moves on fixed update. the only difference is the values are fixed with keyboard translational movement. Mouse input is obviously variable.
So this in theory you would expect consistency with a fixed value coming in from input system - not the case

I've also tried different input system settings such as Update mode to be in fixed update or dynamic update - no effect

Code (CSharp):

1. if (curslock == false || editing == false)
2.         {
3.                 angiteration++;
4.                 yaw = mspeed * LookVec.x * Time.deltaTime * 100 / 10;
5.                 pitch = -mspeed * LookVec.y * Time.deltaTime*100 / 10;
6.                
7.                 if (transform.localEulerAngles.x < -80) { pitch = -mspeed/10; }
8.                 if (transform.localEulerAngles.x > 80 && transform.localEulerAngles.x <100) { pitch = mspeed/10; }              
9.                 RB.AddRelativeTorque(new Vector3(pitch, 0 , 0), ForceMode.VelocityChange);
10.                 RB.AddTorque(new Vector3(0, yaw, 0), ForceMode.VelocityChange);
11.          
12.             x = transform.eulerAngles.x;
13.             y = transform.eulerAngles.y;
14.             Ahor = MoveVec.x;
15.             Aver = MoveVec.y;
16.             Aelav =  elev;
17.  
18. ......

you'll see here the rigid body based movement. I threw the fixed dT in there with the multiplier quickly. Reference original power where MoveVec and LookVec are set via events

 

You should still try to isolate the input values, eliminate the raw values coming in as a source of the problem. You suspected the change was related to the new input system, so either prove it is or eliminate it from the problem.

Additionally you should never read from EulerAngles... they are indeterminate once you reach 90 degrees, and subject to gimbal lock for reasons beyond your control, such as unusual parenting. For rotations you should always keep your own notion of how many degrees around an axis something is rotated. Here's more:

Turret aiming/rotating:

https://forum.unity.com/threads/vector-lookat-unprecise.858511/#post-5658304

Always set rotations explicitly with the

Quaternion.Euler()

factory method.

 

I have other components in game that are susceptible to gimble lock problems and such, etc - I use quaternion identities and such for managing those problems but for the limits and ease of this particular player characters function I'm content with this. Despite that, the solution presented below moves forward with the rigidbody and physics based movement.

I've confirmed its the input systems configuration *when you are using unity events* and you are setting variables that are then used via Update or fixedUpdate. The "Update Mode" in input system configuration MUST MATCH both A) the Update method you're using and B) the Time.(fixed)deltaTime you are multiplying on the input across frames.

Mismatching these will give you frame dependent acceleration on any value coming through the event system. For example, back to my note of "the mouse travels faster in red (high load, low framerate) areas":
My *events* were called in dynamic update - and so even if I used Time.dT... under fixedUpdate - there was still a case where the values across events were higher due to the amount of distance your mouse could travel across frames (lower dynamic update framerate). Even if you used Time.dT in Fixed Update to compensate - it seems the Event updates and the Time dT are not directly related or become asynchronous. In my case - the asynchronous problem manifested itself when I got an *improvement* but not a *complete fix* when using the Time.dT as I would before.

So in summary: I had to change the events update method to "Process Events in Fixed Update" AND (since i was working with rigid bodies) used the Time.fixeddeltatime

A final thing I would note it that if you find yourself having a use-case that requires dynamic update events - you'll likely need to do the above in Update(), but then set another variable to be used in FixedUpdate() if you're updating physics items. redundant... but might help with the asynchronous problems.