# Procedural Terrains: a browser terrain studio that exports to Unity, Unreal and Godot > ZyFou/ProceduralTerrains evaluates height, normals and biome colors on the GPU inside a React and Three.js editor, then bakes GLB, OBJ and engine presets. It suits teams that want to author terrain visually and hand a file to an engine, not teams that want a runtime terrain library. **ZyFou/ProceduralTerrains** — Three.js procedural terrain generator with tile, infinite world, planet mode, volumetric clouds, realistic water and GLB export. - Repository: https://github.com/ZyFou/ProceduralTerrains - Website: https://procedural-terrains.com - Stars: 619 · Forks: 78 - Language: JavaScript - License: MIT - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/zyfou-proceduralterrains ## What Procedural Terrains is for, and who ends up using it The project describes itself as GPU-driven terrain authoring for the browser, with native integrations for Unity and Blender. That single sentence sets the boundary. This is an authoring tool, not a runtime. You open a React and Vite application, shape terrain in one of three world modes, and export baked assets that another engine consumes. The three modes target different jobs. Tile is for authoring and export: a fixed board with multi-tile layouts, paint brushes and close-range detail. Infinite World is for exploration, with streamed chunks around the camera and first-person walking. Planet generates a cube-sphere world with atmosphere, volumetric clouds and orbit controls. If your deliverable is a terrain mesh plus masks for an engine, Tile is the mode that matters. The audience is therefore narrow but real: level designers and technical artists who want a visual editor without installing a desktop DCC tool, and small teams that need to move terrain between Unity, Unreal, Godot, Blender and a Three.js viewer without rebuilding the same heightmap five times. The renderer-neutral .ptrterrain runtime document and the production ZIP exports are the mechanism that makes that possible. What it is not: a library you import into your game to generate terrain at runtime. The README documents an editor, plugins and export presets. Nothing in it describes a runtime streaming component for Unity or Godot, and the Unity package is described as creating native TerrainData, colliders and generation recipe assets, which is an import-time result rather than a runtime system. ## How the GPU noise stack and the export bake actually work The README states that height, normals and biome colors are evaluated on the GPU, so the live view stays editable without relying on a baked CPU heightmap. That is the architectural decision the rest of the tool hangs on. Instead of generating a heightmap array on the CPU, uploading it as a texture, and regenerating whenever a parameter changes, the editor compiles parameters into GLSL and lets the fragment stage do the work. The Noise Stack is the authoring surface for that. It is described as a set of typed, serializable noise layers that compile to GLSL. Typed and serializable are the two words worth noticing: layers survive a save and reload, and they can be written into project files and export metadata rather than living only in memory. Each layer presumably maps to a function call in the generated shader, which is why the editor can offer live shader parameters and settings search without a re-bake on every slider move. Export is the second half. The Export panel offers quick screenshots and heightmaps plus production presets for Unity Terrain, Unreal Landscape, Godot Terrain3D, Blender Scene and Three.js viewer assets. A full ZIP can contain GLB or GLTF or OBJ terrain meshes with configurable resolution, skirts and base slabs; baked color, normal, heightmap, biome splat and collision maps; water surface meshes with depth, shoreline and foam masks; and terrain.json, project.ptrterrain and preset metadata. The Production Check runs before the GPU bake and flags high-memory maps or missing water masks. That ordering matters. It means the tool tries to catch an export that will blow up memory or produce a water surface with no corresponding mask before spending time on the bake, rather than after writing a large ZIP. ## Install and first run: npm run dev on port 6061 The README gives a two-command quick start. Install dependencies, then start the Vite dev server. Both commands run from the repository root. ```bash npm install npm run dev ``` Open http://localhost:6061. Vite listens on all interfaces and prints a LAN URL, so a second machine on the same network can reach the editor. If port 6061 is already taken, Vite selects the next available port, which means the URL you were told to expect may not be the one you get. Check the terminal output rather than assuming. For a production build, the README gives two more scripts. The first builds the static bundle, the second serves it locally for a check. ```bash npm run build npm run preview ``` The editor is local-first and fully usable without an account. Login and registration come from an independent, self-hostable Node.js and MySQL service in the api/ directory. If you do not need accounts, skip it entirely. If you do, the README lists the setup sequence, including copying both environment files and running the migration once MySQL is configured. ```bash cp .env.example .env cp api/.env.example api/.env npm --prefix api install npm run dev npm run dev:api ``` The example environment file defines VITE_API_URL, which defaults to http://localhost:6062/api/v1 in local development, and VITE_DISTANT_URL, which the environment file says is the remote API preselected by the packaged Windows application on its first launch. There is also VITE_GEOCODING_SEARCH_URL, which the example points at the public Nominatim search endpoint and which must implement Nominatim-compatible /search query parameters. That last variable is what the Real terrain map search uses, so a self-hosted or restricted geocoder needs to speak the same query shape. A reasonable first real use is a small tile export. Start the dev server, pick Tile mode, adjust the Noise Stack until the silhouette reads the way you want, then open the Export panel and choose a preset. Watch the Production Check output before you confirm: it is the step that reports high-memory maps and missing water masks. The Unity workflow in the README is four steps, and the third one happens inside Unity rather than the browser: open Window > Procedural Terrains > Terrain Importer and import the ZIP, or use Create to generate seeded terrain natively. ## Where the tool stops: runtime, engine versions and plugin maturity The clearest limitation is the one already implied by the architecture. Everything the README describes happens at authoring and export time. There is no documented runtime terrain component that streams chunks inside a shipped Unity, Unreal or Godot build. If your game needs terrain generated or paged while the player moves, this tool gives you the baked result, and the streaming logic is your problem. The Infinite World mode is an editor exploration mode with FPS walking and plane controls, not a runtime system you ship. Version requirements are the second constraint. The Unity integration is listed at 0.3.0-alpha.1 and requires Unity 6000.3 or newer. The Blender extension is 0.3.3 and requires Blender 5.2 or newer. Those are demanding floors. A studio on an older Unity LTS or Blender 4.x cannot use the plugins as documented, and the alpha label on the Unity package is a signal about how much the API surface should be trusted in a pipeline you depend on. The README also points elsewhere for the truth on the plugins. It directs readers to the Unity package README and changelog for current limitations and release details, and to the Blender extension README for installation, coordinate mapping and performance guidance. That is a reasonable thing for a monorepo README to do, but it means the top-level document does not tell you what the plugin limitations are. You have to open those files. Finally, the production ZIP contents are described in a list, not in a schema. terrain.json, project.ptrterrain and preset metadata are named, and the Blender extension README is cited for coordinate mapping, but the top-level README does not document rollback, version compatibility between export packages and plugin versions, or what happens when a newer editor writes a ZIP an older plugin reads. Treat export packages as a versioned artifact you should test against the plugin build you actually ship with. ## How it differs from Gaea, World Machine and engine-native terrain The obvious comparison is desktop terrain authoring software such as Gaea or World Machine. Those are native applications that run a node graph on the CPU or a GPU compute path and write heightmaps and masks. Procedural Terrains runs in a browser tab, evaluates noise on the GPU in the live view, and keeps projects local-first in the browser with versioned projects, thumbnails, templates and recent-project history. The practical difference is friction and platform: no installer, no licence server, and a LAN URL you can hand to a colleague. The cost is that you are inside a browser tab and a WebGL context, and the export pipeline is the only bridge to your engine. The second comparison is engine-native terrain. Unity's own terrain tools, Unreal Landscape, and Godot's Terrain3D addon all let you sculpt and paint inside the engine, and the export presets here target exactly those formats. If your team already lives in one engine and only needs that engine, the native path avoids a conversion step entirely. Procedural Terrains earns its place when the same terrain has to reach more than one engine, or when the noise authoring is the part you care about and the engine is just the destination. The renderer-neutral .ptrterrain document and the shared import path in both plugins are the features that address that case. A third comparison is code-first procedural generation, typically a noise library plus a mesh builder in your own engine. That approach gives you full control over the runtime and no export step at all, at the cost of building every brush, mask and preview yourself. Procedural Terrains is the inverse trade: a visual editor and a bake pipeline now, and no runtime story later. ## Licence, maintenance and the upgrade cost you are taking on The repository is MIT licensed. For the editor source that is straightforward: you can use, modify and redistribute it, subject to the usual attribution and warranty terms. The nuance is in the plugins. The Unity package and Blender extension are checked into the same repository under plugins/, and the README does not state a separate licence for them. If you plan to redistribute a plugin inside a commercial product rather than use it internally, read the plugin directories and their own README files rather than assuming the root LICENSE covers everything. This is a description of what the repository shows, not legal advice. The repository is not archived, and the last push was on 2026-09-17, so the codebase is being touched. The most recent release listed is v1.7.1, dated 2026-09-01, while package.json declares version 1.8.3. That gap is normal for a project that tags builds separately from the editor package, but it means the version you see in package.json is not the version of the Windows build on the releases page. Check both when you file a bug. Upgrade cost concentrates in the plugins. The Unity integration is an alpha, and the Blender extension targets Blender 5.2 or newer, so a Blender version bump can invalidate the extension. Export packages carry metadata and preset information, and the README does not describe a compatibility contract between package format and plugin version. In practice that means re-testing an export against a new plugin build rather than assuming forward compatibility, and pinning the plugin archive from public/downloads/plugins/ alongside the editor version you standardised on. ## Conclusion Adopt it if you need to author terrain visually in a browser and hand a baked ZIP to Unity, Unreal, Godot, Blender or a Three.js viewer, and if you accept that the Unity plugin is published as 0.3.0-alpha.1 and the Blender extension needs Blender 5.2 or newer. Skip it if you want a runtime terrain library that streams chunks inside a shipped game, because nothing in the README describes a runtime component for your engine. Before committing, run npm run dev and check that port 6061 is free on your machine, then open the Export panel and read the Production Check output for the map sizes you intend to bake. ## FAQ ### What is procedural generation for terrain? It means the terrain shape is computed from parameters and noise rather than sculpted by hand. In Procedural Terrains the Noise Stack composes typed, serializable noise layers that compile to GLSL, and height, normals and biome colors are evaluated on the GPU so the live view stays editable. ### What does procedurally generated mean in this project? The README uses the term for terrain derived from a noise stack rather than a baked CPU heightmap, and for natively generated terrain in the Unity and Blender plugins. The Unity package can create seeded TerrainData from a generation recipe, and the Blender extension can create editable procedural meshes. ### How to make procedural terrain generation in Unity with Procedural Terrains? Download the Unity ZIP or add the local package through Unity Package Manager, then choose the Unity Terrain export preset in Procedural Terrains. In Unity, open Window > Procedural Terrains > Terrain Importer and import the ZIP, or use Create to generate seeded terrain natively. The package requires Unity 6000.3 or newer and is published as 0.3.0-alpha.1. ### Is procedurally generated terrain considered AI? The README does not describe any AI or machine learning component. Terrain here comes from a noise stack of typed, serializable layers compiled to GLSL, and from seeded generation recipes in the plugins. ## Sources - [License: MIT](https://github.com/ZyFou/ProceduralTerrains/blob/main/LICENSE) - [Project website](https://procedural-terrains.com) - [README](https://github.com/ZyFou/ProceduralTerrains/blob/main/README.md) - [Releases](https://github.com/ZyFou/ProceduralTerrains/releases) - [ZyFou/ProceduralTerrains on GitHub](https://github.com/ZyFou/ProceduralTerrains) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zyfou-proceduralterrains