Thursday, March 24, 2011

Funny Blog Post Title

Hey everyone
This blog post is going to be kind of all over the place. This week has been really weird, but weird good.

To show off the XML I developed and posted about last time I've upload a video of folding all four corners to the center (Verlet integration scheme). I was going to upload a fold called a pleat, where you fold it back and forth along parallel creases, but it does not do anything. For some reason the folds cancels each other out and nothing happens. These are some of the bugs I mentioned previously and still working on (see below).



Another development was the discovery of this paper: http://www.csc.calpoly.edu/~zwood/research/pubs/origamiCATA06.pdf .
It is very similar to my proposal. They talk a lot about how their cloth sim will work with the membrane (structural, shear and bend) forces and flexure forces(rotation). They also reference actual materials, but they don't go in depth (kind of like what I will do later). It is interesting to note that they most complicated thing that they were able to fold was the traditional dog model. The things that I am doing differently are the GPU implementation and the memory changing aspect of the paper.
One thing to note is that they reference implicit integration, but they say they don't use it. They use a scheme called Newmark integration. I had never heard of this, but the implementation was easy so I tried it. The integration depends on two values, beta and gamma, to balance out the damping of the integration. I spent a few hours playing around with values and regardless of what values I used for beta and gamma, my paper would always explode. It is possible that I never found that sweet spot, but it seems like Newmark integration is not for me. To me it seems that Newmark is a dampened Euler integration system, so to me it makes sense that it would explode.

So bugs have been cropping up everywhere, including problems with acos. Arccos only returns values from 0 to pi (which I tested). So I think I still need to find negative angles to correctly calculate values of the forces, although the direction of the fold maybe enough. But I am still playing with the implementation of the rotation spring. In the new paper mentioned above they seem to find the angle differently, so I may try their implementation. Another bug seems to be gravity. While gravity does what I want it to, as does the collision with the ground, it seems to have ramifications for the fold. If there is no gravity, the fold does not complete but actually swoops around in a weird manner. So I want to play with forces and try to find a good way to get things folding.



The last thing I started this week was implementing a memory model for the paper. This was my idea of simulating how paper is changed physically when you roll or crease it. I created a new type of bend spring class that holds data for a rotation spring. The rotation spring is placed perpendicular to the bend spring when the bend spring exceeds a certain stretch or compression. The rest angle of the rotation spring is also dependent on the stretch / compression. I tried doing it on a large system, but it is a delicate system and the system seemed to explode when the rotation springs are added. The problem might be stemming from the high spring constant on rotation springs. This means it is more of a balancing issue rather than an implementation problem. I'll post a video when I get it to a better state.
Another approach I took to the memory was simply relaxing the rest length of a bend spring. That certainly had an interesting effect, as if the paper was wet and was suddenly drying. It is a little hard to reproduce sometimes, but basically the paper stays curled and does not unfold because the bend springs are not as strong. It is an interesting approach and something I may consider going forward.


Thursday, March 17, 2011

My Break Only Broke Things

Hey everyone,
I am going to try to make this a quick blog post since I just pulled an all-nighter to finish my 610 assignment. The major thing that I've implemented was an XML schema to let me create more complex folds. The XML schema is setup as follows ( removed the <> since blogger thinks I am trying to type HTML):
Lattice
Size width height /Size
RotSpring
AxisId1 x y /AxisId1
AxisId2 x y /AxisId2
MomentId1 x y /MomentId1
MomentId2 x y /MomentId2
RestAngle f /RestAngle
Direction 0 /Direction
/RotSpring
/Lattice
The size determines the size of the lattice you want to use in terms of point masses on the width and length. The RotSpring tag holds all the information a rotation spring in my simulation has. The AxisIds are the rotation axis and the moment arms are particles you are applying forces to. The rotation spring then has a rest angle and the direction (0 = Valley, 1 = Mountain). Then you can apply more and more rotation springs to make the folds as complex as you want. The nice thing is that I am assuming you are starting from a flat sheet. This means that I can easily detect when structure, bend or shear springs intersect with the rotation springs. So after all the rotation springs are added, I add the structure, bend and shear springs to the system using the standard grid. However before I add the spring I do a check to make sure the spring does not intersect with rotation spring. This allows for flat folding along the rotation springs and a full grid everywhere else.

