> ## Documentation Index > Fetch the complete documentation index at: https://docs.summerengine.com/llms.txt > Use this file to discover all available pages before exploring further. # Environment kit skill for AI agents > Generate a modular environment kit: walls, floor tiles, pillars, doors, arches in one visual style. A Summer Engine skill for AI agents. `environment-kit` is a skill from the [Summer skill library](/mcp/skills): a guide your AI agent reads when the task matches, so it builds the good version on the first try. Generate a modular environment kit: walls, floor tiles, pillars, doors, arches in one visual style. | | | | - | - | | Status | Stable | | Domains | 3D models, Asset pipeline | | Version | `1.0.3` | | Engine version | `>=4.6` | | Recommended set | No, installed by `--all` or by name | ## When your agent uses it * Generating a modular environment kit of snap-together pieces that form a level — dungeon kit, modular walls, interior pieces * Building a dungeon, interior, or town kit from repeatable pieces that snap together in one style ## Install `summer setup` installs every skill for your agent. To add only this one: ```bash theme={null} npx -y summer-engine@latest skills install environment-kit --agent claude-code ``` Swap `claude-code` for your agent, such as `codex` or `cursor`. See [Skills](/mcp/skills#quick-start) for every option. ## The skill A kit is a *family* of meshes — wall, floor, door, pillar, corner, arch — that the level designer snaps together to build interiors and exteriors. The skill exists to solve **one specific failure mode**: generating each piece with a fresh prompt produces six pieces that look like they came from six different games. The fix is the **style anchor pattern** — generate one piece first, lock its prompt suffix, and reuse that exact suffix for every subsequent piece. The backing operation is `assets.generate_3d`, called once per piece; each call answers with a job that `jobs.wait` follows. A 6-piece kit is six generations and about 5 minutes. Generation uses credits, so confirm scope before starting (`dryRun: true` on one piece's call gives its credits). ## When to use * "Build me a dungeon kit — walls, floor, door, pillar." * "I need modular wall pieces for a sci-fi corridor." * "Make a tileset for a wooden tavern interior." * "Generate the pieces for a stone temple — I'll assemble the level." * The user wants to build a level out of repeating, snapping pieces. ## When NOT to use * A single hero prop (single chest, single throne) → `prop-model`. * Open-world terrain (rolling hills, forests) → use a heightmap + scattered organic models from `organic-model`. * Repeating flat surfaces only (just walls and floors, no decorative pieces) → `asset-strategy` Pipeline 2 (textures + CSG) is cheaper and snaps perfectly to grid. * Characters or vehicles in the scene — those are separate skills. ## The style anchor pattern This is the whole skill. Get it right and the kit looks unified. Get it wrong and every piece is wasted. 1. **Generate the anchor piece first.** Pick the most visually defining piece — usually the wall or the door. Iterate the prompt until the user approves it visually. 2. **Extract the style suffix.** Everything after the object description. Example anchor prompt: ``` A stone dungeon wall section, mossy granite blocks with iron reinforcements, torch-bracket sconce, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object. ``` The suffix to lock is everything from `Game asset, ...` onward, plus `mossy granite blocks with iron reinforcements, weathered surface, warm torchlight palette` — the material + palette tokens. 3\. **Reuse the suffix verbatim** for every other piece. Only change the object description at the front. \| Anchor: wall | `A stone dungeon wall section, ...` + LOCKED SUFFIX | \| Floor tile | `A stone dungeon floor tile, square, ...` + SAME LOCKED SUFFIX | \| Pillar | `A stone dungeon pillar, square base, fluted shaft, ...` + SAME LOCKED SUFFIX | \| Door | `A stone dungeon doorway, arched, heavy wooden door with iron studs, ...` + SAME LOCKED SUFFIX | \| Corner block | `A stone dungeon corner wall section, two walls joined at right angle, ...` + SAME LOCKED SUFFIX | \| Arch | `A stone dungeon archway with keystone, ...` + SAME LOCKED SUFFIX | If the user says "the door doesn't match the rest", the answer is almost always: the suffix drifted. Check the exact strings. ## Snap-grid alignment Kit pieces only feel modular if they snap to a fixed grid. Pick the grid before generating and tell the user. | Grid size | Use for | Notes | | - | - | - | | **1m** | Tight interiors (dungeons, ship corridors, cells) | Wall = 1×3×0.3m. Floor = 1×1m. Most common. | | **2m** | Standard interiors (homes, taverns, offices) | Wall = 2×3×0.3m. Floor = 2×2m. Halves piece count. | | **4m** | Exteriors and large halls (temples, warehouses, throne rooms) | Wall = 4×4×0.4m. Floor = 4×4m. Quarter the piece count for the same area. | **Critical:** include the dimensions in the prompt. `assets.generate_3d` doesn't enforce them, but Hunyuan respects scale cues — `2 meter tall wall section` produces a mesh that imports near 2m tall. Then verify with `summer_inspect_resource` and scale-correct in the editor if needed. ## Steps ### 1. Confirm scope and pick the grid > About to build a dungeon kit. Suggested pieces: wall, floor, pillar, door, corner, arch (6 generations, \~5 min). Snap grid: 2m (standard interior). OK? ### 2. Generate the anchor (wall) Use the prop-style prompt with explicit dimensions: ``` assets.generate_3d({ prompt: "A 2 meter wide by 3 meter tall stone dungeon wall section, mossy granite blocks with iron reinforcements, torch-bracket sconce, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.", model: "hunyuan", targetPolycount: 1500 }) jobs.wait({ jobId: "", timeoutSeconds: 50 }) // again until finished; result.assetId assets.get({ assetId: "" }) summer_import_asset_by_id(assetId="", path="res://assets/kits/dungeon/wall.glb") ``` Show the result to the user. **Iterate the anchor until approved** — every other piece copies its style. ### 3. Lock the suffix and generate the remaining pieces Once the user says "yes, that's the look", store the locked suffix and crank through the rest. Same model, same `targetPolycount` scale. Only the object description changes. Start every piece first, then wait on the jobs: they run side by side. ``` # Floor assets.generate_3d({ prompt: "A 2 by 2 meter square stone dungeon floor tile, mossy granite blocks with iron reinforcements, weathered surface. Game asset, centered, stylized low-poly game art, warm torchlight palette, white background, isolated object.", model: "hunyuan", targetPolycount: 800 }) # Pillar assets.generate_3d({ prompt: "A 3 meter tall stone dungeon pillar, square base, fluted shaft, mossy granite blocks with iron reinforcements, weathered surface. Game asset, ...", model: "hunyuan", targetPolycount: 1500 }) # Door, Corner, Arch — same pattern. Then jobs.wait on each job id. ``` For each finished job, capture the returned `assetId`, then import that exact ID with `summer_import_asset_by_id`. Do not search for generated pieces by name after creating them; exact IDs are the production path. Polycount targets per kit piece: walls/floors 800–1500 tris (placed dozens of times), decorative (pillar, arch) 1500–3000, doors 2000–3000. ### 4. Import and stage in a kit scene Don't dump the kit into the level scene. Make a `kit_dungeon.tscn` that holds one of every piece, labelled, positioned next to each other on the snap grid. The level designer instantiates from there. ``` summer_instantiate_scene(scenePath="res://assets/kits/dungeon/kit_dungeon.tscn", parent="./KitRoot", scene="res://assets/kits/dungeon/wall.glb", name="Wall") summer_set_prop(scenePath="res://assets/kits/dungeon/kit_dungeon.tscn", path="./KitRoot/Wall", key="position", value="Vector3(0, 0, 0)") # ...repeat for floor, pillar, door, corner, arch with positions Vector3(2,0,0), Vector3(4,0,0), ... summer_save_scene(scenePath="res://assets/kits/dungeon/kit_dungeon.tscn") ``` Three things the shape of those calls encodes: * **A `.glb` is instantiated, not assigned.** There is no `scene` property on `Node3D`, and an imported `.glb` is a scene, not a `Mesh` — `ResourceLoader.get_recognized_extensions_for_type("Mesh")` on the shipped 4.6.1 binary returns `["tres", "mesh", "res"]`, with no `glb`. Use `summer_instantiate_scene`, which adds the model as a child in one op. * **Every scene-mutating tool takes an explicit `scenePath`**, and node paths are relative to that scene's root (`./`). * **`summer_set_prop`'s property argument is named `key`**, not `property`. ### 5. Verify scale and pivots ``` summer_inspect_resource(path="res://assets/kits/dungeon/wall.glb") ``` Check the AABB. If the wall is 1.85m tall when you asked for 3m, scale it in the editor (or re-import with `Scale` in the import dock). Pivots should sit at the *bottom-back* corner for walls and *bottom-center* for floors — that makes snapping to a 2m grid trivial. If pivots are wrong, use the "Center to Origin" import option. ## Anti-patterns * **Drifting style suffix.** Each piece gets a slightly different suffix → the kit looks mismatched. Copy-paste the exact string. * **Different polycount per piece.** A 5k-tri pillar next to a 500-tri wall reads as "the pillar is a hero piece" — wrong; they should feel like equal kit citizens. Match polycount within \~2× across the kit. * **Skipping the anchor approval.** If you generate all six pieces in a batch, you bake in whatever the first call's interpretation of the style was — and the user may hate it after six generations. * **Generating walls / floors as individual meshes when you only need a tileable texture.** A flat wall section is cheaper as a textured `CSGBox3D`. Reserve the kit for pieces that need actual geometric detail (sconces, mouldings, doorways, arches). * **No scale cue in the prompt.** Wall comes back 0.4m tall. Always include `2 meter wide by 3 meter tall` (or your chosen grid). * **Forgetting the snap grid.** A 1.87m-tall wall with no scale fix → level looks crooked when tiled. ## Edge cases * **Curved or organic kit (cave, alien hive).** Modular geometry resists snapping. Generate longer pieces (4m walls, transition tiles) and accept some overlap. Or switch to procedural — `design-level` can scatter cave pieces with rotation jitter. * **Outdoor kit (cliffs, ruins, forest path).** Use the kit pattern but accept rotation/jitter at placement time. Mesh edges should fade naturally rather than snap cleanly. Pair with `organic-model` for foliage scatter. * **Sci-fi kit (corridors, doors, terminals).** The style suffix becomes critical — `clean panels, soft cyan emissive trim, brushed metal, white background, isolated object`. Hard surfaces drift more than organic ones; review every piece. * **The user wants to add a piece later.** The locked suffix lives in the kit's notes (drop it in `assets/kits/dungeon/STYLE.md` if the user wants persistence). Reuse it verbatim for any addition — never re-derive. ## Without Summer Engine In a session without Summer Engine tools (the assets profile; the `summer-assets` skill has the whole loop), do steps 1-3 and skip steps 4-5 (staging in a kit scene). Save the file where the person asked with `out` (the `summer-assets` skill says how), and tell them the path and format. Tell the person the grid from step 1, so they can check scale and pivots in their own engine. ## Fallback (no MCP) 1. Run each prompt at the Summer dashboard (or Hunyuan / Trellis web UIs), keeping the locked suffix. 2. Download each `.glb`. 3. Drop into `res://assets/kits//`. 4. Build the kit-display scene manually in Summer Engine, with one of each piece snapped to the grid. 5. Hand to the level designer. ## Handoff After the kit is staged: > Dungeon kit ready: `res://assets/kits/dungeon/` with wall, floor, pillar, door, corner, arch on a 2m snap grid. Display scene at `res://assets/kits/dungeon/kit_dungeon.tscn`. > > Next: hand off to the level-design step — instantiate kit pieces into `level_01.tscn`, snap to the 2m grid, dress with props (`prop-model`) and foliage (`organic-model`). For lighting, see `3d-lighting`. ## See also * `prop-model` — for the chests, statues, and decorative props that dress the kit. * `organic-model` — for foliage and rocks that break up modular repetition. * `asset-strategy` — Pipeline 2 (textures + CSG) is the cheaper alternative when pieces are flat. * `scene-composition` — how to organize the kit scene and the level scenes that consume it. * `3d-lighting` — interior kit pieces typically need warm point lights at sconce positions. ## From a shell No Summer MCP tools in this session? Run each one as a command; when `summer --version` is missing or below 4.0, use `npx -y summer-engine@latest` in place of `summer`. Fields are flags in kebab-case (`--scene-path res://main.tscn`) or one `--input ''`, and `summer ops describe ` prints the exact input. The `summer-cli` skill has the rest. | In this skill | Command | | - | - | | `assets.generate_3d`, `summer_assets_generate_3d` | `summer assets generate-3d` | | `summer_assets_generate_image` | `summer assets generate-image` | | `summer_assets_get` | `summer assets get` | | `summer_assets_search` | `summer assets search` | | `summer_add_node` | `summer engine add-node` | | `summer_get_scene_tree` | `summer engine get-scene-tree` | | `summer_import_asset_by_id` | `summer engine import-asset-by-id` | | `summer_import_from_url` | `summer engine import-from-url` | | `summer_inspect_node` | `summer engine inspect-node` | | `summer_inspect_resource` | `summer engine inspect-resource` | | `summer_instantiate_scene` | `summer engine instantiate-scene` | | `summer_save_scene` | `summer engine save-scene` | | `summer_set_prop` | `summer engine set-prop` | | `jobs.wait`, `summer_jobs_wait` | `summer jobs wait` | ## Related skills * [`organic-model`](/skills/organic-model): Generate organic 3D shapes (trees, rocks, mushrooms, plants, crystals) where irregularity looks natural. * [`prop-model`](/skills/prop-model): Generate one static 3D prop (sword, barrel, chest, lantern, statue): one object, no rig, a MeshInstance3D. * [`asset-strategy`](/skills/asset-strategy): Route any 'I need a \[thing]' asset request to the right skill: 2D, 3D, audio, video, VFX or animation. *** Source: [`library/skills/environment-kit/SKILL.md`](https://github.com/SummerEngine/summer/blob/main/library/skills/environment-kit/SKILL.md), rendered from `summer-engine@4.3.0` on npm. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.