Welcome to Fractal Forums

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[...] ?

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

 :beer:

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)

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/

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

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...

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  :beer:

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.

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

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


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 :D but there is a little banding in the area above the light where the clouds are thin :(

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?

@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  :beer:

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:


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:


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