고급 유틸리티: Render Node Template, Troubleshoot Machine, Simulate Local Path, API 액세스

Super Renders Farm은 기본 웹 업로드-제출-다운로드 흐름 이상이 필요한 스튜디오를 위한 네 가지 고급 유틸리티를 제공합니다. Render Node Template(작업을 렌더링하는 워커를 위한 재현 가능한 소프트웨어 스택 정의), Troubleshoot Machine(렌더 노드 환경과 일치하는 RDP 액세스 가능 디버그 VM 실행), Simulate Local Path(하드 코딩된 경로로 에셋을 참조하는 프로젝트에 대한 절대 경로 보존), API 액세스 서페이스(현재 제한됨 — 현재 프로그래밍 방식 제출에 대해서는 §API 액세스 참조). 이 페이지는 네 가지 모두에 대한 참조 매뉴얼입니다. 각 유틸리티를 언제 사용해야 하는지, 저희 팜에서 기본 메커니즘이 어떻게 작동하는지, 각각을 구성하거나 호출하는 정확한 단계, 지원에서 가장 자주 발생하는 실패 유형을 다룹니다.

팜을 처음 이용하며 기본 업로드 흐름을 찾고 있다면 가 올바른 시작점입니다. 실패한 작업을 디버깅하고 있다면 페이지에서 가장 빈번한 오류 패턴을 다룹니다. 여기에 문서화된 유틸리티는 기본 흐름이 맞지 않는 경우를 위한 것입니다. 일반적으로 기존 파이프라인이 있는 대형 스튜디오, 특이한 에셋 경로 요건이 있는 프로젝트, 또는 렌더 워커가 정확히 무엇을 보는지 확인해야 하는 일회성 디버그 세션입니다.

어떤 유틸리티를 사용해야 할지 — 결정 가이드

유틸리티별 섹션에 들어가기 전에 간단한 안내:

| 필요한 작업 | 사용 유틸리티 | |---|---| | 작업에 할당된 워커에서 어떤 DCC 버전, 플러그인 버전, 플러그인 라이선스가 실행될지 고정 | Render Node Template | | Microsoft Remote Desktop을 통해 실제 렌더 워커에 연결하고, 장면을 바로 수정한 다음 실제 작업으로 제출 | Troubleshoot Machine | | 절대 경로(C:\projects\… 또는 D:\textures\…)를 사용하고 상대 경로로 재경로 지정이 불가능한 프로젝트 렌더링 | Simulate Local Path | | 스크립트나 파이프라인 도구에서 프로그래밍 방식으로 작업 제출 | API 액세스(자리 표시자 참조 — 현재 경로는 Client App 또는 DCC 플러그인) |

이것들을 결합할 수 있습니다. Render Node Template을 동일한 작업의 Simulate Local Path와 함께 사용할 수 있습니다. Troubleshoot Machine은 활성 Render Node Template 및 모든 Simulate Local Path 구성을 모두 따르므로 디버그 환경이 프로덕션 렌더 환경과 일치합니다. 네 가지 유틸리티는 조합하도록 설계되었습니다.

Render Node Template

Render Node Template은 네 가지 유틸리티 중 가장 강력하고 가장 오래된 것입니다. 작업을 처리하기 전에 렌더 워커가 갖춰야 할 정확한 소프트웨어 환경을 지정할 수 있습니다. 어떤 버전의 3ds Max, 어떤 V-Ray 빌드, 어떤 플러그인이 설치 및 라이선스 부여되어 있는지, 렌더가 시작되기 전에 워커에 있어야 할 사용자 정의 구성 파일이 무엇인지 지정합니다. 한 번 정의하면 템플릿은 작업 전체에서 재사용 가능합니다. 해당 템플릿으로 태그된 모든 제출은 동일한 워커 스택에 대해 실행됩니다.

해결하는 문제

기본적으로 Super Renders Farm은 모든 렌더 워커에 선별된 소프트웨어 스택을 사전 설치합니다. 최근 DCC 버전과 가장 흔한 렌더러 및 플러그인으로 저희가 가장 많이 보는 작업 부하에 맞게 보정되어 있습니다. 작업의 80%에 이것이 올바른 기본값입니다. 워커에는 이미 장면에 필요한 소프트웨어가 있습니다. 그러나 기본값이 부족한 두 가지 상황이 있습니다.

