How to Create Animations Using Mathematical Patterns? (film, 8 minutes)
Junferno invites viewers into the world of animation in Desmos! In this blog post, the author discusses how to achieve animations using tools like YouTube DL and FFmpeg to convert videos into PNG frames. After obtaining the source material, one can begin creating animations. Furthermore, Junferno highlights the possibilities of creating vector art using Bézier curves, showcasing the application of mathematics in practical programming. Although it requires skill, interesting results can be achieved in a short amount of time, as demonstrated by the author’s rendition of the character Zhongli.
In the next section, the author explains how to convert raster images into vectors, which is crucial for the process ahead. They employ a tool called Potrace that converts pixels into Bézier curves. The author notes the importance of ensuring that images inputted into Potrace are strictly one or two colors, avoiding grayscale. For more complex images with multiple colors, it's necessary to use advanced edge detection, which can be achieved using the OpenCV library.
Then the author shares significant insights about processing edges derived from already computed contours. Junferno elaborates that such actions enhance the definition of the image and make the curves much more complex and visually appealing. They then provide valuable tips on programming a front-end script that renders each frame of the animation. Finally, the author reveals the rendering times for different sequences, which can be crucial for aspiring developers and animation enthusiasts.
To summarize, Junferno emphasizes that the tools and techniques discussed in the video shed light on deeper understandings of processes used in animation within software development. Even though the Desmos animator may not seem the most practical tool for daily use, it creates excellent opportunities for learning and experimenting with computer graphics. At the time of writing this article, the video has over 3.5 million views and nearly 216,000 likes, certainly reflecting its popularity and usefulness for programming and graphics enthusiasts.
Toggle timeline summary
-
Introduction to animating in Desmos.
-
Exploring how to animate with source material.
-
Downloading YouTube videos and extracting frames.
-
Desmos vector art requires time and dedication.
-
Speed and automation are prioritized over cleanliness.
-
Introducing Bézier curves for curve generalization.
-
Difference between raster and vector images.
-
Using Potrace to convert PNG to Bézier curves.
-
Issues with edge detection in color images.
-
Using OpenCV for sophisticated edge detection.
-
Combining two edge detection methods for better results.
-
Rendering frames and timing for animation.
-
Discussion on rendering times for video animations.
-
Reflecting on insights gained from the animation process.
-
Closure and transition from technical details.
Transcription
Now that you've been fooled by the cartoon woman into watching this, let's talk about computer science. So you want to animate something in Desmos, or so have many of you expressed for some reason. How would you go about doing that? Well, the first thing you want to do is to obtain the source material. If you want to animate a YouTube video, you would want to first download said YouTube video with a command line tool like YouTube DL, and then proceed to parse it into its individual frames with FFmpeg. And what you're left with is a directory of PNG files. The question then becomes, where do we go from here? Desmos vector art isn't something that's uncommon, it just takes a long time to do. One of the more impressive ones I could find is this one, where someone made Zhongli in Desmos, and it took them about a week. In contrast, here's my Desmos representation of Zhongli, and here's my Desmos representation of my Desmos representation of Zhongli, and it took me 10 minutes. Now of course, the dedication and mathematical skill required to draw Zhongli manually does have its merits, and you'd also get more control in the cleanliness of the image. However, for our case, what we want is speed and automation, rather than cleanliness. And so, we have to figure out a way to generalize any type of curve with a single equation. If you've seen the previous video, you already know that this equation is the Bézier curve. The Bézier curve is represented by four points, one being the starting point and one being the ending point, and then the other two determine the curvature. As we are software developers, we don't really have to go too much into the math, but just understand that you can think of the two points as the line going from the starting point is going towards the first curvature point, and then when it's going towards the ending point, it's coming from the second curvature point. Using this Bézier curve formula, all we have to do is plug in our parameters, and Desmos will take care of the rest. So how do we get these parameters? Well, to understand this, we have to understand file formats. PNGs, as well as other file formats such as JPEGs and GIGIFs, use a raster image to represent the data. And what this means is that it represents the image as a matrix of pixels. Each pixel representing some color. On the other hand, SVGs and other vector image formats use Bézier curves to represent their images, which is very convenient for us, because all we have to do is convert our PNGs into SVGs, and rather than writing them to a file, take the data and put it into Desmos. We can use a tool called Potrace, or whatever it's called, to put in our PNG data as a bitmap and it will return us a traced path of all the Bézier curves. Once we have our four points, we just put them into our equation and write it as a LaTeX expression, which is what Desmos API uses to draw the graphs. However, another issue arises. Because of the edge detection algorithm used by Potrace, the image that is inputted must be strictly one of two colors, such as black and white. Note that this is not a grayscale, this is strictly black or white pixels. This is because Potrace traces the edges in between two colors and two colors only. Now, if you were trying to trace something that was mostly just black and white, like Bad Apple, you can just, say, convert all the gray pixels to white, and then it should be no problem. However, we want to be able to animate anything in Desmos, and unfortunately for us, Sengoku Nadeko does not live in a universe that is severely monochromatically colorblind, and so we have to deal with things like shading and colors. And so the question arises, how do we represent something that has multiple colors as just two colors, without losing any detail? The solution lies in a secret strategy known by all programmers called, get an external library to do it for you. In this case, we're going to use the OpenCV library's canny edge detection. What this does is it uses a more sophisticated edge detection algorithm to get us contours of the image, which are more detailed lines that we can get from an image, even if it has color. These contours can then be represented on separate images as white lines on a black background. The reason why we still have to use Potrace, and we're not just going to use these lines directly on Desmos, is because these lines are represented as linear straight lines. And so as I said before, with linear approximations, you're either going to have low resolution or a lot of lines to render. So once we get our image in which the edges are all white and everything else is black, we can then put that into Potrace, and what we're doing is running an edge detection on the edges that have been detected by another edge detection. This allows us to give us a much more defined image when we're taking a colored image as our input, but it also has the added effect of making all the lines double lines, since it is tracing something that has already been traced. From there, all you have to do is create some front-end script to render each frame and update the graph at each frame, and then just wait for it to run all the way through. Now some astute viewers have pointed out that they could look at the clock in my videos to determine the exact amount of time in real time that it took to render, to which I say stop. However, in all seriousness, yes, the Bad Apple video took about 1 hour to render, whereas the much shorter sequence you saw at the beginning of this video took 2 hours. This is because the greatest rate limiter is going to be the number of lines that have to be drawn, because what's going on in the Desmos backend is not what we are hosting locally, so we can't do much to control that. As a final note, I think it's nice to point out that even though the Desmos animator on its own may not seem to be very practical in its uses, the tools and algorithms used in the process of making it give us good insight in the way that real videos and animations are processed in real software. Oh wait, I'm sorry, I almost started talking about programming that benefits society. Anyways...