Rename Perlin noise to (fractal) value noise

[kno10]

Fixes #15775: rename Perlin noise to (fractal) value noise, which is what is actually implemented.

I tried to add aliases for the old names. But I'm not sure what is the best way to generate a deprecation warning for the global lua classes such as PerlinNoise and PerlinNoiseMap, don't want to break anything. But these old names are probably not going to be removed the next 5+ years anyway...
This needs to be fine-tuned by an expert on the Luanti Lua API.

In the future, actual Perlin noise or simplex noise could then be added for new mapgens.
For example the fast https://github.com/Auburn/FastNoise2 library is C++ and MIT licensed.

See also:

• Consider simplex noise instead of/in addition to classical Perlin noise #11468
• Calculation of the Perlin noise derivatives (gradients). #14635

[wmikita]

I suggest turning this into two sentences:

Value noise creates a continuously-varying value depending on the input values.
It is similar to Perlin noise, but interpolates between random values instead of
gradient vectors.

1. both 'simple' and 'fast' generally have positive connotations, so negating one over the other using 'but' reads unnatural
2. I'd argue that performance is not a property of the noise itself, but of its implementation, even though a noise itself can be designed to be easier on compute. keep in mind I'm not an expert though :p

[kno10]

Performance is supposedly higher, because interpolating between values is simpler than interpolating gradients.
But it will likely be a small constant. In the FastNoiseListe benchmarks, 2D value noise is about 16-24% faster than Perlin noise across three implementations.

[wmikita]

@sfence this specific PR does not break any API compatibility, it simply introduces a deprecation due to a rename

[sfence]

@wmikita Valid point for get_perli, not for PerlinNoise if I see well.

[wmikita]

@wmikita Valid point for get_perli, not for PerlinNoise if I see well.

global Lua-facing classes aren't touched here yet. the idea is to generate a deprecation warning when somebody tries to use them, similarly to get_perlin and get_perlin_map

[sfence]

@wmikita My error, I missed line lua_register(L, "PerlinNoise", create_object); // deprecated name

[grorp]

As far as I can see:

• You're planning to add perlin and simplex noise in a follow-up PR: Add Perlin and Simplex noise #15877
• You're planning to have them use the same API (that actually seems like a good idea to me, can avoid code and "concept" duplication)

So why are you renaming these APIs to "value noise" here then? That will be obsolete again with your follow-up PR.

[kno10]

@grorp:

You're planning to add perlin and simplex noise in a follow-up PR: Add Perlin and Simplex noise #15877

I did not plan that when I created this pull request.

You're planning to have them use the same API (that actually seems like a good idea to me, can avoid code and "concept" duplication)

It's ugly and limiting though. Only a subset of the FastNoiseLite library currently used is available this way.
I am all but convinced that this is the best way to proceed. A new mapgen may need to design a new noise API to better make use of additional features.

The integration into the old noise API primarily serves the purpose that people can see the difference between the noise quality generated for an actual mapgen, in-game.

So why are you renaming these APIs to "value noise" here then? That will be obsolete again with your follow-up PR.

It will be only obsolete if that second pull is merged as is, and we do not end up making a much better noise API.
ValueNoise is a decent name for the old API; and as stand-alone pull request, this still makes sense.

[grorp]

I did not plan that when I created this pull request.
[...]
It will be only obsolete if that second pull is merged as is, and we do not end up making a much better noise API.

I suppose what you'll have to figure out is: what are the plans for these noise APIs and your second PR? Will a separate general noise API actually happen (this rename would then make sense), or will the current API become the general one (should choose a different name then)?

The reason to think about this now is that we shouldn't end up renaming and still having an inaccurate name, or even renaming twice.

[kno10]

@grorp I don't think I would suggest to do it the way the second pull hacks noise into the existing API via flags.
Hence this pull here makes sense: we won't be able to get rid of the old noise for compatibility, but it is not Perlin.

[sfence]

Looks fine, and works as expected.

[sfence]

Why is this code block in deprecated.lua and env.lua at the same time?

[kno10]

I understood the emerge/env to only apply to the voxel manipulator emerge context, whereas builtin/game seemed to apply to the entire game context.
Maybe this could be better documented.

[appgurueu]

Yes, this is fine.

[appgurueu]

i have some minor suggestions, but nothing which really needs something to be done about it.

the reason i originally wanted this to be no squash is because while the C++ renames should be pretty uncontroversial ¹, the Lua api deprecations are trickier, so i wanted that in a separate commit. but now that the warnings are gone it's fine.

the "new" aliases don't need to support the deprecated multi-param calls (but i can see why it might be more convenient to keep them, so 🤷)

the docs should probably mention that the new aliases are 5.12+? ²

Footnotes

1. why no mention of the fact that it's value noise in the C++ names? i suppose this is to facilitate adding perlin noise later? ↩

2. not sure if we have a policy on this. in principle modders should use the docs corresponding to the luanti version they are targeting, but we typically include such version numbers nevertheless ↩