Talk:OpenGL pixel shader

Issues?

Does anyone see any major problems with this task proposal? --Rdm 18:05, 25 October 2011 (UTC)

Does GLSL have a built-in random number generator? If not, a linear gradient may be easier (and easier to verify) than a random RGB shader. --Ledrug 20:06, 25 October 2011 (UTC)

There is a noise() function, but apparently it's not supported very well. However, we do not need high quality random numbers here -- modulo and arc tangent using old pixel value and coordinate values could probably be made into something adequate. I would like to avoid a gradient, however, because we already a gradient in OpenGL. --Rdm 03:17, 26 October 2011 (UTC)

Assuming you want to procedurally generate color values based on coords in model view space, "random" gives the impression that you want the generated values to be very noisy, i.e. have a high frequency. Broadly speaking, as long as the so generated texture is deterministic, noise is just a kind of gradient. The problem of the word "random" is that, firstly, the code still needs to decide what frequency to use: pixel shader gets called on each pixel on every scanline, which is not directly coupled to model view coordinates due to projection transformations. Secondly, if the frequency is too high (comparable to screen dpi under current projection), it will suffer greatly from aliasing, whereby any movement along z or any rotation will cause pixels to sample to completely different values, resulting in apparently changing texture. Coherent psuedo random texture with frequency cutoff is also difficult (I have a Perlin noise example in the draw sphere task). Granted, it might not be a problem because most implementations will probably just draw something static and never rotate it, but it's still easier to verify the code is doing the right thing if it's asked to draw something identifiable, say a checker pattern, stripes, concentric circles, etc. --Ledrug 03:50, 26 October 2011 (UTC)