I'll post more later on my ideas, I'm a little rushed at the moment. Ciao.
MLP Free Animator
Monday, December 29, 2014
Vector GUI Concept for Vector Applications
I came up with a concept for how I might make an application made for creating vector art and animations, but where the GUI itself is also vectoral. This idea was derived from FlowStone.
I'll post more later on my ideas, I'm a little rushed at the moment. Ciao.
I'll post more later on my ideas, I'm a little rushed at the moment. Ciao.
Thursday, December 11, 2014
Vector Smears (Take 3 - Huzzah!)
I realized I'd been looking at this problem kind of wrong, so after a bit of rework, I finally got a sweet, anime smear (or motion blur) effect.
Anime Smear (Still)
Anime Smear (Moving)
As always, I'll post more updates as things happen.
Tuesday, December 9, 2014
Vector Smears (Take 2)
So after a little bit more work, I've managed to get the smear effect to look a bit better. It still needs a little work, but I'm getting really close now.
Smear (30fps)
Smear (4fps)
I need to figure out how to make the artifacts that occur when the shape flips inside-out stop happening. My best bet is to figure out which points in time the velocity of the object changes dramatically enough to cause such a problem. I'll need to do more testing.
Monday, December 8, 2014
Vector Smears (Take 1)
As a side project, I decided to look into doing algorithmic smear effects. Smears are done in older cartoons, mostly because transparency is difficult when using paint. There's an imgur album full of stuff regarding this topic, you should go check it out first.
As a concept, smears are made by making parts of a body appear to be at different points in time, and that point in time is generally based on what's closest to the "front" of the motion and what's closest to the "rear" of the motion. Using this concept, I've built a simple prototype:
As a concept, smears are made by making parts of a body appear to be at different points in time, and that point in time is generally based on what's closest to the "front" of the motion and what's closest to the "rear" of the motion. Using this concept, I've built a simple prototype:
Path:
Smear (1x):
Smear (2x):
Smear (3x):
Smear (5x):
Smear (10x):
Smear (25x):
It would seem that my algorithm needs a little work, although it's not too far off. I just need to take into account volumetric smearing next.
First PyCairo Test
So I did a little more research on PyCairo this morning. It turns out that the requirements for using it with pygame are really simple - you only really need PyCairo, numpy (or numeric, whatever), and pygame installed. There was even a section in the pygame.org site dedicated to this exact thing.
EDIT: Oh yeah, I also discovered that InkScape uses Cairo! Neat!
EDIT: Oh, yeah, also Cairo has built-in masking stuff, so I won't need to use my slow-ass algorithm anymore :D
As a quick test, I took the old outline program and created a duplicate version for testing out PyCairo.
You can see that the antialiasing is absolutely superb! However, it seems that rendering a scene using an immediate mode algorithm creates some small problems... you might have noticed that there's some artifacts that appeared between the curves and their miter joint; that is the result of the separate shapes being rendered independently, one at a time. When doing this, the library doesn't have any way of knowing that there's two shapes connecting where the gap forms, so it just does antialiasing of the individual shapes, which in the end creates those gaps.
The proper way to deal with this is to create a scene using a retained mode algorithm and then use multisampling to render the entire scene. I don't know yet it Cairo can do retained mode rendering, but in the event that it can't I'll have to find a work-around so these gaps don't become a problem.
EDIT: Oh yeah, I also discovered that InkScape uses Cairo! Neat!
EDIT: Oh, yeah, also Cairo has built-in masking stuff, so I won't need to use my slow-ass algorithm anymore :D
As a quick test, I took the old outline program and created a duplicate version for testing out PyCairo.
So here's what the outline looks like WITHOUT PyCairo:
...and here's what it looks like WITH PyCairo:
You can see that the antialiasing is absolutely superb! However, it seems that rendering a scene using an immediate mode algorithm creates some small problems... you might have noticed that there's some artifacts that appeared between the curves and their miter joint; that is the result of the separate shapes being rendered independently, one at a time. When doing this, the library doesn't have any way of knowing that there's two shapes connecting where the gap forms, so it just does antialiasing of the individual shapes, which in the end creates those gaps.
The proper way to deal with this is to create a scene using a retained mode algorithm and then use multisampling to render the entire scene. I don't know yet it Cairo can do retained mode rendering, but in the event that it can't I'll have to find a work-around so these gaps don't become a problem.
Saturday, December 6, 2014
PyCairo
So I discovered a pretty nice graphics library called Cairo just today, and apparently not only does it have support for Python (PyCairo), but it also works with Pygame! Hell yeah!
What's nice about this library is that it has really nice gradients, everything is beautifully antialiased, and best of all... it's fast. Check it out, I found an image online of what the library is capable of doing:
What's nice about this library is that it has really nice gradients, everything is beautifully antialiased, and best of all... it's fast. Check it out, I found an image online of what the library is capable of doing:
I'm really looking forward to using this library.
Monday, September 22, 2014
Expression Interpilation - The Mouth
One of the hardest things I'll need to tackle is figuring out a way to do expressions. Now, I could just make a whole bunch of presets, but that's not the way I like to do things. Instead, I'd like to come up with an algorithmic way to create expressions.
Focusing on the mouth, two things immediately come to mind: the first is that the muzzle changes shape depending on if the mouth is opened or not.
The second thing is that the mouth seems to work independently from the muzzle, especially while the mouth is close - it almost appears to be superimposed when the mouth isn't opened.
Alright, well let's look at the curves needed to create both mouths, starting with the closed mouth:

