---
title: From Character Concept Art to Animation Frame Sequences
url: https://doc.liz6.com/en/game-development/character-art-to-animation-frames
locale: en
area: game-development
tags:
- game-development
date: 2026-08-27
modified: 2026-08-27
description: 'Transform a character concept art into a stable sprite sheet for idle, attack, hit, and death animations playable in-game: from identity cards and image-to-video, to frame sampling, keying, anchor normalization, and ingestion acceptance.'
---

# From Character Concept Art to Animation Frame Sequences

> The goal is not to generate a video that "looks like it's moving," but to obtain a set of animation resources that can be stably addressed, switched, and reproduced by the game runtime.

This method uses a complete character concept art as the identity baseline, generates short action videos using Gemini Omni Flash, and then compresses the videos into a transparent WebP sprite sheet with a fixed canvas, fixed anchor, and fixed frame count. The actual workload lies not in calling the model, but in pre-generation constraints, action window selection, keying, frame sampling, scale normalization, and per-frame acceptance.

The final pipeline is as follows:

```mermaid
flowchart LR
    A[Character Concept Art] --> B[Opaque Key Color Identity Card]
    B --> C[Gemini Omni Flash Image-to-Video]
    C --> D[Low-FPS Contact Sheet]
    D --> E[Select Clean Action Window]
    E --> F[Adaptive Frame Sampling & Keying]
    F --> G[Unified Cropping, Scale & Foot Baseline]
    G --> H[WebP Sprite Sheet & Action Manifest]
    H --> I[Real-Device Size Acceptance]
```

## Define Applicability Boundaries First

This route is suitable for:

- 2D characters displayed at small to medium sizes in-game;
- Short actions such as idle, attack, hit, and death;
- Performances where the action returns to a static idle state or holds on the final frame after completion;
- Projects where the concept art style is more important than skeletal precision, and the budget is insufficient for frame-by-frame hand-drawing.

It is not suitable for directly handling:

- Close-up hero performances and shots requiring frame-by-face scrutiny;
- Long loops that require pixel-perfect consistency between start and end;
- Actions where weapons must hit specific coordinates along precise trajectories;
- Heavy occlusion, grappling, two-person combat, or complex cloth interactions;
- Projects with strict artistic retouching requirements for the outline and anatomy of every frame.

The key insight is: video models provide a "motion asset" with temporal continuity, not an animation ready for ingestion. The final product comes from subsequent filtering and normalization.

## Why Choose Image-to-Video

The most intuitive approach is to list key poses and generate each frame separately. The actual results usually have three problems:

1. Each frame reinterprets the character; the face, clothing layers, armor plates, weapon length, and body proportions change slightly;
2. Individual frames look fine when zoomed in, but obvious flickering occurs during continuous playback;
3. Each frame interpolation introduces new identity divergences, eventually requiring massive manual retouching to maintain consistency.

The advantage of image-to-video is not that individual frames are prettier, but that adjacent frames within the same generation share temporal context. It still redraws details, but the drift is usually smaller than independent image generation, and you can extract only the most stable 0.5–1.5 seconds from a longer output.

Therefore, this workflow adheres to two principles:

- One video handles only one primary action;
- Do not pursue perfection for the entire video; only look for usable windows with stable identity and clear actions.

Another fully validated route is to convert the character into a Meshy 3D model first, then batch-render frames in Blender.
This works for modeling, rigging, animation, and sprite sheet production, but the final rendering did not pass the 2D artistic quality gate. To avoid disrupting the main workflow, the full experimental review is placed later in the text.

## Prepare the Character Identity Card

### Concept Art Requirements

The character concept art should ideally meet the following conditions:

- Complete from head to toe; the soles of the shoes, weapons, and long hems are not cropped;
- Facing a unified direction agreed upon by the game, e.g., all facing right;
- Face, hairstyle, clothing layers, and signature props are clear;
- Pose is close to a neutral guard stance; limbs do not heavily occlude each other;
- Safe space around the character, especially horizontal space reserved for long weapons and death animations;
- No scenes, shadows, particles, text, or UI.

If you only have a bust portrait, first complete it into a full identity master image. Letting the video model fill in legs, shoes, or weapon ends during the action will almost inevitably cause identity drift.

