FastNoiseLite: a portable noise library with 16 language ports

What FastNoiseLite actually replaces

Most projects that need procedural noise end up with one of three things: a hand-rolled Perlin function copied from a blog post, a dependency on a large noise framework, or a shader-side implementation that does not match the CPU-side one. FastNoiseLite targets the first and third cases. The README describes it as "an extremely portable open source noise generation library with a large selection of noise algorithms" that focuses on "high performance while avoiding platform/language specific features, allowing for easy ports to as many possible languages".

The audience is therefore people who need the same noise values from more than one place. A terrain generator written in C# that must agree with a heightmap shader in HLSL. A Java server that seeds a world and a JavaScript client that previews it. A Rust game tool that exports noise textures which a GLSL renderer later re-samples. Because the library avoids language-specific features, the ports are meant to produce matching output rather than merely similar-looking output.

It is not a world generator, not a texture packer, and not a mesh tool. It returns floating point values for coordinates you supply. Everything above that layer is your code.

The noise algorithms and fractal options in the box

The feature list is short and worth reading literally. 2D and 3D sampling. OpenSimplex2 and OpenSimplex2S. Cellular, also called Voronoi. Perlin. Value. Value Cubic. Two domain warp modes, one built on OpenSimplex2 and one a basic grid gradient warp. Every one of those can be combined with multiple fractal options, and the library supports floats or doubles depending on how you compile it.

That set covers the usual terrain, cloud, cave and texture work. OpenSimplex2 is the general-purpose choice; OpenSimplex2S is the smoother variant. Cellular gives the cell-shaped patterns visible in the repository's example images, and the README shows it both plain and as a fractal. Value Cubic comes from the CubicNoise project credited at the bottom of the README, and it produces a rounder look than plain value noise.

The fractal layer is what most users actually touch. Instead of sampling one octave, you configure octaves, and the library sums them. The README's example images show a ridged fractal and a warped cellular fractal, which are the two configurations people reach for when plain fractal noise looks too uniform. The domain warp options exist for the same reason: they break up the directional artifacts that appear when you stretch noise along an axis.

How the porting model shapes the API

FastNoiseLite is not one library with bindings. It is a set of parallel implementations under separate directories in the repository: CSharp, Cpp, C, HLSL, GLSL, Go, Java, JavaScript, Rust, Fortran, Zig, PowerShell, Odin, Haxe, Pascal and GML. The README credits individual contributors for most of them, which tells you how the project grows: someone needs the library in a language it does not cover, writes a port, and opens a pull request.

This has two consequences. The first is that the API surface is intentionally small and similar across languages, because a port is easier to write when the original is plain. The second is that the ports are not guaranteed to be at the same revision. The README's contributing section says the maintainer is "not an expert or even familiar with every language FastNoise lite has been ported to", which is an honest statement about where review attention goes. If you depend on a less common port, read its directory rather than assuming it tracks the C# or C++ version.

For shader work the same model applies. HLSL and GLSL ports exist so that a renderer can sample noise without a round trip to the CPU. The trade-off is that shader ports are typically a subset: you get the noise functions, but configuration is your responsibility.

Installing FastNoiseLite and generating your first noise field

There is no single install command, because installation depends on the language port you pick. The README points to a wiki page titled Getting Started and a Documentation page for the general workflow, and each language directory contains the source you copy or import. Two ports are published to package registries: the JavaScript and TypeScript port is on npm as fastnoise-lite, and the Rust port is on crates.io as fastnoise-lite.

For the npm package, the README gives no usage snippet, so the install line is the only command it supports directly. Read the JavaScript directory for the import name and method names before writing call sites.

npm install fastnoise-lite

For C++, C, C#, Java, Go and the rest, the README gives no install instructions beyond the language directories. In those cases you vendor the source file into your project, which is consistent with the library's stated goal of being quick to integrate. The Web Preview App at auburn.github.io/FastNoiseLite is the fastest way to see what a configuration looks like before you commit it to code: it renders every feature visually and can export noise textures.

The C++ port is what the README's benchmark table was measured with, using the NoiseBenchmarking project. If you want a starting point that matches the published numbers, that is the directory to read first.

Where the benchmark table stops being in your favour

The README publishes a performance table measured with the C++ version using the NoiseBenchmarking project, on an Intel 7820X at 4.9GHz, Windows 10 x64, compiled with clang-cl 10.0.0 at -O2. The numbers are millions of points of noise per second, higher is better.

