만든 것진행 중

아트

데이터는 완비인데 시각 자산이 0이었습니다. 그리고 가독성을 고치려고 건 게이트가 가독성을 더 나쁘게 만들었습니다.

ΔY 0.22

이 프로젝트의 상태를 한 줄로 말하면 이렇다. 44초식·26신물·30NPC 데이터는 완비인데, 대응하는 시각 자산이 0인 상태가 오래 갔다.

기획 문서에 “아트 톤” 한 줄을 적는 것과 그 톤이 3D 월드에 닿는 것은 완전히 다른 일이다.

명도가 먼저, 색은 나중

가장 자주 틀리는 순서다. 캐릭터 가독성은 색상이 아니라 명도 서열이 만든다.

화면을 세 층으로 나눈다 — 플레이어(밝음) / 배경·바닥(중간) / 적(어두움). 어느 두 층도 명도가 겹치면 안 된다.

실측 하한은 캐릭터와 바닥의 명도차 0.22다. 0.15 아래로 내려가면 실루엣이 배경에 묻힌다.

이 프로젝트를 재봤더니 보스와 바닥의 명도차가 0.009였다. 사실상 같은 명도고, 하필 그 장이 보스전이었다.

검증은 간단하다. 채도를 0%로 놓고 렌더한 스크린샷에서 층이 갈리면 통과. 색을 빼도 읽혀야 한다. 그리고 한 포즈만 보면 안 된다 — 대기·공격·이동·피격·승리 다섯 포즈를, 히어로샷·게임플레이·인식한계 세 거리에서 본다.

프록시 지표가 진짜 문제를 악화시켰다

여기가 이 부문에서 제일 값비싼 교훈이다.

“적이 배경에 묻힌다”를 고치려고 씬 전체 밝기 하한을 테스트로 걸었다. 화면 평균 밝기가 일정 값 이상이어야 통과하게.

그 하한을 통과하려면 바닥을 밝게 올려야 했다. 그런데 바닥이 밝아지자 캐릭터 명도 대역으로 들어왔고, 보스와 바닥의 차이가 0.039에서 0.009로 오히려 나빠졌다.

게이트는 초록불이었다. 그동안 진짜 문제는 악화되고 있었다.

가독성 게이트는 반드시 “캐릭터와 배경의 차이”를 직접 재야 한다. 대신 재기 쉬운 걸 재면, 그 지표를 통과시키는 방향으로 손대다가 원래 문제를 키운다. 이건 아트 이야기가 아니라 측정 이야기다.

색을 배정했는데 왜 안 달라 보이나

열 개 스테이지에 색상이 이미 잘 배정돼 있었다. 13°부터 270°까지 넓게. 그런데 전부 같은 회색으로 읽혔다.

원인은 색상 미배정이 아니라 채도였다. 지각 채도 평균이 0.023. 인접한 아홉 쌍 중 다섯 쌍이 색차 0.02 미만 — 사람 눈으로 구분 불가였다. 채도를 2.4배 올리자 그 다섯 쌍이 전부 해소됐다.

“색을 배정했는데 왜 안 달라 보이지”의 답은 대개 채도다.

그리고 색 차이를 잴 때 RGB 유클리드 거리를 쓰면 안 된다. 명도에 지배돼서 색 차이를 못 잰다. 명도를 뺀 색상·채도 평면에서 재야 한다.

같은 이유로 진영 색을 “같은 급”으로 보이게 하려면 색상만 돌려서는 안 된다. 채도와 명도를 고정하고 색상만 바꾸면 노랑·시안이 빨강·파랑보다 훨씬 밝아 보인다. 진영 간 채도까지 맞춰야 한다.

체계가 색을 배정한다

아티스트가 스테이지마다 색을 고르면 반드시 한쪽으로 몰린다. 체계가 배정하면 자동으로 흩어진다.

무협은 이걸 공짜로 얻는다 — 오행이 이미 세계관 안에 있다. 원소를 스테이지에 1:1로 고정 배정하고, 각 스테이지의 지배색과 형태 언어를 거기서 도출하면 된다.

채도도 총량이 아니라 배분으로 관리한다. 배경과 바닥은 중저채도, 고채도 픽셀은 화면의 5% 이하, 그리고 그 5%의 소유자를 미리 목록으로 못박는다. 소유자를 안 정하면 아무나 채도를 쓰고 결국 다 같이 칙칙해진다.

선언과 실제를 대조한다

문서에는 “3D 셀룩”이라고 적혀 있었다. 실제로 열어 보니 바닥·벽·잡졸·정예 머티리얼이 전부 표준 PBR이었고, 툰 셰이더는 캐릭터 일부에만 붙어 있었다.

화면에서 가장 넓은 면적과 가장 많은 개체가 셀 셰이더를 안 타고 있었다.

그래서 아트 톤 점검은 문서를 읽는 게 아니라 머티리얼이 어느 셰이더를 쓰는지 세는 것부터 한다. 이건 검증에서 반복해서 나오는 이야기와 같다 — 적혀 있는 것과 돌고 있는 것은 다르다.

로우폴리에 표준 PBR을 얹으면 최악의 조합이 된다. 로우폴리는 양식화된 셰이딩이 있어야 의도로 읽히고, 없으면 그냥 싸구려로 읽힌다.

아직 못 한 것

방법론과 실측은 생겼다. 못 한 건 다른 쪽이다.

혼자 만들면 병목이 코드가 아니다. 코드는 AI가 쓴다. 병목은 캐릭터 하나, 애니메이션 한 벌이고, 초식이 28개면 모션도 그만큼 필요하다.

그래서 생성 도구를 볼 때 관심사는 “이 도구 좋다”가 아니라 어디까지 자동으로 나오고 어디부터 사람이 필요한가다. 그리고 그 답을 내려면 도구만 봐서는 안 된다 — 도구 소개만 모으면 결론이 항상 “되긴 된다”로 끝난다. 그래서 외주 견적을 같이 본다. 값을 모르면 판단이 아니라 희망이 된다.

그 한계선을 아직 실측한 적이 없다. 지금 모여 있는 건 도구들이 스스로 주장하는 성능뿐이다. 이 사이트에서 반복하는 말 — 대상의 주장은 근거가 아니다 — 을 정작 여기에는 아직 적용 못 했다.