Kimodo.cpp: NVIDIA 텍스트 투 모션을 GPU 없이도 로컬에서 실행

언리얼 엔진에서 서로 다른 네 개의 캐릭터 리그가 Kimodo가 텍스트 프롬프트로 생성한 모션을 재생하는 모습

이 글에서 사용한 도구

"사람이 회전하며 돌려차기를 한다"라고 입력하면 바로 쓸 수 있는 애니메이션이 나옵니다. 그것도 내 컴퓨터에서, Python 환경도 네트워크 통신도 없이요. 이것이 NVIDIA의 모션 확산 모델 Kimodo이고, 누군가 이를 C++와 GGML로 이식해서 이제 Vulkan에서도 평범한 프로세서에서도 2 GB 미만의 메모리로 돌아갑니다.

저는 하루를 들여 Windows에 처음부터 설치하고, 클립을 생성하고, 그 결과를 Mixamo 리그와 언리얼 엔진에 올려봤습니다. 이 가이드는 그 과정에서 알게 된 모든 것이며, 시간을 가장 많이 잡아먹었으면서 어떤 README에도 없는 두 가지, 즉 실제로 사용이 허용된 모델이 무엇인지, 그리고 왜 이 작업 전체가 그래픽카드가 아니라 디스크에 묶여 있는지도 포함합니다.

전체 워크플로를 한 줄로

텍스트 프롬프트 → Vulkan 또는 CPU에서 실행되는 kimodo.cpp(2 GB 미만, 실제 연산 약 20초) → GLB → 스크립트 두 개로 언리얼 mannequin에, 또는 이름 매핑으로 Mixamo 리그에 → 완성된 애니메이션. SOMA와 G1 체크포인트는 NVIDIA Open Model License라서 상업적 사용이 가능합니다.

1. Kimodo란 무엇이고, C++ 이식이 무엇을 바꿨나

NVIDIA는 2026년 3월에 Kimodo를 공개했습니다. 상업적 사용이 가능한 광학 모션캡처 700시간으로 학습한 운동학 기반 모션 확산 모델로, 텍스트 프롬프트와 희소한 운동학적 제약을 3D 인체 및 휴머노이드 로봇 모션으로 바꿉니다. 골격 포맷은 세 가지로, NVIDIA 자체 SOMA 파라메트릭 바디, Unitree G1 휴머노이드 로봇, 그리고 SMPL-X입니다.

원래 배포판은 PyTorch 프로젝트입니다. 클립 하나를 생성하려 해도 CUDA 스택 전체를 먼저 세워야 했는데, 머신러닝이 아니라 3D 작업용으로 꾸민 컴퓨터를 쓰는 사람에게는 현실적인 장벽입니다.

kimodo.cpp는 네이티브 C++ 및 GGML 이식판입니다. GGUF 가중치를 불러오고, Vulkan이나 프로세서에서 실행되며, 작은 로컬 웹 인터페이스가 함께 들어 있습니다. 생성 시점에 Python도 CUDA도 네트워크도 필요 없습니다. 이야기는 그게 전부지만 들리는 것보다 의미가 큽니다. Kimodo가 "머신러닝 하는 사람들이 돌리는 것"에서 "내 워크스테이션에서 바로 여는 것"으로 바뀌었기 때문입니다.

기본 제공 웹 인터페이스. 모델 선택, 프롬프트, 프레임 수, 실시간 스켈레톤 미리보기, 그리고 Download GLB 버튼까지 모두 localhost에서 제공됩니다.

2. 라이선스 상황, 8월 26일에 막 바뀌었다

대부분의 글이 틀리게 쓰고 있는 부분입니다. 최근에 바뀐 데다, 두 방향으로 동시에 바뀌었기 때문입니다.

