렌더팜에서 USD를 사용하는 Maya 씬 렌더링

Universal Scene Description(USD)는 Pixar 내부 포맷에서 많은 Maya 파이프라인의 핵심으로 자리를 잡았습니다. 스튜디오에서 레이어드 USD 스테이지로 샷을 구성하고, 부서 간 퍼블리시된 에셋을 참조하며, 결과물을 procedural을 통해 렌더러에 전달한다면 USD는 이미 씬의 근간이 되었다는 것을 잘 알고 있을 것입니다. 워크스테이션에서 완벽하게 렌더링되는 씬이 다른 렌더팜에서도 그대로 렌더링된다는 보장은 없습니다. 렌더팜에는 적합한 MayaUSD 빌드, 적합한 렌더 엔진 USD 지원, 그리고 스테이지가 참조하는 모든 에셋 경로를 해석할 수 있는 방법이 필요합니다. 이 중 하나라도 빠지면 명확한 오류가 발생하지 않습니다. 프레임 실패, 무음 폴백, 또는 단순히 지오메트리가 없는 상황이 발생합니다.

저희는 관리형 렌더팜을 운영하고 있으며, Maya에 USD를 결합한 작업은 스튜디오들이 워크스테이션에서 이전하기 어려워하는 워크플로우 중 하나입니다. 이 가이드에서는 USD가 독립적인 .ma 파일보다 원격 렌더링이 왜 더 어려운지, 실제로 무엇이 맞아야 하는지, 그리고 저희가 어떻게 처리하는지를 설명합니다. 여기에는 실수하기 쉬운 부분도 포함됩니다.

Maya USD 렌더 파이프라인: 레이어드 USD 스테이지에서 MayaUSD 플러그인, Arnold USD procedural, 렌더링된 프레임으로 이어지는 흐름. 에셋 해석 및 환경 매칭 포함.

USD가 독립적인 씬보다 원격 렌더링이 어려운 이유

전통적인 Maya 씬은 대부분 자기 완결적입니다. 씬을 열면 메시와 머티리얼이 그 자리에 있고, 렌더러를 연결하면 프레임이 나옵니다. USD 기반 씬은 완성된 요리가 아니라 레시피에 가깝습니다. .usd, .usda, .usdc 파일은 레이어드 명령어의 집합으로 — 서브레이어, 레퍼런스, 페이로드, 배리언트 등이 로드 시 최종 스테이지로 합성됩니다. 이 합성 방식은 강력하지만, 렌더링하는 머신에서 세 가지 별도의 요소가 모두 존재하고 호환되어야 한다는 것을 의미합니다.

첫 번째는 MayaUSD 플러그인 자체입니다. MayaUSD는 Maya가 USD 스테이지를 읽고, 합성하고, 렌더링으로 전달할 수 있게 해주는 브릿지입니다. 렌더팜의 Maya에 MayaUSD가 로드되지 않았거나, 아티스트가 작업한 버전과 다르게 스테이지를 합성하는 버전이 설치되어 있다면, 씬이 열리지 않거나 USD를 통해 가져온 부분이 누락된 채 열립니다.

두 번째는 에셋 경로 해석입니다. USD 스테이지는 경로를 통해 다른 파일들 — 지오메트리, 텍스처, 중첩된 USD 레이어 — 을 참조합니다. 워크스테이션에서는 데이터가 스테이지가 기대하는 위치에 있으므로 경로가 해석됩니다. 렌더팜에서는 동일한 디렉토리 구조와 동일한 리졸버 동작이 재현되지 않으면 참조의 절반이 아무것도 해석하지 못합니다. "집에서는 잘 되는" USD 씬이 렌더팜에서 빈 결과물로 돌아오는 가장 흔한 이유가 바로 이것입니다. 픽셀은 제대로 렌더링되었지만 레퍼런스를 찾지 못한 것입니다.

