1

I have been looking at a lot of questions regarding generating a random number in the fragment shader. However, none of them are of shape:

float rand() {
    ...
    return random_number;
}

All of them require a input parameter. Is there any way to get a random number without any input?

Rabbid76
  • 202,892
  • 27
  • 131
  • 174
  • Could you give and example? I have created a random number in my c++ code which can be used as `time` as you have said. @Rabbid76 –  Aug 14 '17 at 13:40
  • This related question might be useful: https://stackoverflow.com/questions/5149544/can-i-generate-a-random-number-inside-a-pixel-shader – schnaader Aug 14 '17 at 14:50

1 Answers1

1

Computers are deterministic devices that execute algorithms. Randomness cannot manifest itself out of thin air. While many CPUs do have some form of randomness-generating construct, even that takes some kind of input, even if you don't see it.

This is why random number algorithms are technically called "pseudo-random number" generators (PRNG). They take an input and generate an output based on that input. The trick with PRNGs is that they generate output that (theoretically) is not predictable from the input. Outside of hardware-based random generators, all computer RNGs work this way.

Even C/C++'s rand function does, though it hides the input behind the seed state set by srand. rand uses internal state which can be initialized by srand, and that state is used as the input to the PRNG function. Every execution of rand changes this state, presumably in a way that is not easy to predict.

You could theoretically try the rand trick in a shader, by using Image Load/Store functionality to store the internal state. However, that would still qualify as input. The function might not take input, but the shader certainly would; you'd have to provide a texture or buffer to use as the internal state.

Also, it wouldn't work, due to the incoherent nature of image load/store reading and writing. Multiple invocations would be reading from and writing to the same state. That can't happen.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • This answer is a tad bit misleading. Of course, generating random numbers on deterministic hardware would require some kind of input but this answer seems to suggest that it would not be possible for a function like `rand` in C to be exist. Perhaps a discussion of why a function like `rand()` is applicable in C but not in GLSL would help augment the answer. – Kröw Jun 13 '23 at 15:19
  • @Kröw: I don't know what's misleading. I explain how `rand` exists in C, that it *has input* even if you don't see it. That's my point. The OP asked for an RNG that works in GLSL "without any input", and that's not possible for *any* RNG. – Nicol Bolas Jun 13 '23 at 15:46
  • @Kröw: "*Perhaps a discussion of why a function like rand() is applicable in C but not in GLSL would help augment the answer.*" I did. That's what the fourth paragraph is talking about. It does presume that you understand basic fundamentals of shaders (like how they get data), but... this is a question *about shaders*. Readers of this answer are expected to have some idea of what a shader is and how they get data. – Nicol Bolas Jun 13 '23 at 15:50
  • You could probably mitigate the problem of it being misleading by clarifying the difference between *input* meaning a parameter to the `rand()` function and it meaning some data that is taken in by a random generator. The question seems to be asking in the context of the former. Of course, a `rand()` function can easily be made that does not have a parameter, and one could write on in GLSL. – Kröw Jun 13 '23 at 20:26
  • The fourth paragraph doesn't discuss that though. Did you mean the third paragraph? If so, that makes more sense. I think what I meant to say is that specifically clarifying why the way something like `rand()` works in C is not feasible/reasonable in GLSL would be helpful. (Edit: I forgot to mention, you can expect readers to have any understanding but the usefulness or interpretation of the answer is going to be based off of what understanding they have, not what they are expected to have. That is why I was saying the answer could perhaps be augmented.) – Kröw Jun 13 '23 at 20:29
  • @Kröw: "*clarifying why the way something like rand() works in C is not feasible/reasonable in GLSL would be helpful.*" What do you think "Multiple invocations would be reading from and writing to the same state. That can't happen." means? I'm not going to explain how shaders work to an audience that is supposed to already know how shaders works. The OP seemed to not understand how *`rand`* works, not how shaders work. – Nicol Bolas Jun 13 '23 at 21:32
  • You don't seem to be understanding what I'm saying at all, so I apologize for that. I think it's pretty clear that the `rand()` function as it is in C cannot just be ported over to GLSL code. What you say in your fifth paragraph attests to that. I think it would be helpful if your answer discussed, more generally, why a parameterless `rand()` function would not be applicable. – Kröw Jun 16 '23 at 03:20
  • Also, your claim that the audience of this page is "supposed to know how shaders work" is one of the reasons that you've limited your answer and that I think it can be augmented. I could just as easily, and baselessly, claim that your audience is rather "supposed to know how rand() works in C" and that what they are missing is instead knowledge of how shaders work. A best answer would account for both groups, which is, again, why I think the answer could be improved. Please don't misunderstand: I don't think there is anything wrong with your fifth paragraph. – Kröw Jun 16 '23 at 03:23