Hacker News Reader

Comment by webdevver | Hacker News Reader

>Shaders technically don't even know their X and Y coordinates by default unless you specifically provide those

im kind of a boomer regarding shaders but isnt gl_FragCoord always available?

Is the article about OpenGL? I see a few mentions of OpenGL in a section about graphics APIs that also mentions at least Vulkan, which doesn't automatically provide fragment coordinates, and WebGPU, which also doesn't. Shaders by default have no concept of fragment coordinates; it's OpenGL the API that introduces them by default.

The pixel position has to be known, how else are you rasterizing something?

The view transform doesn't necessarily have to be known to the fragment shader, though. That's usually in the realm of the geometry shader, but even the geometry shader doesn't have to know how things correspond to screen coordinates, for example if your API of choice represents coordinates as floats from [0.5, 0.5) and all you feed it is vertex positions. (I experienced that with wgpu-rs) You can rasterize things perfectly fine with just vertex positions; in fact you can even hardcode vertex positions into the geometry shader and not have to input any coordinates at all.

Rasterizing and shading are two separate stages. You don’t need to know pixel position when shading. You can wire up the pixel coordinates, if you want, and they are often nearby, but it’s not necessary. This gets even more clear when you do deferred shading - storing what you need in a G-buffer, and running the shaders later, long after all rasterization is complete.

Technically, the (pixel) fragment shader stage happens after the rasterization stage.

No, that is OpenGL specific and only if using GLSL, other shading languages expect such values as explicit parameters, for example in WGSL it is @builtin(position) that you are to bind to a specific variable.

    @builtin(position) fragCoord: vec4f

Reply on news.ycombinator.com