You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
21
21
22
-
### Demo Video/GIF
22
+
This didnt deploy properly so the live link doesnt work (tbd).
23
23
24
-
[](TODO)
24
+
## Features
25
25
26
-
### (TODO: rest of README)
26
+
- Forward
27
+
- already implemented as a demo for the assignment
28
+
- Forward+
29
+
- Build a data structure to keep track of how many lights are in each cluster and what their indices are
30
+
- Render the scene using only the lights that overlap a given cluster
31
+
- Clustered
32
+
- Reuse clustering logic from Forward+
33
+
- Store vertex attributes in g-buffer
34
+
- Read g-buffer in a shader to produce final output
35
+
- Effects
36
+
- deferred Blinn-Phong shading (diffuse + specular) for point lights
37
+
38
+
## Shading Techniques
39
+
Note: in the below gifs, LICECap software creates the blocky effect, the live version is much smoother.
40
+
41
+
### Forward Rendering
42
+
43
+
This was already implemented as a demo for how the assignment was constructed, and this version of shading is the most straight forward. The overhead of this is that an excessive number of lights will very quickly slow down this simulation.
44
+
```
45
+
for each geometry {
46
+
for each light {
47
+
do calculations...
48
+
}
49
+
}
50
+
```
51
+
52
+
### Forward Plus
53
+
54
+
`*` GIF CONVERTER MADE THIS CHOPPY
55
+
This video is of a forward plus implementation with a Blinn-Phong shader.
56
+
57
+
Instead of doing a double for loop over all the lights, this idea takes the looping and shortens the number of lights associated with each geometry based on the geometry's distance to the light. This improves the performance slightly to prevent the overhead of doing all the light checking for every single geometry.
58
+
59
+
```
60
+
prepass to find light distances
61
+
for each geometry {
62
+
for each light that's appropriately near this geometry {
63
+
do some calculations...
64
+
}
65
+
}
66
+
```
67
+
68
+
### Clustered Deferred
69
+
70
+
`*` GIF CONVERTER MADE THIS CHOPPY
71
+
This video is of a clustered deferred implementation with a lambert shader.
72
+
73
+
Instead of doing the double `for loop` as in the previous two explanations, we create a mid geometry buffer which has a 2d texture storing geometry displacements as needed for rendering (`normal`s, `depth`, `albedo`, etc). This makes rendering even more optimized because it no longer requares the double for loop, but instead just requires a texture call.
74
+
75
+
```
76
+
for each light {
77
+
prepass to fill in texture will all needed information
78
+
}
79
+
80
+
for each geometry {
81
+
look up information in g-buffer as needed
82
+
do some calculations with this information...
83
+
}
84
+
```
85
+
86
+
Something is currently wrong in this implementation :( . My assumption is that my light indexing isnt occuring on a gradient as it should, but is being additive without taking into consideration distances (giving the solid circle effect).
Currently, I have regular lambert shading and Blinn-Phong shading which adds a highlight to the scene. Comparing the two, Blinn-Phong has much stronger highlights as noted in the below images. Notice the flatness of the purple pillar's coloring in the Lambert compared to the more accentuated color changes in the Blinn-Phong.
98
+
99
+
### Optimizations
100
+
101
+
I packed information into the buffers in `vec4`s instead of just a listing of `float`s. Additionally, I optimized the space usage from three `vec4`s for positions, colors, and normals, to two `vec4`s by just abstracting out the `z` component of the normal to be recomputed later.
102
+
103
+
That is, I only put two `vec4`s into my buffer: `vec4(position.x, position.y, position.z, normal.x)` and `vec4(red, blue, green, normal.y)` and I recalculated `normal.z` by using `sqrt(1 - normal.x * normal.x - normal.y * normal.y)`. This optimization works because (hence the name) a normal is always normalized, so we can use the cross of their two attributes we do know to solve for the third.
104
+
105
+
### Runtime Comparisons
106
+
107
+
108
+
109
+
For shading techniques - it follows properly that as the number of lights increases, the runtime of all of the shading implementations goes up; however, the cluster deferred implementation still maintains the fastest runtime due to the texture call instead of recalculations (as explained in the  section). It also goes to show how much each of the techniques improves upon the one prior and that for real-time rendering deferred shading is an optimal solution.
110
+
111
+
112
+
113
+
For optimizations - Again, shorter is better. As the graph shows, the `z` optimization effectively makes for fewer pieces of memory being passed through the g-buffer, leading to a faster runtime.
-[no image]: for a long period of time I had my input values in my deferred shader swapped without realizing, so my output of `albedo` would skew up my lighting calculations since they were using the `albedo` as the `normal` and the `normal` as the `albedo`
124
+
- clustered deferred: as mentioned before, I still have this issue and my current understanding is that it's because of an indexing issue and/or a clamp issue when filling in the lights into the buffer in the first place. It's missing the gradient from the light's source to its radius but it does have the appropriate colors and locations. (unresolved)
125
+
- indexing-resolution issue: The indexing part of this error was that I was casting to an int for my indices before finishing certain calculations with them so I would get a squarish effect in the texture coordinates. The resolution part of this issue that led to LICECap's screen bar being captured in its own video was because worked on this project on a different machine than usual and the resolution was different than my screen capture's software settings. To fix this, I had to reconfigure the resolution specifically for capturing even though it made the text too small to read on the screen.
0 commit comments