Thursday, March 31, 2011

Forgetting and Moving Forward

Hey Everyone
So this past week I focused on prioritized folding, fixing bugs, and memory (opposed to what I said in my evaluation post where I said I would work on the GPU implementation and memory). I did not do the GPU implementation because I felt that I still had too many bugs for me to move over to the GPU just yet.

So I think that I figured out what was going on with the angles and the acos stuff. I also think it does not really matter, mainly since I am controlling the direction of the fold with the mountain and valley direction variable. I decided that I need to add an addition variable to my rotation spring just for finding the angles, because it is possible that there could be problems with stuff lining up. It may make it hard to autogenerate the rotation springs from a UI though.

One thing I wanted to do was add prioritized folding. There is a few reasons for this. One is that it lets me do more complex folds that were having problems when folding all at once. Another reason is that it allowed me to test out some other problems easier and find bugs. In addition to giving rotation springs priorities, they can also be activated and deactivated. This way they are all not moving at once. Another thing the rotation springs got were links to their structural springs along their moment arms. This allows them to disable them during folding because these structural springs can have problems with multiple folds. So the linear springs can also be activated and deactivated now. All these things really helped me debug stuff. So below is my first multistep fold, a pleat fold. Here I fold the paper in half diagonally and then fold the corner back to the center.



I then tried something a little more complex where I have to fold through multiple sheets of paper. Unfortunately it did not work out as well as I hoped. Strange things are happening. When I setup the creases like they should be on the second fold (mountain and valley), it does not fold at all. When I setup the second fold incorrectly (both valley folds), it folds, but then it explodes. Take a look below (I cut out the explosion):



So I still need to fix a few bugs here and there with that setup. But I am in general happy with out it worked out.

After all that I went back to my memory implementation. It is certainly interesting. Last week I had implemented completely new bend springs that add rotation springs when they are stretched or compressed by a certain threshold. However this caused nothing but explosions. So I brought it back and tried doing simple stuff. In my first attempt I had a 2x2 lattice with a rotation spring in the center and gave it an angle that was not 0 or Pi. This worked very well. So I tried creating a large lattice with a bunch of rotation springs along it horizontally to in theory make it curl. Here was the result:


Definitely the best way to describe this is as a "ghost". It actually kind of looks like a plastic bag in the wind. And I am very surprised it remained stable. So after this try I brought it back and tried a few other methods. I played with their angle, spring constants and the amount of rotation springs, but they all had their problems. Here is a video of a single line of rotation springs down the center of the paper. It is interesting that it pulls the middle of the paper up, sort of like pinching it.


So the adding of rotation spring to simulate memory are just not working as I would like them to. I am going to keep at it but I am not sure it is going to work. One thing I did try instead was to actually as the paper compresses or expands, the bend springs change their rest length depending on how they are handled. This actually produced pretty good results. As you can see the two corners are brought to the center, and when the force is removed (the jolt) it pulls back and rolls up. If I did not change the bend spring's rest length then it actually unfolds back to is flat state.



So as for next week I will continue on the memory and fixing the prioritized folding. If I have time I'll start the GPU implementation. Otherwise that will get pushed to after beta, which is unfortunate because I wanted to have it for beta review. I might also have to set aside time to do what ever prep / presentation I need for beta review.

Thursday, March 24, 2011

Self Evaluation

So Joe asks us to do a small self evaluation, taking a look at what we've done and where we want to be done in the future.

Taking a look at my original proposal, I as way too ambitious. It is a little ridiculous and I think I knew it. There is no way I am getting my simulator up and running perfectly along side a step by step UI in QT. Although as it stands right now, I do have a decent simulator with different integration schemes and things kinda folding on the CPU. I wish it was in the state I said it would be in the original proposal, but as it stands it is something that can be showed off. It is definitely a good base for a larger project in the future.

So the things I have are:
  • Cloth System (CPU)
  • Structure, Shear and Bend Springs
  • Rotational Springs
  • Simple Rendering with keyboard controls
  • Gravity forces
  • XML Schema and XML input
I also learned how crazy a cloth simulator can act sometimes. They are certainly very fragile things. I have mixed feelings about not being on the GPU. In a way it was a giant relief since CUDA is so insane sometimes. But I feel like I should be better at CUDA and I need more experience with it. I will be moving over next week, so we'll see how it goes.

So am I disappointed about the current state of the project? A little. Am I surprised? No.

Before I go on to talk about what I want for the future, I want to say that I don't want to kill myself over this project. I don't want to worry about a UI and other surface things that will hamper the more core part of this project. This project is bigger than myself and I'll probably continue it with origamists and the maybe even the PMML project.
Going forward I wrote down the features I want to get done by the end and I organized them into must haves and would be nice.

Must Haves
  • Bug Fixes
  • Simple GPU Implementation
  • Paper Memory and in Simulation Alterations
  • New Rotation Spring class (multiple force points)
  • Prioritized Creases for Ordered Folding
Would Be Nice
  • Implicit Integration
  • Sparse Matrix GPU Implementation
  • Simple UI
Now that I have the list above, I spread them out across the next weeks in a way I feel is somewhat realistically. I feel that the GPU implementation is the largest thing there, mainly because it involves a whole new program in some respects. The bug fixes are a strange thing because it could take any amount of time. Here is my schedule:

March 25th - March 31st
  • Simple GPU implementation
  • Memory
April 1st - April 7th (Beta Review)
  • Bug Fixes
  • New Rotation Spring class
  • Prioritized rotation spring
April 8th - April 14th
  • Implicit integration
  • Sparse Matrix GPU implementation
April 15th - April 2st
  • Simple UI
April 22nd - April 26th (Final Presentation)
  • Poster
  • Presentation
April 29th and beyond
  • Testing and benchmarking
  • Commenting Code
  • Final Report
So as you can see I front loaded all the tasks that I feel I must have to the next two weeks. I don't expect them all to be done, which is why the later weeks are lighter and have tasks that I feel I could live without. So I hope to have a simple GPU implementation and some kind of memory changing paper by the beta review, but I'll probably only have one or the other. Tomorrow I hope to get a lot of work done, so we'll see how it goes. I've also taken into consideration the timing of my other papers and projects for other classes, so hopefully I won't have time problems.


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.