DEV Community: Lewis Liu

Four Open-Source Unreal Engine Indexes for AI Tools, Plugins, Games, and More

Lewis Liu — Sat, 29 Aug 2026 14:56:09 +0000

Unreal Engine has an enormous open-source ecosystem. The hard part is often not finding a project; it is finding the right project for the job, checking whether it supports your UE version, and understanding its license before you build on it.

Today we are opening four focused Unreal Engine collection sites from SeeleAI:

If you want to move from an idea to a native Unreal prototype, you can also try the SeeleAI Unreal Game Creator. The collections below are useful when you want to inspect the tools, plugins, and projects behind that workflow.

These are curated indexes, not replacements for the original projects. Every entry links back to its authors, and each project keeps its own license and support requirements. The four index repositories themselves are MIT-licensed.

Why four lists instead of one?

One giant list quickly becomes difficult to scan. A developer looking for an MCP bridge has a different starting point from a technical artist looking for a procedural-world plugin, or a student looking for a complete gameplay sample.

The four repositories share a simple rule: make the next useful Unreal project easier to discover, while keeping enough context to make a responsible first evaluation.

1. Awesome Unreal AI Tools

Awesome Unreal AI Tools is for the rapidly growing intersection of Unreal and AI. It covers:

AI assistants and agent workflows
MCP servers and editor bridges
reusable agent skills
generative-AI integrations
simulation and embodied-AI tooling

The list includes projects such as VibeUE, UnrealClaude, unreal-mcp, UnrealGenAISupport, and AirSim. It also links to SeeleAI's own public Unreal projects, including Seele Scatter Regions and Seele Art Unreal, so the collection includes both community references and inspectable examples from its maintainer.

This is a useful starting point when your question is: “How can an AI system inspect, author, or automate part of an Unreal workflow?” It is also a good place to compare the boundaries of different approaches: an editor bridge, a coding skill, an MCP transport, and a simulator are not interchangeable components.

2. Awesome Unreal Engine

Awesome Unreal Engine is the broad map of the ecosystem. It brings together open-source:

development tools and editor extensions
gameplay, networking, GAS, and UI projects
rendering, materials, Niagara, and technical-art tools
PCG, procedural worlds, and simulation projects
tutorials, learning resources, samples, and assets
games and community research projects

Examples include SeeleAI's Seele Scatter Regions and Seele Art Unreal, alongside RealtimeMeshComponent, UnrealCLR, Cesium for Unreal, ActionRoguelike, and GASDocumentation.

Start here when you are still exploring the problem space. Once you know whether you need a plugin, a playable reference, or an AI integration, the focused lists make the next step faster.

3. Awesome Unreal Plugins

Awesome Unreal Plugins focuses on reusable Unreal modules and integrations. Its categories include:

runtime rendering and procedural content
character movement and animation
loading and workflow utilities
C#, Lua, and other language integrations
DCC and shader development
geospatial and XR workflows
navigation, gameplay AI, source control, and networking
packaging and asynchronous workflows

The collection also includes two SeeleAI plugins:

Seele Scatter Regions — an MIT-licensed, editor-side C++ plugin for seeded, recipe-driven village, farm, and cemetery layouts. It exposes C++, Blueprint-callable, and JSON automation paths and is validated for UE 5.5 and 5.8 on Windows/Win64.
Seele Art Unreal — an MIT-licensed editor plugin that imports validated FBX, GLB, glTF, and OBJ transfers from Seele Web into a local project through a narrow localhost bridge. Its current beta packages target UE 5.5 and 5.8 on Windows/Win64; it is an editor integration, not a packaged-game runtime dependency.

Projects such as PCGExtendedToolkit, ALS-Community, UnrealSharp, HoudiniEngineForUnreal, and Cesium for Unreal show the range of the list.

The goal is not to declare a “best plugin.” It is to give you a shortlist that you can evaluate against your engine version, target platforms, project architecture, and maintenance needs.

4. Awesome Unreal Open Source Games

Awesome Unreal Open Source Games is organized around playable projects and complete examples. It currently groups projects into areas such as:

survival and horror
action, RPG, and fighting
FPS
animation and gameplay systems
simulation and building
gameplay-architecture samples
focused indie projects

Good study candidates include EpicSurvivalGame, ActionRoguelike, GASPALS, FlowGraph, and MassSample.

Reading a plugin README tells you what a component exposes. Opening a complete game shows how systems meet in practice: input, UI, abilities, AI, networking, content organization, and the gameplay loop. That makes this list especially useful for learning and for validating architecture decisions with real project structure.