• 버전 고정. 스튜디오가 3ds Max 2024 + V-Ray 6.10.05 + 특정 Forest Pack 빌드를 표준화했는데, 같은 애니메이션의 프레임 간에 샘플링 또는 노이즈 차이를 도입하는 최신 포인트 릴리즈를 워커가 선택할 위험을 감수할 수 없는 경우.
• 틈새 플러그인. 기본 팜 스택에 없는 플러그인(또는 플러그인 버전)을 사용하는 경우. 예: 덜 일반적인 Phoenix FD 릴리즈, Pulze ZBrush 브리지, 또는 특이한 Corona 기능 빌드.

Render Node Template을 사용하면 스택을 명시적으로 선언할 수 있습니다. 그러면 팜은 선언된 템플릿과 이미 일치하는 워커로 작업을 라우팅하거나, 작업을 할당하기 전에 일치하도록 새 워커를 프로비저닝합니다. 어느 방식이든 버전 고정 보장은 처음부터 끝까지 적용됩니다.

저희 팜에서의 작동 방식

Render Node Template은 계정에 연결된 명명된 구성 레코드입니다. 다음을 포함합니다.

• DCC 및 버전 — 예: 3ds Max 2024.2.2.
• 렌더러 및 버전 — 예: V-Ray 6.10.05.
• 버전이 있는 플러그인 목록 — 예: Forest Pack Pro 8.4.2, RailClone Pro 6.3, Phoenix FD 5.10.
• 라이선스 채널 — 저희 포괄 라이선스 인프라를 통해 워커에서 사용할 수 있는 라이선스(Chaos, Maxon, Otoy, AXYZ Design). 대부분의 플러그인은 기본으로 지원됩니다. 템플릿이 저희가 아직 호스팅하지 않는 플러그인을 참조하면 지원팀이 표시하고 자체 라이선스 파일을 제공하시기 바랍니다.
• 선택적 파일 페이로드 — 렌더 시작 전에 워커의 알려진 위치에 배치해야 할 구성 파일, 프리셋, 또는 쉐이더 라이브러리.

작업을 제출하고 템플릿으로 태그하면 팜 스케줄러가 현재 워커 풀에 대해 템플릿을 매칭합니다. 일치하는 워커가 유휴 상태이면 작업이 즉시 배포됩니다. 일치하는 워커가 없으면 스케줄러가 템플릿에 맞게 새 워커를 프로비저닝합니다. 이는 일반적으로 기본 스택 작업보다 몇 분 더 걸리며, 이것이 주요 상충 관계입니다.

Render Node Template 만들기

템플릿 편집기는 계정 대시보드의 "Render Node Templates"(또는 유사한 항목 — 정확한 UI 레이블은 대시보드 릴리즈 간에 변경될 수 있습니다. 항목이 보이지 않으면 지원팀에 연락하시면 계정에 표시해 드립니다)에서 액세스할 수 있습니다.

단계:

1. superrendersfarm.com에 로그인하고 대시보드의 Render Node Templates 섹션을 엽니다.
2. 새 템플릿을 만들고 설명적인 이름을 붙입니다. 일반적으로 프로젝트 코드 또는 studio-archviz-2024-vray6과 같은 스튜디오 표준 레이블입니다. 이름은 귀하의 것입니다. 팜은 매칭에만 사용합니다.
3. DCC 및 버전을 선택합니다. 드롭다운에는 현재 저희가 호스팅하는 모든 DCC 버전이 나열됩니다. 필요한 버전이 목록에 없으면 지원 대화 없이는 해당 버전에 대해 템플릿을 만들 수 없습니다. 일부 레거시 버전은 지원이 중단되었습니다.
4. 렌더러 및 버전을 선택합니다. 동일한 제약 — 드롭다운이 현재 팜 스택을 반영합니다.
5. 플러그인을 하나씩 추가합니다. 각 플러그인에 대해: 카탈로그에서 플러그인 이름을 선택하고, 버전을 선택하고, 라이선스 채널을 확인합니다. 카탈로그 외부의 플러그인은 추가하기 위해 지원 대화가 필요합니다. 플러그인이 충분히 주류라면 라이선스를 호스팅할 수 있는 경우 일반적으로 일회성 작업입니다.
6. 파일 페이로드를 첨부합니다. 워커에 필요한 구성 또는 프리셋 파일을 업로드합니다. 팜은 이것들을 템플릿과 함께 저장하고 렌더 시작 전에 워커 작업 디렉토리에 복사합니다.
7. 저장하고 검증합니다. 대시보드가 현재 워커 풀에 대해 검증 패스를 실행하고 "일치하는 워커 사용 가능"(첫 번째 작업에서 즉시 배포) 또는 "현재 일치하는 항목 없음 — 첫 사용 시 워커가 프로비저닝됨"(첫 번째 작업에서 약간의 시작 지연)을 보고합니다.