Read the table carefully, because it contains the library's main limitation in plain sight. In 3D, FastNoise Lite reaches 64.13 for value noise and 47.93 for Perlin. FastNoise 2 with AVX2 reaches 494.49 and 261.10 on the same rows. That is roughly an order of magnitude, and it is not a tuning difference: FastNoise2 uses SIMD, which FastNoiseLite deliberately avoids because SIMD is exactly the kind of platform-specific feature that makes porting hard. The README says as much, recommending FastNoise2 "if you are looking for a more extensive noise generation library" and noting it "provides large performance gains thanks to SIMD".

The comparison with the legacy FastNoise library is more interesting, because it is not a clean win. FastNoise Lite beats legacy on value, Perlin and cellular noise, but loses on 3D simplex: 36.83 against 44.74. The asterisk in the table marks OpenSimplex against the legacy Simplex implementation, so the two rows are not measuring the same algorithm. If your workload is dominated by 3D simplex sampling, the newer library is not automatically the faster one.

Against libnoise and stb perlin the margin is large, especially for cellular noise, where libnoise drops to 0.65 million points per second in 3D.

When FastNoiseLite is the wrong tool

The clearest case against it is throughput-bound work. If you are generating voxel terrain in real time, or filling large 3D textures on a schedule, the AVX2 numbers in the README's own table describe a different class of performance. FastNoiseLite will work, but you will be paying for portability you may not need. A single-target C++ project on x86-64 has no reason to give up SIMD.

The second case is configuration complexity. FastNoiseLite exposes a flat set of settings: noise type, fractal type, octaves, and the warp options. FastNoise2 uses a node graph, which the README describes as allowing "complex noise configurations with lots of flexibility". If your noise needs to be composed, blended and modulated in ways that a flat configuration cannot express, you will end up writing that composition yourself, and at that point the library is only supplying primitives.

The third case is ecosystem. There is no Python port in the supported language list. Teams that prototype noise in Python and ship in C++ will need a different plan, whether that is generating lookup data ahead of time or reimplementing the sampling. Similarly, if your engine already ships noise, adding FastNoiseLite means maintaining a second implementation and keeping the two in agreement, which is the exact problem the library exists to solve but which you have now created for yourself.

Alternative: FastNoise2 and the engine-native option

The README names FastNoise2 directly as the alternative for heavier work. The difference in approach is architectural, not cosmetic. FastNoise2 uses SIMD instructions to process multiple points at once, and it represents a noise configuration as a node graph rather than a settings object. The benchmark table in this README puts its AVX2 path at 494.49 million 3D value noise points per second against FastNoiseLite's 64.13. The cost is portability: SIMD is platform-specific, so the language list is shorter, and the node graph is a larger concept to learn than setting a noise type and an octave count.

There is a second alternative the README does not discuss but the related searches make visible: engines that ship their own noise. Godot, for example, has a built-in FastNoiseLite resource, and the related search phrases around Godot, NoiseTexture2D and FastNoiseLite suggest that many people meet this library through the engine rather than through the repository. If you are working inside such an engine, the engine's version may be the right call, but you should check which revision it tracks, because the engine's copy will not move when this repository does.

Maintenance, licensing and the upgrade question

The repository is not archived and the last push was on 2026-06-21. Releases, however, are sparse: v1.1.1 on 2024-03-05, v1.1.0 on 2023-10-15, and v1.0.3 on 2021-02-22. The gap between the last release and the last push is over two years, which means changes are landing on master without being cut into tagged versions. If you depend on a release artefact rather than the branch, you are depending on code from March 2024.

The licence is MIT, which is permissive and short. In practice that means you can vendor the source file into a proprietary project, and the main obligation is retaining the copyright notice and permission text. The README's credits section lists contributors for individual ports and for the underlying algorithms, including OpenSimplex2 and CubicNoise; if you redistribute a port, keep those attributions intact. This is a description of the licence, not legal advice, and the LICENSE file in the repository root is the authoritative text.

Upgrade cost is low by design. The API is a small set of settings and sampling calls, and the library has no runtime dependencies to reconcile. The real cost is drift between ports: if you use the C# port on the server and the HLSL port in the shader, an upgrade means updating both and confirming they still agree. The Web Preview App is the practical way to check that, since it renders a configuration visually and can export the result for comparison.

Editorial conclusion

Adopt FastNoiseLite when you need one noise implementation that behaves identically across a CPU language and a shader language, and when your noise budget is a few million samples per second. Do not adopt it if you need SIMD throughput, a node-graph configuration, or a Python binding, because the README lists neither FastNoise2's AVX2 path nor a Python port. Before committing, verify that the port for your language exists in the repository tree, that your engine is not already shipping its own noise implementation, and that your target sample rate is below the published benchmark figures.

Frequently asked questions

Official sources

1. Auburn/FastNoiseLite on GitHub
2. License: MIT
3. Project website
4. README
5. Releases