Make it less likely to have objects in an invalid rotation state right after entering another object for a frame
Hi! This commit does exactly that: there sometimes is a slight disconnect between the rotation state of an object and its current animation status.
When one object (i.e. the dark grey circle) enters another one (light grey square) it will first position itself on a designated entry point, which in turn is connected to a so called “slot” on the object to be entered.
In the example above this has already happened, the circle is on the entry point and facing the coordinates of the slot associated with it and changes its ContainedStatusChange from None to Entering. When this is happening, it will also start playing the appropriate animation for the chosen slot type (e.g. “sitting down” for animation type and “front” for position).
While the object visually changes its position, it logically stays in place at its current position, the same is true for its rotation, this is what is seen in step two.
The critical part here is what is happening between step three and four, the number of (logical) ticks that are required to enter the object have passed and the object needs to complete the transition. During this process it will change its ContainedStatusChange from Entering to None, as well as set its new coordinate, rotation and animation.
The problem which can lead to a flickering model here is that the render thread may not be taking the new model rotation (and position) into consideration very briefly, as the logical object (!= model) information may not be synchronised yet, the new animation has already taken effect though.
In short, this commit makes this scenario less likely, does not fully alleviate the problem though. I’m not thrilled by that, but it’s also important to keep the bigger picture (tangible progress) in mind and not getting lost in too many minor details, particularly after wrangling for an extended period of time with a polishing change like improving animation performance.
This does not mean these changes are unimportant in any way, but it is important to carefully consider when the right time is to invest work into a certain topic to get the best, well, bang for the buck. 🙂
Next up will in all likelihood be something in preparation to the scenario/map mechanic, I have also some of other (bigger) topics, those will still need to get turned into GitLab milestones and tickets. One step at a time. Byeee 🙂