Jak tworzyć animacje z wykorzystaniem wzorów matematycznych? (film, 8 minut)
Junferno zaprasza do świata animacji w Desmos! W tym wpisie na blogu autor omawia, jak można zrealizować animacje z wykorzystaniem narzędzi takich jak YouTube DL i FFmpeg do konwersji wideo na klatki obrazów PNG. Po uzyskaniu materiału źródłowego, można przystąpić do tworzenia animacji. Co więcej, Junferno wskazuje na możliwości tworzenia wektorowej sztuki za pomocą krzywych Béziera, co jest zastosowaniem matematyki w praktycznym świecie programowania. Choć wymaga to umiejętności, można osiągnąć interesujące rezultaty w krótkim czasie, co pokazuje praca autora, który stworzył swoją wersję postaci Zhongli.
W kolejnej części autor tłumaczy, jak przekształcić obrazy rastrowe w wektory, co jest kluczowe dla dalszego procesu. Używa narzędzia Potrace, które przekształca piksele na krzywe Béziera. Opisuje także, dlaczego ważne jest, aby obrazy wprowadzone do Potrace były czysto jedno- lub dwukolorowe, bez odcieni szarości. Autor zaznacza, że w przypadku bardziej złożonych obrazów, takich jak te z większą ilością kolorów, konieczne jest użycie zaawansowanej detekcji krawędzi, co osiągamy dzięki bibliotece OpenCV.
W następnej części występują istotne informacje na temat przetwarzania krawędzi z już obliczonych konturów. Junferno wyjaśnia, że takie działanie poprawia definicję obrazu i sprawia, że krzywe są dużo bardziej złożone i przyjemne dla oka. Potem dostarczają cenne wskazówki dotyczące programowania skryptu front-endowego, który renderuje każdą klatkę animacji. Na końcu autor wyjawia czas renderowania dla różnych sekwencji, które mogą być istotne dla zapalonych programistów i miłośników animacji.
Podsumowując, Junferno podkreśla, że narzędzia i techniki omawiane w filmie, mogą ukazać głębsze zrozumienie procesów używanych w animacji w sprzęcie oprogramowania. Pomimo tego, że Animator Desmos nie wydaje się być najprzydatniejszym narzędziem w codziennym zastosowaniu, stwarza świetne okazje do nauki i eksperymentowania z grafiką komputerową. W momencie pisania tego artykułu, materiał filmowy posiada ponad 3,5 miliona wyświetleń i prawie 216 tysięcy polubień, co z pewnością potwierdza jego popularność oraz przydatność dla entuzjastów programowania i grafiki.
Toggle timeline summary
-
Wprowadzenie do animacji w Desmos.
-
Badanie jak animować przy użyciu materiałów źródłowych.
-
Pobieranie filmów z YouTube i wyodrębnianie klatek.
-
Sztuka wektorowa w Desmos wymaga czasu i zaangażowania.
-
Priorytetem jest szybkość i automatyzacja, a nie czystość.
-
Wprowadzenie krzywych Béziera do uogólniania krzywych.
-
Różnica między obrazami rastrowymi a wektorowymi.
-
Użycie Potrace do konwersji PNG na krzywe Béziera.
-
Problemy z detekcją krawędzi w obrazach kolorowych.
-
Użycie OpenCV do zaawansowanej detekcji krawędzi.
-
Łączenie dwóch metod detekcji krawędzi dla lepszych wyników.
-
Renderowanie klatek i czas dla animacji.
-
Dyskusja na temat czasów renderowania animacji wideo.
-
Refleksja na temat wniosków zdobytych podczas procesu animacji.
-
Zamknięcie i przejście od szczegółów technicznych.
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...