A practical discovery workflow

When evaluating a new idea, I use the lists in this order:

Map the space. Start with Awesome Unreal Engine.
Choose the project shape. Need an installable module? Open Awesome Unreal Plugins. Need a playable reference? Open Awesome Unreal Open Source Games.
Add AI only where it helps. For agent, MCP, or generative workflows, use Awesome Unreal AI Tools.
Verify before adopting. Read the original repository's license, supported UE version, target platforms, dependencies, recent activity, and build instructions.

You can clone any list locally:

git clone https://github.com/SeeleAI/awesome-unreal-engine.git
git clone https://github.com/SeeleAI/awesome-unreal-plugins.git
git clone https://github.com/SeeleAI/awesome-unreal-ai-tools.git
git clone https://github.com/SeeleAI/awesome-unreal-open-source-games.git

The lists are intentionally plain Markdown, so they are easy to search, fork, review, and contribute to.

Curation principles

We keep the scope practical:

link to public projects and preserve attribution;
record license and Unreal Engine version when the source provides them;
call out legacy or unstated compatibility rather than hiding it;
avoid treating stars as a quality score;
do not include private repositories or closed-source services as if they were open source.

The collections are independent indexes. Inclusion is an invitation to investigate, not a security, compatibility, or production-readiness guarantee.

Contribute a project

If you maintain a public Unreal project, open a pull request to the most relevant list. Include the original repository URL, license information, supported UE version, and a short explanation of what makes the project useful to study or use.

The Unreal ecosystem gets more valuable when discovery is paired with context. If these lists save you time—or if a project is missing—please open an issue or pull request and help us keep them useful.

If you are ready to test a native Unreal workflow after browsing the collections, open the SeeleAI Unreal Game Creator.

We Shortened Every Path in Our Unreal Build. That Wasn’t the Real Fix.

Lewis Liu — Fri, 21 Aug 2026 12:20:33 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories, powered by Sentry.

We had already done the obvious thing.

The Unreal Engine 5 project was copied to a very short build root. Folder names were trimmed. The packaging workspace was deliberately shallow.

Cook still failed with the familiar pair:

Couldn't save package, filename is too long (... >= 260)
AutomationTool exiting with ExitCode=25 (Error_UnknownCookFailure)

Our first response was to shorten paths even more. That was useful as a defensive measure, but it was not the fix that restored the build. The missing piece was Windows long-path support.

This post explains why a short project root may still be insufficient, what we changed, and how to verify the result without mistaking a started job for a successful package.

Why the short-root workaround was convincing

Unreal packaging does not operate only on the path you see in the Content Browser. Cook and staging add their own directory structure around it. Conceptually, a source asset can become something like:

<short-root>\Saved\Cooked\Windows\<project>\Content\<nested-asset-path>

The project root is only one part of the total length. Deep asset folders, duplicated import directories, generated names, plugin content, and Cook's output structure all spend characters from the same budget.

That is why moving a project from a long workspace into a path such as E:\u\work can reduce risk without guaranteeing success. The generated destination can still cross the legacy MAX_PATH boundary.

Short paths remain good build hygiene. They are especially useful when your pipeline includes tools whose long-path behavior is unknown. But they should not hide a misconfigured Windows runner.

The Windows setting that changed the outcome

On modern Windows, long paths are not simply enabled for every process by default. Microsoft documents two requirements:

The system setting LongPathsEnabled must be set to 1.
The application must declare itself longPathAware.

We enabled the system side from an elevated PowerShell session:

New-ItemProperty `
  -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' `
  -Name 'LongPathsEnabled' `
  -PropertyType DWord `
  -Value 1 `
  -Force

Then we verified the effective registry value:

Get-ItemPropertyValue `
  -LiteralPath 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' `
  -Name 'LongPathsEnabled'

The expected output is:

You can also configure the equivalent policy through Group Policy:

Computer Configuration
  > Administrative Templates
  > System
  > Filesystem
  > Enable Win32 long paths

After this Windows configuration was applied in our build environment, the Unreal packaging flow returned to normal with the longer asset paths intact.

Restarting is part of the change

There is an easy trap here: Windows caches the registry value per process after an affected filesystem function is first called.

If Unreal Editor, AutomationTool, a build agent, or a long-running sandbox service was already running, changing the registry and immediately retrying inside the same process tree may produce the same failure.

Restart the affected UE/UAT and worker processes. For a machine image or persistent build runner, rebooting Windows is the clearest way to remove ambiguity.

Why this is not a universal one-line fix

