The smoothness of the piston animation is inconsistent. Sometimes it's smooth; sometimes it's not.
Steps to reproduce
Place a piston/sticky-piston and put a button or lever on it.
Activate the piston with the button/lever.
The observed result:
Here, I uploaded 2 recordings:
The first one shows laggy animation. The piston looks like it's skipping some frames.
The second video is recorded after I reloaded the world. The piston animation is smoother. But, as pointed out, the piston arm still travels different amounts of pixels for each frame. And also, extension/retraction takes 4 frames in total, which is kind of too little.
The expected result:
The piston arm, when piston is powered/un-powered, should always travel the same distance with the same velocity, consistently. It should also be given more than just 4 frames to do so.
Important note
This issue is not MCPE-146597 which is about the animation of the block that's being moved by the piston.
This issue is about the piston's arm animation.
Additional information
My PC is an Excalibur (Casper) g770 laptop. It has a dedicated Nvidia graphics card and an Intel Core i5 10th Gen processor, so my computer is in no way a low end device.
Only the default resource pack / behavior pack is running and no extra modification to the has been applied whatsoever.
Linked issues
is duplicated by 2
Attachments
Comments 15
This report is about the piston arm animation, not blocks moved by the piston. MCPE-146597 refers to the moving block. They are separate issues as the piston arm animation has been the same choppy and inconsistent through many different versions while moving block visuals have changed.
MCPE-146597 talks about the block that is being moved by the piston, while this one is about the piston arm itself not being smooth, which an entirely separate issue.
The ticket has been slightly updated to clarify what the issue is about.
It seems the beta did not fix this issue
We're always told to use this site as a platform to report bugs. And now we're being told otherwise for doing this exact same thing. This is ridiculous.
Sorry for the delay in reopening the report.
Thanks for reopening
apparently, the issue has been marked as "fixed" in the latest preview versions. If someone could upload a short video demonstrating it, it would be appreciated.
I would not say that the second video shows a "smooth" animation. It's a little less choppy than the first, but it's not smooth at all compared to Java.
I clipped the first two extensions and retractions of each video and slowed them down twice using Windows default tools. Here they are for comparison:
[media][media]Looking more closely at these examples I observe the following:
[media]The extension and retraction animations at best run in exactly 4 steps. Since an extension takes 2 game ticks or 1/10th of a second, that means the piston extension animation is capped at 40 fps. Not terrible, but not great either. (The 4 steps are not an artifact of my video recording or editing in Windows. I also observed exactly 4 steps examining
, which I made in Minecraft on my iPhone 8, and I have noted 4 steps in supporting media from other reports.)
The 4 steps are not consistent with each other. This is why even the "smooth" animation (which I called "Not choppy..." in the video name) is actually not very smooth. In the first extension from the smoother video, the animation steps jump as follows:
[media]||Animation Step||Step Distance (pixels)||Total Distance (pixels)|| ||
|1|3.5|3.5|
|
[media]|2|4.5|8|
|
[media]|3|6.25|14.25|
|
[media]|4|1.75|16|
|
Sometimes (randomly) the animations appear to only have two or three steps. This largely accounts for the less smooth/"Not choppy..." video examples. Given the inconsistency noted in the previous point, this point may just be a result of the game playing successive steps with no difference in distance. Note that the second extension in the smoother/"Not choppy..." video, there are four steps, but the total distance goes 8, 15.5, 15.75, 16.