클라우드 렌더링을 위한 Blender 설정

저희 팜에서 Blender는 Cycles(CPU 및 Optix GPU)와 Eevee Next를 지원합니다. Blender 4.x에 기본 탑재된 두 가지 프로덕션 렌더러입니다. 다른 상용 DCC와 비교했을 때 Blender의 유용한 특징이 하나 있습니다. .blend 파일을 애플리케이션 내부에서 완전히 독립적으로 만들 수 있어, 렌더팜을 위한 패키징이 수동 에셋 탐색 대신 단일 메뉴 동작으로 완료되는 경우가 많습니다. 이 페이지에서는 패키징, 제출 전 검증, Cycles CPU / Cycles GPU / Eevee Next별 렌더러 참고사항, 다중 카메라 애니메이션 렌더링, 세 가지 제출 채널, Blender 전용 문제 해결까지 전체 흐름을 안내합니다. DCC 공통 오류는 에서 확인하시기 바랍니다.

가격 예시 및 저희 팜에서의 GPU vs CPU 선택에 대해서는 를 참조하시기 바랍니다. RTX 5090 플릿에서의 Cycles GPU 벤치마크는 에서 확인하실 수 있습니다.

지원 버전

Blender 4.0, 4.1, 4.2 LTS, 4.3, 4.4가 모든 워커에 사전 설치되어 있습니다. 팜은 .blend 파일에 저장된 버전을 자동으로 일치시킵니다. 관리할 버전 선택기가 없으며, 워커가 파일 헤더를 읽어 해당 바이너리를 실행합니다.

Blender는 3~4개월마다 주요 릴리스를, 연간 LTS 릴리스를 출시합니다. 새 릴리스는 공개 후 약 2주 이내에 프로비저닝됩니다. 프로덕션 작업에는 2026년까지 버그 수정을 받는 안정적인 목표 버전인 Blender 4.2 LTS를 권장합니다.

Blender 3.x에서 저장된 파일은 4.x 워커에서 열리지만, 두 가지 경우에 주의가 필요합니다. Eevee Legacy 렌더가 Eevee Next 출력과 일치하지 않을 수 있으며(Eevee Next 섹션 참조), 매우 오래된 2.7x / 2.8x 파일은 로컬에서 열어 4.x로 다시 저장하고 제출 전에 재테스트하시기 바랍니다. 구버전 프로젝트를 렌더링해야 하는 경우 먼저 버전 고정 사본을 저장하시기 바랍니다. 팜은 4.x 저장 파일을 다운그레이드할 수 없습니다.

Blender 프로젝트 패키징

Blender 프로젝트는 .blend 파일과 외부 에셋(텍스처, 사운드 파일, 시뮬레이션 캐시, 연결된 라이브러리 .blend 파일, IES 조명 프로필, OCIO 구성 파일, EXR HDRI, .osl 셰이더 파일)으로 구성됩니다. Blender의 경로 해석은 다른 DCC보다 유연하지만, 클라우드 렌더링에서는 이 유연성이 문제가 될 수 있습니다. 워크스테이션에서 Blender의 폴백 로직으로 해석되는 경로가 워커에서 동일하게 해석되지 않을 수 있으며, 결과적으로 분홍색 누락 텍스처 플레이스홀더가 나타납니다.

세 가지 패키징 패턴을 지원합니다. 프로젝트 크기와 씬 간 에셋 재사용 빈도에 맞는 방법을 선택하시기 바랍니다.

패턴 1 — Pack Resources (대부분의 프로젝트에 권장)

Blender의 내장 "Pack Resources" 기능은 모든 외부 데이터를 .blend 파일 자체에 임베드하여 완전히 독립적인 단일 파일을 생성합니다.

File → External Data → Find Missing Files. 프로젝트를 탐색하여 해석되지 않은 참조를 보고합니다. 먼저 로컬에서 손상된 항목을 수정하시기 바랍니다.
File → External Data → Pack Resources. Blender가 모든 텍스처, 사운드, IES 프로필, 연결된 이미지를 .blend에 임베드합니다.
프로젝트를 저장합니다. 패킹된 .blend는 이제 독립적입니다. 텍스처 수와 해상도에 따라 10×~100× 크기가 증가할 수 있습니다.
단일 .blend를 업로드합니다. 파일이 압축(.tar.gz 또는 .7z)으로 업로드 속도를 높일 만큼 크지 않으면 아카이브가 필요하지 않습니다(일반적으로 몇 GB 이상인 경우).

