Better living through random numbers...

[Feline]

No offense to the Lumina project that is credited with the way random numbers are done in much of the default code in Fragmentarium (and who's sourceforge page has been down for years now) but if you're driving your trig-function PRNG from your x/y coordinates then you're guaranteed some magnification factor or coordinate choice at which the PRNG will beat against the screen pixels and generate distinctly non-random effects. And one simple way around that is to supply all your various random number operations with a single uniform float as memory and use that to disturb future random numbers.

It's still not entirely random, but certainly more uniform than just using trigonometric functions.

(The attached is the "graphplotter" in your Examples/2D menu - original version zoomed to the max, then modified version).

Could we flow something like this into future versions of Progressive[...] ?

[3dickulus]

interesting results, looks more efficient than calling a special routine for shuffling bits and what not and doesn't require any special GLSL extensions or versions

you can very easily add that to your favorite DE frag, (just search for rand) I don't think there is anything special to do in order to make it work with "progressive" mode as all rendering is done by the frag code so you don't have to wait for an update or future version

currently, I am using a wang-hash function provided (in another thread, I forgot to bookmark) by Syntopia, primarily for the blocky clouds bug
if this is adequate to cure the blocky clouds bug then I will switch to using it and maybe add it to a few DE-frags, I seem to recall 1 or 2 may already do something similar

 

[3dickulus]

the same scene @ 100 subframes

image 1 using lumina noise
image 2 using wang hash
image 3 using seed suggestion by Feline (as indicated above)

Syntopia's Wang Hash function wins (in my books)

[Syntopia]

down for years now) but if you're driving your trig-function PRNG from your x/y coordinates then you're guaranteed some magnification factor or coordinate choice at which the PRNG will beat against the screen pixels and generate distinctly non-random effects. And one simple way around that is to supply all your various random number operations with a single uniform float as memory and use that to disturb future random numbers.

If you need multiple random numbers in the same shader invocation you can of course store some state information (all RNG do this).

The big problem with GPU shaders is how to seed the RNG's (which you can only do it based on the pixel index or coordinates). This requires a good hashing function:
http://www.fractalforums.com/fragmentarium/problem-with-maps/15/

[3dickulus]

ty Syntopia, for this link in particular http://www.fractalforums.com/index.php?topic=22721.msg88910#msg88910 

[Feline]

Oh, but I'm not trying to make my random numbers "better" (in a randomness sense), I'm merely trying to keep them from beating against my pixel grid. Which they are guaranteed to do at some magnifications/orientations/views if they're purely sinusoidal.

Initialization of the seed doesn't matter here (I initialize to zero, hardwired) since the seed merely encodes the deviation from the 'pure sinusoidalness' and it is not important if that deviation is the same for all pixels, it merely has to be large enough to throw off the regularity that will otherwise crop up stepping from pixel to pixel by amounts that happen to be sub-multiples of the frequencies used in the PRNG...

[3dickulus]

I'm sure it will be useful, as is the case with the 2d graph plotter, a much better image with minimal overhead.
another tool for the box thanks Feline 

I don't know if I implemented it correctly, just followed what you indicated above, but in the clouds, rand() uses a vec3 input, normalizing rseed might give better results in 3D version. will be testing this more later this week.

[Roquen]

Assuming a GPU with full 32-bit integer support, then see: http://marc-b-reynolds.github.io/math/2016/03/29/weyl_hash.html

[3dickulus]

As I understand it, the hash function is for seeding the rng, so, I used this modification of the existing rand function...

Code:

float rand(vec3 co){
        // modified for seeding with hash function
        return fract(sin(dot(vec3(hash(co.xx),hash(co.yy),hash(co.zz))*0.123,vec3(12.9898,78.233,112.166))) * 43758.5453);
}

maybe a more knowledgeable math head can tell me if this is good or bad practice and why.

... and it looks (very nice) like this (the same scene @ 100 subframes)

edit:using the routine from http://marc-b-reynolds.github.io/math/2016/03/29/weyl_hash.html referred to by Roquen in all of the rand func (4?) code in DE-Kn2.frag
note: the bulb has nice shading in this one but there is a little banding in the area above the light where the clouds are thin

[Roquen]

I know a little about this stuff and I'm not above nagging the author on twitter.  Could you post the shader and I'll look at it?

[3dickulus]

@Roquen ty

after a few tests it's not the RNG or the clouds that caused that banding,
it is present with Dither set to less than 1.0 and is not there when Dither = 1.0
the default preset has Dither set to 0.75 (to exaggerate the cloud bug I think)

the attached zip has CJR's cloud bug frag and my current support files, MathUtils.frag contains hash functions

it would be nice to see if Feline's method can be adopted/applied to the 3D raytracer rand() routines, it works so well in the 2D plotter frag and requires far less computing clocks 

[Roquen]

Note:  In an ideal world there would be a way to know if full 32-integer support is present (say via a predefined macro) so shaders could have multiple hash & random number generators for both cases.

When you do have full integer support, you can use integers all the way down.  Older and current WebGL shaders make thing blurry since they are (more or less) using variants of one function for both purposes.

NOTE: All of my code is "typing in post" so I could be dropping the ball somewhere.

So the 2D->1D hashing function I was intended to suggest is:

Code:

uint hash(in uvec2 c) { c = uvec2(0x3504f333, 0xf1bbcdcb)*c; return 741103597*(c.x^c.y); }

The floating point version of this might be problematic...it has a smaller domain than the classic sin-based.  Once you've hashed an n-dimensional coordinate you have an integer value which can be used as your first random number (with rescaling).  When you need more random numbers, you switch to using an integer based random-number generator of some sort for the rest.  As an example the classic LCG, reworked to be a little easier to use:

Code:

// returns [0,1]
float u32tofpi(in uint v) { return (1.0/4294967296.0)*float(v); }

// returns [0,1)
float u32tofp(in uint v) { return (1.0/16777216.0)*float(v>>8); }

// base LCG 
uint lcg(in uint v) { return 741103597*v + 0x1234567; }

// return the currect value as a float and then updates
float rng(inout uint v} { float r = u32tofp(v); v = lcg(v); return r; }

This could be replace with anything else, say an Xorshift for higher quality (in terms of randomness).  So a makeshift example might be:

Code:

void doSomething(vecN coord)
{
    uint seed = hash(coord);  // use hash to get first integer from coordinate

    float n0    = rng(seed);    // transform 'seed' to first float and update state.
    float n1    = rng(seed);    // second random number...    
    
   // however many more is needed.  This helper function way I've structured
   // this means we will always be doing one more integer random number
   // generating step than needed.  Since I've typed it that way I'll leave as is.
}