FastNoise VS open-builder

If you go to the FastNoiseLite github you'll see there's a FastNoiseLite.glsl file, this file contains the entire library. So to use this in a shader we need to use the new shader #inlude preprocessor. In short, create a new ShaderInclude resource, paste the contents of the FastNoiseLite.glsl file into it and then simply #include it in your shader.

FastNoiseLite: ValueNoise, OpenSimplex2, OpenSimplex2S, Perlin, ValueCubic (from https://github.com/Auburn/FastNoiseLite )

Fair enough. If it helps, you can drop this into a P5.js sketch without too much friction: https://github.com/Auburn/FastNoiseLite/tree/master/JavaScript

I suppose I'll compile what I can find here for future searchers: Here's the original github for FNL , it has some images to use as examples but few explanations unless you want to download and run the preview program yourself.

Also take a look at FastNoiseLite if you want better control over noise generation, and for cool examples.

I used this repo: https://github.com/Auburn/FastNoiseLite

Yeah, that's literally what a seed does. It's really odd to me that the unity mathematics one doesn't have a seed. I use this one: FastNoiseLite

I really like this library which appears to have gals implementation. https://github.com/Auburn/FastNoiseLite

For the actual dunes I used fast noise lite ( https://github.com/Auburn/FastNoiseLite ). They have a nice gui app, where you can create noise textures (in my case voronoi noise). Then I apply the height map to the individual terrain tiles. So no fancy procedural Generation is going on here.

Another method I think I noticed (probably not, not really sure what I'm talking about) is from Hopson97's open-builder game open-builder/chunk_vertex.glsl at master · Hopson97/open-builder · GitHub where texture coords are stored in the vertex shader. Would the idea for other block types for the above method to have a 2d array of the other block types textures like doors etc? Not sure about this method cause doesn't this require a vertex buffer which the "figured out an optimization" guy says is slow. If so that doesn't seem very sustainable.

For example, in this Notch article, he discussed using trilinear interpolation to speed up noise evaluation as well as to smooth out rough parts. But I tested, and both of his problems actually came mostly from using too many noise octaves. Minecraft used 16 octaves for each noise channel, and 8 octaves for the blending noise, when just 5-6 and 2-3 would be enough. The rest of the speed problems could be solved by implementing something to skip noise evaluations when they wouldn't matter, at least above/below max/min biome height if not dynamic octave skipping. See this screenshot difference.