You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Renaming NetworkTransformMultipleChangesOverTime to just MultipleChangesOverTime (no need for the NetworkTransform part as it is already part of the NetworkTransformTests).
Turning off Lerp smoothing for MultipleChangesOverTime and added lengthy comment as to why.
Fixed the initial check for the first state update in MultipleChangesOverTime due to a change in the Interpolation value. It was not properly checking both pushed and updated values and should only be checked when interpolation is turned off as the default is enabled and when running MultipleChangesOverTime for 3 axis it remains enabled (i.e. there will be no state update for that as nothing changed).
// Lerp smoothing skews values based on our tests and how we had to originally adjust for the way we handled the original Lerp approach and how that
511
+
// consumed state updates from the buffer.
512
+
// With the two new interpolation types, they will process until close to the final value before moving on to the next.
513
+
// Lerp--> Will skip to next state before finishing the current state (i.e. loss of precision but arrives to the final value at the end of multiple updates faster)
514
+
// LerpExtrapolateBlend & SmoothDampening -->
515
+
// Will not skip to the next state update until approximately at the end of the current state (higher precision longer time to final value)
516
+
// How this impacts this test:
517
+
// It was re-written to use TimeTravel which has a limit of 60 update iterations per "WaitforCondition" which if you are interpolating between two large values
518
+
// it can take a few more iterations with lerp smoothing enabled. Lerp smoothing is purely a visual thing and will eventually end up at its final destination
519
+
// upon processing the last state update. However, this test should be only to verify the functionality of the actual lerping between values without the added
520
+
// delay of smoothing the final result. So, instead of having one timeout value for the two new interpolation types and the default for the original I am opting
521
+
// for the disabling of lerp smoothing while this particular test runs as it really is only validating that each interpolator type will interpolate to the right
522
+
// value within a given period of time which is simulated using the time travel approach.
523
+
// With smooth lerping enabled, the two new interpolation types will come very close to the correct value but will not reach the 2nd or 3rd pass values set because
524
+
// this test uses the adjusted approximation checks that prematurely determines the target values (position, rotation, and scale) have been reached and as such
525
+
// sends a new state update that will sit in the buffer for 3-4 frames before the two new interpolation types are done with the current state update. This will
526
+
// eventually lead to a time deficit that will offset the processing of the next state update such that the default time travel timeout (60 updates) will timeout
527
+
// and the test will fail. This only happens with 3 axis since that is the only time interpolation was enabled for this particular test.
528
+
// As such, just disabling smooth lerping for all 3 seemed like the better approach as the maximum interpolation time out period for smooth lerping is now
529
+
// adjustable by users (i.e. they can adjust how much lerp smoothing is applied based on their project's needs).
0 commit comments