이제 템플릿은 이후의 작업 제출 시 선택할 수 있습니다.

제출 시 템플릿 사용

웹 업로드, Client App, DCC 제출 플러그인을 통해 렌더 작업을 제출할 때 제출 양식에 "Render Node Template" 드롭다운이 있습니다. 생성한 템플릿을 선택합니다. 작업이 전체 스택 선언을 상속합니다. 제출 양식 자체에서 DCC, 렌더러, 또는 플러그인 버전을 다시 지정할 필요가 없습니다.

두 가지 운영 참고 사항:

• 템플릿 + Express 우선순위 조합. Express 우선순위로 템플릿화된 작업을 제출할 수 있습니다. 스케줄러는 두 제약 조건과 일치하는 유휴 워커를 찾으려 합니다. 없으면 하나를 프로비저닝합니다. Express 템플릿화된 작업은 일반적으로 기본 스택 Express 작업보다 배포 창이 약간 더 길지만 가격 차이는 동일합니다.
• 템플릿 + Simulate Local Path 조합. 프로젝트에 절대 경로도 필요한 경우 평소와 같이 제출에서 Simulate Local Path를 구성합니다(§Simulate Local Path 참조). 템플릿은 소프트웨어 환경을 제어하고, Simulate Local Path는 파일시스템 레이아웃을 제어합니다. 서로 관계없는 사항입니다.

템플릿 편집 및 버전 관리

템플릿은 변경 가능합니다. 버전 고정을 편집하거나 플러그인을 추가/제거하거나 파일 페이로드를 교체할 수 있습니다. 그러나 템플릿을 편집하면 이를 사용하는 모든 향후 작업에 영향을 미칩니다. 이미 배포된 진행 중인 작업은 제출 시 캡처한 템플릿 버전으로 계속 진행됩니다.

템플릿 수정 전반에서 엄격한 버전 제어가 필요한 스튜디오에 일반적인 패턴은 복제 후 편집입니다. 플러그인 버전을 업데이트해야 할 때, 기존 템플릿을 studio-archviz-2024-vray6-r2로 복제하고 그곳에서 변경하고, 새 템플릿을 가리키도록 프로젝트의 제출 스크립트를 업데이트합니다. 이전 템플릿은 정확한 스택에 의존하는 진행 중인 프로젝트에 대해 변경되지 않은 채로 남습니다.

일반적인 실패 유형

• "일치하는 워커 없음 — 프로비저닝에 5-10분 걸림." 오류가 아니라 단순한 알림입니다. 스택 변경 후 첫 번째 템플릿화된 작업이 새 워커를 프로비저닝합니다. 동일한 템플릿에 대한 이후 작업은 워커가 이미 준비되어 있으므로 즉시 배포됩니다.
• "템플릿에 플러그인 라이선스를 사용할 수 없음." 지정한 플러그인이 저희 호스팅 라이선스 카탈로그에 없습니다. 지원팀에 연락하시기 바랍니다. 주류 플러그인은 일반적으로 며칠 내에 호스팅 라이선스를 추가합니다. 틈새 플러그인의 경우 라이선스를 온보딩하거나 제출 시 라이선스 파일을 제공할 수 있습니다.
• "렌더러 버전이 더 이상 지원되지 않음." 더 오래된 DCC 또는 렌더러 버전은 주기적으로 활성 스택에서 폐기됩니다. 템플릿 편집기가 저장 시 이것을 표시합니다. 수정 방법은 지원되는 버전으로 템플릿을 업데이트하거나 현재 빌드로 복제 후 편집하는 것입니다.
• "작업이 배포되었지만 워커 스택이 템플릿과 일치하지 않음." 드물지만 알아둘 만합니다. 이 경우 작업이 사전 렌더 정상성 확인에 실패하고 팜이 확인된 일치 워커에 자동으로 작업을 재대기열에 넣습니다. 실패한 배포 시도에 대해 비용을 지불하지 않습니다.

