Logo by RedBug - Contribute your own Logo!

END OF AN ERA, FRACTALFORUMS.COM IS CONTINUED ON FRACTALFORUMS.ORG

it was a great time but no longer maintainable by c.Kleinhuis contact him for any data retrieval,
thanks and see you perhaps in 10 years again

this forum will stay online for reference
News: Visit us on facebook
 
*
Welcome, Guest. Please login or register. September 25, 2022, 03:27:18 PM


Login with username, password and session length


The All New FractalForums is now in Public Beta Testing! Visit FractalForums.org and check it out!


Pages: [1]   Go Down
  Print  
Share this topic on DiggShare this topic on FacebookShare this topic on GoogleShare this topic on RedditShare this topic on StumbleUponShare this topic on Twitter
Author Topic: Better living through random numbers...  (Read 892 times)
0 Members and 1 Guest are viewing this topic.
Feline
Alien
***
Posts: 29


« on: April 01, 2016, 08:37:46 PM »

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


* OldRand.jpg (125.66 KB, 1530x374 - viewed 145 times.)

* NewRand.jpg (119.79 KB, 1530x374 - viewed 139 times.)
Logged
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #1 on: April 02, 2016, 05:13:38 AM »

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

 A Beer Cup
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #2 on: April 02, 2016, 06:05:02 AM »

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)


* cloudbug1.jpg (6.32 KB, 400x256 - viewed 252 times.)

* cloudbug2.jpg (5.14 KB, 400x256 - viewed 250 times.)

* cloudbug3.jpg (9.46 KB, 400x256 - viewed 248 times.)
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
Syntopia
Fractal Molossus
**
Posts: 681



syntopiadk
WWW
« Reply #3 on: April 02, 2016, 09:43:25 AM »

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/

Logged
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #4 on: April 02, 2016, 07:48:10 PM »

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

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
Feline
Alien
***
Posts: 29


« Reply #5 on: April 04, 2016, 02:56:35 AM »

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...
Logged
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #6 on: April 04, 2016, 03:44:47 AM »

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 wink thanks Feline  A Beer Cup

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

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
Roquen
Iterator
*
Posts: 180


« Reply #7 on: April 04, 2016, 10:36:50 AM »

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

All code submitted by me is in the public domain. (http://unlicense.org/)
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #8 on: April 06, 2016, 04:09:14 AM »

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


* cloudbug4.jpg (12.44 KB, 400x256 - viewed 204 times.)
« Last Edit: April 06, 2016, 06:15:42 AM by 3dickulus » Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
Roquen
Iterator
*
Posts: 180


« Reply #9 on: April 06, 2016, 10:15:35 AM »

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?
Logged

All code submitted by me is in the public domain. (http://unlicense.org/)
3dickulus
Global Moderator
Fractal Senior
******
Posts: 1558



WWW
« Reply #10 on: April 07, 2016, 05:13:59 AM »

@Roquen ty smiley

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  A Beer Cup

* CloudBug_Files.zip (19.27 KB - downloaded 62 times.)
Logged

Resistance is fertile...
You will be illuminated!

                            #B^] https://en.wikibooks.org/wiki/Fractals/fragmentarium
Roquen
Iterator
*
Posts: 180


« Reply #11 on: April 07, 2016, 10:40:47 AM »

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

All code submitted by me is in the public domain. (http://unlicense.org/)
Pages: [1]   Go Down
  Print  
 
Jump to:  

Related Topics
Subject Started by Replies Views Last post
The Living Fractal Movies Showcase (Rate My Movie) mnih 5 1457 Last post October 02, 2009, 07:51:08 AM
by john.peterson1982
Living ornaments Fractal Fun KRAFTWERK 0 1052 Last post March 26, 2010, 11:55:08 AM
by KRAFTWERK
Not all random numbers are equaly random General Discussion Alef 10 2769 Last post October 10, 2013, 11:25:27 PM
by Roquen
Living in a box Ultrafractal Jimmie 0 422 Last post January 15, 2014, 10:22:56 PM
by Jimmie
CUDA random numbers for threads Programming kubinator4321 5 1006 Last post January 29, 2015, 04:10:13 PM
by ker2x

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM
Page created in 0.218 seconds with 28 queries. (Pretty URLs adds 0.016s, 2q)