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.