You can see that the curve that makes the mouth is completely independent to the curve that makes the muzzle. It's also worth pointing out that the mouth only needs a 3 point bézier curve (two end points and 1 control point) instead of the standard 4 point bézier (two end points and 2 control points).
Now let's compare this to the curves of the open mouth:
Instead of having two separate curves, we have one line made of several curves - 4 to be exact. This is 2 more than when the mouth is closed. The good news is that some things haven't changed at all - the end points and their respective control points for the curve that makes the muzzle are unchanged. Also, the end point of the curve that's at the corner of the mouth still doesn't have any control points. However, it would seem that there's now two curves that make up the mouth instead of just one, and one of them has an end point that has collinear control points (which is why the top of the mouth is curved instead of a sharp corner like the bottom).
Ok, so in order to create both shapes, we have to satisfy the minimum requirements of either. This means we'll likely end up with a less optimal shape. That would be obvious in the case when the mouth is closed, since it usually requires 2 curves total. So let's come up with a case where we can create the shape of the closed mouth using 4 curves:
In a sense, this is the same as the example with only 2 curves - the curves that make up the mouth are identical - they might as well be one curve. Everything else pretty much remains unchanged between when the mouth is close and when the mouth is opened... EXCEPT the corner that makes up the top-front of the mouth!
Look at the curves for when the mouth is opened...


Do you see how the control points are collinear for that one corner, making the top part of the mouth a smooth curve? Compare that to what we just made and you'll see that corner's control points AREN'T collinear when the mouth is closed, which makes it a sharp corner. Do you know what that means? It means we have to interpolate that corner when transitioning between a closed mouth and an open one!
Let's play pretend for a moment - let's say we have a slider called "muzzle-mouth curve" that is used to go between a closed mouth and an open one. When the slider is set to 0 we get the closed mouth shape, and when it's set to 1 we get the open mouth shape. Between the two shapes it would create, we already know what it would look like when it's set to 0. In order to get the other shape, we'd have to make the control point of that one corner (the one that determines the curve of the top-most part of the muzzle) move around until it's collinear with the other control point for that corner. That would look like this:
(I admit, I accidentally moved some other control points too, but ignore that.)
You can see that the top part of the mouth, despite the mouth being closed, now looks rounded. The two identical curves on the inside of the mouth remain unchanged, but we've still managed to get that smooth upper-mouth we need when a character has their mouth opened!
There! We've taken the first steps needed for doing interpolated expressions!
Subscribe to:
Posts (Atom)