Troubleshoot Machine

Troubleshoot Machine은 프로덕션 렌더 경로의 진단 대응물입니다. 실제 작업을 제출하고 오류 메시지와 함께 실패하기를 기다리는 대신, Troubleshoot Machine을 실행합니다. 렌더 노드 소프트웨어 스택과 일치하는 Windows VM으로 Microsoft Remote Desktop Connection을 통해 연결합니다. 렌더 워커가 볼 것을 정확히 보고, 장면 파일을 열고, 무엇이 실패하는지 식별하고, 바로 수정하고, 수정된 장면을 스토리지에 다시 저장하고, 자신 있게 실제 프로덕션 작업을 제출할 수 있습니다.

해결하는 문제

대부분의 렌더 실패는 두 가지 버킷에 속합니다. 장면 레벨 문제(누락된 플러그인, 손상된 에셋 참조, 워커의 버전과 호환되지 않는 렌더러 설정) 및 환경 레벨 문제(사용 불가능한 라이선스, 로드되지 않는 플러그인, 경로 불일치). 두 가지 모두 원격으로 진단하기 어렵습니다. 실패한 프로덕션 작업에서 받는 유일한 신호는 렌더 로그이며 종종 간략합니다.

Troubleshoot Machine은 진단 루프를 단축합니다. 제출 → 실패 → 로그 읽기 → 추측 → 재제출 → 실패 → 추측 → 재제출 대신, Troubleshoot Machine을 실행하고 DCC의 GUI에서 실제 오류를 보고 한 번에 수정하고 작동하는 실제 작업을 제출합니다.

저희 팜에서의 작동 방식

Troubleshoot Machine을 요청하면 팜은 지정한 DCC에 대한 현재 렌더 노드 스택과 일치하는 새 Windows VM을 프로비저닝합니다(활성 Render Node Template이 있는 경우 포함). VM은 SRF Spaces 스토리지를 S: 드라이브로 마운트하므로 이미 업로드한 프로젝트 파일이 프로덕션 렌더 워커와 동일하게 나타납니다. 로컬 워크스테이션에서 RDP를 통해 연결합니다.

VM에는 시간 예산이 있습니다. 일반적으로 분 단위로 측정되며 렌더 크레딧에 대해 문서화된 요율로 청구됩니다(현재 요율은 대시보드를 확인하시기 바랍니다. 가끔 변경됩니다). 완료되면 연결을 끊고 동일한 프로젝트에서 프로덕션 작업을 제출하거나 VM을 해제합니다.

Troubleshoot Machine 세션 시작

단계:

1. 대시보드에서 "Troubleshoot Machine"(또는 동등한 대시보드 항목 — 릴리즈 간에 명칭이 다를 수 있음)으로 이동합니다.
2. 프로젝트와 일치하는 DCC를 선택합니다. VM은 해당 DCC가 사전 설치된 상태로 프로비저닝되며 선언된 Render Node Template이 있는 경우 일치합니다.
3. 시간 예산을 확인합니다. 대시보드는 분당 크레딧 비용을 표시합니다. 최대 세션 길이를 확정하고 필요한 경우 세션 중에 연장할 수 있습니다.
4. 프로비저닝을 기다립니다. 소프트웨어 스택으로 새 VM이 준비되므로 일반적으로 몇 분 걸립니다.
5. RDP 연결 세부 정보를 받습니다. 대시보드는 호스트명, 사용자 이름, 비밀번호(또는 다운로드 가능한 RDP 파일)를 제공합니다. Windows에서는 RDP 파일을 두 번 클릭하여 연결하고, macOS에서는 App Store의 Microsoft Remote Desktop을 사용합니다.
6. 연결합니다. 이제 워커에 있습니다. S: 드라이브에 SRF Spaces 프로젝트 파일이 있습니다.

세션 사용

연결되면 워크플로우는 렌더 워커에 직접 앉아 있는 것과 동일합니다.