LongPathsEnabled=1 removes the OS-side limit only for applications that opt in. A packaging chain can include several executables, plugins, archive utilities, and scripts. Any one of them may still impose its own limit.

If the same error remains after a clean restart, check which layer is rejecting the path:

Windows/API boundary: the executable is not long-path-aware.
Unreal validation: your UE version or configuration still performs an explicit length check.
Plugin or third-party tool: an intermediate cooker, archiver, or file library still assumes 260 characters.
Project content: deeply repeated folders or generated filenames make the pipeline unnecessarily fragile.

At that point, shortening paths is still a valid compatibility fallback. For durable content cleanup, move or rename assets inside Unreal Editor and fix redirectors. Do not rename .uasset files directly in File Explorer.

How we verified the real fix

A successful API response that says "job started" is not packaging proof. Neither is the absence of the first long-path message.

The useful verification sequence is:

Keep the original deeply nested asset that reproduced the failure.
Enable the Windows policy and restart the relevant process tree.
Run the same BuildCookRun path again.
Confirm Cook and AutomationTool complete successfully.
Confirm the staged or archived build artifact actually exists.
If your pipeline uploads the artifact, verify that stage separately.

This matters because long-path failures often create secondary messages such as missing Cook content. Fixing the first path error should remove the downstream symptoms, but only the final artifact proves that the whole packaging chain recovered.

What we kept after the incident

We did not abandon short build roots after enabling long paths. We kept them as a low-cost safety margin for plugins and external tooling.

The resulting policy is deliberately layered:

Enable Windows long-path support on every UE build runner.
Restart or rebuild runners after changing the setting.
Keep temporary packaging roots shallow.
Avoid needless directory duplication in imported assets.
Test the complete Cook, stage, archive, and upload path.

The lesson was not "path length no longer matters." It was that shortening every folder is not a substitute for configuring the operating system that runs the build.

Best AI Model for Unreal Engine in 2026? Kimi K3 vs Claude Opus 5 vs Qwen3.8

Lewis Liu — Sat, 25 Jul 2026 12:26:14 +0000

Evidence checked on July 25, 2026. This comparison separates vendor claims, general coding evidence, and native Unreal Engine delivery. Those are not the same thing.

Kimi K3, Claude Opus 5, and Qwen3.8-Max-Preview all arrived with unusually strong claims around coding, visual iteration, long-running agents, or 3D creation. That makes one question inevitable for game developers:

Which AI model is actually best for building an Unreal Engine 5 game?

The short answer is Claude Opus 5 currently has the strongest public evidence for reliable agentic engineering and 3D reconstruction; Kimi K3 has the clearest first-party claim around playable 3D games and vision-in-the-loop iteration; Qwen3.8-Max-Preview is promising for large, multimodal engineering tasks but remains a preview with no official Unreal delivery proof.

The more important answer is that none of these model announcements, by itself, proves that the model can deliver a valid native Unreal project, compile Blueprint or C++, cook assets, package a build, and reproduce the result. For Unreal work, the execution environment often matters more than a small difference in model intelligence.

TL;DR: the Unreal-specific verdict

Model	Strongest relevant evidence	Unreal-specific gap	Best current role
Claude Opus 5	Strong agentic coding, verification, computer use, a successful 3D FreeCAD reconstruction case, and early-user reports of better games and 3D output	No official native Unreal project or packaging benchmark	Lead engineering agent for difficult implementation, debugging, and review
Kimi K3	First-party claim for playable multiplayer and 3D games, native vision, 1M context, long-horizon tool use, and screenshot-driven iteration	Showcases do not establish `.uproject`, Blueprint, C++, cook, or package success	Long-context, visually iterative game prototyping and tool-driven workflows
Qwen3.8-Max-Preview	2.4T multimodal preview positioned for repository-scale coding, long tasks, image/video/document understanding, and agent workflows	Preview status; no official Unreal or native 3D game-delivery evidence	Cost-aware experimentation, repository analysis, and implementation planning
Other frontier coding models	Strong general software-engineering and terminal-agent baselines	General coding scores still do not prove Unreal asset or build validity	Secondary implementer, reviewer, or fallback inside a controlled harness

My practical ranking is therefore task-dependent:

For difficult code, debugging, and self-verification: Claude Opus 5.
For visual iteration and open-ecosystem experimentation: Kimi K3.
For large-context, multimodal, cost-sensitive evaluation: Qwen3.8-Max-Preview.
For a playable native Unreal result: choose the workflow that can actually open Unreal, inspect screenshots and logs, modify the project, and package the build. Do not choose from model marketing alone.