### Why Use a Solid Color Background

Most video models do not output stable Alpha channels ready for use. Instead of performing generic background removal on complex scenes afterwards, it is better to bake the keying conditions into the input and prompt.

A high-saturation blue `#005AF9` was used in validation because the character subject is primarily warm brown, black-gray, and dark red, which is far from blue in color space. This color is not a standard answer. If the character has blue clothing, cool lighting effects, or cyan edges, switch to green, magenta, or another key color far from the subject's palette.

The identity card should use an opaque canvas of `1280×720`:

1. Save the original RGBA concept art; do not change colors directly on the master image;
2. Composite the character onto the selected key color;
3. Export as a fully opaque PNG;
4. Re-read the file to confirm that canvas size, Alpha, and edge colors have not changed.

Do not give a transparent PNG directly to the model and assume the transparent areas will be preserved. The model may interpret transparent areas as black background, checkerboard, white borders, or a new scene.

### Composition

The identity card only handles character constraints, not the final sprite sheet dimensions. The character should not fill the entire card: attacks extend weapons, hits cause leaning back, and death transitions from a vertical to a horizontal silhouette. Leaving space during the input phase is much more reliable than cropping off hands and feet after generation.

It is recommended to define three invariants first:

- Unified source facing direction;
- Unified approximate foot position;
- Unified visible height range for standing characters.

These three quantities will become part of the sprite sheet manifest during post-processing.

## Generate Action Source Clips with Gemini Omni Flash

The model used in this article is Gemini Omni Flash, with model code `gemini-omni-flash-preview`. It provides image-to-video capabilities via the official Gemini Interactions API. The model is still in Preview; for formal production, you must record the model code and generation date, not just write "Gemini".

Install the official SDK:

```bash
python -m pip install -U google-genai
```

Place the key in the environment variable `GEMINI_API_KEY`. Do not write it into scripts, prompts, or generation logs. Below is a minimal official API call skeleton:

```python
import base64
from pathlib import Path

from google import genai


client = genai.Client()
reference = base64.b64encode(Path("character-key-card.png").read_bytes()).decode()

interaction = client.interactions.create(
    model="gemini-omni-flash-preview",
    input=[
        {
            "type": "image",
            "data": reference,
            "mime_type": "image/png",
        },
        {
            "type": "text",
            "text": Path("attack-prompt.txt").read_text(encoding="utf-8"),
        },
    ],
    response_format={
        "type": "video",
        "aspect_ratio": "16:9",
    },
    generation_config={
        "video_config": {
            "task": "image_to_video",
        }
    },
)

Path("attack-source.mp4").write_bytes(
    base64.b64decode(interaction.output_video.data)
)
```

When the output is large, switch to URI delivery as per the official documentation, and download it locally immediately after generation. Temporary download URLs are not an asset preservation solution.

### Prompts Are Not Action Names, But Constraint Lists

Simply writing "let the character attack" is far from enough. The model will independently add camera movement, enemies, particles, a second attack, or clothing changes. An effective prompt must contain at least six layers of information:

1. **Identity Lock**: Face, hairstyle, body shape, clothing colors and layers, signature props;
2. **Style Lock**: Continue using the 2D painting language of the input image; do not convert to live action, 3D, or another rendering style;
3. **Frame Lock**: Single shot, fixed camera, full body, unified facing direction, and safe zone;
4. **Background Lock**: Key color remains uniform from start to finish; no ground, shadows, scenery, or VFX;
5. **Timeline**: Hold, prepare, action, end pose, recover, or hold on final frame;
6. **Failure Zones**: Extra limbs, second weapon, turning around, costume change, blur, going off-screen, and repeated actions.

You can start with the following sanitized template:

```text
10-second, 16:9, single continuous shot for a 2D game character action.
Treat the input image as an immutable character model sheet and color key.

Keep exactly the same face, hairstyle, body proportions, garment colors,
garment layers, footwear, and signature prop in every frame. Preserve the
same hand-painted 2D illustration style. Never turn the character into live
action, 3D, cel animation, or a different costume.

The full body and the complete prop remain inside the central safe area.
The character faces screen-right for the entire clip. The camera is locked:
no pan, tilt, zoom, shake, lens change, perspective change, or scene cut.
The background remains a perfectly uniform solid key color. No floor,
shadow, particles, blood, text, logo, watermark, attacker, or projectile.

[0.0-1.5s] Hold the input guard pose with only subtle breathing.
[1.5-2.0s] Prepare one clear action while keeping both feet controlled.
[2.0-2.7s] Perform exactly one readable action toward screen-right.
[2.7-3.3s] Hold the completed action pose briefly.
[3.3-4.8s] Recover along a physically plausible reverse path.
[4.8-10.0s] Return as closely as possible to the input guard pose and hold.

Use sharp outlines and a high-shutter look. No motion blur, depth of field,
compression smearing, extra limbs, duplicated props, costume recoloring,
face redesign, body-scale change, background flicker, or second action.
No dialogue, voice, music, or sound effects.
```

Attacks, hits, and deaths cannot be handled by simply replacing a verb. Each type of action must redefine body force, prop state, and ending behavior:

- **Attack**: Only one active action occurs; specify direction, weapon, force path, and recovery pose;
- **Hit**: Attack comes from off-screen; no attacker or projectile appears; the character does not counter-attack, then returns to idle;
- **Death**: Specify losing balance, sinking down, and finally stopping; the character must not stand up or return to guard in the final segment;
- **Idle**: Only allow small movements like breathing, hair tips, and hem swaying; no walking, turning, or camera drift.

Gemini Omni Flash currently does not have independent negative prompts, system instructions, temperature, or `top_p` controls. All prohibitions should be written in the regular prompt. The official documentation also suggests explicitly stating single-shot and no-cut rules, otherwise the model tends to organize multiple shots on its own.

### One Video for One One-Time Action

Do not let the same video sequentially handle idle, attack, hit, and death. While this seems to save API calls, it actually amplifies three problems:

- The model has to maintain identity for a longer time;
- Instant cuts, turning around, or second costumes may appear between actions;
- Failure in any one action drags down the entire video.

A more robust unit is "one character × one one-time action." Generate attacks, hits, and deaths separately. Derive idle animations preferentially from stable hold segments of source clips that have already passed identity review.

## Extract Action Frames from Video

### Select Action Window First, Then Process All Frames

After receiving the MP4, do not immediately key out frames at the full frame rate. First, generate a contact sheet at `2–4 FPS` to quickly check the entire video:

- Which frame does the action actually start?
- Does a second attack or extra recovery appear?
- Where does the face, clothing, or prop change?
- Does it generate an off-screen attacker, lighting effects, a stand-in, or incorrect projectiles?
- Does the character stand up after falling, or suddenly switch to another death pose?
- Which segment is clearest at real-device size?

When selecting the window, prefer shorter over longer. Do not keep useless frames just to fill the model's output duration. An attack in a game usually requires less than one second; the long hold segments provided by the model are only for finding stable entry and exit points.

For example, after selecting the action window, extract candidate frames:

```bash
ffmpeg -y \
  -i attack-source.mp4 \
  -ss 1.40 \
  -t 2.40 \
  -vf "fps=16" \
  candidate/frame-%03d.png
```

### Identity Drift Warrants Discarding the Whole Clip

If any of the following items change significantly in the usable window, regenerate:

- Face, sense of age, or hairstyle;
- Main clothing color, collar, cuffs, and clothing layers;
- Armor plate arrangement, shoulder guard structure, and cloak pattern;
- Weapon length, container count, ropes, or signature hanging props;
- Body proportions, finger count, or limb connection relationships.

Do not take half from two videos with slightly different identities and stitch them into one action. Static contact sheets may not reveal the problem, but continuous playback will form jumps more obvious than slight drift in a single clip.

### Blue Screen Keying and Despill

Simply deleting pixels "close to blue" will leave blue edges on hair, hems, and weapons, and will also swallow semi-transparent brushstrokes. A more stable process involves two steps.

**Step 1: Generate Soft Alpha using Color Distance.**

Let the current pixel be `C`, and the estimated background color be `B`:

```text
d = ||C - B||
t = clamp((d - low) / (high - low), 0, 1)
alpha = smoothstep(t)
```

