ProtonScatter: procedural prop placement for Godot 4

The placement problem ProtonScatter targets

Hand-placing grass, rocks and trees across a terrain is slow, and every revision of the terrain invalidates the work. ProtonScatter exists to make that placement procedural and, in the project's own words, non-destructive: the positions are generated from rules you can reopen and edit rather than committed to the scene as fixed transforms. The README frames the add-on as automation for positioning assets, aimed at scenes with a lot of props that you would rather not place by hand.

The intended user is a Godot 4 developer working in 3D who already has the assets and the terrain, and needs volume. The README's showcase example is a composition built entirely with the add-on: large rocks are randomly placed within an area, then trees, grass and other details are projected onto the rocks' colliders. That second step matters. The add-on is not only a random point generator; projection onto existing geometry is part of the documented workflow.

How the modifier stack generates and transforms points

The architecture is a small node hierarchy. A ProtonScatter node holds the positioning rules, edited in the inspector. That panel is described as very similar to Blender's modifier stack: some modifiers create points, others change their transforms, and you mix them to reach the result you need. One or more ScatterItem nodes select which asset gets placed, and one or more ScatterShape nodes define the area where scattering happens.

That split is the design decision worth noticing. Generating points and transforming them are separate modifier categories, so a grid of points and a random cloud of points feed into the same downstream transforms. The README's examples show three ways to create points: aligned on a grid, randomly, and along an edge. Shapes come in three types, Box, Sphere and Path, and they can be combined. A shape can also be marked negative, shown in red in the editor, which means new items will not appear inside it. That is how you carve holes in a scatter region without splitting it into multiple nodes.

The README also documents uses beyond a flat floor. Mushrooms are placed in space and then projected in a random direction until they hit a tree. A tower is built by stacking individual bricks with two array modifiers. Both examples rely on the same mechanism: points are generated first, then transformed until they land where the geometry is.

Installing ProtonScatter and scattering a first object

The README gives two installation paths. Through the asset library, you search for ProtonScatter and click Install; the README notes that if nothing appears, the add-on was not accepted yet and you should install manually. The manual path is to download or clone the repository and copy the proton_scatter folder into your project's add-on folder. The README is explicit that you must not rename that folder, or it will not work. After copying, enable the plugin under Project settings > Plugins.

The repository layout matches that instruction: the add-on code lives under addons/, and the README names the folder inside it as proton_scatter. There is no command line installer and no package registry step for this add-on, so the manual route is the one to follow.

After enabling the plugin, the first real use follows the setup the README describes. Add a ProtonScatter node, add a ScatterShape to define the area, add a ScatterItem for the asset, then edit the modifier stack in the inspector to create points. If you get lost, the README points to built-in documentation rather than a website: select any ProtonScatter node, look at the Modifier Stack in the inspector, and click the Doc button in the top right corner.

The README's own summary of that node layout is the clearest reference:

A `ProtonScatter` (1) node holds the `positionning rules` (2) that can be edited in the inspector.
One or more `ScatterItem` nodes to select which asset you want to place.
One or more `ScatterShape` items to define the area where the scattering happens.

There is no separate documentation site to consult. The README's answer to where the documentation lives is the Doc button itself, which means the reference material ships with the version you installed.

Godot 3.x is a different add-on, not a version toggle

The clearest limitation is version scope. ProtonScatter for Godot 3.x lives on the v3 branch, and the README warns that the add-on was completely rewritten and overhauled for Godot 4, so there will be significant differences. It states plainly that previous Scatter objects will not be compatible when you upgrade a project from Godot 3 to Godot 4. This is not a migration path with a converter; it is a rebuild.

That has a practical consequence for teams maintaining two branches of a game. The v3 branch and the main branch are separate codebases with separate behaviour, so fixes and habits do not transfer. If your project is still on Godot 3.x, you are adopting the older design, and the documentation you find for the Godot 4 add-on will not describe it.

The second limitation is structural. Because placement is a live modifier stack rather than baked output, the add-on is the wrong tool if your pipeline needs committed geometry. Nothing in the README describes an export or bake step for the scattered result. If you need the final positions as static meshes for a build target that does not run the add-on, there is no documented way to get there.

ProtonScatter versus a Blender particle or geometry nodes workflow

The natural comparison is scattering in Blender and importing the result, which is what the search phrasing around surface scattering usually refers to. The difference is where the rules live. In a Blender scatter workflow the placement is resolved in the DCC and the exported asset carries the arrangement, so the engine receives fixed geometry and the editing loop runs through a re-export. ProtonScatter keeps the rules inside the Godot scene as nodes and modifiers, so placement is resolved by the engine and stays editable while you work on the level.

That trade favours iteration speed on the level and costs you a portable asset. A scene built with ProtonScatter depends on the add-on being installed and enabled, which is why the folder name matters and why the plugin has to be turned on under Project settings. A baked arrangement has no such dependency. The README's own showcase is a case for the Godot-side approach: rocks are placed, then trees and grass are projected onto the rocks' colliders, a projection that depends on the colliders as they exist in the engine scene.

Maintenance, licensing and the demo assets

The add-on is published under the MIT license, which permits use, modification and redistribution provided the license terms are met. The repository is not archived, and the last push was on 2026-07-26. The most recent tagged release listed is 4.0 from 2023-10-23, so the commit history is more recent than the release tags. If you pin to a tagged release you are pinning to something older than the branch; if you copy the repository you get the current state of main with no release number attached.

Upgrade cost is concentrated in the Godot 3 to 4 boundary described above, since that rewrite broke scene compatibility. Within Godot 4, the README does not document a deprecation or migration policy for the modifier stack, so the safe assumption is that scenes are tied to the add-on version you installed.

There is a licensing detail that is easy to miss because it sits under the same heading as the MIT grant. The game assets under the demo folder are split: the 3D assets are MIT, but most textures bundled with the project were created with images from Textures.com. The README states you cannot redistribute those textures on their own, though they are free to use as part of a bigger project, and it points to Textures.com's own FAQ for the license terms. If you copy the demo folder into a shipping project, the 3D assets and the textures carry different conditions. This is a description of what the README says, not legal advice; read the linked terms yourself.

Editorial conclusion

Adopt ProtonScatter if you are building Godot 4 scenes with many repeated props and want to keep placement editable instead of baked. Skip it if you are on Godot 3.x, since the v3 branch is a different, pre-rewrite add-on, and skip it if your pipeline expects exported meshes rather than a live modifier stack. Before committing, open the demo project, confirm the ProtonScatter node's Doc button loads the built-in documentation in your Godot version, and check that the proton_scatter folder sits unrenamed under addons.

Frequently asked questions

Official sources

1. HungryProton/scatter on GitHub
2. Issues
3. License: MIT
4. README
5. Releases