First, define what “building a 3D game” means

Many impressive AI game demos are browser projects using Three.js, Babylon.js, WebGL, or a custom JavaScript runtime. Those can be excellent results, but they are not Unreal Engine projects.

A credible Unreal evaluation should require all of the following:

A valid native project with a .uproject file.
Correct Config, Content, Source, and plugin structure for the chosen scope.
A map that opens without missing dependencies.
Working input, camera, collision, and a small gameplay loop.
Blueprint and C++ that compile where those systems are used.
Assets that cook correctly for a named target platform.
A packaged build that launches outside the editor.
Logs, screenshots, and a reproducible handoff rather than a one-shot video.

Epic's packaging documentation describes Build, Cook, Stage, Package, Deploy, and Run as distinct operations. An attractive screenshot only covers a fraction of that pipeline.

This distinction is the most important part of the comparison. A frontier model can write excellent C++ and still fail because it cannot see the Unreal editor, resolve an asset reference, regenerate project files, inspect a cook error, or rerun the packaged executable.

Release status: what is actually available?

Kimi K3

Moonshot AI introduced Kimi K3 on July 17, 2026 as a 2.8-trillion-parameter model with native vision and a 1-million-token context window. K3 is available through Kimi, Kimi Work, Kimi Code, and the Kimi API. Its technical blog says the full model weights are scheduled for release by July 27, 2026.

That date matters. On July 25, the hosted product and API are available, but “open model” should not be interpreted as “the full weights are already downloadable everywhere.”

Kimi's most relevant claim is unusually direct: K3 combines 3D reasoning, coding, and vision to create playable interactive experiences, with a vision-in-the-loop workflow that alternates between code and live screenshots. The homepage also explicitly promotes playable multiplayer and 3D game creation.

This is highly relevant to game development. It is not yet Unreal-specific proof.

Claude Opus 5

Anthropic released Claude Opus 5 on July 24, 2026. It is available through Claude products and the API as claude-opus-5, at the same base API price Anthropic listed for Opus 4.8.

The release emphasizes long-running software agents, verification, computer use, professional work, and improved visual output. Two pieces of evidence are particularly relevant to 3D work:

In an Anthropic evaluation, Opus 5 reconstructed a machine part as a 3D FreeCAD model after building its own computer-vision pipeline to extract geometry from raw pixels.
An early-access partner reported the best animations, games, and 3D work they had seen from an Opus model.

Opus 5 also places unusual emphasis on checking its own work before reporting success. That behavior is valuable in Unreal, where a model must distinguish “the code looks plausible” from “the editor compiled it and the packaged build launched.”

Again, neither example is a published native Unreal packaging benchmark.

Qwen3.8-Max-Preview

The currently accessible model is Qwen3.8-Max-Preview, not a final open-weight Qwen3.8 release. Alibaba Cloud's developer-community overview describes a 2.4-trillion-parameter multimodal preview for engineering, long-running agents, large repositories, and image, video, and document understanding. It is available through selected Alibaba/Qwen coding and API surfaces, while the final weights remain future-facing.

Qwen's current public positioning is strongest around general engineering and WebDev. That can transfer to Unreal tasks such as reading a C++ module, proposing a subsystem architecture, refactoring build scripts, or interpreting screenshots. But I could not find an official claim that Qwen3.8 generates native .uproject files, compiles Blueprint graphs, cooks assets, or packages a production Unreal build.

Treat it as a promising preview, not a proven Unreal generator.

The readiness matrix: claims versus Unreal delivery

The labels below are evidence grades, not synthetic benchmark scores:

Strong: directly supported by a current first-party release or concrete case.
Moderate: supported indirectly by adjacent capabilities.
Unproven: no current public evidence specific to the requirement.

Requirement	Claude Opus 5	Kimi K3	Qwen3.8-Max-Preview
Long-horizon coding	Strong	Strong	Moderate–Strong
Visual/screenshot iteration	Strong	Strong	Moderate
3D creation evidence	Strong, via FreeCAD case and partner reports	Strong, via first-party 3D/game claims	Moderate, via multimodal/WebDev transfer
Large repository reasoning	Strong	Strong, 1M context	Strong in current positioning
Tool/terminal orchestration	Strong	Strong	Moderate–Strong
Native `.uproject` generation	Unproven	Unproven	Unproven
Blueprint asset compilation	Unproven	Unproven	Unproven
Unreal C++ build success	Unproven	Unproven	Unproven
Cook/package/launch proof	Unproven	Unproven	Unproven