The background color can be the median of clean frame edge pixels. `low` and `high` determine the transition width between fully transparent and fully opaque areas. Using soft Alpha, rather than a single threshold, preserves hair strands and painting edges.

**Step 2: Reverse-Engineer Background Contamination in Edges.**

Anti-aliased edges are already a mix of foreground and blue screen. You can approximately reverse-engineer using the compositing formula:

```text
observed = alpha * foreground + (1 - alpha) * background

foreground ≈
    (observed - (1 - alpha) * background) / max(alpha, epsilon)
```

After reverse-engineering, suppress residual blue dominance, otherwise blue edges in fast actions will look like extra VFX. This must be combined with the character's color palette: if the character already contains a lot of key colors, automatic despill will harm the subject. In this case, change the key color before generation rather than stacking thresholds afterwards.

### Frame Sampling by Motion Amount

Uniform frame sampling wastes slots on static segments while leaving only a few poses with large differences for the fastest attack phases. A better approach is to allocate frames based on cumulative motion.

A practical implementation is:

1. Extract candidate frames at `12–24 FPS`;
2. Downscale each frame to a low-resolution RGBA feature map;
3. Multiply by Alpha first to prevent the transparent background from participating in the difference calculation;
4. Calculate the mean absolute difference between adjacent feature maps;
5. Add a small base weight to each adjacent interval to prevent static segments from losing all frames;
6. Cumulate the weights, then take target frames at equal intervals of cumulative motion;
7. Force-keep the first and last frames of the action window.

Pseudocode:

```text
energy[i] = base + mean(abs(signature[i] - signature[i - 1]))
cumulative = prefix_sum(energy)
targets = linspace(0, cumulative.last, wanted_frame_count)
selected = nearest_indices(cumulative, targets)
```

This way, fast swings get more frames, short pauses are still preserved, and the final playback is smoother than uniform sampling with the same frame count.

The following specifications can serve as a starting point, not a universal standard:

| Action | Final Frame Count | Playback FPS | Duration | End Behavior |
|---|---:|---:|---:|---|
| Idle | 18 | 10 FPS | 1.8s | Loop |
| Attack | 24 | 30 FPS | 0.8s | Return to Idle |
| Hit | 18 | 24 FPS | 0.75s | Return to Idle |
| Death | 30 | 24 FPS | 1.25s | Hold on Final Frame |

Frame counts should obey action readability and runtime rhythm, not mechanically increase for "smoothness." Source clips already slightly redraw details over time; overly dense sampling increases volume without necessarily improving perception.

### Construct Idle Loops from Stable Windows

Video models can usually maintain an approximately static segment at the beginning or end, but the start and end of the entire video are not the same image. Connecting the start and end directly will cause obvious jumps.

A low-cost method is to extract ten stable micro-motion frames from the beginning of an already approved source clip, and then create a ping-pong loop:

```text
forward  = [0, 1, 2, ..., 9]
backward = [8, 7, 6, ..., 1]
idle     = forward + backward
```

Do not repeat the two turning endpoints, otherwise the endpoints will stay for two beats. This ping-pong is only suitable for reversible micro-motions like breathing, hair tips, and hems; actions with a clear time direction like walking, swinging, or cloth falling cannot be reversed into a loop.

Idle animations are best derived from the same accepted source clip as the attack, reusing the same cropping, scale, and foot baseline. Regenerating a separate idle video might result in another face or another set of clothes.

## Unified Canvas and Runtime Coordinates

### Unified Cropping, Scale, and Foot Baseline

The most underestimated problem after keying out transparent frames is canvas jitter. If each frame is centered and scaled according to its own bounding box, the character will suddenly grow and shrink in place, and the body center will drift left and right.

The correct approach is to treat the "action" as the normalization unit:

1. Calculate the Alpha bounding box for all selected frames;
2. Find the joint range of these bounding boxes;
3. Calculate cropping and scaling only once;
4. All frames use the same cropping, scaling, and horizontal position;
5. Each frame only performs limited vertical alignment based on foot position;
6. Paste the results into transparent cells of the same size.

Validation used `1024×1024` cells and a unified foot line. Specific pixel values can vary, but a single project can only have one clear convention.

