Posters and Presentation

So today was the CG@Penn poster session and senior project presentation day. They both went amazingly great. I would upload my presentation video, except it is a gig and it would take about 6 hours to upload to youtube. So this up coming week I am going to work on the final report for the project so I can move on and get ready for SCA submission. So short post for today, but it has been a long day.

Oooooh Pretty....

Hey everyone,

So I've been up to two things this week. The first is the poster for the CS and CG@Penn Poster sessions. If you would like to see the poster, come by the SIG Lab from 2:30 to 3:00 on April 28th.

The second thing I did this week was get Maya rendering to work. Thanks to Igor, I was able to quickly teach myself a little mel and keyframe all the points I needed. I wrote out all the vertices in a diagonal fold and unfold and brought them into Maya. I then created a quick paper shader and put the paper over a ground plane. The video is below:

So Joe complained that there was not memory feed back or a crease mark left in the paper. So I am currently rendering out a new version with both those things. I also tried to get a dual color going, but I could not get it to work how I wanted. So unless people know how to assign two different colors to a polygon, I think it will remain one color for now. I tried rendering out my dog, but it is having problems. I will try to deal with them before my presentation.

So while getting maya rendering work I believe I figured out how to use rotational springs to procedurally add memory to the lattice. I create a rotation spring along the exact same axis of the crease that generated the change in memory. Since my rotation springs allow for more than 2 particles to affect, I push an entire face of particles onto this new memory rotation spring. I set the rest angle to something between 0 and Pi. Since the torque generated on each point is dependent on the distance to the rotation axis, larger torques are given to points closer to the axis. So a smooth curve out is created. You can reverse the direction or the degree of the curvature by changing the angle. It looks like this:

This image also has my crease texture along the diagonal that I'll be using for the animation later.

So this weekend I will be preparing my presentation and making sure that is all in order. After that I will take a look at memory and physical properties again for my final report. Almost there!

Material Matters

Hey Everyone,

So this past week I've worked on two things: memory and material properties.

Memory has been a massive pain in the butt, which is surprising because I thought it would be easy to work with. In my previous post about memory my only somewhat successful memory attempt was done through relaxing the rest length of bend springs. I was relatively happy with that to capture a piece of paper that is incredibly curled up. But it was hard to get it to get slightly bent. So I spent a lot of time trying to get the rotational springs to be added procedurally but regardless of what I did it seemed like it would not work. So I decided to just hard program it and I realized that it required very slight adjustments of the rest angles of the rotational springs to get that slight curl. Take a look at the video below:

So in conclusion of the memory, you can get strong results for memory by playing with the rest lengths of bend springs and this can be done procedurally. However if you want to get slight curl due to moisture or it is light paper, you are better off putting rotational springs in there manually and tweaking them.

So when I say "material properties" I of course mean something that is more visual than something that is grounded in physics. I found this webpage : http://www.paperonweb.com/paperpro.htm and it has a great amount of physical properties of paper.

• The major thing that you have to deal with here is the weight of the paper. So I spent some time playing around with the mass of my particles. What this did visually was it mainly affected how great the forces were acting upon the particles. Mostly this just slowed down or sped up the folding process. However because it changed the speed of the fold, it did make the paper slump or stiffen a little more than usual. So changing the mass definitely had an effect.
• The second property that I deal with is curl. I talk about the curl in my memory portion above. This website lists three different types of curl with regards to paper. When I add rotational springs this is sort of like structural curl, where a difference in the fibers causes the paper to pop up. When I change the bend spring's rest length that is sort of like moisture curl, where fibers in the paper either collapse or expand due to exterior forces or moisture.
• The third major property I deal with is the dimensional stability. Dimensional stability is basically how the fiber in the paper keeps the paper together and affects how it folds. This is akin to my spring constants. I spent a lot of time playing with settings of spring constants to get different affects. Reducing the constants of the shear and bend springs will make the paper much more cloth. Reducing just the shear springs will make the paper more like tissue paper. Reducing just the bend springs will make the act like it is more moist. Reducing the constants of the structural springs is just bad because then the paper no longer holds its form.
• The last property I got from that website was formation. Formation is the alignment and distribution of the fibers in paper. I wrote code that offsets the points in the lattice by a random but clamped epsilon. However this did not seem to change much in my simulation. I think it would be more important if I worked in a very large lattice.