• S:에서 장면 파일을 엽니다. DCC는 템플릿 또는 해당 DCC의 팜 기본값으로 지정된 버전에서 실행됩니다.
• 실패를 재현합니다. 프로덕션에서 실패한 것이 무엇이든 — 렌더 미리보기, 스크립트 오류, 에셋 참조 — 여기서 재현됩니다. DCC의 자체 진단 도구를 사용하여 조사합니다.
• 장면을 수정합니다. 누락된 에셋을 재연결하거나, 렌더 설정을 변경하거나, 플러그인 참조를 수정하거나, 진단에 필요한 것을 합니다.
• S:에 다시 저장합니다. 수정된 장면을 S:\SuperRendersOutput\ 또는 SRF Spaces의 다른 폴더에 저장합니다. 저장은 영구적입니다. Troubleshoot Machine 세션을 종료하면 수정된 장면이 스토리지에 남습니다.
• (선택 사항) VM 내에서 실제 작업을 제출합니다. DCC의 SuperRenders 제출 플러그인이 Troubleshoot Machine 내에 설치되어 있습니다. VM 내에서 프로덕션 렌더 작업을 제출하고 연결을 끊고 팜이 정상적으로 렌더링하도록 할 수 있습니다.

완료되면 RDP에서 연결을 끊고 대시보드에서 세션을 종료합니다. VM이 삭제됩니다. S:에 저장한 파일은 SRF Spaces에 남습니다.

일반적인 실패 유형

• "RDP에 연결할 수 없음 — 연결 시간 초과." 로컬 네트워크 또는 VPN이 아웃바운드 RDP(포트 3389)를 허용하는지 확인합니다. 일부 기업 네트워크는 RDP 이그레스를 차단합니다. 이 경우 IT 팀에 Troubleshoot Machine 호스트명을 화이트리스트에 추가하도록 요청하시기 바랍니다.
• "RDP 자격 증명 거부됨." 대시보드에서 RDP 파일을 다시 다운로드합니다. 자격 증명은 세션별로 다르며 세션이 너무 오래 일시 중지되면 만료될 수 있습니다.
• "S: 드라이브가 비어 있거나 파일이 없음." 드라이브는 SRF Spaces에 매핑됩니다. 파일이 나타나지 않으면 VM이 프로비저닝될 때 SRF Spaces로의 업로드가 아직 완료되지 않았거나 잘못된 폴더를 보고 있는 것입니다. 기본 마운트는 일반적으로 S:\<account-id>\입니다.
• "Troubleshoot Machine에서 수정이 작동했지만 프로덕션 작업이 여전히 실패함." 가장 흔한 원인은 프로덕션 작업이 Troubleshoot Machine 세션이 사용한 것과 다른 Render Node Template(또는 기본 스택)에 대해 제출되었기 때문입니다. 프로덕션 제출의 템플릿 선택이 Troubleshoot Machine 구성과 일치하는지 확인합니다.

Simulate Local Path

Simulate Local Path는 네 가지 유틸리티 중 가장 범위가 작지만 "클라우드에서 렌더링되지 않음" 프로젝트의 가장 큰 단일 카테고리를 해결합니다. 일부 DCC 장면은 상대 경로가 아닌 하드 코딩된 절대 경로(C:\projects\studio\my-scene\textures\wood_01.tx 등)로 에셋을 참조합니다. 해당 장면이 렌더팜에 업로드되면 렌더러가 워커에 절대 경로가 존재하지 않기 때문에 텍스처를 찾을 수 없습니다. Simulate Local Path는 절대 경로가 존재하도록 합니다.

해결하는 문제

이 카테고리의 문제에 대한 직관적인 해결책은 제출 전에 장면을 재경로 지정하는 것입니다. 즉, 모든 에셋 참조를 절대에서 상대로 전환합니다. 그러나 일부 워크플로우에서는 실용적이지 않습니다.