패턴 2 — 상대 경로 + 폴더 구조 (대용량 텍스처 라이브러리용)

Pack Resources로 인해 단일 파일이 너무 커지는 프로젝트의 경우, 상대 경로 패턴은 .blend를 작게 유지하고 에셋을 폴더와 함께 제공합니다.

File → External Data → Make All Paths Relative. 모든 에셋 경로가 .blend 디렉터리를 기준으로 상대적이 됩니다(경로 접두어 //).
File → External Data → Report Missing Files. 누락된 항목이 없어야 합니다. 계속하기 전에 보고된 항목을 수정하시기 바랍니다.
.blend 파일을 기준으로 상대적인 하위 폴더에 모든 참조 에셋을 배치합니다. 표준 구조: project/scene.blend와 project/textures/, project/cache/, project/hdr/, project/osl/, project/lib/. 폴더 이름에 공백을 사용하지 마시기 바랍니다.
전체 프로젝트 폴더를 .tar.gz 또는 .7z로 압축하여 업로드합니다.

패턴 3 — 연결된 라이브러리 (고급; 공유 에셋 라이브러리를 사용하는 스튜디오)

Blender는 라이브러리 연결을 지원합니다. .blend 파일이 다른 .blend의 오브젝트, 재질 또는 씬을 참조합니다. 이는 공유 에셋 라이브러리(소품, 캐릭터, 재질)를 사용하는 스튜디오에서 흔히 사용됩니다.

먼저 상대 경로로 만듭니다 (패턴 2 1단계).
File → External Data → Find Missing Files를 통해 모든 라이브러리 연결이 로컬에서 해석되는지 확인합니다.
아카이브에 모든 연결된 라이브러리 .blend를 포함합니다. //../shared/props/chair.blend와 같은 참조는 워커의 해당 경로에 파일이 있을 때만 해석됩니다. 전체 프로젝트 폴더를 새 위치로 이동하고 마스터 씬을 열어 로컬에서 테스트하시기 바랍니다. 깨끗하게 열리면 워커에서도 동일한 경로가 해석됩니다.
장기 작업의 경우 라이브러리를 로컬로 만드는 것을 고려하시기 바랍니다. File → External Data → Make Library Override는 참조를 .blend 내부의 편집 가능한 복사본으로 변환하여 파일 크기 대신 독립성을 제공합니다.

제출 전 확인 사항

제출 전에 간단한 사전 점검 체크리스트를 적용하시기 바랍니다.

활성 렌더 엔진이 설정되어 있습니다. Properties → Render Properties → Render Engine — Cycles, Eevee Next, 또는 Workbench. 워커는 저장된 설정을 따릅니다.
프레임 범위가 설정되어 있습니다. Properties → Output Properties → Frame Start / Frame End. 팜은 이 범위를 정확히 따릅니다.
출력 경로에 상대 토큰을 사용합니다. 기본값 //tmp/####.png는 괜찮습니다. // 접두어는 ".blend 파일의 상대 경로"를 의미합니다. D:\renders\와 같은 절대 경로는 Linux 워커에서 해석되지 않으므로 사용하지 마시기 바랍니다.
출력 형식이 다운스트림 파이프라인과 일치합니다. 합성용 알파가 있는 PNG 시퀀스, 전체 패스 출력용 OpenEXR 멀티레이어. 애니메이션에는 직접 비디오 출력보다 이미지 시퀀스를 강력히 권장합니다(다중 카메라 FAQ 참조).
색상 관리가 설정되어 있습니다. Properties → Render Properties → Color Management. 대부분의 프로젝트에는 기본값인 Filmic + sRGB가 적합합니다. ACES 또는 커스텀 OCIO 구성을 사용하는 경우 OCIO 구성 파일을 프로젝트 폴더에 포함하시기 바랍니다.
활성 카메라가 설정되어 있습니다. 씬의 활성 카메라(Properties → Scene Properties → Camera)가 렌더링할 카메라를 결정합니다. "잘못된 카메라가 렌더링됨"은 가장 흔한 Blender 지원 티켓 중 하나이며, 가장 쉽게 예방할 수 있는 문제입니다.
시뮬레이션 캐시가 베이킹되어 있습니다. 유체, 연기, 천, 헤어, 소프트 바디 시뮬레이션은 먼저 로컬에서 베이킹해야 합니다. 팜은 베이킹된 캐시에 대해 렌더링하며 라이브 시뮬레이션을 실행하지 않습니다. 업로드 시 캐시 폴더를 포함하시기 바랍니다.
라이트 프로브가 베이킹되어 있습니다. Eevee Next 프로브(Irradiance Volume, Reflection Plane, Reflection Cube)는 로컬에서 베이킹하고 베이킹 데이터를 .blend에 저장해야 합니다(Render Properties → Light Probes → Bake Indirect Lighting). 베이킹되지 않은 프로브는 평탄하거나 누락된 간접 조명을 생성합니다.

렌더러별 참고사항

Cycles (CPU)

Cycles CPU는 저희 Dual Intel Xeon E5-2699 V4 워커 티어(노드당 최대 256 GB RAM)에서 실행됩니다. GPU VRAM을 초과하는 씬, 매우 큰 텍스처 라이브러리를 가진 프로젝트, 또는 GPU 백엔드에서 아직 지원되지 않는 기능을 사용하는 씬에 적합한 선택입니다.

라이선스: Blender는 무료 오픈 소스입니다. 인증이 필요 없고 소비되는 라이선스도 없습니다.
샘플링: Render Properties → Sampling → Render Samples. 노이즈 임계값 0.01의 적응형 샘플링은 애니메이션에 좋은 기본값입니다. 더 높은 품질을 위해 낮은 임계값(0.005, 0.002)을 사용하면 렌더 시간이 증가합니다. 시간 제한(프레임당)은 애니메이션 작업에 유용한 안전장치입니다.
디노이징: Cycles는 OpenImageDenoise(OIDN)와 Optix(GPU 전용)를 지원합니다. OIDN은 CPU에서 실행되며 스틸 및 애니메이션에 좋은 결과를 제공합니다. Render Properties → Sampling → Denoise에서 구성하시기 바랍니다. 애니메이션의 경우 프레임 간 깜박임을 줄이기 위해 시간적 디노이징(Blender 4.2+의 OIDN 2.x)을 활성화하시기 바랍니다.
라이트 트리: Blender 3.4+에는 다중 조명 씬을 위한 라이트 트리 샘플링이 포함되어 있습니다. 수백 개의 광원을 가진 건축 시각화 인테리어나 스테이지 조명의 경우 Render Properties → Sampling → Light Tree에서 활성화하시기 바랍니다.

Cycles (GPU / Optix)

Cycles GPU는 저희 NVIDIA RTX 5090 워커 티어(카드당 32 GB VRAM)에서 실행됩니다. 건축 시각화와 애니메이션의 경우 Cycles CPU보다 일반적으로 프레임당 5~15배 빠르며, 볼류메트릭과 SSS가 많은 패스 트레이싱 VFX 샷의 경우 더 빠릅니다.

디바이스: Properties → Render Properties → Device → GPU Compute. Optix 백엔드(NVIDIA GPU의 RT 코어)는 저희 워커에서 기본적으로 활성화되어 있습니다.
VRAM: 워커당 32 GB는 여러 4K 텍스처를 사용하는 대부분의 건축 시각화, 모션 디자인, 애니메이션 프로젝트에 충분합니다. 한계에 근접한 프로젝트의 경우 Render Properties → Performance의 "Persistent Data"는 최대 VRAM을 약간 높이는 대신 프레임당 로드 시간을 줄입니다. 32 GB를 초과하는 프로젝트는 Xeon 티어의 Cycles CPU로 전환하거나 씬을 분할하시기 바랍니다.
Optix 디노이저: 애니메이션에서 OIDN보다 빠르며 GPU의 표준 선택입니다. Render Properties → Sampling → Denoise → Use OptiX에서 구성하시기 바랍니다. 정적 스틸의 경우 OIDN이 약간 더 깨끗한 출력을 제공하는 경우가 많습니다. 애니메이션의 경우 Optix의 시간적 모드가 일반적으로 더 나은 선택입니다.
기능 패리티: 헤어, 볼륨, SSS, OSL(4.0+, 하드웨어 요구사항 있음), 적응형 세분화 — 4.x에서 Cycles GPU에서 모두 지원됩니다. CPU/GPU 기능 차이는 사실상 없어졌습니다.

Eevee Next

Eevee Next는 저희 GPU 워커 티어에서 실행됩니다. 모션 디자인, 스타일라이즈드 렌더, 빠른 반복 작업, 프레임당 비용이 완전한 충실도보다 더 중요한 프리비즈에 적합한 선택입니다.

샘플링 및 반사: Render Properties → Sampling은 픽셀당 샘플 수를 제어합니다. 파이널 작업의 경우 64~128 샘플이면 일반적으로 깨끗한 출력이 나옵니다. 라이트 프로브, 스크린 공간 반사, 스크린 공간 굴절은 샷별로 베이킹하거나 구성해야 합니다.
Eevee Next vs Eevee Legacy: Blender 4.2+에서는 Eevee Next가 새로운 아키텍처로 제공됩니다(내부 이름 BLENDER_EEVEE_NEXT vs 레거시 BLENDER_EEVEE). Eevee Legacy를 사용하는 구버전 3.x 프로젝트는 마이그레이션 시 조정이 필요할 수 있습니다. 애니메이션을 제출하기 전에 로컬에서 단일 프레임을 테스트하시기 바랍니다.
볼류메트릭스: Eevee Next의 볼류메트릭 파이프라인은 레거시 버전과 크게 다릅니다. Eevee Legacy에서 올바르게 렌더링되었던 볼륨이 밀도나 산란 차이를 보일 수 있습니다. 제출 전에 로컬에서 확인하시기 바랍니다.
라이트 프로브 베이킹: 가장 중요하며 가장 흔한 Eevee 지원 티켓의 원인입니다. Render Properties → Light Probes → Bake Indirect Lighting. 로컬에서 베이킹하고 저장하면 베이크 데이터가 파일과 함께 전송됩니다. 베이킹되지 않은 프로브는 평탄하거나 누락된 간접 조명을 생성합니다.

Workbench

Workbench는 Blender의 뷰포트 렌더러로, 기술 프리뷰 프레임(매트 ID 패스, 클레이 턴테이블, AO 프리뷰)에 유용합니다. CPU 또는 GPU 워커에서 실행됩니다. Render Engine을 Workbench로 설정한 후 저장하면 Cycles 또는 Eevee와 동일하게 제출할 수 있습니다.

Cycles GPU vs Eevee Next 빠른 비교

| 항목 | Cycles GPU | Eevee Next | |---|---|---| | 렌더 속도 (일반 씬) | 프레임당 더 느림, 물리적으로 정확 | 프레임당 더 빠름, 실시간 기반 | | 포토리얼리즘 | 높음 | 낮음 (각 릴리스마다 향상) | | 애니메이션 깜박임 | 낮음 (Optix 디노이저 시간적 모드 사용 시) | 더 높을 수 있음; 프로브 베이킹 필요 | | VRAM 제약 | 32 GB 상한; CPU로 폴백 | 32 GB이지만 일반적으로 사용량이 낮음 | | 볼류메트릭스 품질 | 패스 트레이싱, 정확 | 근사치; 제출 전 로컬에서 확인 | | 최적 용도 | 건축 시각화, VFX, 포토리얼리스틱 애니메이션 | 모션 디자인, 스타일라이즈드, 빠른 반복 |

다중 카메라 앵글 렌더링

단일 제출에서 동일한 씬을 여러 카메라 앵글로 렌더링해야 하는 프로젝트의 경우 Blender는 여러 패턴을 지원합니다. 앵글 간의 관계에 따라 선택하시기 바랍니다.

패턴 A — 활성 카메라가 다른 여러 씬

Blender는 .blend당 여러 씬을 허용하며, 각 씬에는 고유한 활성 카메라와 렌더 설정이 있습니다.

카메라 앵글당 새 씬을 만듭니다(Scene → New Scene → Link Objects는 데이터를 공유하여 편집이 전파됩니다).
각 씬의 활성 카메라를 설정합니다.
제출 시 팜은 저장 시 Active로 표시된 씬을 렌더링합니다. 여러 씬을 렌더링하려면 각각 별도의 작업으로 제출하시기 바랍니다.

패턴 A는 앵글마다 다른 샘플링, 출력 형식 또는 해상도가 필요한 경우에 적합한 선택입니다.

패턴 B — 카메라당 뷰 레이어 (Blender 2.8+)

렌더 설정을 공유하는 여러 카메라 앵글의 경우 각 뷰 레이어에 다른 활성 카메라를 사용하시기 바랍니다.

Properties → View Layer에서 카메라 앵글당 뷰 레이어를 만듭니다.
레이어의 카메라 속성을 통해 각 뷰 레이어의 카메라를 바인딩합니다(또는 Compositor에서 활성 카메라를 구동합니다).
출력 파일 이름에 {layer} 토큰을 사용하여 뷰 레이어당 출력 경로를 구성합니다.
제출하면 워커가 단일 패스에서 활성화된 모든 뷰 레이어를 렌더링합니다.

일반적인 건축 시각화 턴테이블(8~16 카메라 앵글)의 경우 씬이 한 번 로드되고 모든 뷰가 동일한 로드 상태에서 렌더링되므로 패턴 B가 더 효율적입니다. N개의 출력 시퀀스를 생성하는 단일 다중 카메라 작업은 N개의 단일 카메라 작업보다 비용이 적게 듭니다.

패턴 C — Compositor 다중 출력 (고급)

카메라별 복잡한 포스트 프로세싱의 경우 Compositor가 각 카메라의 렌더를 다른 File Output 노드로 라우팅할 수 있습니다. 다중 레이어 AOV 내보내기와 동일한 패턴입니다. 실제 포스트 프로세싱 이유가 없으면 패턴 B를 사용하시기 바랍니다.

제출 흐름

Blender 프로젝트에는 세 가지 제출 채널이 있습니다. 워크플로우에 맞는 것을 선택하시기 바랍니다.

웹 업로드 + 대시보드를 통한 제출. 패킹된 .blend(또는 압축된 프로젝트 폴더)를 계정에 업로드한 후 대시보드를 통해 제출합니다. 대시보드는 .blend 헤더를 읽어 Blender 버전, 렌더 엔진, 프레임 범위, 활성 카메라를 감지하고 제출 양식을 미리 채웁니다. 확인하거나 재정의한 후 제출하고 모니터링하시기 바랍니다.
Client App. Client App(Windows / macOS)은 업로드 + 제출 + 자동 다운로드를 하나로 묶습니다. 설치 후 .blend 또는 아카이브를 앱에 드래그하고, 제출 양식을 확인한 후 앱이 업로드, 진행 상황 모니터링, 완료된 프레임 다운로드를 처리합니다.
제출 플러그인 (Blender 애드온). 앱 내 제출을 위한 Blender 애드온을 사용할 수 있습니다. 계정 대시보드에서 설치하시기 바랍니다. 플러그인은 현재 씬의 렌더 설정을 읽고 재정의(프레임 범위, 출력 경로, 해상도)를 요청한 후 Blender를 떠나지 않고 제출합니다.

크로스 DCC 업로드-제출-다운로드 흐름은 를 참조하시기 바랍니다. 플러그인 설치 단계는 을 참조하시기 바랍니다.

Blender 전용 오류 문제 해결

DCC 전반에 적용되는 일반 문제 해결(에셋 누락, 프레임 범위 불일치, 출력 경로 오류)은 를 참조하시기 바랍니다. 아래 사례들은 Blender 전용입니다.

씬의 일부 오브젝트가 렌더링되지 않습니다. 가장 흔한 원인: 오브젝트의 "Render Visibility"(아웃라이너의 카메라 아이콘)가 비활성화되어 있습니다. 오브젝트가 숨겨진 뷰 레이어에 없는지 확인하고, Object Properties → Visibility → Ray Visibility 플래그(카메라, 디퓨즈, 글로시, 투과, 볼륨, 그림자)를 확인하시기 바랍니다.
Pack Resources 후에도 텍스처가 누락됩니다. 최신 텍스처 변경 후에 Pack Resources가 실행되었는지 확인하시기 바랍니다. 패킹 후 텍스처를 다시 로드했다면 외부 참조로 되돌아갈 수 있습니다. 다시 패킹하고 저장하시기 바랍니다.
렌더 결과가 검정이거나 잘못된 색상으로 나옵니다. 일반적으로 뷰 변환 불일치입니다. Properties → Render Properties → Color Management에서 워크스테이션과 저장된 파일 모두 View Transform: Filmic(기본값)을 사용하는지 확인하시기 바랍니다. Look Transforms와 Exposure 값은 .blend에 임베드되어 워커에 적용됩니다.
워커에서 Eevee Next 라이트 프로브가 베이킹되지 않습니다. 워커는 베이킹을 수행하지 않습니다. 프로브는 로컬에서 베이킹하고 .blend에 저장해야 합니다. Render Properties → Light Probes → Bake Indirect Lighting으로 저장한 후 업로드하시기 바랍니다.
Cycles GPU 작업이 CPU에서 실행됩니다. Properties → Render Properties → Device가 GPU Compute로 설정되어 있는지 확인하시기 바랍니다. NVIDIA GPU가 없는 워크스테이션에서 파일을 작성한 경우 저장된 Device 값이 CPU로 기본 설정될 수 있습니다.
OSL 커스텀 셰이더가 렌더에서 실패합니다. Cycles는 OSL을 지원하지만 .osl 파일을 아카이브에 포함하고 상대 경로로 참조해야 합니다. .blend와 동일한 폴더에 배치하시기 바랍니다. GPU에서의 OSL에는 모든 셰이더에 맞지 않을 수 있는 하드웨어 요구사항이 있습니다. CPU에서는 작동하지만 GPU에서는 작동하지 않는 셰이더의 경우 해당 씬을 CPU 티어에서 렌더링하시기 바랍니다.
연결된 라이브러리 참조가 끊어졌습니다. 연결된 라이브러리는 연결된 .blend가 워커의 예상 경로에 있을 때만 해석됩니다. 패턴 2 패키징을 사용하고 아카이브에 모든 연결된 라이브러리를 포함하시기 바랍니다. 업로드 전에 로컬에서 File → External Data → Find Missing Files를 실행하시기 바랍니다.
워커에서 애드온이 누락되었습니다. 일반 애드온(Animation Nodes, BlenderKit, Sverchok, FLIP Fluids)이 모두 사전 설치되어 있지 않을 수 있습니다. 절차적 애드온의 경우 제출 전에 지오메트리를 정적 메시로 베이킹하시기 바랍니다(Sverchok: Set/Bake to Mesh; Animation Nodes: 액션으로 베이킹; Geometry Nodes: 수정자 적용). 다른 애드온의 경우 워커 이미지에 추가하는 것에 대해 지원팀에 문의하시기 바랍니다.
애니메이션이 깜박입니다 (Cycles). 일반적으로 프레임 간 노이즈 변동입니다. 샘플을 늘리고, 적응형 샘플링 노이즈 임계값을 낮추고, 시간적 디노이징(OIDN 2.x 또는 Optix)을 활성화하시기 바랍니다. 랜덤 시드 모드(Render Properties → Sampling → Advanced → Seed)가 프로젝트 의도와 일치하는지 확인하시기 바랍니다. 자연스러운 변화를 위해서는 Animated, 비트 안정적인 출력을 위해서는 고정값을 사용하시기 바랍니다.
애니메이션이 깜박입니다 (Eevee Next). 거의 항상 베이킹되지 않았거나 오래된 라이트 프로브 때문입니다. 간접 조명을 다시 베이킹하고 저장한 후 다시 업로드하시기 바랍니다. 뷰포트 상태에 의존하는 스크린 공간 반사도 깜박일 수 있습니다. 깨끗한 반사를 위해 Reflection Probe를 사용하시기 바랍니다.

FAQ

Q: 팜에서 지원하는 Blender 버전은 무엇입니까? A: Blender 4.0, 4.1, 4.2 LTS, 4.3, 4.4가 모든 워커에 사전 설치되어 있습니다. 저희는 Blender의 릴리스 주기를 따르며 새 버전을 공개 후 약 2주 이내에 프로비저닝합니다. Blender 4.2 LTS는 2026년까지 버그 수정을 받으므로 프로덕션 작업에 권장하는 선택입니다. 팜은 .blend 파일에 저장된 버전을 자동으로 일치시킵니다. 제출 시 버전을 선택할 필요가 없습니다.

Q: Cycles와 Eevee Next 중 어느 것으로 렌더링해야 합니까? A: 물리적으로 정확한 광 전송이 중요한 포토리얼리스틱 건축 시각화, VFX, 애니메이션에는 Cycles를 사용하시기 바랍니다. 완전한 충실도보다 프레임당 비용이 더 중요한 모션 디자인, 스타일라이즈드 작업, 빠른 반복, 프리비즈에는 Eevee Next를 사용하시기 바랍니다. 저희 RTX 5090 플릿의 Cycles GPU는 동일한 씬에서 Cycles CPU보다 프레임당 일반적으로 5~15배 빠르므로, 씬이 32 GB VRAM을 초과하거나 CPU 백엔드가 필요한 기능을 사용하지 않는 한 GPU가 기본 Cycles 권장사항입니다.

Q: 씬에서 BlenderKit / Sverchok / Animation Nodes / Geometry Nodes 에셋을 사용하는데 렌더링됩니까? A: 이미 다운로드하고 .blend에 저장한 BlenderKit 에셋은 배치 후 표준 메시 데이터가 되므로 정상적으로 렌더링됩니다. Sverchok과 Animation Nodes는 절차적입니다. 절차적 지오메트리가 정적 메시로 베이킹되지 않은 경우 워커에서 예상치 못한 출력이 나올 수 있습니다. 제출 전에 절차적 지오메트리를 메시로 베이킹하시기 바랍니다(Sverchok: Set/Bake to Mesh; Animation Nodes: 액션으로 베이킹; Geometry Nodes: 결과 노드 트리에서 수정자 적용). 베이킹 없이 렌더 시간에 해석되는 Geometry Nodes는 일반적으로 작동하지만, 먼저 로컬에서 단일 프레임을 테스트하시기 바랍니다.

Q: 텍스처를 .blend에 패킹해야 합니까, 아니면 별도 파일로 업로드할 수 있습니까? A: 두 패턴 모두 작동합니다. Pack Resources는 결과가 완전히 독립적인 단일 파일이므로 가장 간단합니다. 상대 경로 + 폴더 구조는 매우 큰 텍스처 라이브러리와 씬 간에 텍스처 라이브러리를 공유하는 프로젝트에 적합합니다. 두 방법 모두 적용하기 전에 Find Missing Files를 실행하여 로컬에서 아무것도 손상되지 않았는지 확인하시기 바랍니다.

Q: 렌더가 완료되었지만 색상이 워크스테이션 뷰포트와 다릅니다. A: 가장 흔히 뷰 변환 불일치입니다. Properties → Render Properties → Color Management에서 워크스테이션과 저장된 파일 모두 View Transform: Filmic(기본값)을 사용하는지 확인하시기 바랍니다. Look Transforms와 Exposure 값도 .blend에 임베드되어 워커에 적용됩니다.

Q: 애니메이션을 렌더링합니다. 비디오 파일 또는 이미지 시퀀스로 출력해야 합니까? A: 거의 항상 이미지 시퀀스를 사용하시기 바랍니다. 합성용 알파가 있는 PNG 또는 전체 패스용 OpenEXR 멀티레이어가 표준입니다. 직접 비디오 출력(FFmpeg)은 병렬화되지 않습니다. 하나의 워커가 모든 프레임을 순차적으로 렌더링하고 하나의 파일을 인코딩합니다. 이미지 시퀀스는 팜이 여러 워커에 프레임을 병렬로 분산할 수 있어 100프레임 이상의 애니메이션에서 더 빠릅니다.

Q: 팜에서 GPU 렌더링과 CPU 렌더링의 비용은 어떻게 비교됩니까? A: GPU는 일반적으로 프레임당 더 빠릅니다(Cycles의 경우 5~15배). 그러나 워커당 요금은 더 높습니다. 대부분의 씬에서 총 비용은 대략 비슷합니다. GPU는 더 짧은 실제 시간에 완료되지만 분당 더 많은 비용이 청구됩니다. 에서 특정 씬의 프레임당 및 작업당 비교를 확인하시기 바랍니다.

Q: 팜에서 Blender 시뮬레이션(유체, 연기, 헤어, 천)을 렌더링할 수 있습니까? A: 먼저 로컬에서 시뮬레이션 캐시를 베이킹한 후 프로젝트 업로드에 캐시 폴더를 포함하시기 바랍니다. 팜은 베이킹된 캐시에 대해 프레임을 렌더링합니다. 라이브 시뮬레이션은 실행하지 않습니다. 디스크로 베이킹하고(Cache Type → All Frames + Save Cache to Disk), 캐시 폴더가 프로젝트 폴더에 있는지 확인한 후 패키징하여 업로드하시기 바랍니다.

---