Seeds

[dsheets]

Provide a means to seed noise generators

[stegu]

The "fake" way of doing this is to add a constant offset to one or
more coordinates at the user call to the noise function. At the
cost of one extra addition, this is a useful replacement for a real
"seed" for the use cases I have seen.
Other ways of adding a seed would add complexity and slow down
the function, and I think speed is absolutely crucial. Performing a
final churn through the permutation polynomial with a "seed" offset
added to the final index would probably do what you want, but it
would be too costly for my purposes.
Can you elaborate on where a seed would be needed, and why
adding an offset to either of the input coordinates would not do
the trick? It's not difficult to write an alternate function that does
the extra permutation with a seed, but I am hesitant to write a
function that is unnecessarily slow.

[dsheets]

This feature wish came from @pyalot so perhaps he can speak to the appropriateness of translating the sample window for his application.

Perhaps a constant macro for permutation group offset would suffice? Macro parameters will soon be first-class module parameter constructs so this would give us A.) no cost and B.) easy parameterization once glol has been polished a bit more.

The down-side is a new shader program for each seed+effect combination but this isn't too bad as A.) the seeds will probably be generated in an authoring tool for aesthetic sampling and B.) seed state transitions aren't smooth.

How would you feel about the abstraction of the polynomial parameters into constant macros?

[pyalot]

I don't want to have to attach your whole preprocessor just to set a seed value.
A macro is also not useful, at all for the following reasons:

1. The seed may be passed into a uniform
2. It may come from a texture
3. It may come from a calculation (such as octave depth etc.)

[dsheets]

I don't want to have to attach your whole preprocessor just to set a seed value.

I was not suggesting you do that. I was merely pointing out that macros can be dynamic with sufficient software. You may use your own pre-preprocessor or manually set the value.

Please, answer Stefan's question: Can you elaborate on where a seed would be needed, and why
adding an offset to either of the input coordinates would not do the trick?

A macro is also not useful, at all for the following reasons:

1. The seed may be passed into a uniform

Why? The seeded permutation is a finite group. Is generating a new shader insufficient? Regardless, pre-preprocessors exist which can fulfill a symbolic dependency by either macro or uniform. The crucial aspect is the penalty-free abstraction for your (undeclared) application.

2. It may come from a texture

Directly in a single shader? What's the use case?

3. It may come from a calculation (such as octave depth etc.)

Where is this calculation? Why is the seed changing frequently?

[pyalot]

It doesn't matter, you don't have to understand why. The fact is that fix-compiled seeds are utter fucking crap period.

[dsheets]

You seem to have a problem with reading comprehension and professional communication.

Seeding/initialization at each compilation stage (including run-time) is possible. Putting penalty-free methods into the distributed source gets us a common interface to noise parameters.

Is there a reason that an offset to the input coordinates does not satisfy your use case?

[pyalot]

An offset into periodic noise is periodic.

[stegu]

Yes, but the period is long and unnoticeable for the use cases I can
imagine. Also, simplex noise has a grid that is not axis-aligned.
What is your reason to require this level of statistical randomness
instead of the apparent randomness that is OK for other cases?

Please understand that I am not being a pain, I seriously want to know.
Despite the fact that you are asking for a service by calling our hard work
"utter crap", I am perfectly willing to provide a seed-enabled version (with
some extra computational cost) if you can explain to me why you need it.
It's not a lot of work, it's just that I don't want to fork and fragment the code
without a good reason. There are already quite a few different functions to
maintain here.

If you don't feel like explaining this more clearly to a person really wanting
to learn, you can add a seed yourself. Make an additional permutation of the
gradient index value just before you do the gradient lookup, after adding an
integer seed, and you should be all set. In the 2D simplex noise version,
you would do it right after this line:

vec3 p = permute( permute( i.y + vec3(0.0, i1.y, 1.0 )) + i.x + vec3(0.0, i1.x, 1.0 ));

by inserting the following line:

p = permute(p + vec3(seed));

where 'seed' is an integer value (stored as a float for compatibility).
A vec3 seed with three different values could also be useful
if you want more than 289 distinct noise fields. Using different
values for the components will get you 289^(N+1) fields for N-D
simplex noise, and 289^(2^N) for N-D classic noise, although fields with
at least one seed component in common will be partly correlated.
If you plan on using large seeds (larger than about 100), change that
extra line to:

p = permute(mod289(p + vec3(seed)));

Quite a lot of extra computations compared to a simple offset,
but it should do what you want.

[pyalot]

@stegu My beef is with dsheets not with you. I've had a lot of this kind of counterproductive conversations with him of the kind where he keeps asking "why" and I try to explain it and it goes nowhere. So him coming on with another of the "why why why" comments makes me see red all over. And secondly, I'm not asking for this. I've told dsheets that it would be handy, he choose to agree. I can live without a seed with your library, I have other noise sources that do what I need them to do. So consider this a service to you, not the other way around. And feel free to do or not do whatever you like. And if you prefer not to, that's fine. I can't make you not publish crap. That's up to you.

So I'll explain it, this one time. A lot of noise cannot be used in realtime because of two reasons. The first reason is that sometimes the result has to be the same on every machine because it carries real meaning (such as terrain height in a game for instance). And the second reason is that sometimes you do things to noise (like convolution, sharpening, blurring or any other kind of kernel filter) that make it prohobitively expensive for instance:

