diff --git a/Images/output.gif b/Images/output.gif
new file mode 100644
index 0000000..d9299b8
Binary files /dev/null and b/Images/output.gif differ
diff --git a/README.md b/README.md
index bec6ca4..0836df8 100644
--- a/README.md
+++ b/README.md
@@ -3,13 +3,28 @@ Vulkan Flocking: compute and shading in one pipeline!
 
 **University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 6**
 
-* (TODO) YOUR NAME HERE
-  Windows 22, i7-2222 @ 2.22GHz 22GB, GTX 222 222MB (Moore 2222 Lab)
+* Nischal K N
+* Windows 8.1, i7-5500U @ 2.40 GHz 16GB, GTX 920M 3839MB (Personal)
 
-  ### (TODO: Your README)
+### OUTPUT
+![](Images/output.gif)
 
-  Include screenshots, analysis, etc. (Remember, this is public, so don't put
-  anything here that you don't want to share with the world.)
+### Q&A
+* **Why do you think Vulkan expects explicit descriptors for things like generating pipelines and commands?**
+
+  Vulkan API pre allocates GPU command pool memory and command buffers cannot be allocated/changed at runtime. Hence explicit descriptors for pipelines and commands are required to specify which data to act on at different stages of the system. This also provides us more flexibility in customizing various stages of the design with minimum overhead of data transfer between CPU and GPU.
+
+* **Describe a situation besides flip-flop buffers in which you may need multiple descriptor sets to fit one descriptor layout.**
+
+  Different channels of an RGBA Image. Each channel represents different color value for the same scene. Hence they fit in one descriptor layout.
+* **What are some problems to keep in mind when using multiple Vulkan queues?**
+  * **take into consideration that different queues may be backed by different hardware**
+  * **take into consideration that the same buffer may be used across multiple queues**
+
+  Vulkan Queues are designed to have high parallelism if the workload is highly independent. But however when ever there is a lot of exchange of data between multiple queues, it must be taken care that there are no guarantees on the order of execution of the queues. Hence appropriate semaphores/fences must be used.
+* **What is one advantage of using compute commands that can share data with a rendering pipeline?**
+
+  Reduces the expensive copy operations of input and output data from compute to render pipeline.
 
 ### Credits
 
diff --git a/base/vulkanexamplebase.h b/base/vulkanexamplebase.h
index a30387e..fc59fa8 100644
--- a/base/vulkanexamplebase.h
+++ b/base/vulkanexamplebase.h
@@ -50,7 +50,7 @@ class VulkanExampleBase
 	bool enableVSync = false;
 	// Device features enabled by the example
 	// If not set, no additional features are enabled (may result in validation layer errors)
-	VkPhysicalDeviceFeatures enabledFeatures = {};
+	VkPhysicalDeviceFeatures enabledFeatures;
 	// fps timer (one second interval)
 	float fpsTimer = 0.0f;
 	// Create application wide Vulkan instance
diff --git a/data/shaders/computeparticles/particle.comp b/data/shaders/computeparticles/particle.comp
index b7dc2f7..6faed7d 100644
--- a/data/shaders/computeparticles/particle.comp
+++ b/data/shaders/computeparticles/particle.comp
@@ -55,14 +55,52 @@ void main()
 		return;
 
     // Read position and velocity
-		vec2 vPos = particlesA[index].pos.xy;
+	vec2 vPos = particlesA[index].pos.xy;
     vec2 vVel = particlesA[index].vel.xy;
 
-		// clamp velocity for a more pleasing simulation.
-		vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1);
+	vec2 newVel = vVel;
+	vec2 center = vec2(0.0f, 0.0f);
+	vec2 separate = vec2(0.0f, 0.0f);
+	vec2 cohesion = vec2(0.0f, 0.0f);
+	int neighborCount1 = 0;
+	int neighborCount3 = 0;
 
