dev.to

We Rendered a HQ Demo Video on a Free Farm Run by Strangers

낯선 사람들이 운영하는 무료 렌더팜에서 고화질 데모 영상을 렌더링했습니다

네 대의 노트북으로 꾸린 렌더팜은 115MB 블렌더 파일을 업로드하는 데 시간이 걸려 단독 렌더링보다 느렸습니다. 작성자는 포인트를 주고받는 무료 커뮤니티 렌더팜 SheepIt으로 옮기고, 외부 파일을 묶은 뒤 압축본을 검증하고 시험 렌더링하는 절차를 만들었습니다.

에디터 노트

이 작업에서 병목은 GPU 수보다 파일 배포와 장면의 외부 의존성이었습니다. 네 대의 노트북으로 구성한 렌더팜은 5Mbit/s 업로드 회선에 묶였고, SheepIt으로 옮긴 뒤에는 파일을 독립적으로 묶고 검증하는 절차가 필요해졌습니다. 렌더링을 커뮤니티에 맡겨도 패키지 제작과 결과 확인은 작성자 몫으로 남습니다. 포인트 잔액과 주문 프레임 수는 비용 환산 공식이 아니라 며칠간의 개인 관찰입니다. 작성자도 정확한 교환 비율을 제시하지 않습니다. 따라서 이 사례가 보여주는 범위는 특정 프로젝트에서 프레임 렌더링을 분산한 절차와 경험이며, 다른 장면이나 작업량에서도 같은 비용 구조가 나온다는 근거는 자료에 없습니다.

AI 요약

네 대의 노트북을 렌더팜으로 묶었지만, 5Mbit/s 업로드 회선으로 115MB짜리 Blender 파일을 배포하느라 렌더링보다 파일 전송에 시간을 썼습니다. 이를 겪은 작성자는 더 많은 GPU를 찾는 대신 파일을 한 번 올리면 여러 기기에 배포해 주는 방법을 택했습니다. SheepIt은 유휴 컴퓨터로 다른 사람의 프레임을 렌더링하면 포인트를 주고, 그 포인트로 자신의 작업을 맡기는 무료 커뮤니티 렌더팜입니다. 작성자는 Java 클라이언트를 실행하고 웹 페이지에 ZIP 파일을 올렸습니다. 서버나 네트워크 인프라는 직접 운영하지 않습니다.

가입 후 며칠 동안 노트북은 다른 사람의 프레임 6,981개를 렌더링했고, 총 2일 7시간을 썼습니다. 그 대가로 17개 프로젝트의 프레임 18,651개를 주문하고도 1,261,589포인트가 남았습니다. 작성자는 SheepIt의 정확한 환산 비율을 모른다고 밝히며 이를 공식이 아닌 관찰로 제시합니다. 해상도가 낮고 가벼운 프레임은 주문 비용이 낮고, 1080p 레이 트레이싱 프레임은 더 많은 포인트가 들며, GPU 성능이 높으면 포인트를 더 빨리 번다고 추정합니다.

낯선 기기에서 열리는 장면 만들기

커뮤니티 렌더링의 조건은 .blend 파일이 작성자의 프로젝트 폴더나 스크립트 없이도 다른 컴퓨터에서 실행되는 것입니다. 기존 장면은 절대 경로로 지정한 텍스처, 도시 화면에 쓰는 이미지 시퀀스, 음성 트랙, 렌더 시점에 Python 스크립트가 적용하는 설정에 의존했습니다. SheepIt 작업자는 그 파일과 스크립트에 접근할 수 없습니다.

작성자는 sheepit_pack.py를 만들어 장면을 독립적인 패키지로 바꿨습니다. 이미지는 .blend에 포함하고, Blender에서 파일 내부에 담을 수 없는 이미지 시퀀스는 별도 폴더에 복사해 상대 경로로 연결합니다. 최종 영상에서 나중에 섞는 음성 트랙과 효과음은 빼고, 해상도 1920x1080, 렌더 샘플 64, 레이 트레이싱, 모션 블러, PNG 출력 설정은 파일에 미리 기록합니다. .blend 파일을 ZIP의 최상위에 넣고 압축하며, 작성자의 패키지 크기는 130~240MB였습니다. SheepIt은 최대 2GB까지 받습니다.