이식판은 처음에 변환된 SMPL-X 가중치를 함께 배포했습니다. 그 가중치는 내려갔습니다. 제작자가 해당 체크포인트 상위의 NVIDIA 라이선스가 파생 모델 배포를 명시적으로 금지한다는 사실을 발견하고 GGUF와 매니페스트, 체크섬을 삭제했기 때문입니다. 그 자리를 대신한 모델 카드는 정체불명의 404를 남기는 대신 이유를 분명히 밝혀두었는데, 예상보다 훨씬 마음에 드는 처리였습니다.

거의 같은 시점에 완전히 다른 라이선스의 체크포인트 네 개가 올라왔고, 이식판도 이들에 대한 지원을 받아들였습니다.

모델	골격	라이선스	상업적 사용
SOMA RP v1.1	SOMA, 30관절	NVIDIA Open Model	허용
SOMA SEED v1.1	SOMA, 30관절	NVIDIA Open Model	허용
G1 RP v1	Unitree G1, 34관절	NVIDIA Open Model	허용
G1 SEED v1	Unitree G1, 34관절	NVIDIA Open Model	허용
SMPL-X RP v1	SMPL-X, 22관절	NVIDIA Internal Scientific R&D	연구 전용

결과물을 배포할 생각이라면 SOMA나 G1을 쓰세요

SMPL-X 체크포인트는 내부 비상업 연구로 제한되며 재배포도 불가능합니다. Hugging Face에서 직접 NVIDIA 라이선스에 동의하고 저장소의 변환기로 로컬에서 가중치를 변환해 쓸 수는 있지만, 그렇다고 상업적 권리가 생기지는 않습니다. 제품에 넣을 수 있는 것은 SOMA와 G1 체크포인트입니다.

인터페이스는 이 점에 대해 솔직합니다. 주말 프로젝트 이식판에서 기대하지 못했던 부분이죠. 모델을 고르면 무언가를 생성하기 전에 어떤 라이선스 아래에 있는지 알려줍니다.

모델 선택기는 골격, 상위 체크포인트, 라이선스 조건을 표시합니다. 비상업 모델의 경우 이 줄 대신 경고가 나옵니다.

3. 실제로 필요한 하드웨어

요구 사양은 낮습니다. 그리고 그 낮음은 표만 훑고 넘기기보다 이유를 이해해둘 가치가 있습니다.

항목	최소	여유 있는 구성
여유 디스크	25 GB	35 GB, NVMe 드라이브
시스템 메모리	4 GB	32 GB, 5절도 참고
VRAM(GPU 경로)	1.2 GB	2 GB
CPU	2코어	6코어

GPU든 프로세서든 어떤 구성에서도 최대 메모리는 2 GB 미만입니다. 조절 손잡이는 KIMODO_TEXT_LAYER_CHUNK이고, 여기에 넣는 숫자는 기가바이트가 아니라 레이어 수입니다. chunk 2는 VRAM 1.2 GB, chunk 4는 1.8 GB, 기본값 chunk 8은 3.5 GB를 씁니다. 값을 키운다고 빨라지지는 않습니다. chunk 크기와 무관하게 인코더는 실행당 한 번만 읽히기 때문입니다.

약 1.3 GB가 절대 하한입니다. 임베딩 테이블이 1.05 GB짜리 단일 할당이라 어떤 chunk 크기에서도 쪼갤 수 없고, 그 아래로는 프로그램이 아예 시작되지 않습니다.

그래픽카드의 효과는 생각보다 훨씬 작다

제작자의 벤치마크에서 RTX 5090 Laptop은 3초 클립을 25.9초에, 16코어 프로세서는 33.7초에, 내장 Intel Arc 그래픽은 32.5초에 처리했습니다. 플래그십 카드와 CPU 사이의 차이가 1.3배에 불과합니다. 작업을 지배하는 것은 15.2 GB 텍스트 인코더를 읽는 일이지 연산이 아닙니다. 카드가 값을 하는 지점은 디노이징 스텝 수가 많을 때이지 클립 길이가 아닙니다.