This table is intentionally conservative. General coding benchmarks can help predict performance, but they do not test binary assets, editor-only APIs, plugin compatibility, shader compilation, cook rules, target SDKs, or packaged runtime behavior.

How each model is likely to behave in an Unreal workflow

Claude Opus 5: the strongest engineering lead

Opus 5 looks best suited to tasks where judgment matters more than raw generation volume:

tracing a multi-module Unreal C++ bug;
questioning an unsafe architecture before editing;
planning a Gameplay Ability System implementation;
interpreting build, cook, and runtime logs;
checking whether a fix addresses the root cause;
iterating with screenshots and tool output;
reviewing a handoff before claiming completion.

Its biggest advantage is not that it can draw the prettiest 3D scene. It is the combination of coding, computer use, iteration, and verification.

The risk is assuming this automatically gives it Unreal asset access. A language model cannot reliably create or repair binary .uasset files without an engine-aware tool path. Give it Unreal, source control, logs, screenshots, and explicit pass/fail checks.

Kimi K3: the strongest 3D-native claim

K3 has the clearest vendor claim around playable 3D creation. Its native vision, long context, terminal orchestration, and screenshot loop are a good match for:

creating a playable prototype over a long session;
iterating on composition, navigation, and visual defects;
retaining a large design brief plus repository context;
coordinating code, research, asset preparation, and testing;
working through a game-development task with minimal supervision.

K3's published limitations are also relevant. Moonshot warns that quality may become unstable if a harness does not preserve the expected thinking history, and that the model can be excessively proactive when instructions are ambiguous. In an Unreal workspace, that means permissions, file boundaries, plugin policy, allowed commands, and packaging targets should be explicit.

K3 may be an excellent engine inside a game-building agent. The current evidence still does not show that the base model alone is an Unreal pipeline.

Qwen3.8-Max-Preview: promising, but evaluate the preview as a preview

Qwen3.8-Max-Preview is attractive when the task contains a very large repository, mixed documents and visuals, or many repeated engineering operations. Possible Unreal uses include:

reading project source, configuration, build files, and technical design documents together;
generating C++ or automation scripts under a review loop;
analyzing screenshots, logs, and specifications;
planning migrations or repository-wide changes;
running cheaper exploratory passes before a stronger verifier reviews the result.

The problem is evidence maturity. The public material I found emphasizes preview access, general engineering, long agents, and WebDev—not a repeatable Unreal result. Until the final release, model card, and native engine tests are available, Qwen3.8 should be evaluated with stricter checkpoints rather than broader claims.

A reproducible Unreal benchmark that would actually matter

If you want to compare models fairly, give each one the same environment, prompt, time budget, tool permissions, and clean Unreal project.

Here is a compact benchmark:

Build a small third-person Unreal 5 game in which the player explores a mountain-and-water environment, reaches three checkpoints, and sees a completion screen. Use only redistributable or generated assets. Add a restart action, package for Windows, launch the packaged build, and provide the project, build logs, runtime logs, and five screenshots.

Score it with observable gates:

Gate	Pass condition
Project validity	`.uproject` opens in the specified Unreal version
Dependency integrity	No missing plugin, module, map, or asset references
Gameplay	Movement, camera, checkpoints, completion, and restart work
Code health	Blueprint and C++ compile without blocking errors
Visual review	Screenshots show the intended scene and readable UI
Packaging	Build, cook, stage, and package complete
Runtime	Packaged executable launches and completes the loop
Reproducibility	A second run from clean state produces the same result
Handoff	Source project, logs, build, assets, and rights notes are present

Record the number of human interventions, tool calls, elapsed time, retries, and unresolved warnings. That will tell you more than a model's generic coding rank.

So which model should an Unreal developer choose?

Choose Claude Opus 5 when you already have a capable tool environment and need the strongest current engineering judgment, difficult debugging, or careful verification.

Choose Kimi K3 when visual iteration, long context, and 3D/game experimentation are central—and when your harness can preserve its expected history and constrain its autonomy.

Choose Qwen3.8-Max-Preview when you want to evaluate a large multimodal model for repository analysis, automation, or cost-sensitive exploration, while accepting preview risk and the lack of native Unreal proof.

For serious work, a multi-model pipeline may be better: one model drafts and implements, another reviews the change, while Unreal itself remains the source of truth through compile, cook, package, and runtime tests.

The deeper conclusion: the harness beats the headline

The 2026 model race is making 3D demos faster and more impressive. But Unreal game development is not one generation step. It is a feedback loop across source code, Blueprints, assets, editor state, logs, rendering, performance, packaging, and runtime behavior.