• Anima 장면(AXYZ Design의 애니메이션 인물 플러그인)은 장면 저장 시 캐릭터 캐시 파일에 절대 경로를 기록합니다. 수동 재경로 지정은 캐시 바인딩을 중단시킵니다.
• Corona Image Editor 4K 캐시 렌더링은 렌더 시점에 동일한 경로에서 다시 찾을 것으로 기대하는 절대 경로를 씁니다.
• Substance / Substance Painter 내보내기 워크플로우는 텍스처 소스에 절대 경로를 포함할 수 있습니다.
• Alembic 에셋 참조는 DCC의 내보내기 설정에 따라 절대 경로를 쓰기도 합니다.
• 오래된 아카이브 프로젝트에서 모든 에셋 참조를 재경로 지정하는 것이 실용적이지 않고 스튜디오가 단순히 프로젝트를 있는 그대로 렌더링하기를 원하는 경우.

이러한 경우에 Simulate Local Path는 팜에 다음과 같이 알려줍니다. 이 작업이 실행될 때 워커에 절대 경로를 재생성하여 렌더러가 장면이 기대하는 위치에서 에셋을 찾을 수 있도록 합니다.

저희 팜에서의 작동 방식

Simulate Local Path가 활성화된 상태에서 프로젝트를 업로드하면 SuperRenders Client App(또는 올바른 설정을 사용하는 웹 업로드)이 업로드 시 원래 절대 경로 구조를 보존합니다. 렌더 워커에서 팜은 렌더 시작 전에 동일한 절대 경로에 해당 디렉토리 트리를 생성합니다. 따라서 장면 파일이 D:\studio-2024\project-x\textures\wood.tx를 참조하면 워커는 렌더 시점에 실제 D:\studio-2024\project-x\textures\wood.tx를 갖고 있어 장면이 올바르게 확인됩니다.

이 메커니즘은 업로드 시 자동으로 절대 경로를 보존하는 SuperRenders Client App의 "Auto keep local path" 옵션과 쌍을 이룰 때 가장 신뢰할 수 있습니다. 웹 업로드의 경우 파일을 업로드하기 전에 SRF Spaces 폴더 구조에서 경로 구조를 수동으로 설정합니다.

Simulate Local Path 구성

이 기능으로 들어가는 두 가지 경로가 있습니다.

SuperRenders Client App을 통해(권장):

1. Client App에서 업로드에 파일을 추가하기 전에 업로드 설정을 엽니다.
2. "Auto keep local path"를 활성화합니다(정확한 레이블은 Client App 버전 간에 약간 다를 수 있습니다. 경로 보존 체크박스를 찾아 보시기 바랍니다).
3. 프로젝트 파일을 추가합니다. Client App이 추가될 때 각 파일의 절대 경로를 읽고 업로드 트리에 보존합니다.
4. 업로드 미리보기에서 경로 트리를 확인합니다. SRF Spaces 아래에 전체 절대 경로 구조가 미러링된 것이 보여야 합니다.
5. 정상적으로 업로드합니다. 경로 구조가 파일과 함께 전송됩니다.
6. 제출 시 "Simulate Local Path"를 활성화합니다 — 대시보드 또는 Client App 제출 양식에 이에 대한 체크박스 또는 드롭다운이 있습니다. 팜이 워커에 절대 경로를 재생성합니다.

웹 업로드를 통해(수동):

1. SRF Spaces(계정 대시보드 내 웹 파일 브라우저)에서 "Create Folder" 버튼을 사용하여 절대 경로 구조를 수동으로 재생성합니다. 예: 프로젝트가 D:\studio-2024\project-x\를 참조하면 D:(문자 그대로 폴더 이름으로), 그 다음 studio-2024 하위 폴더, 그 다음 project-x 등의 폴더를 만듭니다.
2. 재생성된 경로 트리에 파일을 업로드합니다. 각 파일은 SRF Spaces 내의 일치하는 절대 경로에 위치합니다.
3. 제출 시 "Simulate Local Path"를 활성화합니다. 팜은 SRF Spaces에서 경로 구조를 읽고 워커에 복제합니다.

웹 업로드 경로는 더 수동적이지만 올바르게 구성하면 작동합니다. Client App은 정기적으로 이 작업을 수행하는 스튜디오에 더 빠르고 오류가 적습니다.

운영 참고 사항