4. Windows에 설치하기

프로젝트 문서는 Linux 기준입니다. Windows에서도 동작하고 CMake 파일에 명시적인 MSVC 분기도 있지만, 한 시간을 날릴 수 있는 지점이 네 군데 있습니다. 아래는 요약이고, 전체 절차는 이 절 끝에서 내려받을 수 있습니다.

툴체인 설치 후 새 터미널 열기

Git, C++ 워크로드가 포함된 Visual Studio Build Tools, Vulkan SDK, 웹 인터페이스를 쓰려면 Go까지.

winget install Git.Git
winget install Microsoft.VisualStudio.2022.BuildTools --override "--quiet --wait --norestart --add Microsoft.VisualStudio.Workload.VCTools --add Microsoft.VisualStudio.Component.VC.CMake.Project --includeRecommended"
winget install KhronosGroup.VulkanSDK
winget install GoLang.Go

VC.CMake.Project 구성 요소는 선택 사항이 아닙니다. 이게 빠지면 컴파일러는 생기지만 CMake와 Ninja가 없고, 이후에 나오는 오류 메시지 어디에도 그 사실이 적혀 있지 않습니다. 그리고 반드시 모든 터미널을 닫으세요. Vulkan 설치 프로그램이 설정하는 VULKAN_SDK는 머신 전역 변수라, 이미 열려 있던 터미널은 영영 보지 못합니다.

서브모듈까지 함께 클론

git clone --recurse-submodules https://github.com/localai-org/kimodo.cpp
cd kimodo.cpp

GGML은 서브모듈입니다. 그냥 클론하면 비어 있게 되고, 같은 이유로 저장소를 ZIP으로 받으면 아예 동작하지 않습니다.

소스 두 군데를 고친 뒤 빌드

src/denoiser.cpp, src/generate.cpp, src/llm_tokenizer.cpp 에 #include <stdexcept>를 추가하고, src/llm_text_encoder.cpp 의 path.c_str()를 path.string().c_str()로 바꿉니다. 둘 다 모든 플랫폼에서 옳은 수정이고, 단지 아직 상위 저장소에 병합되지 않았을 뿐입니다. 그런 다음 vcvars64.bat를 실행한 터미널에서:

cmake -S . -B build-win -G Ninja -DCMAKE_BUILD_TYPE=Release -DKIMODO_ENABLE_VULKAN=ON -DKIMODO_BUILD_TESTS=OFF
cmake --build build-win

가중치 내려받기

텍스트 인코더는 모든 모델이 공유하므로 15.2 GB 다운로드는 한 번이면 됩니다. 모션 모델은 그 위에 하나당 약 1.13 GB입니다.

pip install huggingface_hub
hf download LocalAI-io/Llama-3-Kimodo-GGML --local-dir . --include "generated/llm2vec-text-bundle/*"
hf download LocalAI-io/Kimodo-SOMA-RP-v1.1-GGML --local-dir . --include "models/*"

오픈 라이선스 모델 네 개를 전부 더해도 약 4.5 GB이지 17 GB의 네 배가 아닙니다. 인코더를 공유하기 때문입니다.

한 시간을 잡아먹은 조용한 실패

SMPL-X 저장소처럼 Hugging Face 저장소가 상위에서 비워진 경우, --include를 붙인 hf download는 아무것도 매칭하지 못하고 성공으로 종료합니다. 오류도 파일도 없고 종료 코드는 0입니다. 제 설치 스크립트는 정상 완료를 보고했고, 생성이 실패한 뒤에야 모델이 없다는 걸 알아챘습니다. .gguf가 실제로 models\ 안에 들어왔는지 항상 확인하세요.

Windows 설치 가이드 전체 내려받기

모든 명령, 두 군데 소스 수정과 그것이 막아주는 실제 오류 메시지, 환경 변수 전체, 그리고 증상별로 진짜 원인을 짚어주는 문제 해결 표. 컴파일러가 하나도 없는 컴퓨터에서 직접 끝까지 해본 뒤에 쓴 문서입니다.

