cis565-fall-2016/project5a-webgl-forward-plus-shading-with-gltf

Project5A-WebGL-Forward-Plus-Shading-with-glTF

WebGL Forward Plus Shading

CLICK ME FOR INSTRUCTION OF THIS PROJECT

University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 5A WebGL Forward Plus Shading

• (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)

Live Online

Demo Video/GIF

(TODO: Your README)

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.

This assignment has a considerable amount of performance analysis compared to implementation work. Complete the implementation early to leave time!

Credits

• minimal-gltf-loader by @shrekshao

project5a-webgl-forward-plus-shading-with-gltf's Issues

Ready for review

@pjcozzi @likangning93

• Finished the core features. Still need to add texture shading, do clean up, and write INSTRUCTION.md. and get a working gltf sponza
• Basic work flow
  • optional depth prepass
  • lightCulling, write the tileLight buffer. threads in a tile share a light array, each element indicating if light[idx] overlap with current tile. Each thread handles one light.
  • lightAccumulation, naive Forward with testing light visible or not
• Students will focus on writing shaders doing light culling and accumulation. Once they fully understand the content and how webgl works (this might take longer than writing code), the workload should be pretty light. Main files for the assignment (one you want to review):
  • glsl/lightCulling.frag.glsl
  • glsl/lightAccumulation.frag.glsl
  • glsl/tileLightDebug.frag.glsl
  • glsl/forward.frag.glsl (this is naive forward pipeline, can be used as a warmup for glsl)
• The tile based Forward+ currently has a improvement about 5 fps with 220 lights compared to Forward shading (still use a texture to read light info) in the duck scene.
• With tile min max depth culling, it performances worse. This doesn't go as expected.
• Extra credit ideas:
  • better frsutum culling method http://www.iquilezles.org/www/articles/frustumcorrect/frustumcorrect.htm
  • fully utilize the tileLightsTexture rgba channel to allow more lights in a scene
  • better idea to parallelize threads
  • performance analysis
    • num of lights
    • tile size
    • with/without frustum near far dpeth/tile min max depth culling
    • use profiler to find bottleneck functions
    • compared to forward shading
    • compared to deferred shading (students pair with those choosing a different one. Although not a complete fair comparison)

I think it's totally reasonable to discard this one if shipping the content in lecture is difficult. And also time is quite limited now. I can save it for myself and next year.

Scatter Approach Dilemma

• Scatter approach light culling in the paper:
  • execute a thread per light
  • find overlapping tile
  • write (lightIdx, tileIdx) pair
  • sort on tileIdx using radix sort, label start and end idx per tile(This step is similiar to that in Gary's proj 1)
  • // ... tile based shading ...
• Bradly's OpenGL light culling approach:
  • create a light idx buffer for each tile with a size of 1024
  • use atomAdd to get offset (i.e. address in the buffer to write lightIdx)
  • // ... tile based shading ...
• Tian Sijie's WebGL light culling approach
  • Scatter lights into tiles totally on CPU...
  • Use texture as buffers for light pos, color, radius, etc...
  • // ... tile based shading

So I feel it a little embarrassing at this time to do scatter light culling with WebGL: no atomic op, no radix sort(implement one in shader? or use cpu sort per frame?)
I'm switching to gather approach, which basically launch a thread per tile, each thread goes through all the lights in the scene and check which of them overlaps with cur tile.

Let me know if you have any ideas on this...

Fallback to CPU tile light assign

Finally it turns out that even with gather approach, we still cannot use shader to assign lights to tile in parallel, since one single thread cannot write multiple pixels to texture (assign multiple lights to buffer). MRT won't work cuz the number is too limited compared to num of lights.

I'm finally falling back to use cpu to assign lights to each tile. Reading from multiple textures (functioning as tile-lightIdx buffer) is still doable (like Sijie Tian's Tile-based deferred one).

Let me know if there's anything I'm missing.