After completing the basic simulation, I can play around with testing different values for ks (spring constant), density, and damping.

The ks value, spring constant, refers to how stiff/stretchy the spring is. A small spring constant refers to a very springy spring; when I adjusted my ks to be 50, the cloth acted very flexible and had many smaller wrinkles. It also bounced a bit harder at the end of the sim, as the springs stretched easily. On the other hand, when I used a high spring constant, the cloth seemed much stiffer and less bendable. Instead of ever having many small wrinkes where the cloth gathers due to the pins, there was only one large fold as if the cloth were made of something like burlap. My experiments are shown below:

Next, I tested different densities. When I tested density = 1, the cloth seemed very light. A higher density in the same volume means the cloth is heavier, so when I tested density = 1000, the cloth behaved much differently. The final resting state of the cloth showed a lot of downward pull in the cloth, as if the cloth were very heavy. There were many folds, compared to the very small folds that occured in density = 1.

Part III: Handling Collisions with Other Objects

In this part, I implemented the ability for the cloth to interact with spheres and planes. Before beginning, I updated my cloth's simulation function to check for potential collisions with every object at each point mass so my changes in the sphere/plane files will run.

For spheres, I want to make sure that none of the cloth's point masses are inside the sphere. So, if a point mass is inside the sphere, I want to push it outside of the sphere. First, I check if the point mass is inside the sphere by checking the distance the point mass is away from the center. If the distance is smaller than the sphere's radius, I know that it is inside the sphere so I continue updating its position. Next, I find the point on the sphere's surface on the ray originating at the sphere's center, in the direction of point. This was simply found using (radius * dir + origin), where dir is a vector I made of the direction from the sphere center and the point mass's position, and radius and origin refer to the sphere's radius and center. Next, I added a correction vector the point mass so that it will reach this point. Finally, I update the point mass's position to be its last position + my correction. I scaled my correction by a term that accounts for friction, (1 - friction) before updating the position.

For plane intersections, we use a slightly different metric to figure out whether the point mass has intersected or not. In this case, we know that the mass has had an intersection with the plane if it has crossed over the plane within the last step. So, if pm.last_position is on a different side of the plane than pm.position, we know that we need to apply a correction to pm's position so that it is bumped back over to the right side of the plane. If this check (which is easily found by checking whether the dot products of the plane's normal and the vector between pm.position/pm.last_position and a point on the plane is negative) is true, we then find the point where the point mass should intersect the plane. This is simply the projection of the point mass over the plane. Next, I compute a correction vector that I can add to the point mass's position to bump it to a valid location, (i.e. on the other side of the plane). Here, I also use a small offset for the point mass to reach a point slightly above the plane.

Below is a recording of a buggy interaction with the sphere. I fixed this by making sure I normalized only the vectors that needed to be normalized.

Part IV: Handling Self-Collisions

In this part, I implemented the ability for the cloth to collide with itself.

In order to speed up the process of finding testing for a self-intersection, I implemented a hash map that places masses into buckets based of the masses' positions. I first wrote a function to find the key a point mass should be added to, using (x*prime) + (y * pow(prime, 2)) + (z * pow(prime,3)) where prime is a prime number chosen at random (I used 3) and x, y, and z are the truncated coordinates from the point mass's position, scaled to the closest 3D box. Next, I add point masses to my hash map using this function. Then, I implemented the self_collide function that looks for any collisions against a given point mass. To implement this, I first created a pairwise_accum vector that will accumulate the adjustments (correction vectors) to the given point mass based. Making sure to not check the point mass against itself, I check whether the point mass is 2 * thickness distance away from the candidate point mass. If so, I compute a correction vector to push the current point so that it will be at least 2 * thickness distance away from the candidate. I accumulate this correction into my pairwise_accum. If I have accumulated at least one of these points, then I average the pairwise_accum vector - dividing each component by the number of candidate points. I also divide the pairwise_accum components by the simulation_steps variable, to help scale the position correction and improve the accuracy of this self-collision check. Finally, I updated my cloth's simulate method to check for self-collisions, similarly to how I updated it earlier to check for object collisions.

Part V: Shaders

In this section, I implemented shaders using GLSL. Shaders are useful because they run computations in parallel on the GPU as other computations (such as raytracing) occur in the CPU. They take in an input, including things like texture files or color parameters, and output a single 4D vector that carries information about vertex, such as the color or displacement at the location specified. In OpenGL, there are vertex shaders and fragment shaders. Vertex shaders apply transformations to the vertices, such as displacement. On the other hand, fragment shaders find the attributes on fragments, which are created after rasterization.

I first implemented a diffuse shader. I use this diffuse shader's calculations as part of the Blinn-Phong shader in the next part, so images are below.

In the Blinn-Phong shading model, we can account for some ambient lighting, diffuse lighting, and specular highlights. Each of these components is represented by its own term in the shading/lighting calculation.

In the above images, the normal was held constant at 20 while the height was as high as possible for me to actually run the software. We can see that at the low coarseness, there is basically no difference between the bump and the displacement; with how difficult it was to run the displacement, we might as well use just the bump. At high coarseness, the normal map is clearly more accurate to what we might want in application. The displaced vertices are also correctly placed, with sharper edges where there exist sharper edges. However, it was even more difficult getting the displacement to show up without the program freezing, as the displacement actually changes vertex positions and is prone to funky outputs.

Finally, I created a mirror shader that samples an incoming radiance, using an environment map. To implement this, I simply reflect the eye vector over the normal at the surface, to get the incoming direction.