sadfrog71/animated-scene-craft

3D Animated Scene Production

Treat the scene as an environment with purpose, spatial relationships, and temporal change. Proactively identify the subject to highlight, the details to refine, and the objects that should move, without waiting for the user to point them out one by one. This proactivity is used to complete authorized scenes, not to arbitrarily change the theme, function, or delivery format.

Execution Entry

When asked to create or modify, read Software, Skills & Execution Path, select the path matching the delivery, and actually execute it; do not only output aesthetic suggestions or prompts. For pure analysis requests, only use the judgment principles below.

This skill provides scripts/scene_tool.py: probe checks the environment, inspect reads the scene, run executes the production script and saves the project, render outputs still frames or sequences, encode creates a normal-speed video. It calls Blender/FFmpeg and is not responsible for arbitrarily deciding geometry or animation; the specific production script is written by the current task based on the judgments below, reusing existing skills for specialized capabilities.

The sequence is: check input and tools → concept render design and confirmation (reuse confirmed goals) → gray-box spatial check → representative scene completion and runtime validation → extension and iterative comparison → deliver source files and evidence. Take the required steps for the task phase; partial corrections of an existing scene do not retrace the entire workflow.

Determine Current Delivery and Reuse Boundaries

First, inspect the existing scene, reference images, cameras, confirmed requirements, and target device. Distinguish between concept draft, editable 3D model, offline animation, real-time scene, and fixed-perspective layer animation; only complete the phase requested by the user.

• Reuse confirmed composition, models, materials, animations, and project organization; targeted optimization should not become a full-scene redo.
• Clarify what the viewer will do, where they view from, if they can move, viewing distance, dwell time, and output size. Only ask questions when there are gaps that would change the goal or cause obvious rework; for ordinary details, make evidence-backed choices independently.
• For free movement, parallax, occlusion changes, or strict multi-view consistency, use a shared 3D space. Fixed-perspective layer animations are only suitable for constrained views; explain the delivery differences before adoption and do not call them full 3D scenes.
• First check available tools and corresponding skills. Select required capabilities for modeling, texturing, procedural generation, image editing, and engine implementation; do not assume dependencies are installed, that a specific MCP is used, or that the production platform is switched.

Concept Render Confirmation and Completion Check

When creating a new scene, doing a major visual overhaul, or needing to verify visual completion, read Visual Goal & Completion Verification. When establishing a new art direction, first use ImageGen to actually generate concept renders and display them; only after confirmation proceed with detailed modeling and batch production. For multi-perspective exploration, reuse game-scene-visual-exploration as needed. If the user has already confirmed goals, reuse them directly without requesting confirmation again. If the user explicitly skips concept renders or only requests a gray-box / technical validation, execute within that scope and note that there is no visual goal baseline yet.

Keep the confirmed goal image, the previous version's actual render, and the current version's actual render for comparison at comparable camera positions. ImageGen improvement drafts are design suggestions and cannot replace actual runtime evidence or change the acceptance goal without confirmation. Check space, representative scenes, and overall delivery separately; do not wait until all individual assets are complete before seeing the combined result for the first time.

Form Production Judgment First, Then Generate or Model

Internally form a concise scene judgment. For complex tasks, key judgments can be shown to the user; it is not mandatory to output the full table every time.

Judgment	Content to Implement in Production
Purpose & Behavior	What the person or main entity does here; operation sequence, arrival path, reach range, contact points
Visual Center	What the current view should first see, what supports it, what should recede to the background
Space & Camera	Scale, adjacency, sightlines, occlusion, depth of field, camera movement, interface margins
Key Details	Which structures, materials, and placement relationships determine credibility when viewed up close
Dynamic & Static	Source of motion, objects that receive motion, fixed constraints, response variances, and stable reference points
Delivery Constraints	Real-time or offline, target device, resource budget, editability, and scope of acceptance for this round

Translate goals like "refined, solemn, lively, tense" into observable conditions; do not just write style adjectives. The visual center changes with task and camera; do not force a single focus for the entire scene.

