<!-- Public archive edition: 2026-09-15-first-public-archive; status: research. Local paths and operational identifiers omitted. -->

# Sim Sim — coherent AI-assisted art production

Research checked 15 September 2026. This is a proposed production system for the Mac/PC cinematic game and Blender workflow. No tools were installed, assets generated, subscriptions purchased, or provider performance benchmarked in this research. Capability claims below come from official documentation; pipeline decisions are our recommendations.

## The decision

**Make the editable 3D world the authority. Use AI to help create and improve its parts.**

Independent prompts do not produce a consistent art collection by themselves. Continuity comes from reusing the same character geometry, material families, dimensional rules, animations, light rigs and authored place. A future model can propose a better asset; it cannot silently redefine what the neighbor, Astrobot or terrace is.

For First Light, concentrate the work in one inhabited room and terrace across three mornings. Preserve the original Stillness, Craft and Connection routes, the neighbor, the device, the notebook and the subtle rain/cooling-grid fiction. The brass instrument in the exploratory concept image remains a proposal, not an approved canonical object. See [source distinctions](/about/).

Déoviá's strongest transferable direction is human movement, art and generosity in beautiful places: hands making something, people helping, a smile exchanged across the terrace, changing light on a material touched by its maker. Its warmth should be visible in ordinary play. Do not translate the music-video costume language mechanically into this different game.

## A small production toolset

