Project 6: Richard Lee

README.md

@@ -3,13 +3,29 @@ 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)
+* Richard Lee
+* Tested on: Windows 7, i7-3720QM @ 2.60GHz 8GB, GT 650M 4GB (Personal Computer)
 
-  ### (TODO: Your README)
+<img src="img/flocking.gif" width="800">
 
-  Include screenshots, analysis, etc. (Remember, this is public, so don't put
-  anything here that you don't want to share with the world.)
+* Why do you think Vulkan expects explicit descriptors for things like
+generating pipelines and commands?
+
+This is likely due to the fact that Vulkan does not manage the pipeline for the developer, and interfaces with the GPU at a low level. This means that the developer must provide explicit descriptors to specify how the pipeline and commands should be executed. In addition, since Vulkan uses "pools" of memory for command buffers and descriptor sets to avoid having to manage memory, the descriptors must manually manage the memory throughout the pipeline.
+
+* Describe a situation besides flip-flop buffers in which you may need multiple
+descriptor sets to fit one descriptor layout.
+
+Since descriptor sets simply specify the input arguments to a specific input format, another situation using multiple descriptor sets could just be passing in two different sets of data to a single shader, such as passing in two separate input models into a vertex shader.
+
+* What are some problems to keep in mind when using multiple Vulkan queues?
+
+Since different queues may be backed by different hardware, certain commands may work on one set of hardware but not another, so it is important to keep hardware compatibility in mind. In addition, since the same buffer can be used across multiple queues, write conflicts and race conditions should be avoided through the use of fences to allow synchronization.
+
+* What is one advantage of using compute commands that can share data with a
+rendering pipeline?
+
+Data does not need to be transferred from the compute to the rendering stage on each call, which makes sharing data far less expensive.
 
 ### Credits
 

base/vulkanexamplebase.cpp

@@ -821,7 +821,7 @@ void VulkanExampleBase::handleMessages(HWND hWnd, UINT uMsg, WPARAM wParam, LPAR
 	case WM_KEYDOWN:
 		switch (wParam)
 		{
-		case KEY_P:
+		case KEY_F2:
 			paused = !paused;
 			break;
 		case KEY_F1:

data/shaders/computeparticles/particle.comp

@@ -48,16 +48,51 @@ void main()
 		// velocity and handles wrap-around.
 		// TODO: implement flocking behavior.
 
+		int N = ubo.particleCount;
     // 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;
 
     // Read position and velocity
 		vec2 vPos = particlesA[index].pos.xy;
     vec2 vVel = particlesA[index].vel.xy;
 
+		//compute velocity change
+		vec2 center = vec2(0.0);
+		float neighborCount = 0;
+		vec2 cohesion = vec2(0.0);
+		vec2 separation = vec2(0.0);
+		vec2 alignment = vec2(0.0);
+
+		for (int i = 0; i < N; i++) {
+			if (i == index) continue;
+			vec2 iPos = particlesA[i].pos.xy;
+			float distance = length(iPos - vPos);
+			// Rule 1: boids fly towards their local perceived center of mass, which excludes themselves
+			if (distance < ubo.rule1Distance) {
+				center += iPos;
+				neighborCount += 1.0;
+			}
+			// Rule 2: boids try to stay a distance d away from each other
+			if (distance < ubo.rule2Distance) {
+				separation -= iPos - vPos;
+			}
+			// Rule 3: boids try to match the speed of surrounding boids
+			if (distance < ubo.rule3Distance) {
+				alignment += particlesA[i].vel.xy;
+			}
+		}
+
+		if (neighborCount > 0) {
+			center /= neighborCount;
+			cohesion = center - vPos;
+		}
+
+		vVel += cohesion * ubo.rule1Scale + separation * ubo.rule2Scale + alignment * ubo.rule3Scale;
+
 		// clamp velocity for a more pleasing simulation.
 		vVel = normalize(vVel) * clamp(length(vVel), 0.0, 0.1);
 

vulkanBoids/vulkanBoids.cpp

@@ -28,17 +28,17 @@
 
 #define VERTEX_BUFFER_BIND_ID 0
 #define ENABLE_VALIDATION true // LOOK: toggle Vulkan validation layers. These make debugging much easier!
-#define PARTICLE_COUNT 4 * 1024 // LOOK: change particle count here
+#define PARTICLE_COUNT 2 * 1024 // LOOK: change particle count here
 
 // LOOK: constants for the boids algorithm. These will be passed to the GPU compute part of the assignment
 // using a Uniform Buffer. These parameters should yield a stable and pleasing simulation for an
 // implementation based off the code here: http://studio.sketchpad.cc/sp/pad/view/ro.9cbgCRcgbPOI6/rev.23
-#define RULE1DISTANCE 0.1f // cohesion
+#define RULE1DISTANCE 0.07f // cohesion
 #define RULE2DISTANCE 0.05f // separation
-#define RULE3DISTANCE 0.05f // alignment
+#define RULE3DISTANCE 0.03f // alignment
 #define RULE1SCALE 0.02f
-#define RULE2SCALE 0.05f
-#define RULE3SCALE 0.01f
+#define RULE2SCALE 0.03f
+#define RULE3SCALE 0.005f
 
 class VulkanExample : public VulkanExampleBase
 {
@@ -157,6 +157,7 @@ class VulkanExample : public VulkanExampleBase
 		for (auto& particle : particleBuffer)
 		{
 			particle.pos = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator));
+			particle.vel = glm::vec2(rDistribution(rGenerator), rDistribution(rGenerator));
 			// TODO: add randomized velocities with a slight scale here, something like 0.1f.
 		}
 
@@ -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,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);
@@ -590,6 +611,7 @@ 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]);
 	}
 
 	// Record command buffers for drawing using the graphics pipeline