hades83bks

장면마다 손이 얼마나 중요한지를 상·중·하 세 단계로 나누는 규칙을 만들었다. 손이 주인공이면 상, 전신으로 뛰거나 넘어지는 장면이면 하.

손 데이터가 온전치 않은 동작 437개가 있는데, 상에서는 빼고 하에서는 그냥 쓰자는 것이다. 멀쩡한 동작을 전신 장면에서까지 버릴 이유는 없으니까.

전부 ‘중’으로 나왔다

돌려봤다. 장면 아홉 개 중 여섯 개가 전부 ‘중’이었다. 걸어 나가는 장면도, 차에 부딪혀 날아가는 장면도, 밀려 넘어지는 장면도 다.

‘중’은 감점이 붙는다. 그래서 여섯 장면마다 437개씩 감점을 먹고 있었다. 전신 장면에서 그냥 쓰자고 만든 규칙이 정반대로 동작한 것이다.

원인은 금방 보였다. 판정에 쓰는 단어 목록이 영어뿐이었다. run, fall, evade… 그런데 우리 장면 설명은 전부 한국어다. “걸어 나간다”, “부딪혀 날아간다”. 하나도 안 걸렸다.

고쳤는데 그대로였다

한국어 단어를 넣었다. 걷·달려·넘어·쓰러·부딪·밀려. 다시 돌렸다.

여섯 개 전부 그대로 ‘중’이었다.

이번엔 한참 걸렸다. 규칙은 분명히 고쳤는데 왜 안 바뀌나. 판정 함수에 실제로 뭐가 들어가는지 찍어봤다.

빈 문자열이었다. 장면 설명이 내가 읽는 자리에 없고 한 단계 위에 들어 있었다. 그러니까 첫 번째 판정도, 한국어를 넣은 두 번째 판정도, 둘 다 아무 글자도 안 읽고 기본값을 내고 있었다.

두 번 다 ‘동작하는 것처럼’ 보였다

설명이 있는 자리를 합쳐 넘기니 그제야 걷기·넘어짐·피격·회피가 ‘하’로 떨어지고 감점이 0이 됐다. 손을 뻗는 장면만 ‘상’으로 남았다.

무서운 건 두 번 다 오류가 안 났다는 것이다. 결과도 나오고 표도 채워졌다. 다만 그 결과가 아무 입력도 안 본 결과였을 뿐이다.

그래서 이제 장면별 등급과 그렇게 판정한 근거 문구를 결과 파일에 같이 남긴다. “기본값”이라고 적혀 있으면 그건 안 읽었다는 뜻이다.

3D 도구를 화면 없이 돌리면서 그 안의 기능을 코드로 부르는 작업이었다. 캐릭터를 세우고, 동작을 재생시키고, 자세를 갱신시키는 순서다.

이름이 이럴 것 같아서 그렇게 적었다. 재생 갱신은 tick_animation, 자세 갱신은 refresh_bone_transforms.

세 번 다 없는 이름이었다

첫 실행. “tick_animation 이라는 것이 없습니다.”

지웠다. 두 번째 실행. “refresh_bone_transforms 이라는 것이 없습니다.”

또 지웠다. 세 번째는 다른 이름이 안 먹었다. 세 번을 이름 짓느라 날렸다.

흔한 이름이라 당연히 있을 줄 알았다. 문서에서 본 적도 있는 것 같았다. 확인은 안 했다.

목록을 뽑는 데 30초 걸렸다

그제서야 그 부품이 가진 이름을 전부 출력해봤다. 669개가 나왔다. 그중 ‘재생’이나 ‘갱신’ 비슷한 단어가 들어간 것만 추리니 몇 개 안 됐고, 내가 부르려던 기능에 해당하는 건 set_position 하나뿐이었다.

세 번 헛발질한 시간보다 목록 한 번 뽑는 게 훨씬 짧았다. 처음부터 그걸 했으면 됐다.

추측이 값싸 보였던 이유

이름을 지어내는 건 바로 다음 줄을 쓸 수 있게 해준다. 목록을 뽑는 건 한 번 멈춰서 결과를 읽어야 한다. 그래서 추측이 더 빨라 보인다.

실제로는 반대다. 추측은 틀렸을 때만 비용을 청구하는데, 그 청구서가 뒤늦게 온다. 게다가 이번엔 그 사이에 다른 원인을 의심하느라 엉뚱한 데를 두 번 더 팠다.