### Standing Actions Share the Same Scale Tier

Attacks usually provide the most complete standing motion range. You can save its cropping, scaling, and baseline as the character's standing scale tier. Idle and hit actions reuse this scale tier to avoid sudden height changes when switching between the three actions.

Do not "fill the canvas" for each action separately. A sprite sheet looking larger in isolation does not mean it is more correct when placed in a combat scene.

### Death Actions Use Joint Cropping

Death transitions from a vertical to a horizontal silhouette. Forcing the standing crop usually cuts off the head, feet, cloak, or weapons. Death actions should use their own joint bounding box.

Joint cropping may make the standing start look slightly smaller. The runtime can provide bounded `display.scale` and offset to restore a visible height close to the standing action; this compensation can only solve layout differences caused by joint cropping, and cannot hide severed limbs, truncated weapons, or incorrect composition.

### Foot Baseline Is Not Necessarily the Alpha Minimum

Characters with short hems and normal weapons can approximate the foot baseline as the bottom of the Alpha bounding box. Long spears, floor-length cloaks, tails, or hanging containers may be lower than the feet. In this case, additional foot masks or manual anchors are needed. Incorrect anchors will cause the character to jump up and down to align with props.

### Fix Source Facing, Decide Mirroring at Runtime

All source frames should adopt the same facing direction, e.g., uniformly facing screen-right. Each action manifest explicitly records `sourceFacing`, and the runtime decides whether to mirror based on the character's position.

Do not let some actions face left during generation and others face right, then rely on filenames or visual inspection to guess. Mixing attack directions, weapon grips, and hit leans makes debugging double-flipping at runtime difficult.

## Package Sprite Sheet and Action Manifest

Use standard static WebP sprite sheets at runtime, not Animated WebP. Static sprite sheets are easier to preload, address frame-by-frame, pause on specific frames, and share resources between normal and reduced motion modes.

A simple directory structure is:

```text
animations/
└── actor-a/
    ├── idle/
    │   ├── manifest.json
    │   └── sheet.webp
    ├── attack/
    │   ├── manifest.json
    │   └── sheet.webp
    ├── hit/
    │   ├── manifest.json
    │   └── sheet.webp
    └── death/
        ├── manifest.json
        └── sheet.webp
```

The action manifest should at least contain:

```json
{
  "schema": 1,
  "id": "actor-a.attack",
  "actor": "actor-a",
  "action": "attack",
  "sourceFacing": "right",
  "sheet": "./sheet.webp",
  "frame": {
    "width": 1024,
    "height": 1024
  },
  "grid": {
    "columns": 6,
    "rows": 4
  },
  "playback": {
    "frames": 24,
    "fps": 30,
    "loop": false,
    "end": "return-idle"
  },
  "cues": {
    "anticipationEnd": 8,
    "contact": 13,
    "recoverStart": 17
  }
}
```

`cues` are more important than "how many milliseconds this animation lasts." Combat logic should align damage, hit VFX, hit reactions, and sound effects with the `contact` frame, rather than guessing the action midpoint. When animation speed is adjusted later, you only need to reinterpret the relationship between frames and time, without changing combat results.

Three generation-era artifacts should also be kept alongside the sprite sheet:

- **Contact Sheet**: View all frames at once to review identity and clothing drift;
- **Real-Device Preview**: View under real background, real display size, and real playback speed;
- **Machine Report**: Record frame sampling timestamps, cropping, scaling, baseline, metrics, and output hash.

These are production evidence and do not necessarily all enter the runtime resource directory.

## Quality Acceptance

### Automated Checks Are Suitable for Finding Structural Errors

- Original video duration, resolution, frame rate, and decode status;
- Whether the target frame count is complete;
- Whether each cell's canvas size matches the sprite sheet rows and columns;
- Whether the Alpha bounding box touches the canvas edges;
- Foot baseline drift after normalization;
- Mean, P95, and maximum displacement of character centroids between adjacent frames;
- IoU of adjacent outlines;
- Average sharpness of the action window and loss relative to the original concept art;
- Color drift of the key color background over time;
- Outline and color differences between start and end to judge loopability;
- Whether WebP can be truly decoded by the target browser.