세 번째는 렌더러의 USD 지원입니다. 렌더 엔진은 Maya가 전달하는 USD 데이터를 이해해야 합니다. Arnold의 경우, 이 경로는 Arnold USD procedural을 통해 처리됩니다. 이 procedural은 전체 스테이지를 Maya에서 먼저 펼치는 것이 아니라 렌더 타임에 USD 콘텐츠를 읽습니다. procedural이 설치되지 않았거나 버전이 데이터와 일치하지 않으면, 렌더러는 읽을 수 없는 것을 조용히 건너뜁니다.

이것은 일부 클라우드 렌더 서비스의 잘 알려진 격차가 드러나는 지점이기도 합니다. AWS 자체의 Maya용 Deadline Cloud 트래커에는 서브미터의 MayaUSD 지원을 다루는 공개 이슈가 있습니다(aws-deadline/deadline-cloud-for-maya#409). 이는 USD 씬이 안정적으로 렌더링되려면 처음부터 끝까지 해결되어야 하는 바로 그 배관 작업의 예시입니다. USD 렌더링은 켜고 끄는 기능 하나가 아니라, 모두 일치해야 하는 버전과 경로의 체인입니다.

Maya의 USD Layer Editor에서 서브레이어와 레퍼런스가 보이는 레이어드 USD 스테이지와 Arnold RenderView 출력.

저희 렌더팜에서 Maya + USD를 렌더링하는 방법

저희의 접근 방식은 단 하나의 프레임도 큐에 올라가기 전에 시작됩니다. 씬을 고정된 렌더팜 이미지에 맞추도록 요청하는 것이 아니라, 환경을 씬에 맞게 조정합니다. 스튜디오에서 USD 기반 Maya 작업을 전송하면 Maya 버전, MayaUSD 빌드, 렌더러, 그리고 에셋이 작업된 USD 버전을 확인한 후 노드를 맞게 구성합니다. 목표는 스테이지가 저희 노드에서 아티스트의 머신에서와 동일한 방식으로 합성되도록 하는 것입니다 — 동일한 플러그인 동작, 동일한 해석, 동일한 procedural.

렌더링 측면에서 Arnold를 사용하는 Maya USD 작업에서 가장 중요한 두 가지 요소는 모두 깔끔하게 초기화되어야 합니다. 스테이지를 Maya 내에서 합성하는 MayaUSD와 렌더 타임에 USD 콘텐츠를 읽는 Arnold USD procedural이 그것입니다. 저희는 노드 풀 전체에서 두 가지가 모두 올바르게 로드되고 실행되는 프로덕션 Maya 작업을 렌더링했습니다. 이것이 실질적인 테스트입니다 — "렌더팜이 USD 지원을 주장하는가"가 아니라 "이 스테이지가 이 레퍼런스들로 아티스트가 기대하는 프레임을 생성하는가"입니다. Arnold는 저희 CPU 노드에서 실행되며, 이는 많은 스튜디오가 최종 품질 USD 작업에 Arnold를 사용하는 방식에 맞습니다. 프로젝트가 요구하는 경우 GPU에서도 동일한 씬을 실행할 수 있습니다.

주목할 만한 세부 사항이 있습니다. 몇 가지 파이프라인을 거친 USD 씬에는 종종 더 이상 사용하지 않는 렌더러의 불필요한 플러그인 레퍼런스와 남겨진 노드 속성이 포함되어 있습니다. 프로젝트가 수개월 전에 포기한 플러그인을 요청하거나, 최종 렌더 경로에 없는 엔진의 속성을 갖고 있는 씬을 봅니다. 저희 노드에서 이러한 잔재는 무해합니다 — Maya는 이들을 지나쳐 실제로 사용하는 엔진으로 렌더링합니다. 정리된 로그를 원한다면 Maya에서 알 수 없는 플러그인 요청과 남겨진 노드를 제거한 후 전송할 수 있지만, 이는 외관상의 문제입니다. 렌더를 멈추게 하는 것이 아닙니다. "무해한 잔재"와 "실제로 실패하는 것"의 차이를 아는 것이 USD 렌더를 원활하게 만드는 핵심입니다.

하드웨어에 대한 솔직한 제약 사항을 설명하겠습니다. 저희 GPU 노드는 GPU당 32GB 메모리를 갖춘 RTX 5090 카드로 구성되어 있으며, 이 메모리는 카드 단위입니다 — 머신의 두 카드 간에 풀링되지 않습니다. 대부분의 스튜디오가 저희에게 가져오는 CPU-Arnold USD 작업의 경우 이 한도가 문제가 되는 경우는 드물지만, 매우 큰 텍스처나 무거운 볼류메트릭이 있는 씬에서 GPU 경로를 실행하는 경우 미리 GPU당 메모리 사용량을 확인하는 것이 좋습니다. 작업이 실행 중에 프레임이 맞지 않는 상황보다 미리 확인하는 것이 훨씬 낫습니다.

재업로드 없이 기존 파일 공간에서 렌더링하기

앞서 설명한 에셋 해석 문제는 스튜디오가 이미 마운트된 파일 공간에 프로젝트를 보관하고 있을 때 깔끔한 해결책이 있습니다. 에셋이 LucidLink에 있다면, 저희는 렌더 노드에 동일한 파일 공간을 마운트할 수 있습니다. 이렇게 하면 USD 스테이지는 아티스트가 보는 것과 정확히 동일한 데이터로 레퍼런스를 해석합니다 — 수 기가바이트의 에셋 라이브러리를 재업로드할 필요도 없고, 디렉토리 구조를 수동으로 재구성할 필요도 없습니다. 스테이지는 실제 경로가 마운트되어 있으므로 실제 경로로 합성합니다.

이것은 패키지화된 단일 파일 씬보다 USD에서 더 중요합니다. USD가 바로 외부 레퍼런스에 의존하기 때문입니다. 진실의 소스를 마운트하면 "레퍼런스를 찾을 수 없음" 오류의 전체 범주가 제거됩니다. 잘못 복사할 것이 없기 때문입니다 — 렌더팜이 스튜디오와 동일한 트리를 읽습니다. 이미 LucidLink를 기본으로 사용하는 팀에게는 번거로운 업로드-and-pray 사이클과 그냥 해석되는 렌더의 차이가 됩니다.

스튜디오 LucidLink 파일 공간이 렌더 노드에 라이브로 마운트되어 에셋을 그 자리에서 읽습니다 — 재업로드 없음.

포함된 항목 — 머신만이 아닌 라이센스와 DCC

저희에서 전용 용량을 임대하면 렌더 엔진 라이센스와 DCC 애플리케이션이 함께 제공됩니다. Maya, 렌더러 — Arnold, V-Ray, Redshift, Octane, Cycles — 그리고 지원 플러그인이 저희가 프로비저닝하는 것의 일부입니다. 노드별로 직접 라이센스를 취득해야 하는 것이 아닙니다. USD 작업의 경우 일반적으로 Arnold 라이센싱이 런의 일부로 저희 측에서 처리됩니다. 블록의 모든 노드에 대해 렌더 라이센스를 별도로 조달할 필요가 없습니다.

이는 베어메탈 또는 자체 구축 방식과 비교할 때 고려할 가치가 있습니다. 머신당 요금이 렌더 엔진 라이센스를 다시 추가하기 전까지는 더 낮아 보일 수 있습니다 — 그 라이센스들은 자체 호스팅 방식에서 노드당, 연간, 엔진당 수백 달러에서 천 달러 이상이 될 수 있습니다. 라이센스를 번들로 제공하는 것이 조용히 작동하는 부분입니다. 렌더링되는 씬은 Maya, MayaUSD, procedural, 엔진 라이센스가 모두 동시에 갖춰진 씬이며, 이를 함께 프로비저닝하는 것이 그 체인을 온전하게 유지하는 방법입니다.

실제 마이그레이션: 클라우드 스케줄러에서 실행할 수 없었던 Maya USD

구체적인 예를 들겠습니다. 최근 저희는 기존 클라우드 스케줄러 설정이 정확히 이 문제로 실패하는 UK 시각 효과 스튜디오와 협력했습니다 — Maya가 해당 환경에서 USD 에셋으로 작업할 수 없었습니다. 파이프라인은 LucidLink 파일 공간의 Arnold를 사용하는 Maya였습니다. 저희는 파일 공간을 노드에 마운트하고, 환경을 씬에 맞게 조정하고, 로그에서 MayaUSD와 Arnold USD procedural 모두 머신 전체에서 올바르게 초기화되고 렌더링된 것을 확인했습니다. 씬에는 이전 생애 단계의 일부 남겨진 레퍼런스가 있었습니다. 이들은 그냥 지나쳐졌고, 프레임이 나왔습니다. 스튜디오는 "USD 렌더가 계속 실패함"에서 깔끔한 런으로 전환했고, 그 이후 규모를 확장했습니다. 스튜디오를 익명으로 유지하고 있지만, 워크플로우 — Maya, USD, Arnold, LucidLink — 는 점점 예외가 아닌 표준이 되고 있습니다.

렌더팜에 USD 작업을 보내기 전 준비 체크리스트

저희와 함께 렌더링하든 다른 곳에서 렌더링하든, USD 씬이 렌더팜에서 예상치 못한 상황을 만들지 않도록 미리 확인할 사항들입니다.

대부분의 실패한 USD 렌더는 처음 세 행 중 하나로 추적됩니다. 작업 후가 아닌 작업 전에 이를 검토하는 이유는, USD에서 깔끔한 런과 빈 프레임의 차이가 보통 하나의 버전 불일치 또는 해석되지 않는 경로이기 때문입니다 — 그리고 마감 480번째 프레임보다 테스트 프레임에서 잡는 것이 훨씬 비용이 덜 듭니다.

바로 그 이유로, 저희가 일반적으로 Maya USD 작업을 시작하는 방식은 대표 프레임입니다. 전체 블록 전에 하나를 실행하여 스튜디오가 스테이지가 합성되고 프레임이 저희 노드에 생성되는 것을 확인하고, 더 큰 약정 전에 파이프라인을 처음부터 끝까지 검증할 수 있습니다. USD에서 하나의 프레임으로 체인을 증명하는 것은 어떤 기능 체크리스트보다 가치 있습니다.

USD를 넘어서 렌더팜에서 Maya 렌더링이 어떻게 작동하는지 더 넓은 그림을 원한다면, 저희 Maya 클라우드 렌더링 가이드에서 일반적인 워크플로우를 다루고 있으며, Maya용 렌더팜 선택 개요에서는 렌더팜을 평가하는 방법을 설명합니다. 이 USD 작업이 실행되는 전용 노드 임대는 저희 렌더팜 임대 페이지에서 설명합니다. 포맷 자체에 대해서는 Pixar의 OpenUSD 문서가 스테이지가 합성되는 방식에 대한 표준 참조입니다.

FAQ

Q: 렌더팜이 USD를 사용하는 Maya 씬을 지원합니까? A: 네. 저희는 MayaUSD 빌드와 렌더러의 USD 지원을 씬에 맞게 조정하여 USD를 사용하는 Maya 작업을 렌더링합니다. 프로덕션 런에서 로그를 통해 MayaUSD와 Arnold USD procedural이 노드 풀 전체에서 올바르게 초기화되고 렌더링되는 것을 확인했습니다. 핵심은 아티스트가 사용한 동일한 MayaUSD 빌드, USD 버전, 에셋 경로가 렌더 측에서 재현되는 것입니다.

Q: 어떤 Maya 및 USD 버전을 지원합니까? A: 하나의 고정된 이미지에 묶어두는 것이 아니라, Maya 버전, MayaUSD 빌드, 그리고 에셋이 작업된 USD 버전에 맞게 조정합니다. USD 합성은 레이어, 레퍼런스, 배리언트가 해석되는 방식에서 버전 차이에 민감하므로, 작업 환경을 맞추는 것이 스테이지를 워크스테이션에서와 동일한 방식으로 합성되게 유지하는 방법입니다.

Q: Arnold USD procedural을 지원합니까? A: 네 — Maya와 Arnold 조합의 경우, Arnold USD procedural은 렌더 타임에 USD 콘텐츠를 읽는 경로이며, 저희는 Arnold와 함께 이를 프로비저닝합니다. 데이터와 버전이 호환되어야 합니다. 그렇지 않으면 렌더러는 읽을 수 없는 것을 건너뜁니다. 저희는 전체 블록을 실행하기 전에 초기화를 확인합니다.

Q: Arnold 라이센스를 직접 가져와야 합니까? A: 아닙니다. Arnold를 포함한 렌더 엔진 라이센스는 저희가 프로비저닝하는 전용 용량의 일부입니다 — 노드별로 직접 라이센스를 취득하는 것이 아니라 포함된 것입니다. 자체 호스팅 방식에서는 머신 비용에 라이센스를 추가해야 합니다. 라이센스를 번들로 제공하는 것이 렌더 체인을 온전하게 유지하는 방법의 일부입니다.

Q: 에셋을 재업로드하지 않도록 LucidLink 파일 공간을 마운트할 수 있습니까? A: 네. 프로젝트가 LucidLink에 있다면, 렌더 노드에 파일 공간을 마운트하여 USD 스테이지가 아티스트가 보는 것과 정확히 동일한 데이터로 레퍼런스를 해석할 수 있습니다. USD에서 특히 이것은 일반적인 실패 모드를 제거합니다. 렌더팜이 다르게 구조화된 복사본이 아닌 동일한 에셋 트리를 읽기 때문입니다.

Q: 저희는 Maya USD 씬을 실행할 수 없는 클라우드 스케줄러를 사용 중입니다. 마이그레이션할 수 있습니까? A: 이것이 스튜디오들이 저희로 이전하는 일반적인 이유입니다. 저희는 환경을 씬에 맞게 조정하고, 파일 공간을 사용하는 경우 마운트하고, 전체 런을 약정하기 전에 대표 프레임에서 USD 스테이지가 합성되고 렌더링되는지 확인합니다. 마이그레이션은 주로 작업 환경을 렌더 측에서 충실하게 재현하는 것입니다.

Q: 씬에 더 이상 사용하지 않는 렌더러의 남겨진 레퍼런스가 있습니다 — 문제가 됩니까? A: 보통 그렇지 않습니다. 몇 가지 파이프라인을 거친 USD 씬에는 종종 불필요한 플러그인 요청과 남겨진 노드 속성이 있습니다. 저희 노드에서 Maya는 이들을 지나쳐 실제로 사용하는 엔진으로 렌더링합니다. 정리된 로그를 위해 Maya에서 이들을 제거할 수 있지만, 이는 외관상의 문제입니다 — 잔재는 렌더를 멈추게 하는 경우가 거의 없습니다.

Q: Maya USD를 CPU와 GPU 중 어디서 렌더링해야 합니까? A: 두 가지 모두 가능하며, 올바른 답은 렌더러와 씬에 따라 다릅니다. 많은 스튜디오가 최종 품질 USD 작업에 CPU에서 Arnold를 실행하며, 저희 CPU 노드는 이를 위해 구성되어 있습니다. 프로젝트가 필요로 하는 경우 GPU도 사용 가능합니다 — 다만 저희 GPU 카드는 카드당 32GB 메모리를 갖추고 있으며 풀링되지 않으므로, 매우 무거운 GPU 씬의 경우 미리 GPU당 메모리 사용량을 확인하는 것이 좋습니다.