Hi,
I want to create a texture with random rgb colors with ARBfp1.0. Without fragment programs my code looks like this:
red=random()%256;
green=random()%256;
blue=random()%256;
But how could I do this in a fragment program?
-FA
You need a function that can generate a random number given a multi-valued input.
I suggest that you use the screen X,Y coordinates, and possibly fragment depth, as input, and the stuff those through some hash function, and the output of that hash function is the color value. Use three different hash functions for the three color channels.
Another approach is to use Perlin noise. Google for that and Bob’s your uncle.
Hi,
but how do I code it? I’m still new to ARBfp and noise, and the funtions for random values I found are all using binary operators (and I’m not advanced enough to convert it to ARBfp). I already googled for perlin noise and found nothing useful, but I’ll try again. I think I would be able to do it in C/C++, but the texture should be computed completely on the GPU.
Do you know Ken Perlin?
He has received an award for his work. Click on it.
Perlin noise doesn’t really sound like what he wants…
for one thing, the original example was just random()%256, if thats good enough, perlin noise is overkill.
more of a problem is the ‘entirely on GPU’ part…seems like it would be hard to write a perlin noise shader that didn’t need an input texture that looks like the one he’s trying to replace in the first place.
to the original poster:
an example of using a hash to make random #s would be something like:
TEMP t;
MAD t,fragment.position,{0.2345,0.3456,0.45675,0.05678},{11.22345,32.34456,95.3876,8.2354};
MUL t,t,{0.0234,-0.0345,-0.456,0.567};
XPD t,t,{2222.1234,-2312.2342,1442.7865,1};
FRC t,t;
where those #s are all just arbitrary numbers i picked by mashing on the keyboard, then poking at em for a min or 2 to create something vaguely random looking…
Why do you need to generate random #s on the GPU, and how random do they need to be? seems like any GPU only solution will not give as good results as one using a texture or 2 as a source of randomness…
Thanks 3B, this code took me a bit further.
I changed .position to .texcoord and the random values to a pre-computed noise texture(rgb), but it is still not what I want.
I want to use it for perturbing normals(smooth animated) and generating special heightmaps. Randomness isn’t very important, but when animated it shouldn’t repeat too often.
If the quality is better with textures I’ll use them.
If using textures is OK, i would definitely move as much work as possible out of the shader and into one or more textures…
my code was just a random attempt at generating values completely on the GPU, if you have a random texture, use it directly, possibly messing with the texcoords a bit to avoid tiling if thats a problem…
for smoothly animated noise, perlin noise might be appropriate, 1d or 3d depending on whether you need the smoothness just in time, or across the texture as well…possibly expensive in fill rate though, depending on how you implement the shader, and how much smoothness you need…
otherwise, you could probably take 2 or 3 random RGB textures, and LRP between them, updating one of them every time you pass then next one…
(or use a 3d texture, and vary the 3rd texture coordinate with time, updating slices of the texture as you pass them again, same effect, but fewer texture accesses, and easier to pass the time parameter)