Project6: Akshay Shah

README.md

@@ -1,16 +1,47 @@
 Vulkan Flocking: compute and shading in one pipeline!
 ======================
+[CLICK ME FOR INSTRUCTION OF THIS PROJECT](./INSTRUCTION.md)
 
 **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)
+* Akshay Shah
+* Tested on: Windows 10, i7-5700HQ @ 2.70GHz 16GB, GTX 970M 6GB (Personal Computer)
 
-  ### (TODO: Your README)
+### Vulkan Boids flocking simulation
 
-  Include screenshots, analysis, etc. (Remember, this is public, so don't put
-  anything here that you don't want to share with the world.)
+Screenshots
+-----------
+
+  ![](img/boids.gif)
+
+Analysis
+--------
+
+* <b>Why do you think Vulkan expects explicit descriptors for things like generating pipelines and commands?</b>
+
+  Since Vulkan gets the memory to store command buffers from a preallocated command pool on the GPU, explicit descriptors for pipelines and commands can be used because it cannot be updated once created. Having preallocation, would mean the input and the output of the pipelines would have been already allocated during runtime and has no other overhead. (i.e., One command buffer can be used for multiple data.)
+
+* <b>Describe a situation besides flip-flop buffers in which you may need multiple descriptor sets to fit one descriptor layout.</b>
+
+  When you want to render different textures on the same mesh or have different vertices set for a mesh. For example, you could render a cube or a sphere with the same descriptionLayout just with different sets.
+
+* <b>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</b>
+
+  Queues are good when there is a lot of operation that is independent of each other. This would mean that these queues could be highly parallelized. Since they are parallelized, any synchronous operation might fail as there is no known order of execution. If the operations involve a lot of transfers between buffers, then a single queue would have better performance.
+
+* <b>What is one advantage of using compute commands that can share data with a rendering pipeline?</b>
+
+  Avoids copying data from input and output.
+
+Bloopers
+--------
+
+![](img/boids_bug.gif)
 
 ### Credits
 
 * [Vulkan examples and demos](https://github.com/SaschaWillems/Vulkan) by [@SaschaWillems](https://github.com/SaschaWillems)
+* [Conrad Parker's notes](http://www.vergenet.net/~conrad/boids/pseudocode.html)
+* [2D implementation in Processing](http://studio.sketchpad.cc/sp/pad/view/ro.9cbgCRcgbPOI6/rev.23?)

data/shaders/computeparticles/particle.comp

@@ -43,32 +43,68 @@ layout (binding = 2) uniform UBO
 
 void main()
 {
-		// LOOK: This is very similar to a CUDA kernel.
-		// Right now, the compute shader only advects the particles with their
-		// velocity and handles wrap-around.
-		// TODO: implement flocking behavior.
+	// LOOK: This is very similar to a CUDA kernel.
+	// Right now, the compute shader only advects the particles with their
+	// velocity and handles wrap-around.
+	// TODO: implement flocking behavior.
 
     // Current SSBO index
     uint index = gl_GlobalInvocationID.x;
 	// Don't try to write beyond particle count
     if (index >= ubo.particleCount)
 		return;
 
+	vec2 v1 = vec2(0.0, 0.0);
+	vec2 v2 = vec2(0.0, 0.0);
+	vec2 v3 = vec2(0.0, 0.0);
+	int ctr1 = 0.0, ctr3 = 0.0;
     // 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);
+	for (int i = 0; i < ubo.particleCount; ++i) {
+		float dist = distance(vPos, particlesA[i].pos.xy);
+		if (i != index) {
+			// Rule 1: boids fly towards their local perceived center of mass, which excludes themselves
+			if (dist < ubo.rule1Distance) {
+				v1 += particlesA[i].pos.xy;
+				ctr1 += 1.0;
+			}
+			// Rule 2: boids try to stay a distance d away from each other
+			if (dist < ubo.rule2Distance) {
+				v2 -= (particlesA[i].pos.xy - vPos);
+			}
+			// Rule 3: boids try to match the speed of surrounding boids
+			if (dist < ubo.rule3Distance) {
+				v3 += particlesA[i].vel.xy;
+				ctr3 += 1.f;
+			}
+		}
+	}
+	if(ctr1 > 0){
+		v1 = v1 / ctr1;
+		v1 = (v1 - vPos) * ubo.rule1Scale;
+	}
+
+		v2 = v2 * ubo.rule2Scale;
+
+	if(ctr3 > 0)
+		v3 = v3 / ctr3;
+	v3 = (v3) * ubo.rule3Scale;
 
-		// kinematic update
-		vPos += vVel * ubo.deltaT;
+	vVel += v1 + v2 + v3;
+
+	// 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;
-		if (vPos.x > 1.0) vPos.x = -1.0;
-		if (vPos.y < -1.0) vPos.y = 1.0;
-		if (vPos.y > 1.0) vPos.y = -1.0;
+	if (vPos.x < -1.0) vPos.x = 1.0;
+	if (vPos.x > 1.0) vPos.x = -1.0;
+	if (vPos.y < -1.0) vPos.y = 1.0;
+	if (vPos.y > 1.0) vPos.y = -1.0;
 
     particlesB[index].pos.xy = vPos;
 

data/shaders/computeparticles/particle.frag

@@ -11,4 +11,5 @@ layout (location = 0) out vec4 outFragColor;
 void main ()
 {
 	outFragColor.rgb = vec3(inColor.x, abs(inColor.y), -inColor.x) * 10.0;
+	//outFragColor.rgb = vec3(1.0, 0.0, 0.0);
 }

vulkanBoids/vulkanBoids.cpp

@@ -157,7 +157,8 @@ class VulkanExample : public VulkanExampleBase
 		for (auto& particle : particleBuffer)
 		{
 			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;
+			// randomized velocities with a slight scale here, something like 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)); // 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,33 @@ 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);
@@ -583,13 +604,15 @@ class VulkanExample : public VulkanExampleBase
 		// are done executing.
 		VK_CHECK_RESULT(vkQueueSubmit(compute.queue, 1, &computeSubmitInfo, compute.fence));
 
-		// TODO: handle flip-flop logic. We want the next iteration to
+		// handle flip-flop logic. We want the next iteration to
 		// run the compute pipeline with flipped SSBOs, so we have to
 		// swap the descriptorSets, which each allow access to the SSBOs
 		// in one configuration.
 		// 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.storageBufferA, compute.storageBufferB);
+		std::swap(compute.descriptorSets[0], compute.descriptorSets[1]);
 	}
 
 	// Record command buffers for drawing using the graphics pipeline