이제 처음 쓰는 부품은 가진 이름부터 뽑아놓고 시작한다.

캐릭터를 실제로 움직여놓고 손가락 위치를 재는 단계였다. 동작을 재생시키고, 프레임마다 손끝이 어디 있는지 읽는다.

숫자가 나왔다. 손가락 다섯 개 전부 변동 0.000. 하나도 안 움직인다는 뜻이다.

너무 깨끗해서 이상했다

앞선 조사에서 약지만 안 움직이고 나머지 넷은 굽는다는 걸 이미 확인한 상태였다. 그런데 여기서는 다섯 개 전부 0이다. 앞뒤가 안 맞는다.

표를 다시 봤다. 왼손 검지 15.726, 오른손 검지 15.726. 왼손 중지 15.945, 오른손 중지 15.945.

사람 손이 좌우가 소수점 셋째 자리까지 같은 자세로 움직이는 동작은 없다. 그리고 이 숫자들은 아무 동작도 주지 않은 기본 자세에서 앞서 잰 값과 정확히 같았다.

재생이 아예 안 되고 있었다

확인해보니 재생을 맡은 부품이 동작을 평가하지 않고 기본 자세만 돌려주고 있었다. 화면 없이 돌리는 방식이라 그 부품이 실제로 일하지 않았던 것이다.

그러니까 그 측정은 동작에 대해 아무 말도 하지 않는 숫자였다. 0이 나온 게 아니라 아무것도 안 재고 0을 적은 것이다.

그대로 보고했으면 “이 방식에서는 손가락 전체가 죽는다”는 결론이 나갔을 것이다. 완전히 틀린 결론이고, 그걸 근거로 다음 작업이 이어졌을 것이다.

다른 길로 다시 쟀다

재생 부품을 쓰지 않고, 동작 데이터에서 뼈 하나하나를 손목까지 거슬러 직접 계산해 손끝 위치를 만들었다. 그랬더니 검지·중지·새끼·엄지는 변동이 잡히고 약지만 0.000이 나왔다. 앞선 결과와 맞는다.

측정값이 모든 항목에서 똑같이 깨끗하면, 그건 결과가 아니라 측정이 안 됐다는 신호일 때가 많다.

캐릭터 동작을 도시 지도 위에 올려 보여주는 작업이었다. 도시 데이터는 이미 있다. 가로세로 3,454미터, 물체 22,324개. 건물·도로·가로수·차까지 다 들어 있다.

캐릭터를 그 위에 세우고 영상을 뽑았다. 여섯 편 다 정상 크기로 나왔다. 이번엔 0바이트가 아니었다.

열어보니 회색 바닥뿐이었다

영상에서 한 장면을 뽑아 눈으로 봤다. 캐릭터는 잘 서 있다. 그런데 배경이 어두운 회색 바닥 하나다. 건물도, 도로도, 나무도 없다.

도시 위에 올렸다는 걸 화면으로는 아무도 알 수 없는 영상이었다.

원인은 두 개가 겹쳤다. 첫째, 캐릭터를 세운 자리를 “평평한 곳”이라는 조건으로 골랐는데, 그렇게 고른 44곳이 대부분 건물 없는 빈터였다. 둘째, 카메라를 캐릭터 뒤 3.4미터에 붙여놨더니 화면이 아스팔트로 꽉 찼다.

자리와 카메라를 숫자로 다시 골랐다

자리는 조건을 바꿨다. 도로 495개를 훑어서 반경 45미터 안에 건물이 4채 이상인 지점만 남겼다. 23곳이 나왔고, 제일 많은 곳은 건물이 14채였다.

카메라는 세 가지 안을 사진으로 뽑아 비교했다. 기존 안은 도시가 아예 없고, 많이 내려다보는 안은 건물이 위로 잘렸다. 뒤 7미터·옆 5.5미터·높이 2.6미터로 잡은 안에서 도로·가로수·건물·횡단보도가 한 화면에 다 들어왔다.

파일 크기만 봤으면 못 잡았다

이번 영상들은 크기가 멀쩡했다. 목록도 가지런했다. 프레임을 직접 열어봐서 잡았다.

바로 앞 작업에서 0바이트 사고를 겪고 “크기를 확인하자”는 교훈을 얻었는데, 크기 확인만으로는 이번 걸 못 잡았다. 만들어졌다는 사실과 목적을 달성했다는 사실이 또 다르다.