| Layer | Recommendation | Reason and boundary |
| --- | --- | --- |
| Concept and paintover | Start with the image-generation capability already available, supplying the same approved references for edits. FLUX.2 is a candidate if a separate controllable API becomes necessary. | FLUX.2 officially supports multi-reference editing and distinguishes identity and pose sources. Use this to propose views, costume details and paintovers. References improve adherence; they do not certify identical anatomy, perspective or object construction. [BFL prompting](https://docs.bfl.ai/guides/prompting_guide_flux2), [pose and layout guidance](https://docs.bfl.ai/guides/usecases_editing_controlnets). |
| Canonical modeling, materials and assembly | **Blender**, with versioned `.blend` sources, shared node groups and export presets. | Use Geometry Nodes for bounded repeated geometry and procedural shading nodes for reusable materials. Bake or translate materials for the game renderer, then judge them in the game. A Cycles image is a look-development reference, not proof of runtime appearance. [Geometry Nodes](https://docs.blender.org/manual/en/latest/editors/geometry_node.html), [shader nodes](https://docs.blender.org/manual/en/latest/render/shader_nodes/introduction.html). |
| AI 3D candidate generation | **Meshy**, first tested on a ceramic vessel and one secondary object, using multi-view references. | Current official docs list `meshy-7`, 1–4 views of the same object, separate multi-view texture references and target topology/polycount settings. Actual polycount can differ. Disable automatic image enhancement when preserving reference appearance is the objective; explicitly choose a model version instead of `latest`. All outputs enter Blender review. [Multi-image API](https://docs.meshy.ai/en/api/multi-image-to-3d). |
| Human motion | Blender animation as the maintained source; **Cascadeur** as an optional specialist when motion quality is the bottleneck. | Cascadeur provides AI-assisted posing and physics tools with editable animation/export. Its inbetweening limitations specifically include prop actions, environment awareness and interaction with other characters. A believable potter, shared tool or hug still needs authored contacts and animation review. [Overview](https://cascadeur.com/help), [limitations](https://cascadeur.com/help/category/278), [FAQ](https://cascadeur.com/help/faq). |
| Temporary locomotion / rig baseline | **Mixamo**, only where it saves time. | Adobe describes a free-with-Adobe-ID service for humanoid rigging and animation, permitting use of its characters and animations in games. It does not supply the game's performance style. Keep local source/export copies; the service does not retain a full character history. Check applicable account and redistribution terms for the actual use. [Official FAQ](https://helpx.adobe.com/creative-cloud/faq/mixamo-faq.html). |
| Runtime appearance | The chosen native game engine, using the same approved assets and defined renderer settings. | Unity is the current candidate in the wider architecture review. Beauty must pass in motion in that renderer, on target Mac and PC hardware, with gameplay visible. The asset pipeline should not depend on a provider's proprietary viewer. |

Do not subscribe to multiple competing 3D services immediately. Benchmark the chosen candidate against an artist-authored Blender asset and an appropriate licensed asset, using the same brief. Add Tripo or another challenger only if the first candidate fails an identified requirement. The winning measure is **time and cost to an accepted, editable in-game asset**, including cleanup and failed attempts, not time to a striking thumbnail.

Do not start the main human character by repeatedly generating a whole new person. Establish one reviewed base mesh, face, proportions, garment construction and rig. AI can assist sculpt references, texture proposals and motion; changes to those source assets are explicit revisions.

## The artifact set that actually prevents drift

These are small linked production artifacts, not separate competing master plans.

1. **One-page visual constitution.** The intended feeling, five visual rules, three forbidden patterns and a few approved examples. Proposed rules: warm human activity against cool weather; tangible craft materials; restrained future technology; readable silhouettes; beauty in normal movement. Reject ornamental science-fiction clutter, interchangeable glossy interiors and a permanent spectacle that obscures the game.
2. **One authoritative scene.** A measured Blender room/terrace, circulation plan and six named review cameras. Lock dimensions, entrances, skyline orientation and major prop locations. Concept images illustrate this geography; they do not redefine it.
3. **A light and color script for three mornings.** Neutral material test lighting plus three runtime light/weather states. Define exposure behavior, wetness ranges, fog, shadow readability and restrained highlights. Capture the room both with and without grading so problems cannot hide behind a LUT.
4. **Canonical identity sheets.** One per hero character, companion and signature object. Include neutral front/profile/back renders from the same geometry, scale reference, silhouette, material swatches, face and hand close-ups, rig ID and permitted variants. Generated turnaround images are hypotheses until their geometry agrees.
5. **A material family library.** Begin with a small set such as plaster, timber, ceramic, fabric, foliage and one metal family. Give each physical scale, roughness range, wetness response and a reason for wear. Reuse and vary these authored materials instead of independently generating a texture on every object.
6. **A motion and contact library.** Start with idle breathing, walk/stop/turn, look/listen, sit/stand, reach/take/place, a craft gesture, a helpful exchange and a modest emotional response. Define foot placement, hand sockets, object contacts, interruption behavior and playback speed. Human intention matters more than the number of animation clips.
7. **A sound palette.** A small family of rain, surfaces, room tone, craft sounds, sparse music and companion speech. Preserve voice identity and route readability. Keep the original source and use permission with every voice/music asset; use silence intentionally.
8. **An in-engine acceptance gallery.** The same room, character and prop shown under all three mornings, close and far, still and moving, with UI, reduced motion and the lower graphics tier. Include approved failures as examples: slippery feet, oversaturated skin, repeating plaster, unreadable notebook, rain clipping through the roof.
9. **An asset manifest and decision log.** Every shipped object names its source, contract, revision and evidence. Rejected ideas stay visibly rejected so future agents do not rediscover and promote them accidentally.

The first complete art slice should be a **walkable 60–90 second moment**: enter the room, approach the terrace, notice the neighbor doing something useful, touch or use one crafted object, then recognize a restrained change in the rain. The length is a proposed production test, not an expansion or replacement of the three-morning game.

## Canonical asset contract

Every accepted asset needs a manifest record. The following is a schema example; identifiers and values are proposed, not claims that these assets already exist.

```yaml
asset_id: FL-PROP-001
revision: 1
status: candidate # candidate | accepted | retired
kind: prop
canon_revision: first-light-art-v1
owner: environment-art
purpose: "A useful object that supports an authored interaction"
source:
  method: human_modelled # human_modelled | licensed | ai_assisted
  editable_file: art/source/FL-PROP-001.blend
  source_sha256: REQUIRED
  parent_asset_id: null
  references: [] # IDs and hashes, not loose filenames
generation:
  provider: null
  model_version: null
  prompt_file: null
  request_id: null
  parameters_file: null
  input_hashes: []
  output_hashes: []
  attempt_count: 0
  cost_record: null
rights:
  source_record: REQUIRED
  intended_uses: [game, trailer, player_capture]
  redistribution_scope: REQUIRED
  likeness_or_voice_permission: not_applicable
geometry:
  unit: meter
  bounds_m: REQUIRED
  pivot_rule: REQUIRED
  export_axis_preset: REQUIRED
  lod_policy: REQUIRED
  collider_policy: REQUIRED
materials:
  approved_family_ids: []
  shader_contract_revision: REQUIRED
  texture_budget_class: REQUIRED
  color_space_and_normal_convention: REQUIRED
interaction:
  sockets: []
  collision_layers: []
  animation_dependencies: []
  save_data_dependencies: []
continuity:
  immutable_features: []
  allowed_variations: []
  prohibited_variations: []
acceptance:
  automatic_report: null
  in_engine_capture_set: null
  art_decision_id: null
release:
  engine_import_preset: REQUIRED
  artifact_hashes: []
  rollback_revision: null
```

For a character, additionally require: stable topology/rig identity, approved body measurements and facial landmarks, expression library, clothing attachment rules, hand/foot contact tests and voice ownership. For an environment module: dimensions, seam and snapping rules, collision, lightmap policy and supported placement neighbors. For an animation: rig revision, root motion policy, loop conditions, contacts, interruption window and event markers.

**Preserve the accepted files themselves.** Reusing a seed and prompt does not guarantee byte-identical results after a model, scheduler, backend or exporter changes. Store the exact model version if exposed, request parameters, provider task ID, inputs and downloaded output hashes. A retired API must not make the game unbuildable.

## Production flow

### 1. Design one living place

Block the room and terrace in editable geometry before mass asset generation. Confirm the player can move, see the neighbor, notice the rain and operate the essential objects. Choose the important camera distances from play, not from a marketing still.

### 2. Resolve the visual language on a small representative set

Produce the room shell, one character, the signature device, one crafted vessel, one plant, one fabric and the rain treatment. Their combination must look like one place. Choose an approved visual target and freeze its source references; do not keep mixing incompatible mood boards.

### 3. Build canonical sources

Model or clean up the chosen items in Blender. Fix silhouette, intended dimensions, topology, UV seams, material scale, pivots and required movable parts. The mechanics determine construction: a drawer needs separate geometry and a defined travel range; an object passed between people needs a stable grip and collider.

Create orthographic/turntable reference renders from this geometry. Later AI-generated variants must relate to these exact sources. For hero items, modify the canonical mesh directly instead of regenerating the whole object.

### 4. Use constrained AI proposals

Give each generation job one asset contract, one approved reference pack and one intended change. Example: propose three glaze variations for the established vessel while preserving its silhouette and dimensions. Do not ask for an entirely new room when the task is to improve one lamp.

Bound the whole job's attempts and cost, including retries and provider fallbacks. Exceeding that budget produces a review item. It must not trigger another nested agent that starts the counter over.

### 5. Return to editable sources and a shared material system

AI meshes are raw material. Retopologize where deformation needs it; repair unwanted holes/intersections, separate required components and provide sensible LODs and colliders. Rebuild prominent surfaces within the approved material family when the generated texture has baked highlights, inconsistent grain or scale.

For repeated objects, expose only approved procedural controls: planter height within a chosen range, leaf density, slight wear and color variants. Keep stable seeds and bounded parameters. Authored placement rules protect paths, camera composition and human activity. Future agents may assemble from the kit without inventing a new visual language.

### 6. Validate the actual game appearance

Import using a pinned exporter/importer configuration. Verify scale, orientation, UVs, normals and all material maps. Blender procedural graphs do not automatically become equivalent runtime shaders; bake and rebuild where required, then compare in the target renderer.

Technical checks cover budgets, missing dependencies, invalid transforms, unexpected materials and collision/contact failures. Visual checks compare the named gameplay cameras and motion sequences to approved baselines. A computer-vision score is triage evidence; it cannot by itself decide that a human gesture is emotionally right.

Measure frame time, memory and download size on both target platforms. Establish numeric budgets from that first representative scene and minimum supported hardware, then encode them in the asset contract. A generic triangle limit copied from another game is not a useful substitute.

### 7. Release a versioned art collection

Bundle asset revisions with the build that passed validation. Keep canonical changes separate from bounded variants in the decision log. Material, lighting or face changes require wider review because they can alter many moments at once. A release manifest and previous artifact set make rollback possible without regenerating anything.

Routine variations that stay within an approved contract can flow through automated checks and the agreed release policy. New identities, changes to the visual constitution and uncertain results go to the creative decision surface. This preserves a director's taste without requiring manual approval of every flowerpot.

## What the newest world models are ready for

### Marble: useful spatial exploration and raw 3D material

World Labs documents splat and mesh export, including collider meshes and high-quality textured GLB exports. Its own documentation notes reconstruction holes, uneven or floating geometry, and difficulty with thin, transparent and reflective surfaces. It describes high-quality world files typically around 100–200 MB. These are concrete reasons to inspect and optimize an export before calling it a gameplay asset. [Mesh export and limitations](https://docs.worldlabs.ai/marble/export/mesh).

Use Marble for a spatial mood study, distant-scene experiment or a scene reconstruction candidate. A generated visible world is not yet a scene of separately editable doors, tools, characters, interaction sockets, navmesh and persistent object identities. That is our production-readiness inference. Convert or rebuild required gameplay parts and benchmark the renderer. Do not commit the native game to a splat renderer before this scene proves its lighting, weather, memory and interaction behavior.

### Project Genie: exploration, not our shipping simulation

Google's January 2026 Project Genie announcement calls it an experimental research prototype, lists a 60-second generation limit and warns of control, latency, physics and adherence limitations. Its May 2026 update expanded eligible access globally and added Street View grounding while still describing the product as experimental. Do not repeat the obsolete claim that it is available only to selected research testers or only in the U.S. [Launch and limits](https://blog.google/innovation-and-ai/models-and-research/google-deepmind/project-genie/), [May update](https://blog.google/innovation-and-ai/models-and-research/google-deepmind/project-genie-expands/).

It can inform visual exploration and research. Those sources do not establish a downloadable, editable Unity scene with stable saves, deterministic game rules, hours of continuity and our required interactions. That gap makes it unsuitable as First Light's authoritative runtime today. Reconsider only against a written capability test, not a launch video.

## Rights, privacy and portability checks

These are production questions to answer from the actual provider terms, asset license and permissions at the time of use; they are not legal conclusions:

- May the specific inputs be uploaded to this provider? Personal likenesses, voices, private choreography and commissioned art require their own recorded scope.
- Do the actual plan and asset license cover shipping the game, trailers and player-shared captures? Does the project intend to release editable source assets as part of an open-source archive? Permission to use an asset in a compiled game does not automatically establish permission to redistribute its raw files.
- Are the source references original, licensed or otherwise authorized for the intended transformation? Provider permission does not settle third-party rights in uploaded material.
- What does the provider retain, publish or use for training, and can the job be private? Is the content automatically exposed in a community gallery?
- Can source and final outputs be exported and retained, including skeletons, textures and motion? Can the game rebuild and run if the vendor disappears?
- Does a future model version change terms, provenance or outputs? Pin the accepted release and review upgrades on a representative test set.

Unresolved records keep an asset in `candidate` state; agents use a known cleared fallback instead of silently changing the production source.

## What no generation platform can guarantee

AI cannot promise coherent art direction, identical identity across independent generations, clean deforming topology, accurate hand-object contacts, sensible gameplay collisions, stable lighting across renderers, correct source rights, permanent vendor availability, a fun mechanic or organic virality. A high score from an AI aesthetic judge cannot prove that players enjoy living in the place.

The practical protection is a small canonical asset library, editable sources, bounded procedural variation, native gameplay validation and recorded human creative decisions. **The future-facing achievement is a world that keeps its character while improving, not a world that is continuously replaced.**

## Recommended first proof and acceptance evidence

Build one representative collection before scaling production:

- One room/terrace shell with stable geography.
- One neighbor with a canonical body/face/rig and useful activity.
- One companion/device design, chosen from the original brief rather than inherited accidentally from the concept image.
- One notebook, readable in the game.
- One vessel, one fabric, one plant and one furniture piece.
- One rain/wetness system, tested indoors and under the roof edge.
- Three morning light states.
- One 60–90 second playable walk-and-interact sequence.

The review package should contain the playable build, a short continuous gameplay capture, the same six viewpoints under the three mornings, a neutral-light material/character sheet, the asset manifest, rejected outputs with reasons, total accepted-asset production cost/time and measured Mac/PC performance. It succeeds when the world stays recognizable and pleasant during play, the human action feels intentional, the scene works at its lower graphics tier, and a reviewer can identify the next improvement without inventing another art direction.