Make Important Things Visible

Guide attention through position, scale, silhouette, light/dark contrast, color, material, negative space, and motion. Select a set of means consistent with the scene; do not make every subject brighter, larger, or more saturated.

• First check composition and spatial relationships, then add materials, details, and lighting. Structural or proportion errors cannot be masked by bloom, depth of field, fog, or decoration.
• The main subject must be recognizable at the actual viewing distance; supporting objects explain purpose, and the background provides spatial context. Not every area should have equal detail density and dynamic intensity.
• For interactive elements, key objects must be visible, reachable, and identifiable; interface overlays, subtitles, or safe zones must not obscure critical operations.
• Faithfully serve the user's specified style. Realism can come from causal and relational consistency; not every scene must be photorealistic or covered with worn textures.

Infer Details from Usage Process

For key areas, mentally simulate the real usage process: how to approach, sit or stand, pick up an object, operate it, put it back, and leave. For non-human or non-daily scenes, use their own activity and physics rules; do not forcibly apply human scale.

Check these relationships that truly affect credibility:

• Structure: Connections, thickness, support, gravity, opening/closing, contact shadows; avoid floating, interpenetration, and unusable arrangements.
• Operation: Motion space for hands or actuators, relative positions of objects, pathways and accessibility; do not fix left/right hand habits without evidence.
• Material: Material scale, edges, roughness, translucency, fluid surfaces, and contact points. Add wear according to the scene's state; do not default every object to being dirty or worn.
• Semantics: Objects consistent with the location, era, and activity; do not invent religious, cultural, or professional artifact rules; when uncertain, check reliable references.
• Viewing Distance: Allocate budget to objects that will genuinely be approached, looked at, or operated; distant views prioritize silhouette and grouping; do not create micro-details that will never be seen.

For example: a ceremonial space checks the relationship between central furnishings and surrounding objects; a writing area checks paper, pen, ink, and arm resting point; a workbench checks tools, workpieces, and operation margins; a product display checks seams, buttons, and material. Examples illustrate the reasoning method and do not constitute a checklist of objects for all scenes.

Make Motion Have Cause, Focus, and Boundaries

When the scene involves dynamics, read Motion Identification & Review. The AI, combined with actual images, scene structure, and gameplay, proactively identifies expected motion, trigger responses, and objects that should remain static; do not wait for the user to list them one by one, and do not only check animations that are already authored. After static concept renders are confirmed, supplement dynamic intent in the production judgment; visual confirmation does not equal animation approval.

"Making things move" does not mean making every object loop. Determine which motions add value to the current scene based on wind, gravity, fluids, heat, mechanical drive, character actions, or narrative intent. Recognize that stillness itself can be the focus.

For each primary dynamic, determine: source, fixed point or support, direction, amplitude, rhythm, phase, mutual influence, visible range, and looping method. Document as needed by the task; do not force a table for every leaf.

• Objects under the same driving force should be related but not mechanically synchronized: mass, stiffness, length, damping, and occlusion differ, so responses differ.
• Distinguish between displacement, deformation, material changes, lighting, and particles. Water surfaces, waterfalls, steam, smoke, fire, cloth, and machinery each have different rules; do not apply a single oscillation formula.
• Fixed points, rigid bodies, and contact relationships must remain reasonable. Hanging objects pivot around their attachment point; attached text or decorations follow; the top of cloth and its free end should not move with the same amplitude.
• Check for interpenetration, detachment, deformation, occlusion, and loop discontinuities within the motion envelope. For multiple cameras, use the shared scene and consistent time relationships; do not generate contradictory animations separately.
• Control attention competition: environmental dynamics support the subject; only increase the salience of relevant dynamics when the task requires emphasizing an operation or event.
• Real-time scenes support pause, resume, background processing, and reduced dynamics as required by the host. Offline films check frame rate, time sampling, and loop continuity; do not impose application lifecycle interfaces.