The best Unreal AI system is therefore not automatically the model with the largest parameter count or the most attractive demo. It is the system that can:

create a native project;
observe the real editor and runtime;
repair failures using logs and screenshots;
package and launch the result;
return editable artifacts with honest limitations.

If you want to evaluate that complete workflow rather than another isolated model claim, SEELE AI provides a native Unreal 5 project workflow with browser preview, packaging, and local download. It is an independent product and is not affiliated with or endorsed by Epic Games. Generated projects, third-party assets, plugins, platform requirements, and release readiness still require review.

That link is included as a practical test option, not as evidence that one underlying model “wins” this comparison.

Sources and methodology

I prioritized current first-party sources, dated every time-sensitive claim, and marked capabilities as unproven when I could not find public Unreal-specific evidence. Vendor benchmarks and customer quotes are useful signals, but they are not a substitute for an identical, independently run Unreal benchmark.

Disclosure: AI tools assisted with source collection and article drafting. The capability boundaries, model status, and linked sources were reviewed against the pages listed above on July 25, 2026.

We Open-Sourced a Seeded UE5 Village Generator — Here’s the C++ Pipeline

Lewis Liu — Sat, 18 Jul 2026 04:05:51 +0000

Randomly scattering meshes is easy. Generating a village that follows the terrain, avoids obvious overlaps, stays art-directable, and can be reproduced from a seed is the harder problem.

We open-sourced the solution as Seele Scatter Regions, an MIT-licensed Unreal Engine 5.5 editor plugin developed by SEELE AI. It generates villages, farms, and cemeteries from project-owned Static Mesh recipes without depending on Unreal Engine's PCG framework.

The repository includes the public C++ source, Blueprint-callable editor tooling, a JSON automation path, packaging validation, and a UE5.5 release. This article walks through how those pieces fit together.

This post walks through the current C++ implementation: how recipe assets become topology, how candidate points are filtered into believable layouts, how instances are projected onto Landscape, and how the generator exposes enough telemetry to be automated safely.

Current scope: beta 0.1.0, Unreal Engine 5.5, editor-side generation, and C++ projects.

The actual problem: controlled randomness

A useful procedural tool needs more than a random position and yaw. We wanted five properties:

Repeatability — the same seed should reproduce the layout when the recipe and scene are unchanged.
Art direction — artists should provide meshes, weights, density, and scale without recompiling C++.
Spatial logic — roads, buildings, fields, tombs, gates, and props need different placement rules.
Terrain awareness — generated content must land on Landscape instead of floating at the input Z.
Automation-friendly results — callers need structured counts, warnings, bounds, and errors, not just a log line.

The implementation became a pipeline:

JSON / C++ input
        ↓
Recipe Data Asset
        ↓
Seeded boundary + road topology
        ↓
Candidate point generation
        ↓
Density, distance, slope, and collision filters
        ↓
Landscape projection
        ↓
Instanced Static Mesh components
        ↓
Structured generation result

The important design decision is that randomness is only one stage. Most of the believable result comes from constraints applied after candidate generation.

1. Put art direction in recipe assets

The public recipe starts with a small piece of shared mesh data:

USTRUCT(BlueprintType)
struct FScatterRegionMeshRecipeData
{
    GENERATED_BODY()

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    TSoftObjectPtr<UStaticMesh> Mesh;

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    FVector ScaleMin = FVector::OneVector;

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    FVector ScaleMax = FVector::OneVector;

    UPROPERTY(EditAnywhere, BlueprintReadOnly)
    bool bUniformScale = false;

    UPROPERTY(EditAnywhere, BlueprintReadOnly, meta = (ClampMin = "0.0"))
    float Weight = 1.0f;
};

A UScatterRegionRecipeDataAsset then exposes type-specific slots:

Village: weighted building slots, local props, fence, gate, road, roadside props, and scatter props
Farm: road, dirt tiles, crops, and scarecrows
Cemetery: road, tombs, and a memorial/panteon slot

The asset normalizes its slot layout in the constructor, PostLoad, and PostEditChangeProperty. When the region type changes, irrelevant slots disappear and the expected slots are restored.

This gives us a stable contract without hard-coding production art. The open-source repository includes lightweight recipes using Unreal's Basic Shapes, while real projects can duplicate a recipe and assign their own assets.

Soft object references matter here: recipes can describe content without eagerly loading every mesh. At generation time, the compiler resolves the selected recipe, validates its slots, loads meshes synchronously, and converts the author-facing data into a compact internal representation.

2. A seed should control topology, not only decoration

Every random choice flows through one FRandomStream:

