Differences

This shows you the differences between two versions of the page.

--- en:toolworks:docs:apparatus:steady-tick [2021/03/24 15:47] – vladius
+++ en:toolworks:docs:apparatus:steady-tick [2021/04/08 22:24] (current) – vladius
@@ Line 45: / Line 45: @@
 During the variable "native" ticking we have to interpolate between the previous steady state and the next one. It's up to the user to do the actual interpolation but Apparatus provides a functional basis to do this.
-First of all there is a steady frame ratio node:
+First, there is a steady frame ratio node available:
+{{ :en:toolworks:docs:apparatus:steady-frame-ratio-node.png?nolink |}}
+This node returns the ratio of the current variable tick in relation to an active steady frame it resides within. For a better understanding see the following schematic:
+{{ :en:toolworks:docs:apparatus:steady-frame-ratio.svg |}}
+This ratio, which is bound from 0.0 to 1.0 (both inclusively), can be used to interpolate the animated visual feedback of some value based on its previous and the next state. In order to achieve that, your steady ticking mechanics have to prepare both states during their processing, while perhaps swapping the past state with the future one. The usual variadic ticking then can use a [[ue>BlueprintAPI/Math/Float/Lerp/index.html|Lerp]] node to implement the actual smoothing.
+Sometimes it's tedious (or kind of difficult) to manage both past and future states in some auxiliary separate variables. You may want to use the current object's state instead of its past one - store it in an Actor's current transform, for example. So we present an another way of smoothing things out - the Steady Future Factor node.
+{{ :en:toolworks:docs:apparatus:steady-future-factor-node.png?nolink |}}
+This node is similar to Steady Frame Ratio in that it is also returning a single float value bound to an inclusive [0.0, 1.0] range. It differs in the actual basis for this range. Let's illustrate it on the picture:
+{{ :en:toolworks:docs:apparatus:steady-future-factor.svg |}}
+As you see, the last change (be it steady or a usual tick) is tracked and remembered as a starting point for the relation. The second part is the same as for the Steady Frame Factor node and actually represents a timestamp of the next future steady frame. Using the future factor you can use the current actual state as a base for [[ue>BlueprintAPI/Math/Float/Lerp/index.html|Lerp]]ing with a next future state. Just be attentive to your calculations and make sure you actually keep track of what your are lerping to what.
+Both of these nodes can be used directly during the Tick event in your mechanisms. However, we implemented a special type of mechanical event called Presentation Tick event, that essentially incorporates them both:
+{{ :en:toolworks:docs:apparatus:presentation-tick-event.png?nolink |}}
+This event is run after your normal variable ticks (and hence after the necessary steady ticking) and is meant to be used for evaluating the visual feedback mechanics. Interpolating mechanics are logically and clearly one of those. Have a look at this complete position interpolation mechanic that is a part of our [[https://github.com/toolworks/ApparatusPlatformer|sample platformer project]]:
+{{ :en:toolworks:docs:apparatus:presentation-mechanic-sample.png?nolink |}}
+The most important Apply Offset function is implemented like so:
+{{ :en:toolworks:docs:apparatus:apply-offset-sample-implementation.png?direct |}}
+Concluding the topic it should be said that the described technique is not mandatory at all. You can evaluate your mechanics anyhow you like and configure the engine to produce fixed FPS updates. We, however, presented you a way to achieve a consistent gameplay framerate and also recommend using it for stability reasons.