I've attached videos of some the presets I've created for my simulation and showing what I described above.

Next week I am going to just concentrate on rendering. I have a problem where the paper can be folded at odd angles, causing breaking. I need to look at Joe's Maya export code before I can come up with a firm idea of how to solve this problem. After I do the rendering I am going create my poster and get ready for my final presentation. Yay!

A Dog's Life

An update? Not on a Thursday night? Is this bizarro world? No. In the last post I did not get to put up any movies. So this morning I laid out everything I needed to fold the traditional dog model and wrote up the XML file. I made her a slightly larger lattice than I have been working with. She is 25x25 opposed to the 13x13 I've been working with. So here she is, my first complete model in my simulation:

I know the top edges on the head are a little weird, but that is because the folds are occurring at weird angles. So I am going to have to deal with that when I get to the Maya export and rendering. I think I can fix it when I get to Maya, otherwise I may just live with it.

Beta-Max

Hey Everyone,

So this week I tried doing two new implementations of my rotational springs. The first one I did earlier this week was an implementation recommended by Steven Gray. Rather than just applying forces to the corner of the lattice these rotational springs apply forces to multiple points. I originally tried applying forces to the points that neighboring the rotation axis. However because the lattice is not incredibly stiff, it only moved those neighbor points across the axis and did not move the entire paper. So I changed the implementation so that all the points above the a rotation spring are affected. So basically an entire rigid body is folded here. This proved to have better results since the forces added on each point are proportional to the distance from the rotation axis. However I feel that it becomes much harder to control where points are moving with this method.

This lead me to the another new implementation. In this implementation I once again allow for multiple points for the torque to act upon. However it is only used when acting upon an edge rather than a corner. This way I can use only one rotation spring in a horizontal/vertical fold rather than two as I was doing in the past. I also setup an XML input method that makes sure that each torque point has a structural spring to help support it. I also make sure that the structural springs turn off when that rotation spring is not active because they can interfere with other rotation folds. Because I changed the XML format for this new rotation spring I spent an hour going through and updating my previous XML files, making sure each one still worked. Some of them did not, which helped me find bugs.

This was all leading up to trying to fold the traditional dog model. This paper: http://www.csc.calpoly.edu/~zwood/research/pubs/origamiCATA06.pdf shows intermediate steps folding the traditional dog. I was able to put together most of the folds for the dog, but it is not quite finished yet. I still want to make tweaks to it and try it on a slightly larger lattice. However I am now 95% sure that I can fold that model with my simulator, which is great. The traditional dog does have a squash fold in it, which does make it technically not pureland. So maybe in the future I can get other stuff working.

So this past week was also beta review. I think it went well. The major thing it did was change how I am going to approach the last few weeks. The first thing is no more GPU implementation. I am going to concentrate on getting memory and material properties worked out so I can put them in the report and on my poster. After I finish those I will use Joe's code for taking the jello cubes into maya and do a bunch of nice renders and animations for my final video. If I have time after that, which I won't, I'll try to get a simple UI built so I can draw out folds rather than writing the XML. So my schedule as it stands is:

April 8th- 14th

• Memory
• Material Properties

April 15-21st

• Rendering
• Poster

April 22nd-April 26nd

• Presentation
• Simple UI (Probably not)

April 29th and Beyond

• Final Report
• Commenting Code

I know this post did not have any videos in it, mainly because today was kind of an annoying day. Next post will have videos, including the folding of the traditional dog. So look forward to it.

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.

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.

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.

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.

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:

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!).

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:

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.

Paper Lattice

As I said in the last post I worked on reviewing VBOs in CUDA and working out the lattice data structure.

Firstly, getting back to CUDA is certainly interesting. All the little tricks that Jon and Joe had shown me in GPU Programming came flooding back as I looked through the CUDA code. I feel like I have a better handle on the code now that I did a week ago, which is a little reassuring and scary. CUDA is certainly a scary language, but it is probably the best for this project.