• let N be the number sample points
• let M be the number of kernel samples
• One filte has a runtime of O(N*M)
• Two have a runtime of O((N*M)^2)
• X filters have a runtime of O((N*M)^X)

That means that quite often you need to bake noise (or the result of the computation) into a texture. This however has one important problem. Unbounded noise goes on forever which is nice. But baked noise has borders (the texture size). If you render unbounded noise into a texture obviously the borders will not match up. This is fine in some cases, but in others where you'd like to use this noise to provide detail it is not. The only solution to reclaim some of the quality of noise (going on forever) is to repeat the texture. Now in order do that you need repeatable noise. And while the quality of repeatable noise may not be as nice as simplex noise, it makes it feasible to bake.

So regarding the offset into the noise. The offset in repeatable noise is of course repeated. This has some nice qualities (you can choose a "soft" seed that'll wrap around) but it has some that are not so nice (you can't get a completely different pattern). For instance if you choose a size of 10x10 cells, then there's only 10 substantially different slices into that noise. Worse yet, any noise (any use you make of it) is the same, not just this one use. For artistic control it is quite often necessary to get entirely different patterns. If you only have 10 patterns to deal with and you combine them a lot, you will end up with very crappy results.

So, a real seed is one necessary component of any real noise function. I didn't think this had to be explained, but apparently it has to be explained, to the people who want to do real noise functions.

[stegu]

Thanks for the explanation. I understand your motivation perfectly now, and the change
I suggested in combination with the periodic classic noise functions ("pnoise") would
do what you suggest and give many different noise fields to choose from. However, a
very similar effect could also be achieved with a constant offset before the index wrap
in "pnoise", to cut out a different region of the full 289x289 cell field of our version of
classic noise. If you use a 10x10 cell region, you would get 28x28 independent places
to put your cookie cutter, and for larger regions, a shift of the pattern of less than the
full cookie cutter size would not be all that noticeable.

So you see, the use case really does matter a whole lot here, because it is not
immediately obvious how best to implement a seed regardless of its intended use.
I kindly ask you to consider the fact that I am a computer graphics researcher, not
a practitioner, so I need other people to tell me how they use noise, or my view will
be restricted to whatever ideas I can come up with all by myself. Research is not
meant to be performed in isolation from real world implementers. Feedback is crucial.

So, a real seed is one necessary component of any real noise function.

I really think you generalize too far here, and promote your view as the only right one.
Most publications in the field do not make any mention of a seed, much less tout it as
a necessary feature without which all noise is utter crap. Built-in noise functions of e.g.
RenderMan SL also do not contain a seed, so there is clearly some good use to be
had from a seedless noise, although admittedly under different conditions than yours.

X filters have a runtime of O((N*M)^X)

Hmm. Wouldn't that be just O(N_M_X) ? If not, what am I missing here?

Anyway, thanks for the constructive input.

[pyalot]

I might have bungled that a little, but it is an exponential.

Say you have a 16-tap kernel, so for discrete samples (N) it'll make 16 taps. So the runtime would be O(N*16).

If you access this discrete sample with the next kernel it will make 16 taps for each discrete sample. Each of which will do 16 taps. So it's O(N_16_16).

At 2 filters it's O(N_16_16_16) so the analytic runtime case is O(N_M^X).

If each filters result is stored say for two filters, then the example would be O(N_M + N_M) for two filters, O(N_M + N_M + N_M) for three and so on. So the cached runtime case is O(N_M*X).

If the produced result does not have to be changed in a frame, the runtime becomes O(1).

• analytic: O(N*M^X)
• cached: O(N_M_X)
• baked: O(1)

[stegu]

I see. Reading "filtering", I was assuming storage of dense sample sets from each step, basically
traditional image processing, or what you refer to as "cached runtime". If intermediate storage is a
problem, then yes, successive filtering becomes prohibitively costly, and the very useful shortcut
provided by kernel decomposition also gets thrown out the window if previously computed samples
from the preceding step cannot be cached and re-used.

I must say I am not really seeing when one would need to do such full-blown uncached analytic
filtering. You don't need to elaborate, but is it a common situation for you, or more of a corner
case?

[pyalot]

Successive filters are required if you do things like source -> erode -> blur -> flow -> sharpen etc.

If the desire is for a gapless product on the borders then only repeatable sources can be used. An aperiodic source precludes usage in storing intermediary results and hence would force an analytic solution.

[stegu]

I see what you mean, but I don't quite agree. Assuming yoy are rendering a bounded area of texels and that it can be meaningfully filtered with discrete convolution kernels, the function can still be sampled, stored as a texture during filtering and then scrapped. Wasteful, yes, but not exponential in complexity for many successive filters. But then again, I have no information on the exact conditions for the applications you have in mind.

Anyway, now I should implement and test that seed argument...

[dsheets]

@pyalot reported "this is your periodic 2D noise layered in 10 octaves with a lacunarity of 2 and a gain of 1" http://codeflow.org/pictures/perlin.png vs. "this is a bicubically interpolated noise from a sin/dot random source with the same parameters" http://codeflow.org/pictures/bicubic-random.png "the noise is billowy (i.e. abs(n))" and "this artifact is not as apparent when using fbm octaves, although in your noise things seem to be more regularly distributed" via freenode #webgl IRC chan and speculated "it's possible this is the artifact of a lacking seed" due to "self-similarity degradation".