Foot baseline drift can initially target `≤2 px` for `1024²` cells, then calibrate based on character size and artistic style. Centroid displacement and outline IoU should not have a universal threshold across actions: fast swings, restrained hits, and deaths naturally have different motion distributions and are better compared to baselines of similar actions.

### Artistic Quality Still Requires Manual Per-Frame Review

- Is the face, hairstyle, and sense of age still the same character?
- Have the main clothing color, collar, cuffs, and layers changed?
- Have armor plates, cloak tears, patterns, and accessories been redrawn?
- Have props like weapons, containers, and ropes been added/removed, bent, or switched hands?
- Have fingers, joints, and limb connections collapsed in contact frames?
- Is there only one action, and do the direction and force align with gameplay?
- Are there extra attackers, projectiles, particles, or stand-ins?
- Are the anticipation, contact, and end poses clearly readable at actual game size?

The review order is recommended to be: contact sheet first, then loop playback, and finally placing it in a real combat scene. Looking only at large transparent images amplifies details that do not affect the real device and misses scale jumps and rhythm issues that truly affect the experience.

## Common Failures and Handling

**The model performed two attacks in a row.**

The prompt explicitly states "only one action in the entire clip," but the model may still append a second attack to fill the duration. Do not force-use the entire clip; cut off the second action. If the first action is incomplete, regenerate.

**An attacker or light bullet appears out of thin air during a hit.**

The prompt must clearly state that damage comes from off-screen and prohibit attackers, weapons, projectiles, and VFX. If the hallucination only appears before or after the action window, shorten the time window; if it covers the contact frame, discard the whole clip.

**Clothing color or armor structure changes during the action.**

Change the identity description from "same character" to an itemized clothing list, and declare that the input image is simultaneously an unmodifiable character design sheet and color key. If drift still occurs, regenerate; do not patch a few frames from a bad clip.

**Blue halos appear on edges.**

Handle both soft Alpha and despill. The prompt must also prohibit VFX, action arcs, and background gradients, as the model may paint blue motion trails as part of the subject.

**The character suddenly grows and shrinks after per-frame cropping.**

Switch to using a joint crop and single scaling for the entire action sequence. Allow only limited anchor translation per frame; do not allow rescaling.

**Long weapons or mounted objects cross the standing crop boundary.**

Prioritize expanding the identity card safe zone or action cell. If the character scale is correct but only a few frames' props slightly cross the boundary, perform bounded smooth displacement on the entire frame while keeping the character scale unchanged; do not shrink the entire character to accommodate a weapon.

**The character stands up at the end of the death action.**

The death prompt must clearly state that the final segment remains held, and post-processing must also cut off before "standing up." Set the last frame to `hold` at runtime; do not loop the entire death clip.

**The idle loop jumps at the start and end.**

Do not directly connect the start and end of the generated video. Select an internal stable hold segment and use a ping-pong loop without repeating endpoints; if the action has irreversible motion, discard this asset and use a static idle or skeletal micro-motion.

**Slight redrawing is visible when zoomed in, but normal on the real device.**

First confirm the delivery scale. Small-scale combat actors allow local brushstroke changes that do not affect identity recognition, but the face, clothing outline, and signature props must not drift. The quality gate should revolve around the usage scenario, not pursue every frame being able to serve independently as character concept art.

## Review of Meshy + Blender 3D Intermediate State Solution

To confirm whether the 3D route could provide more stable sequence frames, the following production chain was also fully validated:

```text
Character Concept Art
  → Standard T-pose Multi-view
  → Meshy Generates Textured 3D Character
  → Auto-rig Standard Biped Skeleton
  → Generate or Reuse Actions and Mount Weapons Separately
  → Blender Fixed Camera Batch Render
  → Transparent Frames, WebP Sprite Sheet, and Action Manifest
```

This validation did not stop at model previews. The experiment actually produced a bindable model, idle, attack, hit, and death animations,
and completed two-handed weapon mounting, orthographic camera auto-framing, transparent background rendering, and browser preview. The four sprite sheets total 31 frames,
all entered into a unified `1280×720` canvas, and passed safe margin checks. Actions are recognizable, frame-to-frame structure is stable, and offline re-rendering
can reproduce the results. From an engineering perspective, this pipeline has run successfully.

