게임용 머티리얼 제작에서 가장 비싼 문제는 텍스처 한 장을 늦게 만드는 일이 아닙니다. Painter에서 괜찮던 재질이 엔진에서 다르게 보이고, 베이크를 조금 수정할 때마다 전체 메시를 다시 굽고, 도구마다 같은 재질을 다른 이름과 범위로 번역하는 일이 반복되는 순간 비용이 커집니다. 룩의 차이를 사람이 눈으로 메우기 시작하면 파일은 늘어나고 검수 기준은 흐려집니다.
Adobe는 2026년 7월 21일 SIGGRAPH 2026에 맞춰 Substance 3D 업데이트를 발표했습니다. 핵심은 Painter 12.1의 OpenPBR 초기 지원, Skew Map Painting, Auto Rebake, Hard Surface Auto UV입니다. Designer 16과 Sampler에 이어 Painter까지 OpenPBR 흐름에 들어왔고, Adobe는 Substance 3D Assets의 머티리얼·데칼·아틀라스 14,000개 이상을 OpenPBR로 변환한다고 밝혔습니다. 별도로 공개한 OpenPBR BSDF 참조 구현은 Apache 2.0 라이선스이며 C++, GLSL, CUDA, MSL, Slang을 한 소스 계층에서 겨냥합니다.
이 변화가 곧 “OpenPBR 버튼을 켜면 Unreal과 Unity에서 같은 픽셀이 나온다”는 뜻은 아닙니다. OpenPBR은 재질의 의미를 맞추는 계약에 가깝고, 엔진의 셰이딩 모델·라이트·톤매퍼·텍스처 압축은 여전히 결과를 바꿉니다. 이 글은 새 기능을 나열하기보다 기존 제작 파이프라인을 어디까지 바꿀지 판단하는 체크리스트로 정리합니다.
이번 업데이트에서 실제로 달라진 세 지점
첫째는 재질 모델의 공통 언어입니다. Adobe의 공식 발표에 따르면 Painter 12.1은 OpenPBR을 지원하고, Designer 16과 Sampler도 같은 모델을 사용합니다. Adobe가 공개한 참조 구현은 OpenPBR 1.1의 전체 파라미터 집합을 대상으로 하며 확산, 스펙큘러, 코트, 퍼즈, 전송, 볼륨 같은 로브를 하나의 BSDF 구조로 묶습니다. 이는 앱 간 이름만 같게 만드는 일이 아니라 각 파라미터가 빛에 어떻게 반응하는지 비교할 기준이 생긴다는 뜻입니다.
둘째는 베이크 수정의 범위입니다. Painter 12.1의 Skew Map Painting은 베이크 중 생기는 기울어짐 왜곡을 브러시나 Polygon Fill로 교정하고 경계 보호를 적용할 수 있게 합니다. Auto Rebake는 변경이 영향을 준 메시 부분만 다시 베이크하는 기능으로 소개됐습니다. 전체 베이크를 반복하던 작업에서 수정 범위를 좁힐 수 있다는 점이 중요합니다.
셋째는 하드서피스 준비입니다. Hard Surface Auto UV는 기계적 형태에 맞춘 직교 정렬 UV 레이아웃을 자동 생성합니다. 이것은 모든 게임 에셋의 최종 UV를 대신한다기보다, 빠른 룩 개발과 초반 베이크 검증 시간을 줄이는 후보입니다. 라이트맵, 텍셀 밀도, 미러링, 패킹 규칙이 있는 제작 프로젝트에서는 결과를 팀 규칙과 비교해야 합니다.
OpenPBR은 파일 포맷보다 검증 계약으로 봐야 합니다
OpenPBR을 도입할 때 흔한 오해는 이름이 같은 파라미터를 연결하면 변환이 끝난다는 생각입니다. 실제 결과는 입력 텍스처의 색 공간, 노멀 포맷, 러프니스 해석, IOR 범위, 코트 노멀, 얇은 표면 처리, 볼륨 단위에 영향을 받습니다. 엔진 쪽 셰이더가 OpenPBR의 모든 로브를 제공하지 않는다면 일부 속성은 근사하거나 베이크해야 합니다.
따라서 첫 산출물은 거대한 변환 스크립트보다 머티리얼 계약표가 되어야 합니다. 각 행에 OpenPBR 입력, Painter 채널, 엔진 파라미터, 단위와 범위, 색 공간, 누락 시 대체 규칙을 적습니다. 예를 들어 base_color가 sRGB인지, specular_roughness가 선형 데이터인지, 전송과 서브서피스가 대상 엔진에서 어떤 셰이딩 모델로 갈지 명시합니다.
Adobe의 오픈소스 구현도 자동 호환을 보장하지 않습니다. 저장소는 동일 구현이 C++, GLSL, CUDA, MSL, Slang을 겨냥한다고 설명하지만 HLSL 직접 타깃이 아니라 Slang 경로를 제시합니다. 배열 기반 LUT와 텍스처 LUT 모드의 성능·바인딩 조건도 다릅니다. 이 코드는 제작 검증 기준과 렌더러 통합 참고자료로 유용하지만, 게임 엔진에 그대로 붙이는 일은 별도 엔지니어링 판단입니다.
골든 머티리얼 세트를 먼저 만들어야 합니다
전환 테스트에는 멋진 에셋보다 실패가 잘 보이는 재질이 필요합니다. 불투명 유전체, 금속, 거친 코트, 얇은 투과, 퍼즈, 발광, 노멀 강도가 큰 표면을 작은 세트로 구성합니다. 각 재질은 같은 HDRI, 같은 카메라, 같은 노출에서 Painter와 대상 엔진 캡처를 남깁니다.
비교 항목도 “비슷해 보임”으로 끝내면 안 됩니다. 베이스 컬러의 중간 회색, 러프니스 단계별 하이라이트 폭, 금속 가장자리 에너지, 코트의 이중 하이라이트, 퍼즈의 역광 반응, 투과 두께를 정해진 화면 위치에서 확인합니다. 수치 비교가 가능한 항목과 아티스트 판단이 필요한 항목을 분리하면 회귀 테스트가 쉬워집니다.
Unity 6.5와 Houdini Engine 업그레이드 판단 글에서 골든 씬을 먼저 고정한 것과 같은 이유입니다. 도구가 바뀔 때는 기능 수보다 같은 입력이 같은 기준을 통과하는지 확인해야 합니다. OpenPBR 전환도 원본 프로젝트 전체가 아니라 6~10개의 대표 머티리얼로 시작하는 편이 안전합니다.
Painter 12.1 베이크 기능은 시간을 따로 측정해야 합니다
Skew Map Painting은 결과를 직접 교정할 수 있다는 장점이 있지만, 수정이 원본 로우폴리·하이폴리 문제를 가리는지 확인해야 합니다. 잘못된 케이지, 너무 작은 UV 섬, 부정확한 노멀을 페인트로 덮으면 다음 에셋에서 같은 문제가 반복됩니다. 교정 레이어에는 왜 수정했는지와 재베이크 조건을 기록하는 편이 좋습니다.
Auto Rebake의 가치는 전체 베이크 시간보다 반복 횟수에서 드러납니다. 작은 메시 변경, UV 변경, 케이지 변경, 고해상도 소스 변경을 각각 테스트하고 어떤 경우에 부분 베이크가 적용되는지 기록합니다. 첫 주에는 기존 전체 베이크와 결과 해시 또는 차이 이미지를 함께 남겨 누락된 영역이 없는지 확인해야 합니다.
Hard Surface Auto UV도 초반 프리뷰와 최종 납품을 구분합니다. 빠른 프로토타입에는 유용해도, 모듈형 환경 에셋이나 방향성이 강한 표면은 수동 심과 패킹이 더 나을 수 있습니다. 자동 UV가 팀의 텍셀 밀도, 패딩, 미러링, UDIM 규칙을 통과하는지 먼저 봐야 합니다.
Unreal과 Unity에서는 최종 셰이더를 별도로 판정해야 합니다
OpenPBR은 DCC 사이의 의미 손실을 줄일 수 있지만, 게임 엔진의 최종 머티리얼은 성능 예산과 플랫폼 제약을 가집니다. Unreal의 Material과 Unity의 Shader Graph 또는 커스텀 셰이더가 모든 OpenPBR 속성을 같은 비용으로 구현하지는 않습니다. 특히 다중 로브, 볼륨, 투과, 퍼즈를 한 재질에 모두 켜면 셰이더 변형과 픽셀 비용이 늘 수 있습니다.
따라서 변환 결과에는 direct, approximated, baked, unsupported 네 상태를 붙이는 방식을 권합니다. 직접 매핑은 엔진 파라미터로 유지하고, 근사는 차이를 문서화하며, 베이크는 어떤 조명 가정을 포함했는지 적습니다. 지원하지 않는 속성은 조용히 버리지 말고 검수 실패로 표시해야 합니다.
UE 5.8 MegaLights 라이팅 워크플로 정리처럼 엔진 업데이트도 머티리얼과 셰이더의 실제 결과를 바꿀 수 있습니다. OpenPBR 변환 테스트에는 엔진 버전, 렌더러, 플랫폼, 품질 프리셋을 함께 기록해야 합니다. 하나의 PC 캡처가 모바일이나 콘솔의 결과를 대표하지 않습니다.
2주 파일럿은 작은 자산군으로 끝내는 편이 좋습니다
첫 주에는 기존 Painter 템플릿 하나를 복제하고 OpenPBR 채널 매핑표를 만듭니다. 대표 머티리얼 6~10개를 내보내 기존 셰이더와 새 변환 경로를 같은 씬에서 비교합니다. 이때 목표는 새 경로가 무조건 더 좋아 보이는지가 아니라 차이가 설명 가능하고 반복 가능한지 확인하는 것입니다.
둘째 주에는 실제 하드서피스 에셋 한 종류를 고릅니다. Skew Map Painting으로 교정한 시간, Auto Rebake 적용 범위와 소요 시간, Auto UV 수정 시간을 기존 작업과 비교합니다. 최종 엔진 캡처가 허용 오차를 통과하고, 원본 파일과 내보내기 설정을 다른 작업자가 재현할 수 있어야 합니다.
중단 조건도 미리 둡니다. 같은 입력의 엔진 결과가 반복해서 달라짐, 색 공간 자동 판정 실패, 지원하지 않는 로브의 조용한 누락, 부분 베이크의 미갱신 영역, 자동 UV의 팀 규칙 위반 중 하나가 나타나면 전체 전환을 멈춥니다. 새 기능을 쓰지 말자는 뜻이 아니라 계약이 부족한 지점을 먼저 고치자는 뜻입니다.
Unreal VFX 학습 로드맵에서 Material과 Niagara를 함께 이해해야 하는 이유도 여기에 연결됩니다. 텍스처 제작 도구의 변화는 최종 이펙트의 블렌딩, 라이팅, 오버드로, 파라미터 제어 방식과 만나야 실제 제작 가치가 생깁니다.
채널 매핑표에는 변환 규칙과 책임자를 함께 적어야 합니다
채널 매핑표를 단순한 이름 대응표로 만들면 실제 문제를 놓치기 쉽습니다. base_color → Base Color, specular_roughness → Roughness처럼 적는 것만으로는 부족합니다. 소스 값의 기본값, 유효 범위, 텍스처 색 공간, 알파 사용 여부, 대상 머티리얼 도메인, 변환 계산식, 최종 승인자를 한 행에 넣어야 합니다. 그래야 값이 잘못됐을 때 Painter 템플릿, 익스포터, 임포터, 엔진 셰이더 중 어디를 고쳐야 하는지 찾을 수 있습니다.
특히 러프니스와 글로시니스는 이름이 비슷해도 방향이 반대일 수 있고, 노멀 맵의 녹색 채널 방향은 도구와 플랫폼 설정에 따라 달라질 수 있습니다. 메탈릭 맵처럼 데이터 텍스처는 sRGB 샘플링이 꺼져야 하며, 채널 패킹을 사용하면 각 채널의 압축 오차도 확인해야 합니다. 이러한 항목은 OpenPBR 명세만으로 엔진 임포트 설정까지 자동 결정되지 않습니다.
코트와 퍼즈는 더 조심해야 합니다. 최종 엔진 셰이더가 별도 코트 노멀이나 퍼즈 로브를 지원하지 않으면 베이스 노멀에 섞거나 림 조명 근사로 바꾸고 싶어질 수 있습니다. 하지만 근사 방식은 조명 방향과 카메라 각도에 따라 차이가 커집니다. 어떤 재질은 허용되고 어떤 재질은 원본 룩을 잃는지 자산 유형별로 판정해야 합니다.
볼륨과 전송은 단위까지 기록합니다. Adobe 참조 구현은 거리 단위의 일관성을 호스트 렌더러가 책임져야 한다고 설명합니다. DCC에서 센티미터로 만든 두께와 엔진의 월드 단위가 다르면 흡수와 산란 결과가 크게 달라질 수 있습니다. 투과 재질을 다룬다면 테스트 메시의 실제 두께와 스케일까지 골든 세트에 포함해야 합니다.
변환 책임도 분명히 나눕니다. 아티스트는 의도한 룩과 허용 차이를 승인하고, 테크니컬 아티스트는 채널·임포트·셰이더 매핑을 관리하며, 렌더링 엔지니어는 지원하지 않는 로브와 성능 비용을 판정합니다. 한 사람이 모든 차이를 눈대중으로 수정하는 구조는 빠르게 보이지만 다음 엔진 버전이나 플랫폼에서 같은 비용을 다시 만듭니다.
검증 기록은 캡처 두 장보다 재현 가능한 실험이어야 합니다
골든 캡처에는 이미지뿐 아니라 조건 파일이 필요합니다. 에셋 버전, Painter 버전, 템플릿 버전, 내보내기 프리셋, 엔진 버전, 셰이더 커밋, 텍스처 임포트 설정, HDRI, 라이트 강도, 카메라 노출, 포스트 프로세스, 해상도를 함께 저장합니다. 그래야 한 달 뒤 결과가 달라졌을 때 무엇이 바뀌었는지 좁힐 수 있습니다.
캡처는 최소 세 각도로 나누는 편이 좋습니다. 정면은 베이스 컬러와 거칠기 단계를 보기 쉽고, 사선은 코트와 금속 하이라이트를 드러내며, 역광은 퍼즈·얇은 투과·노멀 문제를 보여줍니다. 움직이는 조명 한 개를 추가하면 정지 이미지에서 숨은 하이라이트 끊김이나 노멀 불연속을 발견하기 쉽습니다.
비교 이미지에는 자동 차이와 사람 판정을 같이 남깁니다. 자동 차이는 프레임 정렬이 정확할 때만 의미가 있으므로 카메라와 랜덤 시드를 고정합니다. 픽셀 차이가 크더라도 톤매퍼 차이 때문일 수 있고, 차이가 작더라도 중요한 실루엣 하이라이트가 사라질 수 있습니다. 수치 임계값은 실패 후보를 찾는 필터로 사용하고 최종 룩 승인은 아티스트가 맡아야 합니다.
성능 기록도 같은 실험에 붙입니다. 셰이더 명령 수 하나만 보지 말고 변형 수, 샘플러 수, 텍스처 메모리, 오버드로, 대상 GPU 프레임 시간을 비교합니다. 고급 로브를 정확히 재현해도 사용 빈도가 높은 VFX 머티리얼의 예산을 넘으면 제작 경로로 채택하기 어렵습니다. 반대로 히어로 에셋 한 개라면 비용을 허용하고 룩 정확도를 우선할 수 있습니다.
마지막으로 실패 사례를 삭제하지 않습니다. 지원하지 않는 전송, 지나치게 비싼 퍼즈, 자동 UV로 깨진 방향성 패턴 같은 실패 샘플은 다음 작업자가 같은 실험을 반복하지 않게 합니다. 성공한 프리셋만 공유하는 것보다 실패 조건과 대체 경로를 함께 남기는 편이 파이프라인 자산으로서 가치가 큽니다.
지금의 판단: OpenPBR은 전면 교체보다 비교 가능한 기준부터
Painter 12.1의 베이크 개선은 아티스트가 바로 체감할 수 있는 변화이고, OpenPBR 확장은 장기적으로 DCC 사이 재질 번역 비용을 줄일 가능성이 큽니다. Adobe가 제작에서 사용한 OpenPBR BSDF 구현을 Apache 2.0으로 공개한 점도 단순한 마케팅 자료보다 강한 검증 자산입니다.
하지만 발표만으로 게임 엔진 결과의 동일성이 증명되지는 않습니다. OpenPBR의 파라미터 계약과 엔진의 셰이딩 구현, 톤매핑, 압축, 성능 예산은 서로 다른 층입니다. 도입의 첫 단계는 기존 라이브러리를 일괄 변환하는 일이 아니라 대표 머티리얼, 채널 매핑표, 고정 조명 캡처, 허용 오차를 만드는 일이어야 합니다.
VFX와 테크니컬 아트 팀이라면 Painter 12.1을 작은 하드서피스 자산군에 먼저 적용해 보세요. 부분 재베이크가 실제 반복 시간을 줄이는지, 교정이 원본 문제를 숨기지 않는지, OpenPBR 채널이 엔진에서 어떤 상태로 번역되는지 기록하면 다음 선택이 선명해집니다. 이번 업데이트의 가장 큰 가치는 기능 개수가 아니라 재질의 의미와 검증 과정을 팀의 공통 언어로 만들 기회에 있습니다.
참고 출처
- Adobe, Substance 3D innovations at SIGGRAPH 2026, 2026-07-21: https://blog.adobe.com/en/publish/2026/07/21/adobe-substance-3d-unveils-new-innovations-deliver-faster-workflows-openpbr-everywhere-digital-twins-scale
- Adobe, OpenPBR BSDF reference implementation: https://github.com/adobe/openpbr-bsdf
- Academy Software Foundation, OpenPBR specification: https://academysoftwarefoundation.github.io/OpenPBR/