On Friday, 3 January 2014 at 18:23:23 UTC, monarch_dodra wrote:
> On Friday, 3 January 2014 at 17:41:48 UTC, Jeroen Bollen wrote:
>> On Friday, 3 January 2014 at 13:42:19 UTC, monarch_dodra wrote:
>>> On Friday, 3 January 2014 at 13:30:09 UTC, Jeroen Bollen wrote:
>>>> I already considered this, but the problem is, I need to smoothen the noise, and to do that I need all surrounding 'checkpoints' too. This means that it'll have to load in 5 at a time.
>>>
>>> I don't see that as a problem. Just because you can load sub-regions at once, doesn't mean you are limited to only loading one at a time.
>>
>> That still means that out of 5 million pixels loaded, only 1 million 4 thousand will be used. I guess I can recycle them though.
>
> You could also do a "subdivision" approach:
>
> First, a table that contains seeds for 1Kx1K blocks... However each seed is designed to seed 10000 new seeds, to generate 10x10 blocks (for example).
>
> This way, you can first load your big 1Kx1K block, and then 400 10x10 blocks. Seems reasonable to me.
>
> I don't know exactly how big your data is, so your mileage may vary. Depending on your algorithm, you may have to adapt the numbers, or even amount of subdivisions.

What generator would be most fitting for this? The Documentation says the "MersenneTwisterEngine" is an 'overall' good one. I decided to go with blocks of 32*32, which all require to be filled with an unsigned byte.

Also where is UIntType defined?

On Saturday, 4 January 2014 at 20:16:31 UTC, Jeroen Bollen wrote:
> Also where is UIntType defined?

Alright, turns out it was just a template.

One more question though, I have my Engine set to have 'ulong' as a seed through the template, which means that it'll also return 'ulong' as a result. Is there a way to have it take 'ulong' as a seed, and output 'ubyte'? Divisions for every result would be expensive, and shifting the output wouldn't return a uniform distribution.

Jeroen Bollen:

> Divisions for every result would be expensive, and shifting
> the output wouldn't return a uniform distribution.

If the ulong is uniform, then every of its ubytes is uniform. So "& ubyte.max" could suffice. If that's not good enough for you, then you can xor together the eight ubytes of the ulong with some masking & shifts :-)

Bye,
bearophile

On Saturday, 4 January 2014 at 21:48:02 UTC, bearophile wrote:
> Jeroen Bollen:
>
>> Divisions for every result would be expensive, and shifting
>> the output wouldn't return a uniform distribution.
>
> If the ulong is uniform, then every of its ubytes is uniform. So "& ubyte.max" could suffice. If that's not good enough for you, then you can xor together the eight ubytes of the ulong with some masking & shifts :-)
>
> Bye,
> bearophile

Oops yeah sorry, I was thinking there is more chance to get a small number and thus more chance for there being zeros up front, but actually there is as much chance due there being as many numbers started with 1 as with 0. Thanks for the help. :D

On Thursday, 2 January 2014 at 20:38:10 UTC, Jeroen Bollen wrote:
>
> Is it good to re-seed a generator for every coordinate, will this be performance intensive? Is there maybe way to easily implement Generator.at(uint x) in D?

http://www.valion-game.com/337/noise-functions-to-generate-landscapes/

I successfully implemented a D version of the above for my toy voxel engine project.
I will be happy to share it ( it's currently not uploaded anywhere ).

How do you correctly create a MersenneTwisterEngine with a ulong as seed?

On Wednesday, 15 January 2014 at 21:00:57 UTC, Jeroen Bollen wrote:
> How do you correctly create a MersenneTwisterEngine with a ulong as seed?

If you are trying to create a very large 2D noise generator, this is how you do it, and you can any degree of smoothness you want:

Create a 2D RNG.

e.g.,

RND2D(x,y) { seed(S + x + N*y); return rand; }


You could use this to generate your whole map very predictably up to the seed length(at some point it will repeat because of the finite size of the seed).

If you have any degree of smoothness you do not want to use this per point unless you do want to have some "noise" which could be controlled by weighting the RND2D function so intergrid points are not so random:


RND2D(x,y, xS, yS)
{
    s = RND2D(x,y)
    sm1m1 = RND2D((int)(x/xS) - 1, (int)(y / yS - 1));
    sm1m1 = RND2D((int)(x/xS) - 1, (int)(y / yS + 1));
    ...
    return interpolate(s, x, y, sm1m1, sm1p1, ...);
}

where interpolate returns the modified seed that is partially based on the seed at the point x,y and partially an interpolation value between the sub grid points.

Anyways, now that you have your RND2D you don't ever have to pre-generate your noise. Obviously it is more computationally expensive though.

I guess this was the function you were looking for before if I now understand what you are trying to do?

On Friday, 3 January 2014 at 13:39:41 UTC, Andrea Fontana wrote:
> On Friday, 3 January 2014 at 01:01:21 UTC, Frustrated wrote:
>> On Thursday, 2 January 2014 at 20:38:10 UTC, Jeroen Bollen wrote:
>> [...]
>> e.g.,
>>
>> seed(k);
>> for(i = 1..10)
>> print(rnd(i));
>>
>> and
>>
>> for(i = 1..10)
>> {
>> seed(time);
>> print(rnd(i));
>> }
>>
>> will both produce random sequences of numbers(and random sequences of numbers are "identically random".
>> [...]
>
> The second example is error-prone. If "time" var doesn't change between cycle, it's not random at all.

Wrong, in this example I'm using rnd(i) as having a seed i. Obviously, I'm not using i as an interval.

i still changes per iteration of the loop so rnd still changes. (if I did not seed the rnd I would not have used rnd(i) but rnd;)

i.e.,

for(i = 1..10)
{
seed(time);
print(rnd(i));
}

and

for(i = 1..10)
{
seed(time);
print(rnd);
}

are different

but my example could easily have been written as

for(i = 1..10)
{
seed(time+i);
print(rnd);
}

which may be more obvious. The point of writing it the first way was to try to make it more clear about actually changing the seed vs the ith random number. (the seed changes the sequence of random numbers to another sequence but rnd returns the ith value in the sequence which is ultimately cyclical)

On Wednesday, 15 January 2014 at 21:23:03 UTC, Frustrated wrote:
> Anyways, now that you have your RND2D you don't ever have to pre-generate your noise. Obviously it is more computationally expensive though.

Thing is, the image is finite so I figured it'd be best to pre-generate a set of seeds, and then when I need a certain chunk of pixels simply quickly generate that one, like already suggested in this topic.