kimodo-windows-setup.md

5. 첫 클립 생성하기

명령행 인자는 위치 기반이고, GGML DLL은 실행 파일 옆이 아니라 빌드 트리의 bin 폴더에 있습니다. 이걸 놓치면 프로그램이 아무 출력 없이 즉시 종료되는데, 겉보기에는 크래시와 똑같지만 실제로는 Windows가 DLL을 못 불러온 것입니다.

Command Prompt

set PATH=%CD%\build-win\bin;%PATH%
build-win\kmd-generate.exe models\kimodo-soma-rp-v1.1-f32.gguf generated\llm2vec-text-bundle prompt.txt 90 20 41 out

30 fps에서 90프레임, 즉 3초이고, 디노이징 20스텝에 시드 41입니다. 웹 인터페이스를 쓰려면:

go run ./demo -addr 127.0.0.1:8094 -generator build-win/kmd-generate.exe

결과물의 질을 결정하는 숫자는 두 개입니다. 프레임 수는 약 300, 그러니까 10초까지 일관성이 유지됩니다. 400에서는 떨림이 생기고, 600에서는 대략 300프레임 이후 노이즈로 무너집니다. 직관과는 반대로 짧은 클립이 더 힘 있게 나옵니다. 같은 프롬프트라도 120프레임이 300프레임보다 더 날카롭고 운동감 있게 읽히는데, 모델이 남는 시간을 채우려 들 뿐 같은 동작을 더 세게 하지는 않기 때문입니다.

스텝 수는 디노이징 횟수이고, 20이면 초안과 최종본 양쪽에 충분합니다. 비용은 선형이라 100스텝은 다섯 배가 들면서도 눈에 보이는 이득이 없습니다. 기본 제공 인터페이스는 현재 demo/index.html에 100을 하드코딩해 두었으니, 본격적으로 쓰기 전에 20으로 바꿔둘 만합니다.

첫 실행이 몇 분씩 걸리는 이유, 모델 탓이 아니다

생성할 때마다 15.2 GB 인코더를 읽습니다. 파일 캐시가 이를 담지 못하면 그 읽기가 매번 반복됩니다.

제 컴퓨터, Ryzen 7 7800X3D에 메모리 31 GB, 가중치는 SATA SSD에 둔 환경에서 3초 클립에 399초가 걸렸습니다. 그중 약 380초가 디스크 읽기였고 CPU는 10초였습니다. RTX 4070 SUPER는 내내 놀고 있었습니다. 드라이브 속도는 40 MB/s였고, 15.2 GB를 40 MB/s로 나누면 정확히 380초입니다. 계산이 딱 맞아떨어집니다.

효과가 큰 순서로 해결책은 둘입니다. 가중치를 NVMe 드라이브에 두는 것, 그리고 생성 전에 메모리를 비우는 것. 인코더가 상주하려면 대략 16 GB의 여유 파일 캐시가 필요한데, 32 GB 컴퓨터라도 브라우저와 채팅 클라이언트를 켜두면 여유는 7 GB 정도뿐이라 16 GB 컴퓨터처럼 동작합니다.

6. 모션을 실제 리그에 올리기

생성은 쉬운 쪽 절반입니다. 이 이식판이 연구자가 아니라 3D 아티스트에게 흥미로운 이유는, 출력이 거의 씨름 없이 평범한 캐릭터 리그에 얹히기 때문입니다.

웹 인터페이스에는 Download GLB 버튼이 있습니다. 데모 서버가 glTF를 직접 만들어주기 때문에, Blender에서 열면 본 계층과 키프레임이 이미 들어 있는 파일을 받게 됩니다. 대부분의 작업에서는 이것으로 끝이고, 아래의 포맷 세부 사항은 전부 건너뛰어도 됩니다.

