EDGEbuilder design

Draft 1, 2026-10-13. Status: B0, deciding. Nothing is built yet; this page is what to build and in what order.

EDGEbuilder is a world builder for Cyberpunk 2077: pick an asset from the game’s own files, drop it into the live game, move it into place, arrange a scene, and bake the scene into a streaming sector that loads like any other mod. It runs as a REDnode package, so the editor is a web page over the game and the logic is Node. REDbridge supplies the asset list and does the baking, REDcode holds the project the bake lands in, and REDdeck installs both EDGEbuilder and what it bakes.

Where the idea comes from

World Builder by keanuWheeze, a Cyber Engine Tweaks mod, showed that a world editor can live inside the running game, and that its real product is not the preview but the exported streaming sector. EDGEbuilder is a from-scratch design of that idea for the EDGE platform. It uses none of World Builder’s code, files, data lists or file formats, which its license reserves. What we took from studying it is understanding (the full findings are on the study page):

Behaviours

EDGEbuilder is six behaviours. Each is described by what the player does and what happens underneath.

Everything else, favourites, prefabs, scattering, splines, areas, AI, is a later behaviour built on these.

Two halves

A world builder has a runtime half and a project-time half. World Builder is only the first; EDGEbuilder is both, around one scene file.

The scene file is the contract. Saved in a REDcode project it is a project file like a mesh or a script; the runtime builder opens it from there and saves back to it, and the project builder reads and bakes the same file. Without a project the runtime builder keeps scenes in its own data folder, and Bake asks for a project to put them in. “Open in game” from REDcode hands the scene to the running EDGEbuilder through REDnode, the same loop REDcode uses for mods.

The runtime half is v1. The project half starts with what costs little and pays at once: the scene file in the project, validation, Bake from the command palette, and the tree. Its 3D view waits until REDbridge exports meshes.

The pieces

 ┌──────────────────────────── the game ────────────────────────────┐
 │  REDnode plugin ── spawns previews, sets transforms, projects     │
 │        ▲                        points, raycasts, draws windows   │
 └────────┼─────────────────────────────────────────────────────────┘
          │ pipe
 ┌────────┴──────────── REDnode host (outside the game) ────────────┐
 │  EDGEbuilder package                                              │
 │   overlay app ──── editor window: assets, scene, properties, bake │
 │     │ channel          and a transparent canvas for the gizmo     │
 │   Node mod ─────── scene tree, history, scene files, asset index  │
 │     │ JSON-RPC         and the bake                               │
 └─────┼─────────────────────────────────────────────────────────────┘
       ▼
   REDbridge ──── lists assets, reads mesh bounds, writes the sector
       ▼
   REDcode project ──── source/archive/<scene>.streamingsector, .xl
       ▼
   REDdeck ──── packs and deploys it; next start, it is the world

EDGEbuilder is a combined package: a manifest with both entry and main. The page is the face, the mod is the brain, and they talk over channel. The page never touches files or the bridge; the mod never draws.

The preview in the game

Every placed object is a preview entity. For the game’s own entity templates the preview is the template itself, spawned at a transform with an appearance. For every other kind the preview is EDGEbuilder’s own empty entity with one component attached when the entity assembles:

The empty entity, and nothing else, ships in a tiny archive of EDGEbuilder’s own, authored as JSON in this repo and built by REDbridge. No gizmo meshes: the gizmo is drawn by the overlay.

Rules learned from the game, to be verified in B1:

• Components can be attached only while the entity assembles. The spawn is therefore event-driven: spawn, wait for assemble, attach, wait for attached, then the object is live. Moves requested earlier are queued.
• A moved preview gets a new world transform on the entity. The component follows.
• Selection shows as the game’s own render highlight on the entity.
• Mesh bounds come from REDbridge reading the mesh file, not from loading the resource in the game. They are cached with the asset index. Entity bounds are the union of their mesh components’ bounds, read the same way.

The editor

The panel docks to the right edge. The rest of the screen is the viewport: in REDnode’s interactive mode the page gets the mouse and keys, and the transparent canvas behind the panel draws the gizmo, the selection box and the outlines of colliders. In passive mode the game has the controls and the panel stays visible.

Camera. v1 drives the player: while the editor is active the player is kept at an orbit pivot and the first-person camera is offset back by the orbit distance, so the middle mouse orbits, Shift pans and the wheel zooms. Leaving the editor puts the player back. This is the approach World Builder verified in game, and it needs no plugin work. A true free camera inside REDnode is a later improvement.

Picking. A ray from the cursor, built from the camera’s transform and field of view, tested against each object’s oriented bounds in the Node mod. The nearest hit wins; an object whose bounds sit inside another’s is preferred. Surface hits use the game’s physics raycast.

Files

A scene object, in EDGEbuilder’s own shape:

{
  "id": "obj_01J9",
  "kind": "mesh",
  "resource": "base/environment/decoration/.../crate_a.mesh",
  "appearance": "default",
  "transform": { "position": [x, y, z], "rotation": [x, y, z, w], "scale": [1, 1, 1] },
  "streaming": { "primary": 60, "secondary": 48 },
  "ref": "edgebuilder/my_scene/crate_a_01",
  "props": { "shadows": "default" },
  "group": "grp_01J8"
}

Rotation is a quaternion in the file and Euler angles in the panel. Streaming ranges default to a function of the object’s size and can be edited. The reference is generated and unique within the scene.

Baking

sector.build is a REDbridge method (0.6.0): it takes a scene file and a target folder and writes, with WolvenKit’s own writers, one worldStreamingSector with a node per object and a node-data entry carrying position, orientation, scale, bounds and streaming distances; one worldStreamingBlock whose descriptor holds the sector’s streaming box; and an ArchiveXL .xl that registers the block. Into a REDcode project they go under source/archive as game files, so the project packs them without conversion.

Validation before the bake: every object has a resource that exists in the game, a unique reference, and finite streaming ranges; the scene is not empty; the target project exists. The bake is repeatable: the same scene bakes to the same files.

After the bake, REDdeck’s Add from REDcode project puts the packed mod in the library, deploy links it into the game, and the next game start shows the objects for real, with the preview entities gone.

What EDGEbuilder needs from the other repos

For REDnode, the design’s assumptions that are not in the SDK today, in the order B1 hits them:

For REDbridge: sector.build as above (REDbridge #1, done in 0.6.0), a read of a mesh file’s bounds and appearances (REDbridge #2, done in 0.6.0 as mesh.info), and building EDGEbuilder’s support archive from JSON, which is project.pack on a one-file project. The scene file is pinned on the scene format page.

For REDcode, later: the scene file as a project file, Bake from the command palette, validation (REDcode #2).

For REDdeck: the rednode kind, so a zip or folder with rednode-app.json deploys to red4ext/plugins/REDnode/apps/<id>/. Done in REDdeck 0.20.0.

Risks

Roadmap

Each phase ends with an in-game test on the owner’s PC, with the steps written down in a results page, as REDnode does.

Not in v1

Communities and AI spots, devices and persistent state, splines, areas, variants, imports from other editors, and anything that needs an engine hook rather than the game API.