인게임 캐릭터를 색깔 원에서 그림으로 바꾸는 작업의 기록.
움직이는 그림은 따로 있다
서 있는 그림(도트·회전 시트)은 여기, 뛰는 그림은 달리기 애니메이션 에 있다. 그쪽은 산출물이 갱신될 때마다 자동으로 다시 쓰인다.
🔴 이 문서는 하다가 알게 된 것을 남기는 자리다. 계획이 아니라 실측이다. 수치(가중치·해상도)는 코드가 정본이라 여기 옮겨 적지 않는다 —
scripts/art/를 본다.
✅ 2026-08-27 — 만드는 순서를 나눴고, 게임이 뭉개던 것을 고쳤다
사장님 지적: “니가 만든거보다 내가 gpt 한테 직접 만드는게 훨씬 나은데?” — 맞았다.
🔴 갈린 것 하나 — 단계를 나눈다
Claude 는 한 번에 “회전 시트를 만들면서 도트화도 해라” 를 시켰고 GPT 는 둘 다 어중간하게 했다. 사장님은 나눠서 시켰다. 그리고 레퍼런스 그림을 직접 넣었다 — 이게 결정적이었다. 말로 “블록 10px · 아웃라인 10~20px” 이라 적는 것보다 그림 한 장이 이긴다.
원본 일러스트 → 도트화 → 스프라이트 → 5방향 회전 시트
(게임 밖) └──────── 인게임용 ────────┘
사장님이 던진 한마디가 스펙이 됐다 — “서양 똥겜 캐릭터처럼 나오더라고.” GPT 가 그걸 받아 배제 목록을 만들었다: 서구 인디게임풍의 사실적인 얼굴 · 거친 윤곽 · 3D 렌더 · 흐릿한 픽셀. Claude 가 만든 것이 정확히 그거였다.
| 도트화 | 스프라이트(투명) | |
|---|---|---|
| 엘라 |  |  |
2026-08-27 기준 여섯 명 전부 도트화까지 나왔다 — 하루 · 리안 · 세이 · 미르 · 노아. 회전 시트는 엘라만 있다. 각 인물 문서 참조.
✅ 뽑기 전에 정할 것이 둘 다 정해졌다 (2026-08-27).
회전 시트는 도트에서 파생되므로 이 둘이 먼저 정해져야 두 번 일하지 않는다. 이제 뽑아도 된다.
⚠️ 리안의 긴 머리 판도 바리에이션으로 등재됐지만 회전 시트의 원본은 트윈테일이다.
🔴 갈린 것 둘 — 게임이 캐릭터를 뭉개고 있었다
사장님 지적: “픽셀 고정값을 넣지 말고, 기기의 화면에 따라서 상대값으로 달라져야하는거 아니야?” 맞았다. 원인이 둘이었고 헤드리스로 직접 재서 잡았다.
| 원인 | 무엇이었나 |
|---|---|
| 고해상도 화면에서 절반 해상도 | 캔버스가 resolution: 1 이라 CSS 픽셀 크기로만 그려지고 브라우저가 DPR 배로 부드럽게 늘렸다. 캐릭터만이 아니라 바닥 격자선까지 번졌다 |
| 소스의 87% 를 버림 | 소스가 96px 인데 데스크톱에서 2~3배로 확대해 그렸다. 회전 시트엔 766px 이 있는데도 |
고친 방식: 소스를 512px 로 올리고(사장님 지시 “최대 512px”), 배율을 매 프레임 곱하는 대신 텍스처를 표시할 크기로 한 번 줄여 두고 1:1 로 그린다. 정수 스냅을 없앴는데도 떨림이 안 생긴다 — 소수배 표본 자체가 사라졌기 때문이다. 덤으로 창 크기에 따라 계단으로 점프하던 것도 없어졌다.
⚠️ 알려진 한계: 배율이 다른 모니터로 창을 옮기면 그 화면에서 다시 흐려진다. 런타임에 해상도를 바꾸는 코드는 검증할 모니터가 없어 넣지 않았다. 회귀는 아니다 — 예전엔 모든 화면에서 항상 흐렸다.
코드·검수 기록은 저장소에 있다. 자산 설치는
scripts/art/sheet-to-sprites.py한 줄이다.
✅ 2026-08-26 — 엘라가 게임 안에서 움직인다 · 화풍 확정
엘라 의 8방향 도트가 인게임에 들어갔다. 색깔 원에서 그림으로 바뀐 첫 캐릭터다.
🔴 사장님 확정: “여기서 너랑 만든걸로 갈거야. 그걸 레퍼런스 / 베이스로 해서 남은 캐릭터의 픽셀아트도 같은 방향으로 진행한다.”
미르(근거리) · 노아(탱커) 도 같은 레시피로 만든다. 등신(6~7) · 생성(회전 시트) · 축소(Lanczos) · 크기(96px) 전부 동일하다.
⚠️ 같은 날 다른 세션이 치비(~3등신) ControlNet 경로를 따로 만들었다. 화풍은 이쪽으로 정해졌고 그쪽은 배선과 포즈맵 계산만 남긴다(지우지 않는다 — 다른 데 쓸 수 있다).
인게임 스프라이트 8방향(→ ↘ ↓ ↙ ← ↖ ↑ ↗). 186×512px(2026-08-27 에 96px 에서 올렸다).
🔴 경로가 통째로 바뀌었다. 아래 절들은 대부분 역사다.
| 그때까지 (~2026-08-25) | 지금 | |
|---|---|---|
| 만드는 법 | ComfyUI · Blender 3D · ControlNet · IPAdapter | fal openai/gpt-image-2/edit 회전 시트 한 장 |
| 비용 | GPU 시간 · 8일에 8장 | $1 · 호출 1회로 8방향 |
| 도트화 | pixelize.py (최빈색 축소) · 12~16색 | Lanczos 축소 · 양자화 없음 |
| 크기 | ~48px | 512px (2026-08-27. 그 전엔 96px) |
8월 내내 못 풀던 것이 구조로 풀렸다. 방향마다 머리색·의상이 흔들린다 가 문제였는데, 5방향을 한 장 안에서 같이 뽑으니 흔들릴 수가 없다(인물 높이 편차 ±0.5%).
채택한 원본 시트(2026-08-27 판). 정면 · 45° · 측면 · 135° · 뒷모습. 나머지 3방향은 좌우 미러로 얻는다.
🔴 하루에 네 번 헛돌았다
pixelize.py를 썼다 — 그건 3D 렌더용이다. 7×7 블록에서 최빈색을 고르니 얼굴처럼 세밀한 곳은 사실상 아무 색이나 집는다. 이미 도트인 그림에 쓰면 안 된다.- 16색으로 깎았다 — 원본이 이미 AI 가 그린 도트라 깎을 이유가 없었다.
- 시트를 바꾸고 방향 매핑을 재사용했다 — 시트마다 회전 방향이 다르다. 좌우가 뒤집혔다.
- 도형용 연출을 그림에 얹었다 — 스쿼시·런지·흰 타원 전부. 육즙이 아니라 왜곡이 됐다.
움직임이 부드럽지 않았던 원인 다섯
도형일 때는 안 보이다가 96px 그림에서 전부 드러났다. 하나씩 재서 잡았다.
| 증상 | 원인 | 실측 |
|---|---|---|
| 울렁거림 | 스쿼시·호흡이 매 프레임 배율을 바꿈 | 크기 고정으로 해결 |
| 잔상 | 스프라이트 위치만 정수 반올림 → 격자·적·컨트롤 링과 좌표계 불일치 | 위치는 실수로 |
| 버벅임 | 렌더 보간 부재(시뮬 60Hz vs rAF 위상 불일치) | 틱 0회 16% · 2회 15% → 0.8% · 0.5% |
| 부르르 떨림 | 비정수 배율 — 96행을 115행에 밀어 넣어 19행 복제, 위치가 매 프레임 이동 | 정수배 스냅 → 1.0× / 2.0× |
| 공격 후 급증 | 런지 오프셋 — attack 이 뒤로 5 · 앞으로 13 만큼 캐릭터를 민다 | 델타 편차 5.801 → 0.940 |
교훈 하나로 줄이면: 색깔 도형에 맞춰 튜닝한 연출을 그림에 얹지 마라. 움직임은 실제 프레임이 져야 한다.
⚠️ 아직 완전하지는 않다 — 사장님이 “아직 버벅임이 있는 부분은 있다” 고 했다. 남은 몫이다.
레시피 전문·프롬프트·콘텐츠 필터 회피 어휘는 저장소에 있다:
docs/handoff/2026-08-26-ella-sprite-recipe.md원본 시트는games/gangnam-survivors/art/sprite-sheets/에 커밋해 뒀다(다시 사지 않으려고).
아래는 2026-08-25 까지의 기록 (역사)
⚠️ 여기부터는 Blender·ComfyUI 경로다. 인게임 스프라이트에는 더 이상 쓰지 않지만, 위키 공식 일러스트와 얼굴 텍스처에는 계속 쓴다. 지우지 않는 이유가 그것이다.
무엇이 필요한가
캐릭터 한 명당 5클립(idle · run · attack · hurt · down) × 4방향.
좌우를 뒤집어 8방향을 만든다. 상태기계는 이미 코드에 있고(src/anim.ts),
지금 비어 있는 것은 그림뿐이다.
🔴 목표 화질 — 하데스 정도 (사장님 확정 2026-08-17)
“원본 위키 이미지의 특징과 스타일을 유지한채로 2d화 / 게임 내 스프라이트는 하데스 2d 정도로만”
목표가 둘이고 방향이 서로 다르다:
- 지킨다 — 위키 원본 컷의 특징과 화풍. 머리색·머리모양·눈·의상 색·실루엣이 같은 사람으로 읽혀야 한다.
- 낮춘다 — 화질. 하데스(Supergiant) 수준의 손그림 2D면 합격이다. 컨셉 일러의 밀도까지 갈 필요가 없다.
이게 지금까지의 목표를 바꾼다. 8/17 파일럿까지는 컨셉 일러를 그대로 회전시키려 했는데, 하데스 기준이면 그럴 필요가 없다. 인게임에서는 작게 보이고, 그 크기에서 정체성을 지는 것은 얼굴 디테일이 아니라 실루엣과 색 덩어리다. 요구 화질이 내려가면 “같은 인물로 보이게 하기” 도 같이 쉬워진다.
🔴 정정(2026-08-17 저녁) — 픽셀아트다. 사장님이 도트 레퍼런스를 주면서 확정했고, 6~7등신이다(치비 아님). 위 “하데스 정도” 는 화질 기준이었지 화풍 지시가 아니었는데 내가 화풍으로 읽고 “픽셀아트가 아니다” 라고 적었었다. 3D 는 여전히 중간 재료로만 쓴다. 시점은 게임과 같은 아이소메트릭 3/4 다.
🔴 2026-08-17 파일럿 — 실패했고, 실패가 답을 줬다
엘라 idle 을 4방향으로 뽑아 IPAdapter 가 같은 인물을 붙드는지 보려던 시험이다.
20시트를 뽑기 전에 싸게 사는 정보였다.
결과 1 — 방향이 아예 안 잡힌다
front · three quarter · side · back 을 각각 시켰는데 네 장 모두 정면으로 나왔다.
“엄격한 옆모습”, “뒤에서 본” 같은 지시를 그냥 무시한다.
이게 가장 중요한 발견이다. 방향이 안 되면 스프라이트 자체가 성립하지 않는다. 글로 시켜서 될 일이 아니라 자세를 뼈대로 지정해야 한다는 뜻이고, 그래서 받아 둔 ControlNet 이 선택이 아니라 필수가 된다.
결과 2 — IPAdapter 는 이 조합에서 오히려 해로웠다
같은 시드·같은 프롬프트로 끈 판을 같이 뽑아 비교했다.
| IPAdapter 켬 | IPAdapter 끔 | |
|---|---|---|
| 배경 | 분홍 무늬로 무너짐 | 흰 배경 유지 |
| 의상 | 레퍼런스에서 더 멀어짐 | 레퍼런스에 가까움 |
| 얼굴 | 끈 쪽과 눈에 띄는 차이 없음 | — |
| 방향 | 정면 | 정면 (둘 다 실패) |
이유는 짐작이 간다. 우리 캐릭터는 이미 외형·얼굴·체형·의상이 글로 강하게 고정돼 있어서 IPAdapter 가 더 얹을 것이 별로 없고, 대신 레퍼런스 그림의 배경과 색조까지 끌고 온다.
⚠️ “IPAdapter 가 나쁘다” 가 아니라 “이 조합에서는 이득이 없었다” 이다. 직전 프로젝트가 성공한 방식은 레퍼런스를 주는 이미지 편집 모델이었고 그건 다른 물건이다.
결과 3 — 대조군을 안 만들면 판정 자체가 불가능하다
첫 시도에는 끈 판이 없었다. 그런데 금발·청록 눈은 프롬프트에도 들어 있어서, 켠 그림에 그게 보인다고 “레퍼런스를 붙들었다” 가 되지 않는다. 끈 판을 뽑고 나서야 두 효과가 갈렸다.
🔴 2026-08-17 (2) — 산 스프라이트에서 포즈를 뽑는 것은 안 된다
사장님이 8방향 기사 에셋(128px 칸 · 15프레임 × 8방향)을 받아 주셨다. 거기서 자세 뼈대를 뽑아 우리 캐릭터에 입히려 했고, 세 번 시도해서 세 번 다 빈 뼈대가 나왔다.
| 시도 | 입력 | 결과 |
|---|---|---|
| 1차 | 칸 그대로 4배 확대 (검정 배경) | 뼈대 픽셀 0 |
| 2차 | 인물만 크롭 + 흰 배경 | 판정 불가 — 합성이 뒤집혀 흰 실루엣이 들어갔다 |
| 3차 | 2차를 고쳐 제대로 된 기사 + 흰 배경 | 뼈대 픽셀 0 |
⚠️ 2차를 실패로 세면 안 된다. ComfyUI 의 LoadImage 가 내주는 마스크는 알파의 반대라,
안 뒤집으면 배경만 칠해진다. 그걸 모르고 “추출기가 실패했다” 로 적을 뻔했다 —
입력을 눈으로 보고서야 알았다.
결론: 자세 추출기는 사진으로 배운 물건이라 양식화된 갑옷 기사를 사람으로 못 본다. 해상도·대비·크기를 다 고쳐도 안 된다. 이 경로는 접는다.
그럼 산 에셋은 쓸모가 없나 — 아니다
- 8방향의 각도가 어떻게 보이는지의 실물 기준이 된다. 우리 카메라에 맞춰 뼈대를 그릴 때 본다.
- 클립별 프레임 수(대기 15프레임 등)와 작은 크기에서 무엇이 읽히는지의 참고가 된다.
- ❌ 그림 자체는 안 쓴다. 우리 캐릭터가 아니고, 우리 스프라이트는 초상과 같은 얼굴이어야 한다.
🔴 Knight_player_1.4 는 아예 쓰지 않는다. 동봉 Read_me.txt 가 AI·머신러닝·파생 기술
사용을 명문으로 금지하고 법적 조치를 언급한다. 회색지대가 아니라서 뺐다.
(그건 측면 뷰 플랫포머라 8방향도 아니다.)
지금 하고 있는 것 — 뼈대를 코드로 그린다
scripts/art/pose.ts. 공짜이고 라이선스가 안 걸리고 결정론적이다.
🔴 2D 뼈대에서 방향을 만드는 것은 얼굴 점이다. 몸통만 보면 정면과 뒷모습이 거의 같다. COCO-18 의 코·눈2·귀2 가 그 일을 한다 — 정면은 다섯 다, 3/4 은 먼 귀가 빠지고, 옆은 코+가까운 눈+가까운 귀, 뒤는 코도 눈도 없이 귀 둘만 남는다.
⚠️ 아직 안 끝났다. 지금 상태의 결함:
- 비율이 틀렸다. 어깨 폭이 키 대비 절반쯤이라 사람이 아니라 막대로 읽힌다.
- ControlNet 에 넣어 본 적이 없다. “방향이 실제로 잡히는가” 는 여전히 미검증이다.
- 옆·3/4 는 정면을 가로로 접어 만들다가 팔다리가 몸통에 겹쳐 사라져서 따로 적어야 했다. 같은 함정이 달리기·공격에서 또 나온다.
🔴 2026-08-17 (3) — 뼈대를 줘도 방향은 안 잡힌다. 대신 다른 걸 고쳤다
합성 뼈대를 ControlNet OpenPose 에 실제로 넣었다. 같은 시드로 켠 판과 끈 판을 나란히 뽑았다.
방향 — 실패
side 와 back 둘 다 정면으로 나왔다. back 은 뼈대에 코도 눈도 없고
프롬프트에도 “뒤에서 본” 이라 적었는데도 얼굴이 이쪽을 본다.
즉 이건 조건이 약해서가 아니라 모델의 성향이다. “애니 그림의 여자는 카메라를 본다” 가 뼈대의 얼굴 점 부재보다도, 글보다도 세다. 강도를 올리거나 뼈대를 더 정확히 그려서 넘을 수 있는 벽이 아니다.
그런데 ControlNet 은 확실히 먹었다 — 다른 문제를 고쳤다
| 뼈대 없음 | 뼈대 있음 | |
|---|---|---|
| 배경 | 카메라 삼각대 두 개 + 하트 | 깨끗한 흰 배경 |
| 손 | 삼각대를 짚고 있다 | 몸 옆에 자연스럽게 내려온다 |
| 구도 | 흔들린다 | 가운데 정렬·발밑까지 들어온다 |
이건 큰 소득이다. 프로필 주석에 “빈 손이 황동 기둥을 부른다” 로 적혀 있던 고질병이 뼈대 하나로 사라졌다. 방향과 무관하게 본 생성에 붙일 값어치가 있다.
남은 길 — 깊이(depth) 계열
OpenPose 뼈대는 앞뒤가 원래 모호하다(막대기에는 앞뒤가 없다). 반면 뒤에서 본 사람의 깊이 맵에는 얼굴 굴곡이 아예 없어서 모호할 수가 없다. 그래서 다음 후보는 3D 로 자세를 만들어 깊이를 뽑고 depth ControlNet 에 주는 것이다.
⚠️ 아직 못 한다. depth ControlNet 모델이 안 받아져 있고, 3D 자세 소스도 정해야 한다 (Mixamo 가 무료이고 우리 카메라 각도로 렌더할 수 있어 1순위).
🔴 2026-08-17 (4) — 뼈대가 체형을 덮어썼다
사장님 지적: “엘라 이미지 보니까 상하로 눌려서 뚱뚱해졌어. 캐릭터의 체형은 함부로 변형하지마.”
맞는 지적이었다. ControlNet 에서 뼈대는 자세 힌트가 아니라 체형 처방으로 작동한다 —
내가 그린 몸통이 짧으면 캐릭터가 실제로 그렇게 눌린다. 엘라는 설정에 키가 크다·허리가 가늘다 로 적혀 있는데 내 뼈대가 그걸 덮어썼다.
두 곳을 같이 고쳤다:
- 뼈대 비율 — 키를 늘리고(0.705→0.775) 다리 비율을 올리고(0.51→0.56) 어깨를 좁혔다(0.217→0.185). 첫 값은 실사 남성 쪽 비례였다.
- ControlNet 을 일찍 놓아준다 — 세기 1.0→0.6, 적용 구간 0.8→0.45. 구도와 소품 억제는 초반 스텝에서 정해지고 체형은 뒤쪽에서 다듬어지므로, 일찍 놓으면 소품 환각 억제는 살면서 체형은 캐릭터가 되찾는다. 이쪽이 더 근본적이다.
결과: 세로로 눌린 것이 풀리고 소품 환각도 여전히 없다.
⚠️ 이 두 값은 눈으로 보고 잡는 것이다. 낮추면 체형은 살아나지만 구도 통제가 같이 약해진다. 렌더를 안 보고 숫자만 만지지 마라.
🔴 2026-08-17 (5) — 체형은 눈이 아니라 자로 맞춘다
사장님이 다시 짚었다: “엘라 완성본이 위키 이미지랑 체형이 아직도 다른데?”
그래서 추측을 멈추고 원본과 렌더의 실루엣 폭을 키 대비로 직접 쟀다. 그랬더니 내 눈대중 진단(어깨가 넓다)이 틀렸다는 것이 나왔다:
| 부위 (키 대비) | 원본 | 고치기 전 | 원인 |
|---|---|---|---|
| 머리 | 0.117 | 0.115 | 맞았다 |
| 어깨 | 0.192 | 0.179 | 오히려 좁았다 |
| 허벅지 | 0.162 | 0.213 | 🔴 |
| 종아리 | 0.137 | 0.178 | 🔴 |
문제는 상체가 아니라 하체였고, 원인은 체격이 아니라 뼈대의 벌어진 스탠스였다. 원본은 다리가 거의 붙어 있다. 뼈대에서 다리를 모으니 종아리가 1.30배→0.79배, 허벅지가 1.31배→1.24배로 잡혔다.
⚠️ 폭을 잴 때 팔을 같이 세지 마라
처음엔 엉덩이가 1.65배로 나와서 “골반이 부풀었다” 로 읽을 뻔했다. 그런데 그 줄의
연속 구간을 나눠 보니 원본은 [48, 12, 225, 14], 내 렌더는 [84, 158, 35, 4, 67] —
가장 넓은 덩어리(=몸통)만 비교하면 1.04배로 사실상 같았다. 1.65배는 전부
옆에 내려온 팔이었다. 원본은 한 팔이 머리로 올라가 있어서 그 줄에 안 잡힌다.
왼쪽 끝~오른쪽 끝으로 재면 자세가 체형으로 위장된다.
남은 차이
허벅지가 아직 1.24배다. 완전히 같지는 않다. 원본의 다리 선이 더 길고 가늘다.
🔴 2026-08-17 (6) — 방향이 뚫렸다. 마지막 조각은 깊이가 아니라 프롬프트였다
깊이를 실제 인체 메시에서 뽑기로 하고 Blender MPFB2 로 직교 8방향을 렌더했다
(scripts/art/mannequin.py). 캡슐과 달리 180° 가 코도 눈도 없는 확실한 뒤통수로 나왔다.
그런데 그것만으로는 여전히 정면이 나왔다. 갈린 것은 프롬프트였다.
| 같은 깊이 맵 · 같은 시드 | 결과 |
|---|---|
최소 프롬프트(1girl, solo, standing) | 뒷모습 |
| 엘라 전체 프롬프트 | 정면 |
| 엘라 프롬프트 − 얼굴 블록 | 뒷모습 |
엘라의 face 에는 묘사가 10여 개 있고(쌍꺼풀·큰 눈·도톰한 입술·미소·표정) 그것들이 전부
“이 얼굴이 화면에 보여야 한다” 는 압력이라 깊이의 방향 지시를 이긴다.
⚠️ 캡슐 때의 180° 실패도 같은 원인이었을 가능성이 크다. 깊이 탓만 하고 있었다.
그런데 블록을 빼면 정체성이 흔들린다
사장님 지적: “뒷모습이랑 정면이랑 머리색이 다른거 같아.” 맞았고, 머리색만이 아니라 의상까지 달랐다(정면 진한 금발+흰 스커트 / 뒷모습 밝은 애시+금색 스커트). 프롬프트에서 블록 하나를 빼면 남은 토큰의 상대 비중이 전부 달라져 같은 시드라도 그림이 통째로 재구성된다. 얼굴만 빠지는 게 아니다.
그래서 positive 를 그대로 두고 negative 로만 정면을 막는 길(--back-neg)을 재봤다:
| 각도 | 얼굴 블록 제거 | negative 방식 |
|---|---|---|
| 135° | 뒤 ✓ / 색 틀어짐 | 뒤 ✓ / 색 일치 |
| 180° | 뒤 ✓ / 색 틀어짐 | 정면 ✗ |
| 225° | 뒤 ✓ / 색 틀어짐 | 뒤 ✓ / 색 일치 |
판정 — 7/8 은 되고 180° 만 트레이드오프가 남았다
8방향 최선 조합을 한 시트에 놓고 확인했다(방향 · 동일인 · 금발 · 의상 · 등신):
- 0·45·90·135·225·270·315 — 방향과 동일인성을 동시에 만족한다.
- 180° 만 둘 중 하나다. 뒤를 보면 다른 사람이 되고, 같은 사람이면 정면을 본다.
⚠️ “얼굴 태그를 빼서 방향을 얻은 것은 identity 를 팔아 direction 을 산 것 아닌가” 라는 외부 검수 우려가 있었는데, 135°·225° 가 negative 로 둘 다 지켰으므로 그 우려는 180° 에 국한된다. 다만 180° 에서는 우려가 실재한다.
⚠️ 별개로 상의가 민트색으로 나온다. 원화 엘라는 흰/크림 니트다. 아직 안 고쳤다.
🔴 2026-08-17 (7) — Blender-direct 파일럿. 결론을 한 번 잘못 냈다
사장님이 파이프라인 재검토를 지시했다. 8방향 × 5클립 × 프레임 × 캐릭터로 늘리면
수백 장에서 정체성을 AI 로 계속 유지해야 하고, 그게 180° 하나보다 큰 문제라는 것.
그래서 Blender 를 구조적 정본으로 쓰는 반대 구조를 vertical slice 로 시험했다
(scripts/art/ella_pilot.py — 엘라 idle 4방향 → pixelize.py).
결과는 엘라로 안 읽혔다. 거의 나체 · 머리는 금색 덩어리 · 얼굴 없음 · 의상 없음.
🔴 그걸 “Blender-direct 실패” 로 결론냈고 그건 틀렸다. 입력에 엘라가 없는데 출력에서 엘라를 평가한 것이다. 물어야 했던 질문(Blender 기반 생산이 유리한가)과 실제로 검증한 질문(Blender Python 으로 엘라를 procedural modeling 할 수 있는가)이 다르다.
정확한 결론 셋:
- ✅ Blender 의 방향·비율·일관성 생산성은 검증됐다 — 4방향 3초 · 직교라 흔들림 0 · 결정론적. 생산 시스템의 어려운 절반은 확보한 상태다.
- ❌ procedural primitive 만으로 엘라 외형을 만드는 것은 실패했다.
- ❓ 엘라용 3D 에셋을 어떻게 얻을지는 아직 미검증이다. VRoid Studio 가 유력하지만 확정이 아니다 — 엘라는 성숙한 체형·볼륨 있는 상체·허리/골반 강조가 중요해서 기본값으로 뽑으면 모에하지만 엘라가 아닌 캐릭터가 될 위험이 있다.
다음 실험: 엘라에 근접한 3D 캐릭터를 싸게 확보 → Blender direct → pixelize → 실제 게임에 넣어 비교. 화풍 선택은 사장님 몫이라 그 판단을 기다린다.
이번에 물린 함정 (전부 코드 주석에 박아 뒀다)
- 🔴 Blender 기본 씬 큐브가 하반신을 가렸다. 그런데 픽셀 통계는 정상으로 보였다 (배경 57%·인물 41%·8장 균일) — 큐브를 인물로 세고 있었다. 렌더를 눈으로 보고서야 알았다.
- 🔴 Blender 5.2 에는 컴포지터의
scene.node_tree·Composite·Math·MapRange가 없다. Z 패스를 컴포지터로 다듬는 흔한 방법이 깨진다 — 깊이를 emission 재질로 굽는 쪽으로 우회했다. - ⚠️
scene.render.filepath에 상대 경로를 주면 드라이브 루트로 쓴다(C:\art\depth\). - ⚠️
set_target_value는 없는 shape key 를 조용히 지나간다.load_target이 먼저다. - ⚠️ ControlNet 첫 작업이 몇 분씩 걸린다. GPU 100% 인데 스텝 로그가 한 줄도 안 찍혀서
“죽었다” 로 오판하고 ComfyUI 까지 재시작했는데, history 에는 전부
success였다. 원인은 다른 프로그램의 VRAM 점유였다(사장님이 게임을 끄자 정상화).
다음에 할 것
-
depth ControlNet 모델 확보— 2026-08-17 받았다(OpenPose 와 같은 xinsir 계열, 바이트 크기까지 동일). ComfyUI 가 재시작 없이 인식한다. - 허벅지 1.24배 좁히기 — 다음 뼈대 조정 때 같이 재서 확인한다
- depth 경로 시험 — 3D 자세 소스(Mixamo 우선) 정하고 깊이 맵으로 방향이 잡히는지
-
뼈대를 ControlNet 에 넣어 방향이 잡히는지 확인— 2026-08-17 안 잡힌다로 판정 - 방향과 별개로 OpenPose 뼈대를 본 생성에 붙인다 — 소품 환각이 사라진다
- IPAdapter 를 쓸지 다시 판단 — 지금 증거로는 빼는 쪽이 낫다
- 5클립으로 넓히는 것은 파이프라인 판정(Blender-direct vs hybrid) 이후에 시작한다
정해야 할 것
-
엘라의 병과— 2026-08-17 Caster(마법사) 로 확정(사장님). 엘라 참조 -
인게임 자산의 노출 상한— 2026-08-17 확정(사장님). 노출 컨셉은 니케 기준, 비노출은 붕괴 스타레일 기준이고 컨셉·인게임에 같이 적용된다. 캐릭터별 축은 코드가 정본이다(scripts/art/profiles.ts의exposure).