Mixamo 리그 다섯 개, 프롬프트 다섯 개, 모델 하나. 여기에 손으로 만든 애니메이션은 하나도 없습니다.

여기서 SOMA가 뜻밖의 행운으로 드러납니다. SMPL-X의 명명 규칙을 전혀 쓰지 않거든요. 30개 관절의 이름이 Hips, Spine1, LeftShoulder, LeftForeArm 같은 식이라 Mixamo의 관례와 거의 같습니다. 대부분의 본은 mixamorig: 접두사만 붙이면 그대로 대응되고, 그 밖에 할 일이 없습니다.

다리가 함정이고, 이름이 충돌한다

SOMA의 LeftLeg는 허벅지입니다. Mixamo의 mixamorig:LeftLeg는 정강이입니다. 올바른 대응은 SOMA LeftLeg를 mixamorig:LeftUpLeg에, SOMA LeftShin을 mixamorig:LeftLeg에 붙이는 것입니다. 접두사만 붙이는 매핑을 쓰면 무릎이 골반에서 꺾이는 캐릭터가 나옵니다. 리타깃 결과가 이상해 보일 때 가장 먼저 확인할 지점입니다.

언리얼 쪽은 손으로 하는 걸 그만뒀습니다. 아래에 클립 폴더를 넣으면 mannequin 위에 베이크된 Anim Sequence를 남겨주는 두 단계짜리 스크립트가 있습니다. 관절 수로 골격이 정해지기 때문에 세 가지 모두 설정 없이 통과합니다.

1단계: 클립을 파일로, 내 데스크톱에서

Python 3.8 이상만 있으면 됩니다. Blender도 추가 패키지도 필요 없습니다. Kimodo가 써낸 폴더를 가리키면 .glb가 나옵니다.

