Help me understand love.math.noise usage properly...

[Jasoco]

Now I know how it works. And I don't need to know why it works. I am just curious as to why and how it works. lol

Noise takes four parameters according to the Wiki. It doesn't say there's a limit to the values. They can apparently be very very large values from negative to positive.

I know the first two parameters are simple. They're normal X and Y values. According to the Wiki, the third is Z. But I don't understand what the fourth is supposed to be. The Wiki labels it as W. What does that mean? What do the Z and W parameters really do? Z is obvious, it moves in the third dimension. But W seems to do it too, but in a different way... I don't get it.

Now I created a little project to play around with the Noise function.

(Ignore the naming of the other two arguments. I named them before I checked the Wiki)

Noise supposedly always returns the same values given the same exact parameters every time. So it's not affected by love.math.setRandomSeed() at all. It will always look the same if passed (0, 0, 0, 0) like in the video above. Is this consistent across platforms like love.math.random is?

I don't even know what I'm asking really. I mean I know enough about how it works now. I just don't know how to use it well enough except for creating random detail variations in world terrain and such.

Maybe we can get a discussion going about some good uses for it.

As I understand it, pre-Biome update Minecraft versions used a sort of noise algorithm as this. Back when worlds were really random and jumbled before biomes were implemented and world generation changed completely. (I'd love to know how they do it now actually. It seems so complicated now.)

[zorg]

You could intuitively think of all 4 parameters as offsets for spacial translations; just because we live in a reality where there's only 3 orthogonal axes of space, that doesn't mean that mathematically it's impossible to design functions that work in more dimensions.

Since you already made that video, you could see that, technically, you have a 2D surface for your screen, so you could only really make sense of the x and y parameters changing; they moved the value map on the left/right and up/down axes; the z parameter moved it along the axis paralell to the line between you and your screen, so you were changing what "slice" the theoretical camera was showing you; think of it like slices in a 3D medical scan.



The W parameter is no different, except that it can't really be seen in any better way even in our 3D reality, much less on a 2D screen.


(Despite what you see, all sides remain the same lengths! )

For procedural world generation,this kind of noise function is useful; since it gives back values that are related to each other, even moreso. You select two input parameters and consistently use them for your world's x and y axes; the third should not change unless you need to generate different values for different "height" layers too; as for the fourth, that should remain the same as well for a 3D-world like minecraft's. Then again, the seed value could be distributed across all 4 of the input params.

I can't really think of a game design that would benefit from getting values from the 4D version of the noize function, unless it was like dwarf fortress, which generated world history too (but then the W-param would need to be strictly increasing in the lore-builder function)

The function's returned values iirc should be consistent across OS-es, the one thing it's not consistent is that the 1D and 2D versions use perlin noise, while the 3D and 4D ones use simplex noise (because of patent issues), but that shouldn't be a problem if you only use one version for one thing.

[slime]

You can also think of the extra dimension as time. You can animate noise in 2D over time by steadily changing the Z value of 3D perlin noise over time, and you can animate noise in 3D over time by changing the W value over time instead.

[raidho36]

The noise function simply grabs a sample from specific point you pass into it. It uses deterministic algorithm to produce the sample, as if you were sampling from a texture. And due to its nature, it can work in many dimensions, not just 1 or 2. Using 3-dimenisonal variant samples from a noise map that extends in 3 cardinal directions, 4-dimensional variant samples fro ma noise map that extends in 4 cardinal directions. You can think of it as sampling from a N-dimensional space full of noise.

Simply put, you can use more parameters to generate a noise sample.

[qwitwa]

I don't quite understand how the FFI stuff works, but it seems like love.math.noise is defined here, to reference some functions somewhere defined in C++. In the libraries part of the love codebase, you can find a folder called noise1234, which holds these files, which contain a 4 dimensional perlin noise implementation. As I say, I'm not a luajit FFI master, so I can't quite see how the C++ connects to the lua layer, but I'd assume that's what's being used under the hood.

[raidho36]

That's an alternative Lua wrapper for math library, it's active when LuaJIT is available and enabled - then using plain Lua is faster than Lua to C++ glue for trivial functions. Normal C++ wrapper loads first, then it loads Lua wrapper. It exists solely for performance reasons, don't pay too much attention to it, instead look at C++ wrapper code.

[zorg]

Let me correct my above statement a bit, löve uses 1 and 2 dimensional simplex noise, and 3 and 4 dimensional perlin, not the other way around; the reason being that 3 and 4 dimensional simplex noise is patented.

[Jasoco]

What's the real difference between peril and simplex? From an actual usage standpoint.

[zorg]

Nothing, simplex is just computationally simpler (takes less time) and has less/none of the "visually significant" directional artefacts perlin noise exhibits; You use both of them the same way.

(Also i feel like it could be either artifact or artefact; must be the mandela effect in play... :c)

[raidho36]

It's "artifact". It's a latin word, there's no alternative spelling.