FRandomStream Stream(Spec.Seed);

if (Spec.RegionType == TEXT("farm"))
{
    GenerateFarm(Context, Spec, Recipe, Stream);
}
else if (Spec.RegionType == TEXT("cemetery"))
{
    GenerateCemetery(Context, Spec, Recipe, Stream);
}
else
{
    GenerateVillage(Context, Spec, Recipe, Stream);
}

The seed influences boundary irregularity, road bends, branch placement, building selection, density filtering, mesh weights, position jitter, yaw, and scale. This is more useful than applying a seed only to the final prop scatter: the large-scale composition is reproducible too.

For villages, the generator builds a smoothed closed boundary, chooses a gate along the boundary, and grows the road graph inward from that gate. The primary road is made from short quadratic Bézier segments; secondary branches search for valid endpoints inside the polygon.

In simplified form:

const FVector2D Control =
    (Start + End) * 0.5f +
    Normal * Stream.FRandRange(-BendStrengthCm, BendStrengthCm);

for (int32 Index = 1; Index <= SegmentCount; ++Index)
{
    const float T = static_cast<float>(Index) / SegmentCount;
    const FVector2D A = FMath::Lerp(Start, Control, T);
    const FVector2D B = FMath::Lerp(Control, End, T);
    const FVector2D Current = FMath::Lerp(A, B, T);
    Segments.Add(MakeRoadSegment(Previous, Current, bPrimary));
    Previous = Current;
}

The result is deterministic but not rigidly grid-shaped.

There is one important caveat: deterministic generation means same seed + same recipe + same scene state. If the Landscape or mesh bounds change, projection and collision decisions can change as well. The seed makes a build reproducible; it does not freeze the world around it.

3. Treat placement as a point-processing pipeline

The reusable core is a lightweight graph-point structure containing location, yaw, density, bounds radius, Z offset, and a scale multiplier.

Instead of placing a mesh immediately, each region strategy creates candidate points and runs them through small transforms. The village roadside-prop path is a good example:

SidePropPoints = ScatterRegionDensityFilter(
    SidePropPoints, Stream, 1.0f);

SidePropPoints = ScatterRegionDifferenceAgainstRoads(
    SidePropPoints,
    RoadSegments,
    MinRoadDistance,
    MaxRoadDistance);

SidePropPoints = ScatterRegionDifferenceAgainstPlacements(
    SidePropPoints,
    BuildingPlacements,
    BuildingClearance);

SidePropPoints = ScatterRegionSelfPruning(
    SidePropPoints,
    Stream,
    MinimumSpacing,
    true);

ScatterRegionLookAtRoad(SidePropPoints, RoadSegments);

ScatterRegionTransformPoints(
    SidePropPoints,
    Stream,
    80.0f,          // position jitter in cm
    12.0f,          // yaw jitter in degrees
    FVector(0.85f),
    FVector(1.15f),
    true);

Each operation has one job:

Density filter accepts points probabilistically from recipe density.
Difference against roads enforces a minimum and optional maximum road distance.
Difference against placements keeps props away from buildings or reserved landmarks.
Self-pruning rejects candidates that are too close to already accepted points.
Look-at-road rotates a point toward its nearest road segment.
Transform adds controlled position, yaw, and scale variation.

Collision reservation uses mesh bounds when available, so a large building and a small prop do not consume the same amount of space.

This pipeline is the heart of the system. Region generators can create very different candidate sets while reusing the same constraints.

4. Project every accepted instance onto Landscape

Candidate generation happens in local XY space around a root actor. Before an instance is committed, the plugin traces vertically through the editor world:

const FVector Start(
    WorldXY.X,
    WorldXY.Y,
    Context.Center.Z + LocalLocation.Z + 200000.0f);

const FVector End(
    WorldXY.X,
    WorldXY.Y,
    Context.Center.Z + LocalLocation.Z - 200000.0f);

TArray<FHitResult> Hits;
Context.World->LineTraceMultiByChannel(
    Hits,
    Start,
    End,
    ECC_Visibility,
    QueryParams);

for (const FHitResult& Hit : Hits)
{
    if (IsLandscapeTraceHit(Hit))
    {
        OutLocalLocation.Z =
            Hit.ImpactPoint.Z - Context.Center.Z;
        Context.ProjectionHits++;
        return true;
    }
}

The trace ignores the root actor and actors tagged as previously generated regions. Without that, later generations could project onto earlier generated meshes instead of the Landscape.

After projection, the mesh is grounded using its bounds:

Location.Z += GroundedZ(RecipeMesh, Scale);
Location.Z += VerticalOffsetCm;

The generator tracks projection attempts, hits, and misses. A complete miss becomes a warning rather than silently producing a misleading "success."

Slope checks reuse Landscape samples around building or memorial candidates. That lets large semantic objects be rejected on steep terrain before they are committed.

5. Batch output with Instanced Static Mesh components

Spawning one Actor per crop, tomb, or fence segment would create unnecessary editor and rendering overhead. The plugin groups instances by slot + mesh path:

const FString ComponentKey = Slot + TEXT("|") + RecipeMesh.Path;

if (UInstancedStaticMeshComponent** Existing =
        Context.Components.Find(ComponentKey))
{
    return *Existing;
}

UInstancedStaticMeshComponent* Component =
    NewObject<UInstancedStaticMeshComponent>(
        Context.RootActor,
        ComponentName);

Component->SetStaticMesh(RecipeMesh.Mesh);
Component->AttachToComponent(
    Context.RootActor->GetRootComponent(),
    FAttachmentTransformRules::KeepRelativeTransform);

Every accepted transform is added to the matching UInstancedStaticMeshComponent. The generated region remains one tagged root actor with a manageable component set, while slot counts and world bounds are updated as instances are added.

We have deliberately not attached a benchmark number to this design: performance depends on meshes, materials, instance counts, and the target machine. The architectural benefit is still concrete—thousands of repeated objects do not become thousands of Actors.

6. Three content grammars, one infrastructure

The generators share recipes, random streams, point filters, projection, collision reservation, output components, and telemetry. What differs is the content grammar.

Region	Topology	Main placement rules
Village	Irregular boundary, gate-rooted main road, bent branches	Road-facing building clusters, local props, perimeter fence/gate, roadside and free scatter
Farm	Closed boundary, two-lane access roads, tiled fields	Dirt tiles avoid road footprints; crops sit above dirt; scarecrows are density-filtered and spaced
Cemetery	Closed boundary and access paths	Memorials reserve exclusion zones; tomb grids avoid roads and memorials, then self-prune

This separation is valuable. A "universal" random scatter function would bury these differences in flags. Three small domain strategies over shared primitives are easier to reason about and extend.

7. Make the generator safe to automate

The same generator can be called from C++, a Blueprint-callable Editor Subsystem, or a JSON adapter.

A request looks like this:

{
  "region_type": "village",
  "center": [75000, 37000, 0],
  "size_m": 150,
  "seed": 76101,
  "recipe_asset": "/Game/MyRecipes/DA_Village.DA_Village"
}

The public command is generate_scatter_region. Inputs are validated before the world is touched:

region type must be village, farm, or cemetery
size is clamped to 20–1000 meters
a recipe asset path is required
generation is rejected when PIE is active
the editor world must be initialized and available

The result reports:

success
generated actor name
instance and component counts
per-slot counts
projection attempts, hits, and misses
generated bounds
warnings and structured errors

That observability is not just polish. It lets an automation client distinguish "the command returned" from "a useful region was actually generated."

A practical success check is:

success == true
region_actor is not empty
instance_count > 0
projection_hits > 0 when Landscape projection is expected
errors is empty

What we learned

A few design lessons survived every iteration:

Randomness is an input, not the architecture. The spatial constraints do most of the work.

Determinism must include topology. Reproducing only prop jitter is not enough when roads and clusters define the composition.

Authored data and generation logic should evolve separately. Recipe assets let artists replace meshes and tune density without turning the generator into project-specific code.

Telemetry belongs in the public API. Counts, bounds, warnings, and projection statistics make editor automation debuggable.

Scope should be explicit. Version 0.1.0 generates in the editor, not at packaged-game runtime. The generated actor and instanced components can be saved with the edited level.

Try it or read the source

Seele Scatter Regions is MIT-licensed and open source:

If you are building procedural tools in Unreal Engine, I would be interested to hear how you balance deterministic generation, designer control, and terrain constraints—especially if you have taken a PCG-based or runtime-first approach.

A website that counts open source model tokens online is recommended

Lewis Liu — Sat, 17 Aug 2024 10:18:42 +0000

Still wondering how to count tokens for the open source model?

Today, I recommend a web tool whose main function is to count tokens for open source models that currently support both Mistral and Llama2 models.

web links：toolai.fun

Using this web tool is very simple. Just select the corresponding model, enter the characters, the system will automatically calculate the number of tokens, and provide intuitive results display. This not only saves the user's manual calculation time, but also improves the work efficiency.

If you need it, save it and use it toolai.fun