클라우드 렌더링을 위한 Houdini 설정
저희 팜에서 Houdini는 현대적인 USD 우선 파이프라인을 중심으로 구축된 멀티 렌더러 환경입니다. Karma XPU는 Houdini 20.5의 새 프로젝트에 대한 SideFX 권장 경로이며 저희 랜딩 페이지의 기본 렌더러입니다. Karma CPU와 Mantra는 레거시 작업을 위해 계속 사용할 수 있습니다. 타사 렌더러인 Redshift, Arnold, V-Ray for Houdini, Octane은 해당 엔진으로 구축된 파이프라인을 운용하는 스튜디오를 위해 지원됩니다. 이 페이지에서는 프로젝트 패키징(Houdini에서는 텍스처뿐만 아니라 HDA와 시뮬레이션 캐시를 포함), Solaris/USD 에셋 워크플로우, 렌더러별 참고사항, 제출 흐름, 지원 티켓에서 가장 많이 나타나는 Houdini 전용 문제 해결 방법을 다룹니다.
시작하기 전에 라이선스에 대해 안내해 드립니다. 저희는 렌더 전용 활용(render-only utilization) 방식으로 팜에서 Houdini를 운영합니다. 이를 통해 고객 프로젝트의 오프라인 렌더링을 위해 렌더 워커에서 Houdini를 실행할 수 있습니다. Super Renders Farm은 SideFX 파트너가 아닙니다. 렌더 전용 활용은 스튜디오 라이선스 풀에서 SideFX 시트를 점유하지 않고 팜에서 Houdini 씬을 렌더링할 수 있게 하는 법적 프레임워크입니다. Houdini 라이선스를 저희에게 이전할 필요가 없으며, 아티스트 측의 프로젝트 티어 메타데이터(Indie, Core, FX)는 워커의 라이선스 방식을 결정하지 않습니다. 워커는 팜 측 라이선스를 활용합니다.
지원되는 Houdini 버전, 하드웨어 적합성, 가격 예시 등 높은 수준의 정보는 전용 랜딩 페이지가 공식 참조 자료입니다. 지금 읽고 계신 페이지는 워크플로우 문서입니다. 제출 버튼을 클릭하기 전에 Houdini에서 해야 할 작업을 안내합니다.
지원 버전
Houdini 19.5, 20.0, 20.5가 팜의 모든 워커에 사전 설치되어 있습니다. 저희는 SideFX의 릴리스 일정을 추적하며 새 주요 빌드를 공개 후 4주 이내에 프로비저닝합니다. 포인트 릴리스(예: Houdini 20.5.410 vs. 20.5.487)는 지속적으로 추적됩니다. 노드 호환성 문제로 프로젝트가 특정 빌드 번호로 고정된 경우 제출 시 작업 메모에 빌드를 언급하면 워커를 해당 빌드와 일치시킵니다.
Houdini FX(프로덕션 티어)와 Houdini Indie 씬 파일(.hip 및 .hipnc) 모두 워커에서 로드되어 팜의 렌더 전용 활용 방식으로 렌더링됩니다. 아티스트 측 티어(Indie vs. Core/FX)는 워커의 라이선스 시트로 전파되지 않습니다. 워커는 팜이 렌더링을 위해 프로비저닝한 티어를 사용합니다. Houdini Apprentice 파일은 렌더링되지만 SideFX의 비상업적 라이선스 조건에 따라 워터마크가 포함된 출력을 생성합니다. 유료 프로덕션 작업의 경우 제출 전에 비-Apprentice 라이선스에서 씬을 저장하시기 바랍니다. 교육 라이선스도 동일한 규칙이 적용됩니다.
Houdini의 릴리스 주기에 대한 참고사항: SideFX는 12~18개월마다 주요 버전을, 더 자주 포인트 업데이트를 출시합니다. Karma XPU는 특히 19.5, 20.0, 20.5 사이에 크게 개선되었습니다. 19.5에서 CPU 폴백이었던 기능(무거운 볼륨, 특정 셰이더 네트워크)이 20.5에서는 XPU 네이티브가 되었습니다. 프로젝트가 특정 빌드에서 출시된 Karma XPU 기능에 의존하는 경우, 워커가 최신 버전을 선택하도록 두는 대신 작업 메모에 빌드를 고정하시기 바랍니다.
Houdini 프로젝트 패키징
Houdini 프로젝트는 .hip(또는 .hipnc) 씬 파일 그 이상입니다. 일반적으로 HDA(Houdini Digital Assets — .hda 또는 구버전 .otl 형식), 시뮬레이션 캐시 파일(.bgeo, .bgeo.sc, .vdb, .abc), USD 에셋 레이어와 참조(.usd, .usda, .usdc), 텍스처 맵, File 또는 Alembic SOP에서 가져온 모든 외부 지오메트리도 포함됩니다. 씬이 참조하는 모든 의존성이 워커에 있을 때 클라우드 렌더링이 성공합니다. 워크스테이션 전용 경로를 통해 로컬에서 해석되지만 팜에서 해석될 곳이 없으면 실패합니다.
Houdini의 경로 규칙은 환경 변수 기반입니다. 가장 일반적으로 $HIP(.hip 파일이 있는 디렉터리로 해석), $HIPNAME(씬 파일 기본 이름), $JOB(환경 변수로 설정된 프로젝트 루트)입니다. 클라우드 렌더링에서 신뢰할 수 있는 규칙은 모든 곳에 $HIP-상대 경로를 사용하는 것입니다. 아래 패키징 단계는 이 규칙을 엔드투엔드로 적용합니다.
- 프로젝트 폴더를 설정합니다. 새 프로젝트를 저장할 때 Houdini는
$HIP를.hip파일이 있는 디렉터리로 설정합니다. Python 쉘에서hou.text.expandString('$HIP')으로 확인합니다. 경로가 씬 파일이 있는 위치와 일치해야 합니다. - 표준 하위 폴더 구조를 사용합니다.
$HIP/cache/(시뮬레이션),$HIP/geo/(Alembic 및 외부 지오메트리),$HIP/tex/(텍스처),$HIP/hda/(디지털 에셋),$HIP/usd/(USD 레이어 및 참조),$HIP/render/(출력). 씬의 File SOP, File COP, ROP 출력, 텍스처 참조의 모든 경로는 절대 드라이브 경로가 아닌$HIP/...를 사용해야 합니다. - 경로가 해석되는지 확인합니다. File → Refresh All. Houdini는 해석되지 않은 파일 참조를 콘솔에 보고합니다. Python 쉘에서
hou.fileReferences()는 외부 참조의 전체 목록을 반환합니다.D:\,Y:\,\\server\와 같은 UNC 공유, 또는 워커가 도달할 수 없는 경로로 시작하는 항목을 검색하시기 바랍니다. - 시뮬레이션을 디스크로 베이킹합니다. 팜은 렌더 작업의 일부로 시뮬레이션을 실행하지 않습니다. 시뮬레이션은 워크스테이션 작업이며, 팜은 사전 베이킹된 캐시 파일에 대해 렌더링합니다. 제출 전에 모든 DOP 네트워크(FLIP 유체, Pyro, Vellum 천, RBD Bullet, 그레인), 파티클 솔버, 기타 시뮬레이션 출력을
$HIP/cache/의.bgeo.sc또는.vdb파일로 베이킹하시기 바랍니다. "Save to Disk"를 사용하는 File Cache SOP가 표준 워크플로우입니다. - HDA를 임베드하거나 포함합니다. 씬에서 스튜디오 라이브러리의 커스텀 HDA를 사용하는 경우,
.hip에 임베드하거나(Asset 메뉴 → Save Operator Type → "Embedded")$HIP/hda/에.hda/.otl파일을 포함하여 워커가 프로젝트 폴더에서 로드할 수 있도록 하시기 바랍니다. 네트워크 드라이브의 스튜디오 공유 HDA 라이브러리는 워커에서 접근할 수 없습니다. - USD 레이어를 평탄화하거나 번들로 만듭니다. 씬에서 Solaris/LOP를 사용하는 경우, 제출 전에 USD ROP를 통해 USD 스테이지를 단일 구성된 USD 파일로 베이킹하거나, 모든 레이어가 워커에서 해석되도록 전체
$HIP/usd/디렉터리 트리를 포함하시기 바랍니다. USD 에셋 해석 규칙은 다음 섹션에서 자세히 설명합니다. - 전체
$HIP폴더를 압축합니다..tar,.tar.gz, 또는.7z를 사용하시기 바랍니다. Houdini 프로젝트의 경우.zip업로드는 허용되지 않습니다(Houdini의 파일 이름 규칙에는 Linux 워커의 Windows.zip아카이브 내에서 문제를 일으키는 문자가 포함될 수 있습니다).
Houdini 전용 일반적인 함정: ROP 노드의 "Pre-Render Script"와 "Post-Render Script" 필드가 워크스테이션 전용 Python 스크립트(스튜디오의 파이프라인 도구, 로컬 Houdini 구성 경로, 워커가 표시할 디스플레이가 없는 대화 상자를 여는 hou.ui.displayMessage 호출)를 참조하는 경우가 있습니다. 클라우드 렌더링이 자동으로 실패하거나 도착하지 않을 입력을 기다리며 중단됩니다. 제출 전에 사전 렌더 Python 또는 HScript 콜백을 검사하시기 바랍니다. 로컬 전용 경로, UI 호출, 또는 워크스테이션 바이너리에 대한 hou.system() 쉘 호출을 비활성화하거나 경로 이식성 있게 만드시기 바랍니다. 인터랙티브 콜백보다 print() 로깅을 선호하시기 바랍니다.
Solaris, USD 레이어 및 에셋 해석
씬이 Solaris(/stage LOP 네트워크)에서 작성된 경우, USD 에셋 해석 레이어가 OBJ/SOP 전용 씬에는 없는 클라우드 제출의 추가 차원을 더합니다. Houdini의 USD 리졸버는 표준 USD 에셋 해석 규칙을 따릅니다. 레이어의 참조는 레이어의 식별자 경로, houdini.env 또는 에셋 리졸버 플러그인을 통해 구성된 검색 경로, 스테이지가 사용하는 구성 호에 대해 해석됩니다(참조, 서브레이어, 페이로드).
클라우드 제출에는 두 가지 패턴이 신뢰할 수 있게 작동합니다.
- 스테이지를 평탄화합니다. "Flatten Stage" 옵션을 활성화하여 USD ROP 노드를 "Save to Disk"와 함께 사용합니다. 결과는 모든 참조가 해석된 전체 스테이지가 포함된 단일 구성
.usd(또는 바이너리용.usdc) 파일입니다. 가장 간단한 패턴입니다. 워커는 하나의 파일을 읽으며 리졸버 간접 참조가 없습니다. 그러나 협업에 USD를 유용하게 만드는 레이어드 구조를 잃게 됩니다. - 전체 에셋 트리를 번들로 만듭니다. 모든 USD 레이어를
$HIP/usd/아래에 배치하고 서브레이어, 참조, 페이로드에서$HIP-상대 참조를 사용합니다. 워커는$HIP를 업로드 루트로 해석하므로 동일한 상대 위치의 레이어 파일이 올바르게 로드됩니다.
한 가지 미묘한 점: Solaris의 "Asset Reference" LOP와 /obj 컨텍스트의 Reference SOP는 모두 참조 경로를 작성된 대로 직렬화합니다. Reference LOP에 D:\studio_assets\char_robot.usd를 입력한 경우, 워커에는 D:\가 없어 참조가 실패합니다. 참조를 $HIP/usd/char_robot.usd(또는 팜이 인정하는 문서화된 환경 변수 매핑을 사용하는 ${SRF_ASSETS}/char_robot.usd)로 다시 작성하시기 바랍니다. 경로가 단순할수록 더 안정적으로 전달됩니다.
두 번째 미묘한 점: USD 에셋 라이브러리는 자체 버전 관리 간접 참조를 포함할 수 있습니다. USD 23.x에 맞게 컴파일된 USD 에셋을 참조하는 Solaris 스테이지는 구버전 Houdini 빌드에 번들된 USD 22.x가 있는 워커에서 깨끗하게 로드되지 않을 수 있습니다. Houdini와 USD 버전 매트릭스가 중요합니다. 에셋 라이브러리가 Houdini 20.5의 USD 버전용으로 작성된 경우 Houdini 20.5 워커에서 렌더링하시기 바랍니다.
HDA 관리
Houdini Digital Assets(HDA, 구버전 .otl 확장자로도 볼 수 있음)는 독립형 에셋 파일로 패키징된 재사용 가능한 노드 네트워크입니다. 절차적 에셋(건물, 식물, 군중 시스템, 커스텀 솔버)에서 개별 샷과 별도로 작성되어 씬 간에 공유되는 프로덕션 파이프라인에서 흔히 사용됩니다.
팜에서 HDA 처리를 위한 세 가지 패턴:
- HDA를
.hip파일에 임베드합니다. Asset 메뉴 → Operator Type Manager → HDA를 우클릭 → "Save to Embedded." HDA가 이제.hip내부에 저장되어 씬과 함께 이동합니다. 일회성 작업이나 단일 샷을 위해 특별히 작성한 HDA에 가장 안전한 패턴입니다. $HIP/hda/에 HDA를 번들합니다. 모든.hda/.otl파일을 프로젝트의 하위 폴더에 배치한 후, Houdini → Edit → Preferences → File Locations에서$HIP/hda/가 OTL 검색 경로의 일부인지 확인합니다(또는houdini.env에서HOUDINI_OTLSCAN_PATH에$HIP/hda/를 포함하도록 설정합니다). 워커는 씬을 로드할 때 이 위치에서 HDA를 읽습니다.- 스튜디오 공유 라이브러리에서 HDA를 참조합니다. 스튜디오가 네트워크 드라이브(예:
\\studio-fs\houdini\hda\)의 공유 HDA 라이브러리를 사용하는 경우, 해당 라이브러리는 워커에서 접근할 수 없습니다. 관련 HDA를 제출 전에$HIP/hda/에 복사하거나.hip에 임베드하시기 바랍니다.
제출 전에 Python 쉘에서 씬에 로드된 HDA를 나열하시기 바랍니다.
for hda in hou.hda.loadedFiles():
print(hda)출력의 모든 경로는 $HIP 아래에서 해석되거나 Houdini 자체와 함께 제공되는 표준 SideFX HDA여야 합니다(모든 워커에 사전 설치됨). $HIP 외부에 있는 타사 HDA는 찾을 수 없습니다.
캐시 파일 관리
캐시 파일은 일반적으로 Houdini 프로젝트 업로드에서 가장 큰 단일 카테고리입니다. FLIP 시뮬레이션, Pyro 캐시, Vellum 천 베이크, Alembic 내보내기, VDB 볼륨은 각각 수십 또는 수백 기가바이트에 달할 수 있습니다. 두 가지 패턴이 렌더를 손상시키지 않고 업로드 시간을 줄입니다.
- 베이킹 시 캐시를 압축합니다.
.bgeo.sc(압축된 bgeo, 블로스크 압축)는 동일한 지오메트리에 대해.bgeo보다 훨씬 작으며 File Cache SOP의 현대적 기본값입니다. VDB 파일의 경우 볼륨이 OpenVDB 컨테이너 내에서 이미 압축되어 있지만.tar.gz아카이브는 주변 디렉터리 메타데이터를 잘 압축합니다. $HIP/cache/를 일관되게 사용합니다. Houdini의 File Cache SOP 기본값은$HIP/cache/{node_name}/$F4.bgeo.sc로, 팜 이식 가능한 씬에 올바른 패턴입니다.D:\sim_cache\와 같은 절대 캐시 경로를 사용하지 마시기 바랍니다. 워커에D:\가 없으면 렌더가 시작되고 "캐시 파일을 찾을 수 없음" 경고를 기록하며 시뮬레이션이 있어야 할 곳에 빈 지오메트리를 생성합니다.
브라우저 업로드를 초과하는 매우 큰 시뮬레이션(웹 업로드 폼을 초과하는 멀티 테라바이트 FLIP 또는 Pyro 캐시)의 경우 웹 업로드 폼 대신 SFTP를 사용하시기 바랍니다. 문서에서 SFTP 워크플로우, 아카이브 재개 가능성, 웹 업로드에서 SFTP로 전환하는 실제 임계값을 설명합니다.
워크스테이션에서 캐시하고 팜에서 렌더링하는 스튜디오를 위한 워크플로우 참고사항: 캐시 디렉터리가 빠른 로컬 SSD에 있고 프로젝트 파일이 $HIP/cache/를 사용하면, 업로드 시 캐시가 프로젝트와 함께 이동합니다. 수동 리매핑이 필요 없습니다. 워크스테이션 패턴이 공유 네트워크 드라이브에 캐시하고 .hip가 해당 드라이브를 직접 참조하는 경우, 캐시를 $HIP/cache/에 복사하고 File Cache SOP 경로를 업데이트하거나, 워커에서 워크스테이션의 네트워크 공유를 미러링하는 $JOB 환경 변수를 설정해야 합니다(덜 신뢰할 수 있음; 상대 경로 방식이 권장됨).
제출 전 확인 사항
Houdini 제출을 위한 간단한 사전 점검 체크리스트:
- 활성 ROP 노드가 올바르게 설정되어 있습니다. Output 컨텍스트 → Render. 제출 시 선택한 ROP가 워커가 호출하는 렌더러를 결정합니다. 잘못된 ROP(예: Mantra용으로 작성된 씬에 Karma ROP 선택)는 "렌더가 완전히 다르게 보임" 티켓의 가장 흔한 원인입니다.
- 프레임 범위가 ROP 설정과 일치합니다. ROP에 저장된 프레임 범위(
f1,f2,f3파라미터)가 타임라인의 재생 범위나 뷰포트의 현재 프레임이 아닌 워커가 사용하는 범위입니다. ROP의 프레임 범위가 렌더링하려는 것과 일치하는지 확인하시기 바랍니다. - 출력 경로에
$HIP-상대 토큰을 사용합니다.$HIP/render/$F4.exr은 4자리 패딩이 있는 멀티레이어 EXR의 안전한 기본값입니다. ROP 출력 표현식에서 절대 드라이브 경로를 사용하지 마시기 바랍니다. - 모든 File SOP와 텍스처 참조가 해석됩니다. File → Refresh All. 제출 전에 콘솔의 "Unable to read" 오류를 수정하시기 바랍니다. 워커도 이를 보고하지만 렌더 프레임 낭비 비용이 발생합니다.
- HDA가 임베드되어 있거나
$HIP/hda/에 있습니다. 씬을 완전히 닫고 다른 Houdini 세션에서 다시 열어 확인하시기 바랍니다. HDA가 로컬에서 로드에 실패하면 워커도 로드에 실패합니다. - 캐시가 베이킹되어 있습니다. 제출 전에 각 File Cache SOP에서 Render → Save to Disk를 통해 수동 캐시 베이크를 실행하시기 바랍니다. "Auto-Bake on Frame Change"에 의존하지 마시기 바랍니다. 명시적으로 베이킹하고 캐시 파일이 예상
$HIP/cache/...경로에 있는지 확인하시기 바랍니다. - USD 레이어(Solaris를 사용하는 경우)가 번들되거나 평탄화되었습니다. 전체
$HIP/usd/트리를 포함하거나 USD ROP를 통해 평탄화된 구성 USD를 작성하시기 바랍니다. - 인터랙티브 사전 렌더 또는 사후 렌더 스크립트가 없습니다. UI 호출, 쉘 호출, 또는 워크스테이션 전용 경로가 있는 ROP Python 콜백과 Pre-Frame Script를 검사하시기 바랍니다.
렌더러별 참고사항
Karma XPU (권장)
Karma XPU는 SideFX의 하이브리드 CPU+GPU 렌더러로, Houdini 20.5에서 프로덕션 준비 상태로 승격되었으며 새 Houdini 프로젝트의 기본 전망 경로입니다. 저희 Houdini 랜딩 페이지의 기본 렌더러이며 팜에서 새 고객들이 가장 많이 채택하는 경로입니다.
구성 참고사항:
- 워커 티어: 렌더의 GPU 부분을 위해 저희 RTX 5090 GPU 워커 티어(카드당 32 GB VRAM)에서 실행되며, XPU 코드 경로에서 아직 지원하지 않는 기능에 대한 CPU 폴백이 있습니다.
- VRAM 제약: 워커당 32 GB VRAM. Karma XPU는 순수 GPU 렌더러보다 VRAM 효율이 높습니다. VRAM이 제한될 때 렌더의 일부(특히 볼류메트릭스)를 CPU 메모리로 오프로드할 수 있기 때문입니다. 그러나 고해상도 볼륨이 있는 매우 밀도 높은 USD 씬은 여전히 32 GB 범위 내에 있는 것이 유리합니다.
- USD 파이프라인 통합. Karma는 Solaris USD 기반 파이프라인을 위해 설계된 렌더러입니다. 프로젝트가
/stage(Solaris LOP 컨텍스트)를 사용하는 경우, Karma가 자연스러운 렌더러 선택이며 워커는 File SOP 참조와 동일한 방식으로 USD 에셋 참조를 해석합니다.$HIP-상대 경로가 우선합니다. - AOV. USD 스테이지의 Render Settings prim별로 렌더 제품마다 구성됩니다. 멀티채널 EXR이 기본 출력 형식이며 VFX 파이프라인에 권장됩니다(프레임당 단일 파일에 모든 AOV 보존).
- 샘플링. Karma의 패스 트레이싱 샘플은 Render Settings prim별로 구성됩니다. 시퀀스를 제출하기 전에 단일 프레임에서 로컬로 보정하시기 바랍니다. XPU 샘플 수렴은 CPU와 다르며, 보정이 워커에 직접 변환됩니다.
- 모션 블러. Karma XPU는 지오메트리 모션 블러와 셔터 창 블러를 지원합니다. USD 카메라 prim의 모션 블러 셔터 설정이 Render Settings prim에서 예상하는 것과 일치하는지 확인하시기 바랍니다. Solaris 셔터 처리와 Karma 모션 블러 샘플링이 항상 일치하지는 않으며, 증상은 "렌더는 괜찮아 보이지만 모션 블러가 없거나 두 배로 보임"입니다.
Karma CPU
Karma CPU는 Karma의 순수 CPU 변형입니다. Houdini 19부터 기능 완성 및 안정화되었습니다. GPU VRAM을 초과하거나 XPU 코드 경로에 아직 구현되지 않은 기능에 의존하는 씬의 자연스러운 폴백입니다.
구성 참고사항:
- 워커 티어: CPU 워커 티어(Dual Intel Xeon E5-2699 V4 노드, 노드당 96~256 GB RAM, 플릿 전체에 20,000개 이상의 집계 CPU 코어).
- Karma XPU보다 선택해야 할 때: 매우 무거운 지오메트리(5천만 폴리곤 이상), 32 GB VRAM을 초과하는 밀도 높은 볼류메트릭 렌더링, XPU 동등 기능이 아직 없는 OSL 커스텀 셰이더, 또는 동일한 제출에서 CPU 집약적 시뮬레이션 패스를 혼합하는 프로젝트.
- Karma XPU와 동일한 Solaris/USD 통합. 렌더 제품과 AOV 구성이 동일합니다. 계산 백엔드만 다릅니다.
Mantra (레거시)
Mantra는 Houdini의 사전 Karma 렌더러입니다. USD 우선 파이프라인보다 먼저 나온 SideFX의 마이크로폴리곤 엔진입니다. SideFX는 Mantra가 앞으로 나아가는 경로가 아니라고 밝혔습니다. Karma가 그 경로입니다. Mantra는 Karma가 실용적이기 전에 작성된 프로젝트와의 하위 호환성을 위해 Houdini 빌드에 남아 있습니다.
구성 참고사항:
- 워커 티어: CPU 워커 티어.
- 성능. Mantra는 동등한 씬에서 일반적으로 Karma CPU보다 프레임당 느리며 Karma XPU가 제공하는 GPU 가속 경로가 없습니다. 새 프로젝트는 Karma를 사용해야 합니다.
- 사용 시기. 프로젝트 파일이 Mantra에 고정된 경우(Karma가 실용적이기 전에 시작된 장기 프로덕션, 아직 포팅되지 않은 셰이더 라이브러리), 또는 Mantra 전용 기능이 필요한 경우(일부 Mantra 마이크로폴리곤 엣지 케이스에는 아직 정확한 Karma 동등 기능이 없음). 2026년 새 작업의 경우 Karma를 기본값으로 사용하시기 바랍니다.
Redshift for Houdini
Redshift for Houdini는 저희 RTX 5090 GPU 워커 티어에서 실행됩니다. Redshift는 구축된 Redshift 파이프라인을 가진 스튜디오에 적합한 선택입니다. 종종 DCC 간에 셰이더 라이브러리를 공유하기 위해 FX를 위해 Houdini로 분기하는 Maya 또는 Cinema 4D 스튜디오에 해당합니다.
구성 참고사항:
- 라이선스 프레임워크. 저희 팜의 Redshift는 저희 라이선스로 실행됩니다. Redshift는 현재 Maxon 제품이며, 저희 Maxon 파트너십은 저희가 지원하는 모든 DCC(C4D, Houdini, Maya)에서 Redshift를 커버합니다.
- 아웃 오브 코어 메모리. 기본적으로 활성화됩니다. 워커당 32 GB VRAM 상한을 초과하여 유효 씬 메모리를 확장합니다. GPU에서 OOM이 발생할 수 있는 밀도 높은 씬에 중요합니다.
- Houdini 전용 기능. Redshift는 Houdini의 볼륨 기본 유형(VDB, Pyro 캐시)과 직접 통합됩니다. 볼륨 렌더링을 위한 특별한 내보내기 단계가 필요하지 않습니다. Redshift ROP는 레이 바이어스, 샘플링, AOV 구성을 위한 Houdini 네이티브 파라미터를 노출합니다.
- 버전 고정. Redshift는 Houdini의 릴리스 주기와 독립적으로 자체 3.x 주기로 릴리스됩니다. 주요 Redshift 버전(3.0 → 3.5 → 4.0 출시 시)은 하위 호환성이 보장되지 않습니다. Redshift 3.5.18로 저장된 씬이 Redshift 3.0.x를 실행하는 워커에서 깨끗하게 로드되지 않을 수 있습니다. 씬 저장 시 Redshift 빌드를 기록하고 전체 시퀀스를 제출하기 전에 워커 호환성을 확인하시기 바랍니다.
Arnold for Houdini
Arnold for Houdini(HtoA라고도 하며, 현재 Arnold 7.x 릴리스 주기)는 저희 CPU 워커 티어에서 실행됩니다. 룩데브가 한 DCC에서 작성되고 FX가 다른 DCC에서 작성되지만 셰이더와 렌더링 레이어가 통합된 공유 Maya/Houdini Arnold 파이프라인을 가진 스튜디오에 적합한 선택입니다.
구성 참고사항:
- 라이선스 프레임워크. 저희 팜의 Arnold는 Autodesk 렌더 노드 라이선스로 실행됩니다.
- AOV. Houdini에서 Arnold의 AOV 시스템은 Maya에서와 동일하게 작동합니다. ROP별로 구성하고 멀티채널 EXR 또는 AOV별 파일에 씁니다. 크로스 DCC 패턴이 일관됩니다.
- 버전 고정. HtoA 버전은 Arnold의 릴리스 주기를 따릅니다(Houdini 19.5/20.0용 HtoA 6.x; 출시 시 Houdini 20.5/21.0용 HtoA 7.x). 주요 HtoA 점프(6 → 7)는 절대 호환 가능하다고 가정해서는 안 됩니다. 워커에 씬이 저장된 최소 마이너 버전이 있는지 확인하시기 바랍니다.
V-Ray for Houdini
V-Ray for Houdini는 저희 CPU 워커 티어에서 실행됩니다. Houdini에서의 채택은 3ds Max 또는 Maya보다 현저히 낮지만, V-Ray 중심 파이프라인을 가진 스튜디오를 위해 통합이 지원됩니다.
구성 참고사항:
- 라이선스 프레임워크. 저희 팜의 V-Ray는 저희 라이선스로 실행됩니다.
- VRayProxy 에셋. 지원됩니다. 워커가 해석할 수 있도록
.vrmesh파일을$HIP/geo/에 포함하시기 바랍니다. - Houdini 전용 사항. Houdini용 V-Ray의 ROP는 3ds Max의 V-Ray와 동일한 렌더 설정(샘플러 유형, 렌더 요소(AOV), 출력 형식)을 노출합니다. 크로스 DCC 파라미터 매핑은 Chaos의 V-Ray for Houdini 참조에 문서화되어 있습니다.
Octane for Houdini
Octane for Houdini는 저희 RTX 5090 GPU 워커 티어에서 실행됩니다. 주로 스타일라이즈드 출력을 위해 Houdini와 Cinema 4D를 연결하는 모션 디자인 스튜디오가 사용합니다.
구성 참고사항:
- 라이선스 프레임워크. Otoy 렌더 노드 라이선스.
- VRAM 제약. Cinema 4D용 Octane과 동일합니다. 워커당 32 GB VRAM이며 Redshift보다 공격적인 메모리 프로필입니다(아웃 오브 코어 경로 없음). Redshift에서 24 GB에 맞는 씬이 Octane의 32 GB에 맞으려면 텍스처 다운샘플링 또는 지오메트리 데시메이션이 필요할 수 있습니다.
제출 흐름
팜에서 Houdini 프로젝트에는 세 가지 제출 채널이 있습니다.
- 웹 업로드 + 대시보드를 통한 제출.
$HIP폴더를.tar.gz또는.7z로 압축하여 웹사이트를 통해 업로드한 후, 작업(렌더러, ROP 노드, 프레임 범위, 출력 형식)을 구성하고 제출합니다. 일회성 Houdini 작업과 총 업로드 크기 ~50 GB 미만의 프로젝트에 가장 일반적인 경로입니다. - 대용량 프로젝트를 위한 SFTP. 멀티 테라바이트 시뮬레이션 캐시가 있는 Houdini 프로젝트는 재개 가능한 전송을 위해 SFTP를 통해 전송해야 합니다. SFTP 워크플로우, 자격증명, 웹 업로드에서 SFTP로 전환하는 임계값은 를 참조하시기 바랍니다.
- Client App. Super Renders Farm Client App은 데스크톱 애플리케이션에서 업로드, 제출, 자동 다운로드를 하나로 묶습니다. 파라미터 변경과 함께 동일한 프로젝트 구조를 반복 렌더링하는 스튜디오에 유용합니다. 을 참조하시기 바랍니다.
Houdini UI와 직접 통합되는 Houdini용 제출 플러그인이 개발 중이지만 아직 모든 워커에 사전 설치되어 있지 않습니다. 현재는 웹 대시보드 제출 흐름이 권장 경로입니다. 작성할 내용, 프레임 범위 설정 방법, 출력 파일 위치 등 크로스 DCC 제출 안내는 에 있습니다.
내부적으로 워커는 Houdini의 배치 렌더링 진입점을 호출합니다. OBJ/SOP 컨텍스트 ROP(Mantra, Karma CPU, Redshift, Arnold, V-Ray, Octane)에 대한 HIP 파일 제출에는 hbatch, Karma(CPU 또는 XPU)에 대한 USD 스테이지 제출에는 husk를 사용합니다. 일반적으로 기본 호출을 알 필요가 없지만, 예상치 못한 출력 이름 지정이나 프레임 범위 동작을 디버깅하는 경우 ROP 레벨 설정이 워커가 명령줄 플래그를 통해 hbatch/husk에 전달하는 것입니다.
Houdini 전용 오류 문제 해결
일반 크로스 DCC 문제 해결(에셋 누락, 프레임 N에서 렌더 실패, 일반적인 출력 형식 문제)은 를 참조하시기 바랍니다. 지원 티켓에서 가장 많이 나타나는 Houdini 전용 오류 패턴:
- "Unable to find HDA" 또는 HDA가 오래된 노드 플레이스홀더로 로드 실패. 워커가 씬이 참조하는 HDA 파일을 찾을 수 없습니다. HDA가
.hip에 임베드(Asset 메뉴 → Operator Type Manager → "Save to Embedded")되어 있거나 검색 경로가 구성된$HIP/hda/에 있는지 확인하시기 바랍니다. 스튜디오 공유 라이브러리에서 HDA를 참조하는 경우 제출 전에 프로젝트 폴더에 복사하시기 바랍니다. - 렌더 시 캐시 파일을 찾을 수 없음 / 빈 시뮬레이션 지오메트리. 제출 전에 캐시 파일이 실제로 디스크에 베이킹되었는지 확인하시기 바랍니다. 각 File Cache SOP를 열고 "Output" 탭이 표시된 경로에 파일이 있는지 확인하시기 바랍니다. 경로에 절대 드라이브 문자(
D:\sim_cache\flip.0001.bgeo.sc)가 사용된 경우$HIP/cache/{node_name}/$F4.bgeo.sc로 변경하고 다시 베이킹하시기 바랍니다. 업로드 전 60초 확인 — File → Refresh All과 File Cache SOP 수동 검사 — 이 Houdini 렌더 실패의 가장 큰 단일 카테고리를 예방합니다. - 렌더 출력이 완전히 비어 있음 / 검정 프레임. ROP의 "Render Settings" prim(Solaris 스테이지의 Karma) 또는 카메라 참조(/ obj 컨텍스트 ROP의 Mantra, Redshift, Arnold, V-Ray, Octane)를 확인하시기 바랍니다. 가장 흔한 원인은 뷰포트에서 설정되었지만 ROP에서 참조되지 않은 카메라입니다. 워커에는 뷰포트가 없으므로 ROP 레벨 카메라 참조가 권위 있는 설정입니다.
- Karma XPU가 "OptiX not available" 또는 "GPU not detected"로 즉시 실패합니다. GPU 워커 플릿에 확인된 CUDA + OptiX 드라이버 커버리지가 있으므로 저희 팜에서는 드문 경우입니다. 발생하는 경우 가장 흔한 원인은 업데이트 중인 워커나 진행 중인 드라이버 롤백입니다. 5~10분 후 다시 제출하거나 여러 제출에서 문제가 지속되면 지원팀에 문의하시기 바랍니다.
- 사전 렌더 Python 스크립트가 워커에서 실패합니다. 스크립트를 비활성화하거나 경로 이식성 있게 만드시기 바랍니다. 워크스테이션 전용 모듈 경로(스튜디오의 파이프라인 도구)를 참조하거나, UI 대화 상자를 열거나,
hou.system()을 통해 로컬 바이너리를 호출하는 커스텀 Python은 헤드리스 Linux 워커에서 실행되지 않습니다. - Solaris / USD 에셋 참조가 끊어집니다. USD 에셋 리졸버 경로는
$HIP-상대적이어야 하고, 워커가 로드할 수 있는 USD 리졸버 컨텍스트를 사용하거나, 제출 전에 USD ROP를 통해 단일 구성 USD로 평탄화되어야 합니다. USD 참조 레이어의 절대 경로가 여기서 가장 흔한 오류 모드입니다. - 플러그인 버전 불일치 / 씬 로드 실패. 로컬 플러그인 버전이 워커와 다릅니다. HtoA 6 → 7 또는 Redshift 3.0 → 3.5 점프에서 가장 흔합니다. 씬 저장 시 플러그인 버전을 확인하고(HIP 파일 헤더 텍스트 또는 플러그인의 ROP 메뉴 버전 스탬프를 통해 확인 가능) 워커에 해당 마이너 버전 이상이 있는지 확인하시기 바랍니다. 주요 버전 점프는 절대 호환 가능하다고 가정해서는 안 됩니다.
- Houdini 버전 불일치 (20.0 워커에서 20.5 씬). HIP 파일 형식에는 버전 메타데이터가 포함됩니다. 구버전 Houdini는 최신 버전으로 저장된 씬을 열 수 없습니다. 워커에 씬 저장 버전 이상의 Houdini가 있는지 확인하거나, 절대적으로 필요한 경우 씬을 대상 버전으로 다시 저장하시기 바랍니다.
- OpenCL 시뮬레이션이 렌더에서 실행되지 않습니다. OpenCL 시뮬레이션은 렌더 시간이 아닌 베이킹 시간에 실행됩니다. 제출 전에 캐시로 베이킹하시기 바랍니다. 팜은 렌더링 중에 라이브 OpenCL 시뮬레이션을 실행하지 않습니다. 이는 설계에 의한 것이며 FLIP, Pyro, Vellum 및 기타 OpenCL 가속 솔버에 적용됩니다.
- 제출과 워커 간 OCIO 구성 드리프트. 로컬
OCIO환경 변수가 워커에 없는 스튜디오 전용 구성을 가리키는 경우, 색상이 워커의 기본 구성으로 렌더링되어 다르게 보입니다. OCIO 구성 파일을 프로젝트와 함께 번들하거나, 제출 환경 재정의를 통해OCIO를 설정하거나, 워커도 제공하는 Houdini의 내장 ACES 구성을 사용하시기 바랍니다. - Houdini 버전 간 Pyro/FLIP 캐시 "missing field" 경고. 캐시 파일 형식이 주요 Houdini 버전 간에 때때로 변경됩니다. 최신 Houdini에서 로드된 구버전 캐시가 필드를 삭제할 수 있습니다. 대상 Houdini 버전에서 시뮬레이션을 다시 캐시하거나, 워커가 캐시를 작성한 것과 동일한 Houdini 빌드를 사용하는지 확인하시기 바랍니다.
관련 링크
- — 업로드, 제출, 다운로드 워크플로우 (크로스 DCC)
- — Houdini 작업 비용 계산 방법 (GPU vs CPU 티어)
- — SFTP 가이드, 아카이브 형식, 대용량 프로젝트 전송
- — 크로스 DCC 문제 해결
- — 데스크톱 제출 래퍼
- — 랜딩 페이지 (렌더러 매트릭스, 하드웨어, 가격 예시)
FAQ
Q: 팜에서 지원하는 Houdini 버전은 무엇입니까? A: Houdini 19.5, 20.0, 20.5가 모든 워커에 사전 설치되어 있습니다. 저희는 SideFX의 릴리스 일정을 추적하며 새 주요 빌드를 공개 후 4주 이내에 프로비저닝합니다. Houdini FX(.hip)와 Houdini Indie(.hipnc) 씬 파일 모두 지원됩니다. Houdini Apprentice 파일은 렌더링되지만 SideFX의 비상업적 라이선스 조건에 따라 워터마크가 포함된 출력을 생성합니다. 유료 프로덕션 작업의 경우 제출 전에 비-Apprentice 라이선스에서 저장하시기 바랍니다.
Q: 팜에서 렌더링하기 위해 Houdini 라이선스를 이전해야 합니까? A: 아닙니다. 저희는 렌더 전용 활용 방식으로 Houdini를 운영합니다. 이를 통해 스튜디오 라이선스 풀에서 SideFX 시트를 점유하지 않고 렌더 워커에서 오프라인 렌더링을 위해 Houdini를 실행할 수 있습니다. 로컬 Houdini 라이선스는 귀하와 함께 유지됩니다. Super Renders Farm은 SideFX 파트너가 아닙니다. 렌더 전용 활용은 팜에서 Houdini 씬 렌더링을 허용하는 법적 프레임워크입니다.
Q: 새 프로젝트에 Karma XPU, Karma CPU, Mantra 중 어느 것을 사용해야 합니까? A: 2026년 새 프로젝트에는 Karma XPU를 사용하시기 바랍니다. SideFX의 권장 전향 경로이며, 저희 RTX 5090 GPU 티어에서 실행되고, 대부분의 씬에서 Karma CPU 또는 Mantra보다 훨씬 빠릅니다. 32 GB VRAM을 초과하거나, GPU를 넘치는 무거운 볼류메트릭스에 의존하거나, XPU에서 아직 지원되지 않는 OSL 커스텀 셰이더를 사용하는 씬에는 Karma CPU를 사용하시기 바랍니다. 프로젝트 파일이 Mantra에 고정된 경우(Karma가 실용적이기 전에 시작된 장기 프로덕션, 또는 Karma 동등 기능이 없는 Mantra 전용 셰이더 기능)에만 Mantra를 사용하시기 바랍니다. 새 작업의 경우 Karma를 기본값으로 사용하시기 바랍니다.
Q: 팜에서 Houdini 시뮬레이션(Pyro, FLIP, Vellum, RBD)을 실행할 수 있습니까? A: 아닙니다. 시뮬레이션은 워크스테이션 작업입니다. 제출 전에 모든 시뮬레이션 캐시를 로컬에서 .bgeo.sc 또는 .vdb 파일로 베이킹하시기 바랍니다. 팜은 사전 베이킹된 캐시에 대해 렌더링합니다. 렌더 작업의 일부로 라이브 시뮬레이션을 실행하지 않습니다. 이는 대부분의 관리형 클라우드 팜에서 Blender 또는 Maya 시뮬레이션 워크플로우와 동일한 패턴입니다.
Q: 프로젝트에서 Houdini의 Solaris/USD 파이프라인을 사용합니다. 올바르게 렌더링됩니까? A: 예. Karma(CPU 또는 XPU)를 렌더러로 사용하면 됩니다. Solaris를 위해 설계된 경로는 Karma입니다. 두 렌더러 모두 USD 스테이지를 네이티브로 사용하며 Solaris/Karma 통합이 SideFX 권장 전향 파이프라인입니다. 클라우드 제출의 경우 USD ROP를 통해 USD 스테이지를 단일 구성 .usd 파일로 평탄화하거나, 모든 레이어가 워커에서 해석되도록 전체 $HIP/usd/ 디렉터리 트리를 번들하시기 바랍니다. 타사 렌더러(Redshift, Arnold)도 Houdini 통합이 지원하는 경우 USD 기반 씬을 렌더링할 수 있습니다. 전체 시퀀스를 제출하기 전에 단일 프레임에서 로컬로 확인하시기 바랍니다.
Q: 씬에서 스튜디오 공유 라이브러리의 커스텀 HDA를 사용합니다. 팜에서 찾을 수 있습니까? A: 팜은 스튜디오 공유 네트워크 드라이브(\\studio-fs\hda\... 또는 동등한 것)에서 HDA를 찾을 수 없습니다. Asset 메뉴 → Operator Type Manager → "Save to Embedded"를 통해 HDA를 .hip에 임베드하거나, 프로젝트를 압축하기 전에 .hda/.otl 파일을 $HIP/hda/에 복사하시기 바랍니다. Python 쉘에서 hou.hda.loadedFiles()를 사용하여 모든 로드된 HDA가 $HIP 아래에서 해석되거나 표준 SideFX 에셋인지 확인하시기 바랍니다.
Q: 시뮬레이션 캐시를 사용하는 Houdini 프로젝트를 어떻게 패키징합니까? A: 모든 시뮬레이션을 제출 전에 로컬에서 $HIP/cache/{solver_name}/$F4.bgeo.sc(또는 볼륨용 .vdb)로 베이킹하시기 바랍니다. File → Refresh All을 통해 캐시 파일이 예상 경로에 있는지 확인하시기 바랍니다. cache/ 하위 폴더를 포함한 전체 $HIP 폴더를 .tar.gz 또는 .7z로 압축하시기 바랍니다. 수백 기가바이트를 초과하는 캐시의 경우 웹 폼 대신 SFTP를 통해 업로드하시기 바랍니다. 팜은 베이킹된 캐시에 대해 프레임을 렌더링합니다. 시뮬레이션 자체는 워커 노드가 아닌 워크스테이션에서 실행됩니다.
Q: Houdini 프로젝트 업로드는 얼마나 클 수 있습니까? A: 업로드 크기 상한이 없지만 단일 브라우저 업로드는 ~50 GB 미만을 권장합니다. 그 이상은 재개 가능한 전송을 위해 SFTP로 전환하시기 바랍니다. 를 참조하시기 바랍니다. 팜은 적절한 디렉터리 구조로 SFTP를 통해 업로드된 멀티 테라바이트 Houdini 시뮬레이션 렌더를 처리했습니다.
Q: 팜에서 Mantra 렌더가 로컬보다 훨씬 느립니다. 예상된 것입니까? A: 저희 CPU 워커 티어(Dual Xeon E5-2699 V4)에서 Mantra의 프레임당 속도는 고성능 워크스테이션과 비슷합니다. 로컬보다 프레임당 시간이 훨씬 느린 경우 가장 가능성 높은 원인은 워커의 다른 샘플링 구성(Mantra는 ROP에서 샘플을 읽습니다. ROP 레벨 설정이 일치하는지 확인하시기 바랍니다) 또는 워커의 CPU 전용 티어에서 활성화되지 않은 로컬 OpenCL 가속입니다. 구조적 수정 방법은 마이그레이션입니다. 저희 GPU 티어의 Karma XPU는 대부분의 씬에서 Mantra보다 훨씬 빠르며, Karma는 SideFX가 앞으로 권장하는 경로입니다.
Q: 팜에서 분산 작업 관리를 위한 Houdini의 PDG/TOPs를 지원합니까? A: PDG는 워크스테이션 측 오케스트레이션입니다. 팜은 자체 큐와 워커 할당 시스템을 사용합니다. PDG를 로컬에서 에셋 작성 및 베이킹에 사용한 후 웹 대시보드나 Client App을 통해 최종 ROP 작업을 팜에 제출할 수 있습니다. 외부 팜에 대한 직접 PDG 기반 제출은 로드맵에 있지만 아직 일급 워크플로우는 아닙니다.
Q: Houdini 클라우드 렌더링의 비용은 어떻게 계산됩니까? A: 팜에서 Houdini 비용은 렌더러의 워커 티어를 따릅니다. Karma XPU, Redshift, Octane에는 GPU 요금, Karma CPU, Mantra, Arnold, V-Ray for Houdini에는 CPU 요금이 적용됩니다. 프레임당 복잡도(샘플 수, AOV 수, 출력 해상도)가 프레임당 비용을 결정합니다. 렌더러 선택이 노드당 시간 요금을 결정합니다. 시뮬레이션은 팜에서 실행하는 경우에만 추가 비용이 발생합니다(로컬에서 캐시하고 캐시를 업로드하는 것을 권장합니다). 가격 세부 정보는 를 참조하거나 저희 에서 추정하시기 바랍니다.
---