I have already created several lattices using the XML schema, but that just revealed a lot of bugs. I was able to fix a few obvious ones that were causing problems. However I realized that using a dot product to find the angle along the rotation axis does not always work. The dot product returns an angle that is along a rotation axis that is cross product of the two vectors. This is not the rotation axis I necessarily want.

Therefore I developed a method to find the correct angle. I am given two vectors, a, b and a rotation axis between them, r. We can define a plane created by a and r. We can then project b into that plane and get proj_b. I think that the correct angle will be defined as dot(proj_b, a). I need to check the math, and there are a few corner cases, but I think this will fix a few problems.
There are other bugs, but I'll post again with those when I've gotten some sleep and I don't have up coming interviews tomorrow.

Thursday, March 3, 2011

Bugs and Books

Heyho,

This week I was finally able to meet up with Steve Gray and Vijay Kumar. Steve was able to help me out a lot. I was able to identify a bunch of bugs with my rotation springs that were causing problems outside of the basic diagonal fold. The major one is that for some reason acos(double) is returning values only from 0 to pi and not -pi to pi like I would like it to. The problem clearly manifests itself when I turn off gravity and collision with the ground and the paper continuously rotates itself around over and over again. Originally I thought I could determine the angle with a cross product between the two arms that define the angle. However, this does not seem to produce consistent results. Since I have two arms to define the angle, I can use a cross product between one arm and the rotation axis to find a plane. Then if the point is above the plane(in the direction of the normal), I know the angle is positive. There are a few other bugs and Steve was able to explain a bit about how to add damping to the rotation spring.

In addition to that bug chasing I was able to clean up some more code, making it easier for me to create different lattices by putting them into separate methods. So I was able to implement a vertical fold (also known as a book fold).



Here I actually use two of my rotation springs on top of one another. One rotation spring moves the top corner while the other moves the bottom. The paper is a little floppy here, but I am pretty happy with the result.

I have a few things I want to get done over spring break. The first one is clearly fix the bugs that have arisen in the rotation springs. After I fix the bugs in the rotation springs I want to try implementing them differently where I can apply torque to multiple particles in the lattice, not just one. This way I can try applying force to the particles that are adjacent to the rotation axis, not the furthest particle away. Steve thinks that this implementation will work better than the current one and I agree. I also want to work on an XML schema that will quickly let me test different crease patterns. The XML schema will contain the length and the width of the grid and the location and properties of all the rotation springs. Then I will generate the particles and the rotation springs. After that I will add the bend, structural and shear springs, however I will do a 2d line-line intersection test with all the rotation springs in the system. This way I can make sure I am not adding linear springs on top of rotational springs that could prevent flat folding. Once I get that done and working I can test more and more complex folding systems.

Thursday, February 24, 2011

Complete Fold

Heyho everyone,
This will be just a quick post tonight since I am busy studying for my Pixar interview and for the alpha presentation tomorrow.
This week in addition to preparing my alpha video I did the following things:
-Cleaned up some code
-Experimented with adding friction forces to the paper when it collides with the ground
-Added quad rendering for the lattice to make it look like paper
-Removed the bend springs that lied along the fold axis
-Experimented with where I apply the torque
-Played with constant values for gravity and spring constants

The coolest thing is that I was able to get a complete fold done. The rest angle of the fold can also be toggled between 0 and PI so that the fold can be undone. The lattice is also incredibly stable, so the folding can happen multiple times. Enjoy the video:

Thursday, February 17, 2011

Torsion Springs

Heyho,
So I did not get to implicit or imex this week, but I did get to work on the rotational springs and got stuff folding.

I will first go over the implementation of the rotational springs.
Variables:
-axisPoint1
-axisPoint2
-momentArmPoint1
-momentArmPoint2
-springConst
-dampingConst
-restAngle
The first two points form the axis of rotation. The other two points define two moment arms from the midpoint of the axis. The spring and damping consts are used for force calculation. The rest angle is the desired angle between the moment arms.
In order to calculate the forces on the points on the moment arms I need to first calculate the torque generated by the spring on each moment arm. I am currently missing the damping part of the function, which causes explosions (see later in the post). Once I calculate the torque I can figure out the forces from that value. But since these are scalar values, I still need to find the force vector. I determined that if I take the cross product between the axis and the moment arm I get the force vector I want. So this lets me update the forces on the moment arm points and integrate the springs into the rest of the system.