업로드 전후 검증

원본 .blend를 확인하는 데서 그치지 않고 ZIP을 새 임시 폴더에 풀어 검사합니다. 외부 파일이 모두 존재하는지, 경로가 상대 경로인지, 사운드 트랙이 남지 않았는지, 해상도와 샘플 수 등 설정이 맞는지 확인합니다. 이어 압축을 푼 사본에서 실제 프레임 한두 장을 렌더링합니다. GTX 1650으로 1080p 테스트 프레임을 만드는 데 7~35초가 걸렸습니다. 이렇게 하면 전체 작업을 다른 사람이 렌더링하기 전에 패키지 오류와 예상 작업량을 확인할 수 있습니다.

작성자는 ZIP 내부 파일명을 검사하는 셸 명령에서도 문제를 발견했습니다. set -o pipefail을 켠 상태에서 unzip -Z1 "$ZIP" | grep -q "파일명"을 실행하면 grep이 일치 항목을 찾자마자 종료합니다. unzip은 남은 목록을 쓰려다 파이프가 닫혀 SIGPIPE를 받고, pipefail은 파이프 안 명령의 실패를 전체 실패로 처리합니다. 파일이 ZIP 최상위에 있어도 검사가 실패하는 이유입니다. 작성자는 파일 목록을 변수에 먼저 담은 뒤 grep으로 검사하도록 바꿨습니다.

필요한 프레임만 주문하고 결과 점검하기

최종 영상에는 장면 일부가 빠지고 Blender 밖에서 만든 2D 제품 보드도 포함됩니다. 따라서 각 패키지에는 실제 영상에 필요한 프레임 구간만 넣었습니다. 0부는 458프레임, 1부는 잘라낸 세 장면을 제외해 약 535프레임을 건너뛰고 세 구간을 주문했습니다. 2부는 2,441프레임입니다. 3부는 같은 ZIP을 두 번 올려 1~664프레임과 2,150~3,661프레임을 렌더링했습니다. 전체 영상은 8,229프레임, 4분 34초 분량으로 늘었습니다.

돌아온 프레임 ZIP은 손상 여부, 프레임 수와 번호의 연속성, PNG 디코딩과 해상도, 완전히 검은 프레임이 있는지 검사합니다. 문제가 있으면 해당 구간을 다시 주문합니다. 검증을 통과한 프레임은 복사 대신 하드 링크로 번호가 붙은 폴더에 모읍니다. 이후 ffmpeg로 기본 영상을 만들고 음성, 효과음, 음악, 자막과 프레임 번호를 합칩니다. 장면이 바뀌면 이전 프레임 폴더를 삭제하지 않고 다른 곳으로 옮긴 뒤 새 폴더에 렌더링합니다. 기존 파일을 건너뛰는 스크립트가 변경 전 프레임을 새 결과에 섞는 일을 막기 위해서입니다.

초안은 로컬에서 360p, EEVEE, 레이 트레이싱과 모션 블러 없이 렌더링합니다. 프레임당 약 0.7초가 걸려 2,441프레임 작업은 약 30분, 전체 영상은 약 2시간이 걸립니다. 최종본은 SheepIt에서 1080p, 64샘플, 레이 트레이싱과 모션 블러를 적용해 렌더링합니다. 작성자는 두 파트의 1080p 렌더를 이미 받았지만 팀 피드백에 따라 영상이 바뀌어, 검증을 마친 새 패키지를 다시 준비했습니다. 경험에서 도출한 원칙은 장면을 독립적인 파일로 만들고, 업로드 전 압축을 푼 사본을 시험 렌더링하며, 저렴한 초안 작업을 유지하는 것입니다.

원문: dev.to / 번역·요약: Trawling