-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Omnilight shadow map wgsl #15
Conversation
// do a full projection | ||
// vec4 clip = light.projection * vec4(0.0, 0.0, -major_axis_magnitude, 1.0); | ||
// float depth = (clip.z / clip.w); | ||
|
||
// alternatively do only the necessary multiplications using near/far | ||
let proj_r = light.far / (light.near - light.far); | ||
let z = -major_axis_magnitude * proj_r + light.near * proj_r; | ||
let w = major_axis_magnitude; | ||
let depth = z / w; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something that should be discussed. This bit trades a full matrix multiplication for these couple of lines, but at the cost of needing to update the shader if the light projection changes.
Because it's in the fragment shader it might be worthwhile as an optimization, but early optimization etc etc...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is reasonable for now, given that the projection needs to be a 90 degree field of view to fully cover the cube map. Any more would result on overlap, any less would result in gaps right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. I'm also not sure what other projections make sense, except maybe infinite reverse.
bd87a1f
to
955853d
Compare
Replaces #9 with a version using wgsl