Project 6: Xueyin Wan

README.md

@@ -3,13 +3,27 @@ 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)
+* Xueyin Wan
+* Platform: Windows 10, i7-4870 @ 2.50GHz 16GB, NVIDIA GeForce GT 750M 2GB (Personal Laptop)
 
-  ### (TODO: Your README)
+## Showcase My Result
+![alt text](https://github.com/xueyinw/Project6-Vulkan-Flocking/blob/master/showcase.gif "Final Result")
 
-  Include screenshots, analysis, etc. (Remember, this is public, so don't put
-  anything here that you don't want to share with the world.)
+## Analysis
+#### Why do you think Vulkan expects explicit descriptors for things like generating pipelines and commands?
+In Vulkan, whenever we want to draw a 3D scene from vertices and vertex attributes, we will use command buffers. Command buffers cannot be allocated directly. Instead, they are provided by a pre-allocated GPU command pool. 
+So the descriptor here is to help us update the mapping relationship to each buffers during the whole procedure. Once we have a descriptor set, we can update it directly to put specific values in the bindings, and also copy between different descriptor sets.
+With the help of descriptor, we could use command buffer with more flexibility.
+
+#### Describe a situation besides flip-flop buffers in which you may need multiple descriptor sets to fit one descriptor layout.
+When we have color map, normal map, depth map, etc. and we want to map these to the same scene, we could put them as different descriptor sets in a single descriptor layout, and during the process we use different sets to fit different stages' needs.
+
+#### What are some problems to keep in mind when using multiple Vulkan queues?
+The notion of queues are how work becomes serialised to be passed to the GPU. When using multiple vulkan queues, we need to include sync primitives for queue to wait before processing the submitted work, and signal when the work in this submission is completed.
+Also we need to keep in mind that queue can accept different types of work.
+
+#### What is one advantage of using compute commands that can share data with a rendering pipeline?
+Save a lot of time and space by reducing I/O operations since compute commands could share data.
 
 ### Credits
 

data/shaders/computeparticles/particle.comp

@@ -50,14 +50,56 @@ void main()
 
     // Current SSBO index
     uint index = gl_GlobalInvocationID.x;
-	// Don't try to write beyond particle count
+	  // Don't try to write beyond particle count
     if (index >= ubo.particleCount)
 		return;
 
+    vec2 centerOfMass = vec2(0.0, 0.0); // Rule 1
+		vec2 seperation = vec2(0.0, 0.0);   // Rule 2
+		vec2 alignment = vec2(0.0, 0.0);    // Rule 3
+		float neighborOfCountRule1 = 0.0;
+		float neighborOfCountRule3 = 0.0;
+		float distanceBetweenTwoBoids = 0.0;
+
     // Read position and velocity
 		vec2 vPos = particlesA[index].pos.xy;
     vec2 vVel = particlesA[index].vel.xy;
 
+    for (int i = 0; i < ubo.particleCount; ++i) {
+	      if (i == index) {
+ 	      		continue;
+ 	      }
+        distanceBetweenTwoBoids = distance(particlesA[i].pos, vPos);
+				if (distanceBetweenTwoBoids < ubo.rule1Distance) {
+     			  centerOfMass += particlesA[i].pos.xy;
+ 		    	  neighborOfCountRule1 += 1.0;
+ 		    }
+
+				if (distanceBetweenTwoBoids < ubo.rule2Distance) {
+ 	  			  seperation -= particlesA[i].pos.xy - vPos;
+  			}
+
+        if (distanceBetweenTwoBoids < ubo.rule3Distance) {
+				    alignment += particlesA[i].vel.xy;
+						neighborOfCountRule3 += 1.0;
+				}
+		}
+
+		if (neighborOfCountRule1 > 0.0) {
+				centerOfMass /= neighborOfCountRule1;
+				vVel += (centerOfMass - vPos) * ubo.rule1Scale;
+		}
+
+// Refer to project 1 feedback, maybe we do not need to subtract this time?
+
+		if(neighborOfCountRule3 > 0.0) {
+				alignment /= neighborOfCountRule3;
+				vVel += alignment * ubo.rule3Scale;
+		}
+
+		vVel += seperation * ubo.rule2Scale;
+
+
 		// clamp velocity for a more pleasing simulation.
 		vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1);
 

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)) * .1f;
 		}
 
 		VkDeviceSize storageBufferSize = particleBuffer.size() * sizeof(Particle);
@@ -244,8 +245,8 @@ 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, pos)); // TODO: change this so that we can color the particles based on velocity.
+	    	offsetof(Particle, vel));
 		// vertices.inputState encapsulates everything we need for these particular buffers to
 		// interface with the graphics pipeline.
 		vertices.inputState = vkTools::initializers::pipelineVertexInputStateCreateInfo();
@@ -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?
+
+			vkTools::initializers::writeDescriptorSet(
+			compute.descriptorSets[1],  
+			VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
+			0,  
+			&compute.storageBufferB.descriptor),  
+
+
+			vkTools::initializers::writeDescriptorSet(
+			compute.descriptorSets[1],
+			VK_DESCRIPTOR_TYPE_STORAGE_BUFFER,
+			1,
+			&compute.storageBufferA.descriptor),
+
+
+			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.storageBufferA, compute.storageBufferB);
+		std::swap(compute.descriptorSets[0], compute.descriptorSets[1]);
 	}
 
 	// Record command buffers for drawing using the graphics pipeline