• 드라이브 문자. 렌더 워커에서 시뮬레이션된 드라이브(예: 프로젝트가 D:\…를 사용하면 D:)는 물리적 드라이브가 아닌 논리적 마운트입니다. 마운트는 작업 시작 시 생성되고 작업 종료 시 해제됩니다. 영구적이지 않습니다.
• 경로 길이 제한. Windows에는 역사적인 경로 길이 제한(레거시 애플리케이션의 경우 약 260자)이 있습니다. 절대 경로가 매우 길면 일부 DCC는 Simulate Local Path가 구성된 후에도 파일을 로드하는 데 실패할 수 있습니다. 수정 방법은 프로젝트 레벨에서 경로를 단축하거나 대부분의 현재 버전이 지원하는 DCC에서 긴 경로 지원을 활성화하는 것입니다.
• 크로스 DCC 조합. Simulate Local Path는 Render Node Template 및 Troubleshoot Machine과 결합할 수 있습니다. 시뮬레이션된 경로 트리가 세 가지 컨텍스트 전반에서 동일하게 나타납니다.

일반적인 실패 유형

• "Simulate Local Path를 활성화한 후에도 에셋이 여전히 누락됨." 가장 흔한 원인은 업로드가 실제로 경로를 보존하지 않은 것입니다. 웹 대시보드에서 SRF Spaces를 열고 절대 경로 구조가 있는지 확인합니다. 없으면 Client App에서 "Auto keep local path"를 활성화하고 다시 업로드합니다.
• "렌더가 시작되지만 잘못된 텍스처가 로드됨." 때로는 장면에 다른 경로에 같은 파일 이름의 에셋이 여러 개 있습니다. 경로 시뮬레이션이 불완전하면 렌더러가 같은 이름의 다른 파일로 폴백할 수 있습니다. SRF Spaces에 전체 경로 구조가 보존되어 있는지 확인합니다.
• "렌더러가 시뮬레이션된 경로에서 액세스 거부를 보고함." 일반적으로 경로에 일반 폴더로 생성할 수 없는 Windows 예약 디렉토리 이름(con, aux, prn 등)이 포함된 것을 의미합니다. 예약된 이름을 피하도록 프로젝트를 재경로 지정합니다.

API 액세스

Super Renders Farm 제출에 대한 프로그래밍 방식 액세스가 로드맵에 있습니다. 작업 제출, 상태 폴링, 출력 검색을 위한 공개 REST API가 설계 중입니다. 현재는 직접 통합을 위한 공개 API 엔드포인트가 없습니다.

현재 프로그래밍 방식 제출 요구 사항을 위한 지원되는 경로:

• SuperRenders Client App — 데스크톱 Client App()은 명령줄 서페이스(가능한 경우)를 통하거나 업로드 디렉토리의 파일 드롭 자동화를 통해 Windows 및 macOS의 스크립트로 구동할 수 있습니다. 기존 파이프라인 자동화 도구가 있는 스튜디오의 경우 Client App이 현재 모범 사례 통합 지점입니다.
• DCC 제출 플러그인 — DCC별 플러그인(3ds Max, Maya, Cinema 4D)은 DCC의 자체 스크립팅 환경(MAXScript, Python 등)과 통합되며 이미 DCC 내에서 실행되는 파이프라인 스크립트로 구동할 수 있습니다.

공개 API가 출시되면 이 섹션은 전체 API 참조(인증, 엔드포인트, 속도 제한, SDK 예제)로 교체됩니다. 파이프라인 통합을 위해 공개 API가 필요하여 차단된 스튜디오는 지원팀에 연락하여 사용 사례를 공유하시기 바랍니다. 로드맵은 실제 파이프라인 요구 사항에 의해 결정됩니다.

상호 참조

• — 이 유틸리티 없이 기본 업로드-제출-다운로드 흐름
• — 데스크톱 애플리케이션 설치 및 사용
• — 브라우저 기반 제출 흐름
• — 대형 프로젝트 전송 패턴
• — Troubleshoot Machine 세션 요금을 포함한 렌더 크레딧 청구 방법
• — 크로스 DCC 문제 해결 참조
• — 업로드 방법 비교
• , , — 이 유틸리티와 함께 사용하는 DCC별 제출 설정

FAQ

Q: 모든 작업에 Render Node Template이 필요한가요? A: 아니요. 대부분의 작업은 팜의 기본 소프트웨어 스택(가장 일반적인 플러그인이 있는 가장 일반적인 DCC 및 렌더러 버전)에서 깔끔하게 실행됩니다. Render Node Template은 장기 프로젝트 전반에서 버전 고정이 필요하거나 기본 카탈로그에 없는 플러그인을 사용하는 경우를 위한 것입니다. 필요한지 확실하지 않다면 기본 스택이 거의 항상 올바른 시작점입니다.