For fixed-perspective layer or shader animations, additionally check mask edges, sampling ranges, reflections, and occlusions: adding displacement might bring building colors from the background into the sky, or stretch the edges of static objects. Do not replace object motion with full-screen shake.

Real-Time Game Animation Production and Integration

When involving characters, creatures, mechanisms, or interactive animations, read Real-Time Animation Production & Integration. It explains the responsibilities of behavior, displacement, and pose; animation transitions, source file and exported asset consistency; and target device validation. Purely static scenes or offline animations need not read it.

• Determine action requirements from player operations and observable feedback. First complete one representative "input → state change → action/feedback → end or interrupt" segment, then expand to similar content. Environmental loops do not enforce win/loss, combat, or state machines.
• Animation serves gameplay and style: action games focus on anticipation, contact, recovery, and interruptible timing; exploration, puzzle, or management games focus on operation feedback, readability, and state continuity; do not apply a uniform rhythm.
• This skill is responsible for scene and animation, not for replacing full gameplay development. When the user requests a complete game, link within the existing project to the corresponding gameplay and verification skills, deliver an actually playable flow, and not just a scene preview. See execution.md for specific paths.

Generation and Implementation

First resolve space, composition, and subject, then complete key details and animation. For local modifications to already finalized parts, make direct edits; do not mechanically retrace all phases.

When generating images, organize the prompt as below, tailoring it to the actual task:

Reference and purpose; content that must be preserved; specific changes for this iteration; subject position, proportion, and spatial relationships; structural and usage details of key objects; material, lighting, and visual hierarchy; camera, output, and interface margins; changes that are not allowed.

• First actually inspect the input image to determine if it is a style reference, layout guide, or source for editing. For local modifications, prioritize editing the confirmed source image; after generation, verify that non-target areas have not drifted.
• Inspect small objects, thin rods, paper surfaces, text, joints, and building seams up close; correct blurry pseudo-details or irregular shapes promptly.
• Dynamic, editable, or business-driven text is typically drawn with real text/scene objects; do not bake it into the generated background.
• When only a concept image is available, do not promise geometric consistency, editable models, or runtime performance. If production does not achieve the desired result, explain the specific limitations; do not use prompts, still frames, or parameter tables to pass off as finished animation.
• Measure real-time performance on the target device; prioritize using existing capabilities like instancing, LODs, and baking for identified bottlenecks; do not assume generic triangle counts or frame rate budgets.

Acceptance and Stopping

Separate technical execution from visual effect. Pixel changes, time progression, or render success only prove execution, not that the animation is perceptible or the scene is credible. Check content, spatial composition, art, dynamic interaction, and runtime fidelity separately for the current phase; use PASS / PARTIAL / FAIL / BLOCKED and provide corresponding evidence; unverified items cannot count as passed. See Comparison Methods & Completion Conditions for details.

1. Check at actual viewing perspective, size, and normal playback speed: first impression focus, close-up details, visibility of motion, subject occlusion. When comparison is needed, keep a baseline with the same camera, lighting, and playback duration.
2. Check key objects for function, support, and contact relationships; check objects that should not move and animation edges. For free-view scenes, add necessary side, back, and movement checks.
3. Per Motion-Specific Checks, verify missing expected motion, actual motion versus static reference, then observe full animation/loop and trigger transitions. Do not set a uniform playback time; do not use fast playback to prove visibility at normal speed.
4. Verify against deliverables: offline output checks the fully exported segment; real-time scenes check actual loading, operation, pause/resume, and performance on the target device. Clearly mark untested devices or processes.
5. Deliver openable source files or runtime results, along with necessary dependencies, versions, resource lists, and previews. When native functionality and scene layers are separated, provide resource and control interfaces; avoid duplicate audio, text, or business state.

For revisions, first address the biggest issues affecting usage and visual impression; do not keep adding decorations to replace corrections. Stop when the current round's goals are met; report the verified scope and remaining limitations; do not automatically expand the entire environment or upgrade the project structure.