manim
manim copied to clipboard
`Transform`ing to similar `MathTex` object distorts sometimes
Description of bug / unexpected behavior
When transforming two objects that are visually identical, the transformation should appear like a translation. However, it seems that sometimes the object distorts during the animation.
Expected behavior
Object in animation should appear as if it is simply translating across the screen.
How to reproduce the issue
Code for reproducing the problem
var = "a"
a1 = MathTex("2").shift(UP)
a2 = MathTex(var)
a3 = MathTex(var).shift(DOWN)
self.play(Write(a1))
self.wait()
self.play(Transform(a1, a2))
self.wait()
self.play(Transform(a1, a3))
self.wait()
Additional media files
Unexpected Behavior
Expected Behavior
System specifications
System Details
- OS: macOS Big Sur (11.5.2)
- RAM: 16 GB
- Python version: Python 3.7.3
- Installed modules:
attrs 21.4.0
black 22.1.0
certifi 2021.10.8
charset-normalizer 2.0.11
click 8.0.3
click-default-group 1.2.2
cloup 0.7.1
colorama 0.4.4
colour 0.1.5
commonmark 0.9.1
Cython 0.29.27
decorator 5.1.1
glcontext 2.3.4
idna 3.3
importlib-metadata 4.10.1
isosurfaces 0.1.0
manim 0.14.0
ManimPango 0.4.0.post2
mapbox-earcut 0.12.11
moderngl 5.6.4
moderngl-window 2.4.1
more-itertools 8.12.0
multipledispatch 0.6.0
mypy-extensions 0.4.3
networkx 2.6.3
numpy 1.21.1
packaging 21.3
pathspec 0.9.0
Pillow 9.0.1
pip 20.2.3
platformdirs 2.5.0
pluggy 0.13.1
py 1.11.0
pycairo 1.20.1
pydub 0.25.1
pyglet 1.5.21
Pygments 2.11.2
pyobjc-core 8.2
pyobjc-framework-Cocoa 8.2
pyparsing 3.0.7
pyrr 0.10.3
pytest 5.4.3
requests 2.27.1
rich 11.2.0
scipy 1.6.1
screeninfo 0.6.7
setuptools 50.3.0
six 1.16.0
skia-pathops 0.7.2
srt 3.5.1
tomli 2.0.1
tqdm 4.62.3
typed-ast 1.5.2
typing-extensions 4.0.1
urllib3 1.26.8
watchdog 2.1.6
wcwidth 0.2.5
wheel 0.35.1
zipp 3.7.0
LaTeX details
- LaTeX distribution: TeX Live 2020
FFMPEG
Output of ffmpeg -version
:
ffmpeg version 4.4.1 Copyright (c) 2000-2021 the FFmpeg developers
built with Apple clang version 13.0.0 (clang-1300.0.29.3)
configuration: --prefix=/usr/local/Cellar/ffmpeg/4.4.1_3 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libbluray --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-avresample --enable-videotoolbox
libavutil 56. 70.100 / 56. 70.100
libavcodec 58.134.100 / 58.134.100
libavformat 58. 76.100 / 58. 76.100
libavdevice 58. 13.100 / 58. 13.100
libavfilter 7.110.100 / 7.110.100
libavresample 4. 0. 0 / 4. 0. 0
libswscale 5. 9.100 / 5. 9.100
libswresample 3. 9.100 / 3. 9.100
libpostproc 55. 9.100 / 55. 9.100
Additional comments
It appears to make a difference what the starting text is. For example, when beginning with a 2 the Transformation of the a is distorted (see Unexpected Behaviour gif), but when beginning with a 3 the Transformation of the a works as intended (see Expected Behaviour gif). It also depends what the end text is. For example, when using the letter a there are issues (see Unexpected Behaviour gif), but using other letters such as b (see Expected Behaviour gif), works as intended.
I have a user-level guess as for why the 2→a→a animation behaved like that, after some quite unsuccessful dives into interpolation logic - interpolate
, straight_path
, etc.
The use of Transform(a1, a2)
and Transform(a1, a3)
promises a continuous two-step transformation without leaving an extra a in the middle when the second step starts [using Transform(a2, a3)
for the second instead will lead to this issue]. But even though the second step appears to be moving a2
(a) to a3
(a), the actual arguments describe a change from a1
(2) to a3
(a). So the resulted a at the beginning of Transform(a1, a3)
might still be inheriting the point distribution (or interpolation path) of a 2, thus causing the unintended distortion.
But this is still far from explaining why going 3→a→a and 2→b→b (plus 2→c→c, 2→bb→bb) do not trigger this issue.
There seems to be too many places to look for its root cause: play
, interpolate
of Mobject
, straight_path
or even the way LaTeX outputs are converted into SVG-based renderable objects. Is there any advice for where to investigate first - if this issue is really worth a fix?
I've done a bit of exhaustive testing on the interference between characters across transformations. Some findings:
- All occurrences of a buggy character will experience unintended distortions, even if inside a formula.
- If the initial number is 0, 6, 7, 8 or 9, then no interferences will occur. Otherwise, 1 interferes with e6, 2 with agqv, 3 with rPZ, 4 with agq and 5 with A. The pattern is deterministic but seems rather random.
- If the initial number is 2 or 5, they will interfere with their respective super- and subscripts.
https://user-images.githubusercontent.com/35942162/161665848-a7f3e958-6e7f-4896-8a65-4de164e21ec3.mp4
https://user-images.githubusercontent.com/35942162/161665864-e40ed795-4393-4497-ac92-bd92d9471e22.mp4
https://user-images.githubusercontent.com/35942162/161667099-6248c554-1c58-4426-86a3-f14500952983.mp4