-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Rework of #1203: Provide the camera's view matrix to shaders #1611
Changes from all commits
93c05f6
8962b8c
a7e84f2
26654c7
8a22500
1e8c67a
55910d3
5501613
081e0fd
dde6079
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,9 +14,12 @@ layout(location = 2) in vec2 v_Uv; | |
|
||
layout(location = 0) out vec4 o_Target; | ||
|
||
layout(set = 0, binding = 0) uniform Camera { | ||
layout(set = 0, binding = 0) uniform CameraViewProj { | ||
mat4 ViewProj; | ||
}; | ||
layout(set = 0, binding = 1) uniform CameraView { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Neither of the forward shaders use CameraView, but removing it causes rendering to break (see the ui/sprite shaders, which are currently broken but can be "fixed" by adding CameraView). As-is this implementation has the same problem I called out in #1203, but with the added downside of more boilerplate. For this to be a solution, users need to be able to pull in only what they need. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for the review. I made a wrong assumption that led me think these things would work: I assumed that the reason this worked for render resources was due to a difference between a uniform struct and separate bindings. I am a complete beginner when it comes to shaders... I did fail to test all the examples, I will remember better next time. Clearly there’s much more going on under water in the render resource bindings. Is it using shader reflection to create bindgroups that only have the bindings used in the shaders? If so, that seems useful and I’d love to find out how. But I’m finding the related code to be both dense and somewhat spread across different implementations. Can you point me in the right direction? But wouldn't that also mean the cost of not having to have these bindings in some shader code goes up yet again? There's the cost of using multiple buffers instead of one. Multiple bindings. But now we even have to set up the bind groups for the camera every time the pipeline changes, I think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No worries! I can see why you would think that, given that the bindings provided by RenderResourceBindings are flexible in exactly that way. The reason it doesn't work here is that bind groups need to exactly match the shader layout. PassNode sets an explicit bind group for the camera (with two bindings), whereas RenderResourceBindings creates the exact bind group required to match the shader layout (if it doesn't already exist), which could have any number of bindings in any order. Handling this case is non-trivial, especially if we want to do it generically. If every camera had a different name, we could just throw them into the global RenderResourceBindings and everything would magically work. However we dont want that for cameras. I'm personally pretty attached to the idea of including pbr in 0.5, so I'm willing to consider short term solutions (such as the original impl: having a single combined binding/buffer and requiring that people include the camera position in every shader, or special-casing cameras to somehow allow both layouts). I'll need to think a bit about this. Once I've wrapped up the other reviews i need to do, I'll probably spend some time on this. Feel free to explore the space too if you feel inclined! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think I have a handle on this. Let me try to fix this PR. |
||
mat4 View; | ||
}; | ||
|
||
layout(set = 1, binding = 0) uniform Lights { | ||
vec3 AmbientColor; | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,8 +6,9 @@ layout(location = 2) in vec2 Vertex_Uv; | |
|
||
layout(location = 0) out vec2 v_Uv; | ||
|
||
layout(set = 0, binding = 0) uniform Camera { | ||
layout(set = 0, binding = 0) uniform CameraViewProj { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This binding is now incorrect and sprites no longer render |
||
mat4 ViewProj; | ||
mat4 View; | ||
}; | ||
|
||
layout(set = 2, binding = 0) uniform Transform { | ||
|
@@ -25,7 +26,7 @@ void main() { | |
|
||
uint x_flip_bit = 1; // The X flip bit | ||
uint y_flip_bit = 2; // The Y flip bit | ||
|
||
// Note: Here we subtract f32::EPSILON from the flipped UV coord. This is due to reasons unknown | ||
// to me (@zicklag ) that causes the uv's to be slightly offset and causes over/under running of | ||
// the sprite UV sampling which is visible when resizing the screen. | ||
|
@@ -41,4 +42,4 @@ void main() { | |
|
||
vec3 position = Vertex_Position * vec3(size, 1.0); | ||
gl_Position = ViewProj * Model * vec4(position, 1.0); | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,8 +7,9 @@ layout(location = 2) in vec2 Vertex_Uv; | |
layout(location = 0) out vec2 v_Uv; | ||
layout(location = 1) out vec4 v_Color; | ||
|
||
layout(set = 0, binding = 0) uniform Camera { | ||
layout(set = 0, binding = 0) uniform CameraViewProj { | ||
mat4 ViewProj; | ||
mat4 View; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This binding is now incorrect and sprite sheets no longer render |
||
}; | ||
|
||
// TODO: merge dimensions into "sprites" buffer when that is supported in the Uniforms derive abstraction | ||
|
@@ -25,7 +26,6 @@ layout(set = 1, binding = 1) buffer TextureAtlas_textures { | |
Rect[] Textures; | ||
}; | ||
|
||
|
||
layout(set = 2, binding = 0) uniform Transform { | ||
mat4 SpriteTransform; | ||
}; | ||
|
@@ -75,11 +75,10 @@ void main() { | |
bottom_left, | ||
top_left, | ||
top_right, | ||
bottom_right | ||
); | ||
bottom_right); | ||
|
||
v_Uv = (atlas_positions[gl_VertexIndex]) / AtlasSize; | ||
|
||
v_Color = color; | ||
gl_Position = ViewProj * SpriteTransform * vec4(vertex_position, 1.0); | ||
} | ||
} |
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 (across every shader) is the one part of this PR that feel problematic to me, because it will break pretty much every single shader people have. On the other hand it seems messy to let the name remain just Camera.
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 seems to be a sensible change with an easy fix. My opinion is that it's better to make breaking changes like this sooner, in order to reduce the total code that must be fixed, and then add a note to our migration guides.