python kimodo_to_glb.py path/to/clip
python kimodo_to_glb.py clips/* --outdir glb

파일을 쓰기 전에 스스로 검증합니다. 방금 만든 파일에서 포즈를 다시 만들어 입력과 비교하므로, 축을 잘못 잡았거나 쿼터니언 성분 순서를 틀린 경우 언리얼까지 가지 않고 여기서 잡힙니다. 출력되는 숫자는 1e-08 언저리여야 합니다.

2단계: 파일을 캐릭터로, 언리얼 안에서

Output Log를 열고 아래쪽 입력창을 Cmd에서 Python으로 바꾼 다음 붙여넣습니다:

py "C:/path/to/unreal_retarget.py" "C:/path/to/walk_150.glb"

그러면 파일을 가져오고 IK Rig와 IK Retargeter를 만들고 아래 두 가지 보정을 적용한 뒤 베이크해서 /Game/Kimodo/Retargeted/에 Anim Sequence를 남깁니다. mannequin을 레벨에 놓고 Animation Mode를 Use Animation Asset으로 바꾼 다음 그 시퀀스를 고르면 됩니다. 경로를 여러 개 넘기면 한 번에 처리되고, 마지막에 Skeletal Mesh 경로를 붙이면 다른 캐릭터를 대상으로 삼을 수 있습니다.

눈대중에 맡기지 않고 클립마다 결과를 알려줍니다:

kick_120: SMPL-X, 22 joints
    9 chains mapped, 19 left at rest (Root, LeftThumb, ...)
    reach 102 cm to 95 cm, arms corrected by up to 48 deg
    arms match 0.998 (worst lowerarm_r), pelvis 93 cm, lowest toe -1 cm,
    travelled 123 cm over 4.0 s

arms match는 캐릭터의 팔이 소스의 팔이 가리키던 방향과 얼마나 일치하는지를 클립 전체에서 샘플링한 값입니다. 0.95를 넘으면 좋습니다. lowest toe는 0에 가까워야 하며, 많이 크면 캐릭터가 떠 있고 많이 작으면 바닥에 가라앉습니다.

두 가지 보정, 그리고 손으로 만든 리타깃터가 이걸 빼먹으면 생기는 일

소스가 절반쯤 땅에 묻혀 있다. Kimodo는 골반을 원점에 두고 다리를 그 아래로 늘어뜨리기 때문에, 리그가 바닥에 파묻힌 상태로 시작하고 리타깃터에는 수직 여유가 남지 않습니다. 스크립트는 기본 자세의 다리 길이만큼 들어 올립니다. 애니메이션 첫 프레임이 아니라 기본 자세라는 점이 중요합니다. 그러지 않으면 웅크린 채 시작하는 클립이 똑바로 선 상태로 베이크됩니다.

양쪽 기본 자세가 다르다. mannequin은 A-포즈로 쉬지만 Kimodo는 아닙니다. 그냥 두면 리타깃터가 그 차이를 동작으로 읽어 클립 내내 팔 위치가 어긋납니다. 스크립트는 양쪽을 측정해 팔 세그먼트별로 부모에서 자식 순으로 상쇄합니다. 보통 45~55도에 해당합니다.

주의할 것은 G1

세 골격 모두 mannequin으로 리타깃되지만 Unitree G1은 로봇입니다. 쇄골도 목도 머리도 없어서 캐릭터 쪽 그 네 개 체인은 기본 자세를 유지하고, mannequin에서 하나인 고관절을 단축 관절 세 개로 쪼개기 때문에 고관절 회전이 일부 사라집니다. 팔과 다리는 문제없이 넘어옵니다. SOMA와 SMPL-X는 완전히 매핑됩니다.

리타깃은 사람에만 한정되지 않습니다. 이 크리처도 위의 Mixamo 캐릭터들과 완전히 같은 30관절 출력으로 움직입니다.

일괄 실행 결과. 캐릭터마다 고유한 프롬프트가 있고, 그 문구가 머리 위에 렌더링되어 텍스트와 모션의 대응을 읽을 수 있습니다.

SMPL-X용 리타깃 코드를 이미 가지고 있다면, 그건 깨집니다

원시 출력은 float32 파일 두 개입니다. local_rotations_xyzw.f32가 [FRAMES, JOINTS, 4], root_positions.f32가 [FRAMES, 3]입니다. 공개된 포맷 표에는 22관절이라고 적혀 있지만 그건 SMPL-X 전용입니다. SOMA는 30개, G1은 34개입니다.

90프레임 SOMA 클립은 정확히 90 x 30 x 4 x 4 = 43,200바이트입니다. 이걸 22관절 stride로 읽으면 예외도 경고도 없이, 리그가 발작하는 것처럼 보이는 애니메이션이 나옵니다. 관절 수를 하드코딩하지 말고 파일 크기에서 계산하세요.

도구와 포맷 노트 내려받기

스크립트 두 개, 아무것도 생성하지 않고 언리얼 쪽만 먼저 시험해 볼 수 있는 예제 클립, 그리고 노트: 부모 인덱스를 포함한 30관절 SOMA 계층 전체, 깔끔하게 대응되지 않는 본까지 담은 완전한 Mixamo 이름 매핑, 쿼터니언 순서 함정, 그리고 Blender 작업 절차.

kimodo_to_glb.py unreal_retarget.py 리타깃 노트 예제 클립

3D AI 도구들의 실제 순위 보기

Kimodo가 만드는 것은 메시가 아니라 모션입니다. 파이프라인의 모델 쪽은 저희 블라인드 Arena에서 확인하세요. 생성기들을 익명 대결로 붙여 홍보가 아니라 투표로 순위를 매깁니다. 그리고 리더보드는 메시 품질, 로우폴리, 텍스처링 전반의 커뮤니티 평가를 집계합니다.

정리

단계	비용	메모
툴체인 설치	약 30분, 약 3 GB	Build Tools, Vulkan SDK, Go
빌드	약 2분	먼저 한 줄짜리 소스 수정 두 군데
가중치	15.2 GB + 각 1.13 GB	인코더는 모든 모델이 공유
생성(캐시 상태)	연산 약 20초	여기에 디스크 읽기 추가, 5절 참고
Mixamo로 리타깃	몇 분	이름 매핑과 다리 수정

핵심은 텍스트로 모션을 만드는 모델이 존재한다는 것이 아닙니다. 이 모델이 이제 이미 가지고 있는 하드웨어에서 돌아가고, 결과물을 배포할 수 있는 라이선스를 가지고 있으며, 오후 한나절이면 Mixamo 리그에 얹힌다는 점입니다. 가장 뜻밖이었던 것은 병목이 그래픽카드가 아니라 디스크 읽기였다는 사실인데, 이는 이 작업을 진지하게 하려는 사람에게 가장 저렴한 업그레이드가 더 좋은 GPU가 아니라 NVMe 드라이브라는 뜻입니다.

여기까지 이어지는 나머지 파이프라인이 궁금하다면 다음 가이드들이 있습니다. AI 3D 캐릭터 파이프라인 전체, 비인간형 캐릭터의 AI 리깅, 그리고 알아둘 만한 또 하나의 텍스트 투 애니메이션 모델 HY-Motion.

자주 묻는 질문

Kimodo를 그래픽카드 없이 돌릴 수 있나요?

가능합니다. KIMODO_BACKEND=cpu 로 설정하면 프로세서에서 실행됩니다. 전체 파이프라인은 연산이 아니라 15.2 GB 텍스트 인코더를 읽어 들이는 데 좌우되기 때문에, 제작자의 벤치마크에서도 3초 클립 기준으로 RTX 5090이 16코어 프로세서보다 약 1.3배 빠른 정도였습니다. 문서상 최소 사양은 2코어입니다.

Kimodo.cpp에는 VRAM이 얼마나 필요한가요?

어떤 구성에서도 최대 메모리는 2 GB 미만입니다. 조절값은 KIMODO_TEXT_LAYER_CHUNK 입니다. chunk 2는 1.2 GB로 2 GB 카드에서도 안전하고, chunk 4는 1.8 GB, 기본값인 chunk 8은 3.5 GB를 씁니다.

Kimodo로 만든 애니메이션을 상업적으로 쓸 수 있나요?

어떤 체크포인트를 썼느냐에 따라 다릅니다. SOMA와 G1 모델은 NVIDIA Open Model License로 공개되어 상업적 사용이 허용됩니다. SMPL-X 체크포인트는 NVIDIA Internal Scientific Research and Development Model License 적용 대상이며, 내부 비상업 연구로 제한되고 재배포가 금지됩니다. 결과물을 배포하기 전에 어떤 모델로 생성했는지 확인하세요.

첫 생성이 왜 이렇게 느린가요?

실행할 때마다 15.2 GB 텍스트 인코더를 디스크에서 읽습니다. 파일 캐시에 다 들어가지 않으면 이 읽기가 매번 반복됩니다. Ryzen 7 7800X3D에 가중치를 SATA SSD에 둔 환경에서는 3초 클립에 399초가 걸렸고, 그중 약 380초가 디스크 읽기, CPU 시간은 10초에 불과했습니다. 가중치를 NVMe 드라이브에 옮기고 생성 전에 메모리를 비우세요.

SOMA로 바꾼 뒤 리타깃 스크립트가 이상한 결과를 내는 이유는?

관절 수가 달라졌기 때문입니다. SMPL-X는 22개, SOMA는 30개, G1은 34개인데 원시 출력 포맷 자체는 어느 쪽인지 알려주지 않습니다. SOMA 파일을 22관절 stride로 읽으면 오류 없이 조용히 어긋납니다. 관절 수를 하드코딩하지 말고 파일 크기에서 계산하세요.