Blockout 2 Real writes fitted lights and UV textures into Blender scenes

• Blockout 2 Real returns an editable, relightable .blend, with UV textures, materials and fitted lights, as gokayfem demonstrated.
• Nano Banana 2 generates the target photograph; Marigold V2, MoGe-3 and PATINA help separate its surface properties, according to the launch post.
• Camera moves can expose smeared or filled-in textures: the first-run notes document the limits of the open-source release.

A Photoshop paintover can supply the target. The toolkit can also build its starting geometry from a JSON specification of primitives, or just an idea.

Blockout 2 Real's best feature is the deliverable: an ordinary Blender scene whose materials and lighting remain editable.

Gokayfem previously shared a sculpting attempt made in Blender. This project starts with a whole scene's existing shapes and follows a three-part image-to-material workflow:

1. Generate the target. Nano Banana 2 turns the grey camera render into a photograph-like reference. Five conditioning levels are tested; the weakest that preserves edge alignment with the object masks is retained. The agent also checks overlays, since an object can move without changing its outline.
2. Separate the maps. Different models supply different properties:
3. Write into UVs. The known camera projects the maps into each object's texture coordinates. Visibility checks keep samples on the correct object, and the resulting textures feed Principled BSDF materials.

Each candidate light is rendered alone in Cycles, using the actual scene materials. A nonnegative optimization solves its strength and colour against the target, then removes lights that contribute too little; LPIPS, a perceptual image-distance metric, selects between pruning variants.

In the first room's final lighting fit, image-energy shares were:

• Window area light: 34%.
• Sky: 11%.
• Hidden ceiling fill: 55%.

The fit reached an R² of about 0.84 only with that virtual fill.

After each iteration, the workflow measures LPIPS and per-object errors, then handles the residual differences in two ways:

• Small errors: add bump detail, retained only where it improves the score.
• Large errors: send the target and re-render to a fresh reviewer, whose proposed geometry edits become the next blockout.

Because each iteration generates a new target, every candidate scene is scored against every target. Otherwise, an easier reference could masquerade as a better scene.

The reported room test kept the middle of three iterations. The final attempt's finer foliage read as polka dots and scored worse.

The fit targets one fixed view, with visible compromises in the published tests:

• Unseen surfaces are filled. Hidden texels borrow from visible texels on the same object. Moving the camera revealed smearing beneath furniture and a flat fill on the far wall.
• Roughness remains weak. The first run rejected PATINA's lighting-dependent roughness; the replacement map was blurry, and a glossy black side table rendered grey.
• Some detail is view-fitted. Bump detail improved the original camera's score but would not fully transfer to another view.

The project's declared scope excludes glass and mirrors, foliage made from primitives, animation and multiple cameras.

The MIT-licensed repository offers a Claude Code plugin and a shared skill installation for other coding agents:

The documented requirements and spend are:

• Runtime: Python 3.10+, the listed Python dependencies and Blender 5.2+.
• API access: a fal key in FAL_KEY. Target generation and decomposition require fal; there is no offline path.
• First room: about $1.47 in fal calls across three iterations.
• Second scene: about $0.49 for one iteration of a separately built home-office scene.

Every paid call passes through a per-case budget and is logged. The privacy notes say images and prompt text go to fal, while .blend files, meshes and texture files are not uploaded.