These frames were not adopted in the end because they did not pass the artistic quality gate.

### Pipeline Passed, Final Product Failed

| Acceptance Layer | Actual Result | Judgment |
|---|---|---|
| Model & Texture | Multi-view input successfully generated usable mesh, front, side, and back structures complete | Pass |
| Skeleton & Animation | Four types of actions playable, attack action and two-handed weapon relationship recognizable | Pass |
| Rendering & Packaging | Fixed camera, transparent frames, unified anchors, sprite sheet, and action manifest all produced | Pass |
| Real-Device Size Comparison | Character identity, outline temperament, and painting texture significantly weaker than concept art | Fail |

This result is easily masked by "the animation actually moves." Looking at the 3D candidates alone, they are complete game characters; the gap only becomes concentrated when placed in the same scene, same foot line, and same display size as the concept art assets. Concept art has a wide and low combat silhouette, dark shading, and damaged, feathery, and irregular edges on clothing and armor; 3D candidates are more upright and symmetrical, with neat clothing layers, continuous outlines, and more uniform lighting and materials. The action semantics are preserved, but the character's visual identity is not.

### First Quality Loss Occurs Before Modeling

To improve the success rate of auto-modeling and rigging, the input must first be organized into a standard bipedal character: T-pose or A-pose, clear limbs, consistent front, side, and back views, and weapons, cloaks, ribbons, and complex occlusions removed. This is a reasonable 3D production input, but not necessarily a faithful input to the concept art.

The most recognizable parts of the concept art are often these "non-standard" details: skewed center of gravity, composition stretched by weapons, broken armor, overlapping plates, exaggerated hand/foot proportions, and ink blocks that only exist in the current perspective. When organizing the character into a clean neutral stance, what is deleted first is not noise, but outline language. Even if multi-views are supplemented, the added back and side views can only ensure view consistency, not automatically recover designs that have been normalized away.

This also explains why "giving more views" did not solve the final problem. Multi-views reduce 3D reconstruction ambiguity, but do not guarantee that the new settings still possess the expressiveness of the concept art.

### Second Quality Loss Occurs in the 2D-to-3D Translation

Comparing the experimental multi-view input and Meshy model, we can see that clothing categories, armor positions, and character proportions are basically preserved,
but details are continuously averaged: faces become closer to generic templates, armor and clothing folds lose layers, edges change from broken brushstrokes to continuous surfaces, and dirt and local color differences are compressed into more uniform textures. The mesh is very stable during action, but it is stable on a character that has already become more ordinary.

This is caused by different goals between 3D reconstruction and 2D painting. Auto-modeling prioritizes finding closed, continuous, texture-mappable, and riggable surfaces; concept art can rely on gaps, soft edges, large dark areas, and perspective-limited exaggerations to exist. The former interprets the latter's painting techniques as geometry or texture, and then normalizes the undetermined parts. Increasing frame-to-frame stability does not make up for this information loss.

### Third Quality Loss Is Amplified at Real-Device Size

Blender rendering already uses transparent backgrounds, fixed orthographic cameras, tone compression, and unified downsampling, but these processes can only unify output specifications, not turn 3D surfaces back into concept art brushstrokes. When scaled down to the actual game size, faces and fine textures are almost invisible; what truly determines perception is the outer outline, light/shadow blocks, and action center of gravity. Concept art has clear designs in these three aspects, while 3D candidates present a clean, continuous, and standard game model visual language, thus looking like they come from two different asset libraries compared to 2D characters on the same screen.

Outlines, paper textures, color grading, or NPR materials can change the rendering surface, but cannot recover cloak shapes deleted in the input stage, nor automatically reconstruct the broken edges, asymmetric color blocks, and facial expressions in the concept art. To achieve the same quality, one must return to the character level to retopologize, repaint textures, design specialized materials, and manually retouch keyframes. This can become an effective 3D-to-2D art pipeline, but it is no longer the automatic solution of "handing concept art to Meshy, then framing in Blender."

### What This Route Is Still Suitable For

In this experiment, the action master, weapon trajectories, camera, and sprite sheet tools all retain value for continued use. 3D results are suitable for:

- Action rhythm and center of gravity reference;
- Two-handed weapon grip and trajectory verification;
- Camera, placeholder, and collision range pre-visualization;
- Projects where the final art style already accepts 3D, 2.5D, or unified NPR.

But for the final pixels based on hand-drawn 2D concept art as the identity baseline, the acceptance order should be "first look like this character, then check if the action is stable." These 3D candidates are exactly the opposite: the action and engineering specifications are qualified, but the visual quality of the character itself has significantly declined.
Therefore, they are retained as action research and did not enter formal assets. This failure also determined the acceptance priority for subsequent workflows: first maintain character identity and 2D art style, then handle frame-to-frame stability.

## Production Records and Sanitization

To enable future reproduction, it is recommended to save:

- Model code, generation date, and official SDK version;
- Sanitized prompt templates and action differences;
- Content hash of the input identity card and original video;
- Reasons for adoption and rejection;
- Final action time window and candidate sampling rate;
- Key color, keying thresholds, and despill versions;
- Cropping, scaling, foot baseline, and source facing;
- Frame count, playback FPS, action cues, and sprite sheet hash;
- Manual review conclusions and target runtime screenshots.

Input concept art should only use self-owned works or materials with clear authorization. Officially generated videos carry invisible SynthID source markers; internal production records should continue to retain the model and input source, not using "already sampled into frames" as a reason to discard source information.

Public experience documents do not need to save:

- API keys, authorization headers, and temporary download URLs;
- External task IDs, internal project IDs, and supply chain routes;
- Real character names, worldview nouns, and unreleased asset paths;
- Single costs, account information, and private storage addresses;
- Complete prompts and original images that can reverse-engineer unreleased content.

Internal projects can retain complete production records; public documents only extract methods, boundaries, and transferable parameters.

## Minimum Acceptance Checklist

Before Generation:

- [ ] Concept art is complete, without cropping feet, hems, or props;
- [ ] Key color has sufficient distance from the character's main palette;
- [ ] Identity card is fully opaque, character is in the safe zone;
- [ ] Prompt locks identity, style, camera, background, timeline, and failure zones separately;
- [ ] Each video is assigned only one primary action.

During Processing:

- [ ] Check low-FPS contact sheet first, then determine action window;
- [ ] Discard entire window if identity or clothing drifts;
- [ ] Use soft color key and despill, do not use hard threshold keying;
- [ ] Sample frames based on cumulative motion;
- [ ] Calculate cropping and scaling only once for the same action;
- [ ] Standing actions share scale tier, death actions use joint cropping;
- [ ] Source facing, foot baseline, and end behavior written to manifest.

Before Ingestion:

- [ ] Contact sheet checked frame-by-frame for face, clothes, armor, and props;
- [ ] Sprite sheet frame count, grid, and manifest are consistent;
- [ ] No severed limbs, truncation, blue edges, or transparent dirty spots;
- [ ] Playback passes under real background and real display size;
- [ ] Attack contact frame, hit reaction, and death hold frame align with runtime rhythm;
- [ ] Browser can decode WebP, with static fallback frame on failure.

## Conclusion: The Final Product Is an Animation Contract

Video models solve "making the same 2D character produce continuous motion"; game production also needs to solve "which frames are usable, how to align, how to play, when to hit, and how to degrade on failure."

The truly reusable result is not a single generated video, but this set of stable constraints:

- Same identity card;
- One action per source clip;
- Clean time window;
- Adaptive frame sampling;
- Unified scale and anchors;
- Explicit playback manifest;
- Automated metrics plus manual identity review.

As long as this contract is stable, the video model can be upgraded, the number of actions can increase, and the runtime does not need to be rewritten.

## References

- [Gemini Omni Flash: Official Guide to Generating and Editing Video](https://ai.google.dev/gemini-api/docs/omni)
- [Gemini API: Overview of Video Generation Models](https://ai.google.dev/gemini-api/docs/video)

*Keywords: Game Development, Character Animation, Action Frames, Sprite Sheet, Image-to-Video, Gemini Omni Flash, Chroma Key, Adaptive Frame Sampling, Foot Baseline, Animation Sprite Sheet, WebP*