Project 5: Harry Guan

README.md

@@ -2,25 +2,78 @@
 
 **University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 5**
 
-* (TODO) YOUR NAME HERE
-* Tested on: (TODO) **Google Chrome 222.2** on
-  Windows 22, i7-2222 @ 2.22GHz 22GB, GTX 222 222MB (Moore 2222 Lab)
+* Harry Guan
+* Tested on: **Google Chrome 141** on
+Windows 11, Intel i7-14700 @ 2.10GHz 32GB, NVIDIA T1000 4GB (Moore 100B virtual labs)
 
 ### Live Demo
 
-[![](img/thumb.png)](http://TODO.github.io/Project4-WebGPU-Forward-Plus-and-Clustered-Deferred)
+[![](images/bicycle_main.png)](https://hazingoo.github.io/Project5-WebGPU-Gaussian-Splat-Viewer/)
 
 ### Demo Video/GIF
 
-[![](img/video.mp4)](TODO)
+[![](images/video.gif)]()
 
-### (TODO: Your README)
+### Results
 
-*DO NOT* leave the README to the last minute! It is a crucial part of the
-project, and we will not be able to grade you without a good README.
+Side‑by‑side: raw point cloud vs. Gaussian splats.
 
-This assignment has a considerable amount of performance analysis compared
-to implementation work. Complete the implementation early to leave time!
+**Bicycle**
+
+| Point Cloud | Gaussian Splats |
+| --- | --- |
+| ![](images/bicycle_cloud.png) | ![](images/bicycle_gaussian.png) |
+
+**Bonsai**
+
+| Point Cloud | Gaussian Splats |
+| --- | --- |
+| ![](images/bonsai_cloud.png) | ![](images/bonsai_gaussian.png) |
+
+## Description
+I implemented a 3D scene viewer that uses a technique based on the paper "3D Gaussian Splatting for Real-Time Radiance Field Rendering" to render beautiful, realistic scenes in your web browser. Unlike traditional 3D rendering that uses polygons, Gaussian Splatting represents every piece of a scene as a cloud of many tiny, colored points that blur together to create smooth surfaces and lighting effects. The viewer loads 3D scenes (saved as PLY files) and lets you navigate around them, rotating and zooming in real-time to explore objects like bonsai trees, bicycles. You can adjust how the points are displayed and switch between different visualization modes to see both the raw point cloud data and the final beautiful splat rendering. 
+
+
+## Feature Overview
+
+### Preprocessing Pipeline
+
+Before rendering, the system processes all 3D Gaussian points to determine which ones are visible and how they should appear on screen. Starting with each point's position, rotation, and size, the code unpacks the data from a compact 16-bit format. The scale values, which are stored in logarithmic form, are converted back to actual sizes. The opacity values are also converted from their stored format to a usable range using a sigmoid function. Each point is then transformed from 3D world space into the camera's 2D view space using standard camera matrices.
+
+The first optimization is view frustum culling, which removes any points that are outside the visible screen area. This check uses a slightly larger boundary (1.2 times the screen size) to ensure that points right on the edge don't get accidentally discarded. Only points that pass this check continue to the next steps.
+
+For the remaining visible points, the system calculates how each 3D Gaussian blob should appear when projected onto the 2D screen. This involves computing the shape and size by combining the point's rotation and scale information. The mathematical approach projects the 3D shape through the camera lens to determine its elliptical appearance on screen, accounting for the viewing angle and distance. A small stability factor is added to prevent numerical issues.
+
+The color of each point is computed based on the viewing direction using spherical harmonics, a mathematical technique that allows the appearance to change naturally as you look at it from different angles. This gives the scene realistic lighting that responds to your viewpoint. The opacity is also extracted and combined with the color.
+
+Finally, all this information for each visible point is packed into a compact format and stored in memory. The system also prepares depth values for sorting, carefully handling the bit representation to ensure the sorting works correctly for both positive and negative depths. A counter tracks how many visible points there are, which is used later to determine how many quads to actually render.
+
+### Rendering Pipeline
+
+The rendering system draws each visible point as a small quad on the screen. The number of quads to draw is determined automatically by counting how many visible points there are from the preprocessing step. Each point's position, size, color, and shape information is unpacked from memory and used to position a quad centered at the point's 2D screen location. The quad is scaled to match the point's computed radius, and the color information is passed along for shading.
+
+The fragment shader determines what each pixel of the quad should look like. It checks if the pixel is actually inside the elliptical shape of the Gaussian splat by computing its distance from the center and using a mathematical formula to determine if it falls within the boundary. Pixels outside the splat are discarded entirely. For pixels inside the splat, the opacity falls off smoothly as you move away from the center—this creates the soft, blurry edges that make the individual points blend together to form smooth surfaces. Very transparent pixels far from the center are also discarded since they contribute almost nothing to the final image.
+
+All these semi-transparent splats are blended together using standard transparency blending, which combines the colors and opacities of overlapping splats in the correct way.
+
+
+## Performance analysis
+
+### Compare your results from point-cloud and gaussian renderer, what are the differences?
+
+ The point‑cloud view looks grainy and full of tiny gaps. The Gaussian renderer blends those points into smooth, continuous surfaces with cleaner edges and more natural shading. So the overall image looks closer to a photo.
+
+### For gaussian renderer, how does changing the workgroup-size affect performance? Why do you think this is?
+
+ Small workgroups underuse the GPU and run slower. Very large ones don’t help much and can even hurt. Because overly large groups increase register/shared memory pressure and reduce how many groups can run in parallel.
+
+###  Does view-frustum culling give performance improvement? Why do you think this is? 
+
+ Yes, it helps. When I point the camera so a lot of the scene is off‑screen, frame rate noticeably improves because we skip preprocessing, sorting, and drawing those splats. You feel it most when zoomed in on a small part of the scene.
+
+### Does number of guassians affect performance?  Why do you think this is? 
+
+More Gaussians means more work almost everywhere (preprocess, sort, and blending). Performance scales roughly with how many are visible. Large scenes still run, but the sort and memory bandwidth start to dominate.
 
 ### Credits