In my proposal I describe two separate programs: the simulator and the interface. Both pieces have a mesh data structure of vertices, edges, and faces. However, the data structures are very different in my mind. Therefore I will call the simulator's data structure a "lattice" and the interface's data structure a "mesh." I spent some time looking at paper and what people considered it's properties and attributes. There are measurements for the stiffness and stretchability of paper, which will factor into the values and constants I have for my simulator later on. These ideas influenced how I thought about creating the lattice data structure

The lattice data structure is a traditional cloth simulator data structure. It is made up of a mass-spring system with vertices and springs as edges. Each vertex will be represented by a position vector, velocity vector, and accumulated force vector. Each linear spring will be represented by a since vector of information about what two vertices the spring connects and the spring and damping constants of the spring. Since CUDA is a language focused on float4s, I have divided the information above into float4s. The b in the velocity vector is a boolean which tells the vertex whether or not it is a boundary vertex, which is important information for conversion between the mesh and the lattice. The m in the force vector is the mass of the point.


Vertex Position = [ x y z -] (Put into VBO for fast rendering)
Vertex Velocity = [x y z b]
Vertex Accumulated Force = [x y z m]
Linear Spring = [vertex_id1 vertex_id2 k d]

The major difference is the introduction of rotational springs to allow for folding. The first thing I decided was that I did not want the rotational springs to intersect or cross any of the linear springs in the lattice. I also wanted to ensure that the program will never split a linear spring by adding a mass point to allow a rotational spring to cross. The rotational springs are also pretty different from linear springs. Since it is torque there exists a moment arm which creates a force perpendicular to moment arm. Based on how origamists fold paper, I decided that the moment arm should extent to the farthest point of the face that the rotational spring boarders. So I can calculate the amount of torque created by the rotational spring and then convert it to a force and apply it to a vertex. However looking at the Huzita-Hatori axioms I noticed that I would need to apply the torque to multiple vertices, not just one if I was folding an edge to an edge. So I find the furtherest edge or vertex from the rotational spring and store that information for simulation. I made need to store even more vertices than two, but I will try it with two for now. So the data structure for the rotational spring is as such:

Rotational Spring Information = [vertex_id1 vertex_id2 k d]
Rotational Spring Moment Arm = [vertex_id1 vertex_id2 d -]

The d in the moment arm vector is the distance each vertex is to the actual spring for quick calculations. This should be relatively constant.

I have also developed a few ideas about the mesh data structure that is very similar to my rigid body origami simulator. It will be focused on faces rather than springs and edges. The paper is divided up into faces that are separated by the creases in the paper. It is more important her to keep track of what creases are intersecting others and how that will change how the faces are broken up. Once the creases are finalized, the mesh structure sends the face data down to be triangulated and turned into the lattice.

My next steps will be to implement the mass-spring system stated above with a simple integrator. Most likely I'll then improve the integrator and play with constant variables till I get something I like.

Introductions

Hey everyone, here is my first post on my senior project blog. I am sure the next few months are going to be fun. Here is my abstract:

Origami is the ancient Japanese art of folding paper that has many mathematical and geometric properties. Over time designers have developed instruction sets, commonly known as diagrams, in order to record the step-by-step procedures to replicate an origami model. However the applications that exist to make diagrams are not really effective. Most people use illustrating applications such as Adobe Illustrator, Corel Draw, Macromedia Freehand, and even Microsoft Word. Clearly none of the programmers of these applications had any intention to use them for origami design.
The purpose of this project is to develop an application that would be used to create diagrams in a natural and easy manner. The program will be divided into two segments: a simulator and a designer GUI. The simulator will be a cloth simulator written in CUDA and C++ that will accurately simulate the origami paper. To get a realistic method of folding a dynamic lattice coupled with rotational springs will be used. This physically based approach to folding will yield more advanced folds. The user will interact with the simulator through an interface that is specifically designed for origami artists to use. The artist will be able to input their folding steps into the simulator and then instantly create publishable diagrams without having to make major changes. It is my intention to make the interface as fluid and intuitive for a person with knowledge about origami diagrams as possible. The ultimate goal is to create an application that will provide a unified method for origami designers to create content.

The next steps are get my PC setup with all my CUDA stuff, start working out the lattice data structure and get out my old VBO code.