So what does this all mean? Folding! I was truly amazed how well the rotational springs worked with the rest of the cloth sim. I setup relatively stiff values for all the linear springs and added the springs. I seem to get a surprising result that looks pretty close to paper. I have two videos showing the rotational springs interacting with the system. Note the videos are at x2 speed, because they are amazing slow otherwise.



In this first video I do a few things. The lattice is setup like a normal cloth sim grid. The red line through the center of the paper is the rotational spring. At the beginning I start the simulation with structure, shear, bend and rotational springs. One thing to note is that there is no spring between the center of the rotational axis that goes along the moment arm. Because of this the paper curls inward, responding to gravity and the bend springs keeping it from being completely stiff. I am pretty happy with this because it looks like if you were to roll up the paper. When the rotational spring is removed, the system unrolls back to normal. I then remove the bend springs and add the rotation spring back to show how it looks without the bend springs. You can really see where they got their name ;) The cool thing is that I have folded and unfolded in this manner several times and it seems like it goes pretty stable.



In the second video I made some changes to the lattice. There are two structural springs that run from the center to the ends of the paper where the moment arms are. They provide a good way to judge the angle you are seeing the paper folding. Another thing to not is that the shear springs that run across the bend spring are removed. I found that this is necessary or they will prevent a total fold.
The simulator goes pretty smooth until it gets to a point where gravity starts to out do the springs and the thing starts to collapse. At least I hope it is gravity. It is sort of hard to tell, but it is cool to see the lattice turn inside out... and then explode.
For next week I will play with constants, look at the explosion a little more closely and prepare for alpha reviews on Friday (Fear!). In front of Pixar (FEAR!).

Thursday, February 10, 2011

RK4 and Reading

Heyho,
This past week was pretty hectic. I spent a lot of time working on internship applications and getting my demo reel in order for said applications. So this week I was able to do the following things:
-Reformatted parts of my spring code so it is easier to debug
-Fixed a fatal flaw in my midpoint implementation that was causing problems
-Implemented RK4
I also been reading through the papers Joe posted as comments in my last post in an effort to understanding implicit and imex integrators. So now I think I am better prepared to implement them for next week. I also hope to start the implementation of rotational springs to get some basic folding going. That way I can have some folding going for alpha review. As a final treat, enjoy the hammock images from my RK4 integration:

Thursday, February 3, 2011

Bringing it Back to Basics

Heyho,

Taking Joe's advice I brought the project back a little. I did start in with some CUDA code, taking the always favorite SimpleGl code sample and adding variables and preparing kernels. Nothing really complicated, mostly setup.

However most of the week's progress went to the CPU. I built up a new framework of particles and springs for a cloth simulation in C++. The framework is simple, but it has a nice little camera that lets me pan around a bit. There are three different types of springs: Structural, Shear and Bend. Those apply forces to the particles and the particles have different integration schemes to move them based on those forces. The particles also respond to gravity and hit a floor at z = 0. It also has callbacks all setup for mouse and keyboard. It mostly came from code from my 277 projects.

Then I implemented 3 different integrators: Verlet, Euler and Midpoint. Currently Verlet and Midpoint are stable, while Euler blows up with the current spring and damping constants. Playing around with those can be fun, because it certainly makes the cloth do interesting things. Currently I've found a balance in the constants that makes the cloth kind of obey the constraints and does not make the cloth explode. Some screenshots below:





So as you can see in the second image, there are some bending along the cloth, which in certainly interesting. Bend springs should be preventing that, but playing with the constants can cause explosions.

The next steps is more integrators, working my way to an implicit euler or implicit RK4. I can already see that Midpoint is starting to change the frame rate a bit, so a smaller lattice might be indicated already. It also might be how I have implemented it, but we'll see. If I have time, I'll also start on the rotational springs in C++ and see if I can integrate them and maybe get some first folding action.