Q: Troubleshoot Machine 세션 비용은 얼마인가요? A: Troubleshoot Machine 세션은 세션 시작 시 대시보드에 표시된 분당 요율로 렌더 크레딧에 대해 청구됩니다. 기본 VM 인프라를 업데이트함에 따라 요율이 가끔 변경됩니다. 대시보드가 항상 권위적입니다. 일반적인 30분 진단 세션의 경우 단일 전체 렌더 작업 비용의 작은 분율이 예상됩니다.

Q: 프로젝트가 macOS 또는 Linux에 있는 경우 Simulate Local Path를 사용할 수 있나요? A: 워커 렌더 환경은 Windows이므로 절대 경로는 Windows 경로(D:\… 형식)로 시뮬레이션됩니다. 프로젝트가 /Users/… 또는 /home/… 형식의 절대 경로를 가진 macOS 또는 Linux에서 작성된 경우, 경로 시뮬레이션은 여전히 작동할 수 있습니다. 팜은 장면이 기대하는 경로 문자열과 일치하는 논리적 Windows 마운트를 생성합니다. 그러나 실제로 macOS/Linux에서 작성된 프로젝트는 일반적으로 상대 경로를 사용하므로 이 유틸리티가 필요하지 않습니다.

Q: Render Node Template이 렌더 시간에 추가되나요? A: 새 템플릿에 대해 제출된 첫 번째 작업은 팜이 일치하는 워커를 프로비저닝하는 동안 배포에 몇 분 더 걸릴 수 있습니다. 동일한 템플릿에 대한 이후 작업은 일치하는 워커가 이미 준비되어 있으므로 기본 스택 속도로 배포됩니다. 템플릿이 활성화된 후 작업당 순 시간은 기본 스택과 동일합니다.

Q: 작업이 진행 중일 때 Render Node Template을 편집할 수 있나요? A: 예, 그러나 진행 중인 작업은 제출 시 캡처한 템플릿 버전으로 계속 진행됩니다. 편집은 향후 제출에만 영향을 미칩니다. 더 엄격한 버전 제어가 필요한 프로젝트의 경우 템플릿을 새 이름으로 복제하고 기존 템플릿을 편집하는 대신 새 복제본을 가리키도록 제출 스크립트를 업데이트합니다.

Q: Render Node Template 드롭다운에 제 DCC 버전이 없습니다. 어떻게 해야 하나요? A: 필요한 버전을 공유하여 지원팀에 연락하시기 바랍니다. 주류 DCC의 경우 일반적으로 현재 버전과 몇 가지 이전 버전을 호스팅합니다. 매우 오래된 버전은 활성 스택에서 폐기되었을 수 있습니다. 일반적으로 며칠의 준비 시간으로 이전 버전을 온보딩하거나 장면 호환성과 일치하는 가장 가까운 지원 버전으로 안내할 수 있습니다.

Q: 파이프라인에서 작업을 제출하는 데 사용할 수 있는 공개 API가 있나요? A: 아직 없습니다. 공개 REST API가 로드맵에 있습니다. 현재 권장되는 프로그래밍 방식 제출 경로는 SuperRenders Client App(스크립트로 구동) 또는 DCC별 제출 플러그인(DCC의 기본 스크립팅 환경으로 구동)입니다. 파이프라인 자동화 사용 사례가 특히 공개 API에 의해 차단된 경우 지원팀에 연락하시기 바랍니다. 로드맵은 실제 파이프라인 요구 사항에 의해 결정되며 귀하의 입력이 우선순위를 정하는 데 도움이 됩니다.

Q: Render Node Template에 대해 Troubleshoot Machine을 실행할 수 있나요? A: 예. 이것은 템플릿화된 작업을 디버깅할 때 권장되는 패턴입니다. Troubleshoot Machine 세션은 프로비저닝 시 활성 Render Node Template을 읽고 일치하는 소프트웨어 스택으로 VM을 프로비저닝합니다. 템플릿화된 플러그인 버전을 포함하여 프로덕션 워커가 볼 것을 정확히 봅니다.

---