-		// kinematic update
-		vPos += vVel * ubo.deltaT;
+	for (int j = 0; j < ubo.particleCount; j++) {
+		if (index == j) continue;
+		float distance = distance(vPos, particlesA[j].pos.xy);
+		if (distance < ubo.rule1Distance) {
+			// Rule 1: boids fly towards their local perceived center of mass, which excludes themselves
+			center += particlesA[i].pos.xy;
+			neighborCount1 += 1;
+		}
+
+		// Rule 2: boids try to stay a distance d away from each other
+		if (distance < ubo.rule2Distance) {
+			separate -= (particlesA[j].pos.xy - vPos);
+		}
+
+		if (distance < ubo.rule3Distance) {
+			// Rule 3: boids try to match the speed of surrounding boids
+			cohesion += particlesA[j].vel.xy;
+			neighborCount3 += 1;
+		}
+	}
+	if (neighborCount1) {
+		center /= float(neighborCount1);
+		newVel += (center - vPos) * rule1Scale;
+	}
+	if (neighborCount3) {
+		cohesion /= float(neighborCount3);
+		newVel += (cohesion - vVel) * rule3Scale;
+	}
+	newVel += separate * rule2Scale;
+	vVel = newVel;
+
+	// clamp velocity for a more pleasing simulation.
+	vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1);
+
+	// kinematic update
+	vPos += vVel * ubo.deltaT;
 
     // Wrap around boundary
 		if (vPos.x < -1.0) vPos.x = 1.0;
diff --git a/data/shaders/computeparticles/particle.comp.spv b/data/shaders/computeparticles/particle.comp.spv
index 059ab59..c32242d 100644
Binary files a/data/shaders/computeparticles/particle.comp.spv and b/data/shaders/computeparticles/particle.comp.spv differ
diff --git a/vulkanBoids/vulkanBoids.cpp b/vulkanBoids/vulkanBoids.cpp
index 9b2f122..6133f6d 100644
--- a/vulkanBoids/vulkanBoids.cpp
+++ b/vulkanBoids/vulkanBoids.cpp
@@ -158,6 +158,7 @@ class VulkanExample : public VulkanExampleBase
 		{
 			particle.pos = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator));
 			// TODO: add randomized velocities with a slight scale here, something like 0.1f.
+			particle.vel = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator)) * 0.1f;
 		}
 
 		VkDeviceSize storageBufferSize = particleBuffer.size() * sizeof(Particle);
@@ -244,7 +245,7 @@ class VulkanExample : public VulkanExampleBase
 			VERTEX_BUFFER_BIND_ID,
 			1,
 			VK_FORMAT_R32G32_SFLOAT,
-			offsetof(Particle, pos)); // TODO: change this so that we can color the particles based on velocity.
+			offsetof(Particle, vel)); // TODO: change this so that we can color the particles based on velocity.
 
 		// vertices.inputState encapsulates everything we need for these particular buffers to
 		// interface with the graphics pipeline.
@@ -540,13 +541,34 @@ class VulkanExample : public VulkanExampleBase
 			compute.descriptorSets[0],
 			VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER,
 			2,
-			&compute.uniformBuffer.descriptor)
+			&compute.uniformBuffer.descriptor),
 
 			// TODO: write the second descriptorSet, using the top for reference.
 			// We want the descriptorSets to be used for flip-flopping:
 			// on one frame, we use one descriptorSet with the compute pass,
 			// on the next frame, we use the other.
 			// What has to be different about how the second descriptorSet is written here?
+
+			// Binding 0 : Particle position storage buffer
+			vkTools::initializers::writeDescriptorSet(
+			compute.descriptorSets[1], // LOOK: which descriptor set to write to?
+			VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
+			0, // LOOK: which binding in the descriptor set Layout?
+			&compute.storageBufferB.descriptor), // LOOK: which SSBO?
+
+			// Binding 1 : Particle position storage buffer
+			vkTools::initializers::writeDescriptorSet(
+			compute.descriptorSets[1],
+			VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
+			1,
+			&compute.storageBufferA.descriptor),
+
+			// Binding 2 : Uniform buffer
+			vkTools::initializers::writeDescriptorSet(
+			compute.descriptorSets[1],
+			VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER,
+			2,
+			&compute.uniformBuffer.descriptor)
 		};
 
 		vkUpdateDescriptorSets(device, static_cast<uint32_t>(computeWriteDescriptorSets.size()), computeWriteDescriptorSets.data(), 0, NULL);
@@ -590,6 +612,8 @@ class VulkanExample : public VulkanExampleBase
 		// We also want to flip what SSBO we draw with in the next
 		// pass through the graphics pipeline.
 		// Feel free to use std::swap here. You should need it twice.
+		std::swap(compute.descriptorSets[0], compute.descriptorSets[1]);
+		std::swap(compute.storageBufferA, compute.storageBufferB);
 	}
 
 	// Record command buffers for drawing using the graphics pipeline