PBR 재질 자동 생성을 위한 AI 프롬프트 가이드와 텍스처 채널 최적화
AI로 PBR 재질을 자동 생성할 때 필요한 프롬프트 구조, Base Color·Normal·Roughness 채널 검수 기준, ORM 패킹과 해상도 최적화 방법을 실무 흐름으로 정리한다.
핵심 요약
AI로 PBR 재질을 만들 때는 이미지를 한 번에 생성하는 방식보다 재질 유형·스케일·표면 상태·조명 제거 조건을 고정한 프롬프트 가이드를 먼저 만드는 편이 안정적이다. 생성 결과는 Base Color, Normal, Roughness, Ambient Occlusion을 각각 검수하고 런타임에서는 Roughness·Metallic·AO를 ORM 텍스처의 RGB 채널에 패킹해 텍스처 샘플 수를 줄인다. 메모리 절감 여부는 대상 플랫폼의 텍스처 포맷과 압축 설정에 따라 달라진다.
AI PBR 재질 자동 생성에서 무엇을 표준화해야 할까?
AI 텍스처 생성에서 중요한 과제 중 하나는 재현성이다. 같은 재질을 여러 번 생성했을 때 조명 방향, 명암, 재질 스케일, 마모 표현이 달라지면 채널 분리와 셰이더 적용 단계에서 추가 작업이 필요할 수 있다.
프롬프트 가이드는 재질별 묘사 문구를 모아 둔 목록이 아니라 결과를 PBR 파이프라인에 넣기 위한 입력 규격이다. 다음 항목은 타일형 PBR 텍스처 프롬프트에 공통으로 지정할 수 있다.
| 항목 | 프롬프트에 지정할 내용 | 누락 시 문제 |
|---|---|---|
| 재질 정체성 | painted steel, weathered oak, limestone 등 | 재질 특성이 혼합됨 |
| 실제 스케일 | 1 m x 1 m, small scratches, 5 mm grout lines 등 | 타일링 시 크기가 부자연스러움 |
| 표면 상태 | dry, matte, oxidized, clean, chipped edges 등 | Roughness 해석이 불안정함 |
| 조명 제거 | flat albedo, no directional lighting, no cast shadow | Base Color에 명암이 남음 |
| 반복 가능성 | seamless, tileable, edge-to-edge continuity | 반복 경계가 드러남 |
| 금지 요소 | no text, no logo, no objects, no perspective | 불필요한 형태가 섞임 |
재사용 가능한 AI 텍스처 프롬프트 템플릿
아래 템플릿은 이미지 모델에 맞춰 일부 표현을 조정할 수 있지만 정보의 순서는 유지하는 것이 좋다.
Seamless tileable PBR base color texture of [MATERIAL].
Real-world scale: [SIZE]. Surface condition: [CONDITION].
Uniform top-down orthographic surface, edge-to-edge continuity.
Flat diffuse albedo only, physically plausible color variation.
No directional lighting, no shadows, no highlights, no ambient occlusion.
No text, logos, objects, perspective, borders.예를 들어 오래된 콘크리트 벽면이라면 다음처럼 작성한다.
Seamless tileable PBR base color texture of aged cast concrete.
Real-world scale: 2 m x 2 m. Surface condition: dry, matte,
subtle pores, faint formwork seams, sparse hairline cracks.
Uniform top-down orthographic surface, edge-to-edge continuity.
Flat diffuse albedo only, no directional lighting, no shadows,
no highlights, no ambient occlusion. No text, logos, objects,
perspective, borders.AI가 생성한 이미지는 조명 없는 알베도라는 지시를 완벽히 따르지 않을 수 있다. 따라서 이 프롬프트는 품질 보증 수단이 아니라 후처리와 검수를 줄이는 입력 제약으로 다뤄야 한다.
PBR 텍스처 채널은 왜 분리해서 검수해야 하는가?
PBR 셰이더는 각 채널이 다른 물리 정보를 가진다는 전제에서 동작한다. Base Color에 그림자가 남아 있거나 Roughness에 광원 반사가 섞이면 엔진의 동적 라이팅과 중복되어 표면이 탁하거나 과도하게 번들거린다.
| 채널 | 저장 정보 | 검수 기준 |
|---|---|---|
| Base Color | 조명 제거된 고유 색상 | 그림자, 하이라이트, AO가 없어야 함 |
| Normal | 미세 표면 방향 | 초록 채널 방향과 압축 후 계단 현상 확인 |
| Roughness | 미세 표면의 거칠기 | 검정색에 가까울수록 매끈하고 흰색에 가까울수록 거침 |
| Metallic | 금속성 마스크 | 대부분의 일반 재질은 0, 금속 영역은 대체로 1 |
| Ambient Occlusion | 미세 틈의 차폐 | 넓은 그림자가 아니라 접촉부 위주여야 함 |
금속성과 거칠기는 조명 결과에 직접 영향을 준다. 금속 재질은 금속성 값이 1에 가까울수록 반사광의 색이 Base Color를 따른다. 비금속 재질은 일반적으로 Metallic을 0으로 둔다.
물리 기반 렌더링에서 거칠기는 미세 표면 분포를 제어한다. 셰이더 구현에 따라 perceptual roughness를 사용하는 경우가 많으며 GGX 분포의 alpha 값은 다음처럼 변환할 수 있다.
여기서 은 0부터 1 사이의 perceptual roughness다. 이 관계 때문에 Roughness 맵의 중간톤을 무심코 보정하면 반사 하이라이트가 기대보다 크게 달라질 수 있다.
AI 생성 결과를 PBR 채널로 만드는 3단계
1. Base Color에서 조명 성분을 제거한다
먼저 생성 이미지에서 강한 명암, 방향성 그림자, 반사 하이라이트를 제거한다. AI 이미지의 어두운 부분을 AO로 재활용하면 안 된다. 이는 광원의 방향과 표면 색상을 함께 포함하기 때문이다.
Base Color는 sRGB로 저장하고 엔진에서 색상 텍스처로 가져온다. Unreal Engine 5에서는 Base Color용 텍스처의 sRGB를 켜고, Normal·Roughness·Metallic·AO 같은 데이터 텍스처는 sRGB를 끈다.
2. Normal과 Roughness를 독립적으로 생성·보정한다
Normal 맵은 높낮이 정보에서 파생되므로 생성 이미지의 큰 명암을 그대로 사용하면 가짜 굴곡이 생긴다. 벽돌 줄눈, 나뭇결, 콘크리트 기공처럼 실제로 빛의 방향을 바꿔야 하는 정보만 남긴다.
Roughness는 색상 대비를 그대로 변환하지 말고 재질 의미를 기준으로 작성한다. 예를 들어 페인트가 벗겨진 금속은 노출된 금속만 매끈하다고 단정할 수 없다. 산화나 먼지의 정도에 따라 거칠기가 더 높을 수 있다.
3. 엔진에서 중립 조명으로 검수한다
재질 미리보기는 HDRI 하나만으로 판단하지 않는다. 중립 회색 환경, 회전하는 방향광, 낮은 각도의 점광원을 번갈아 사용해 채널 오류를 찾는다. 특히 다음 현상은 채널별 오류를 빠르게 가리킨다.
- 카메라를 움직여도 어두운 얼룩이 고정되면 Base Color 또는 AO가 과함
- 광원 이동에 따라 표면 요철이 반대로 보이면 Normal의 Y 방향이 반전됨
- 하이라이트가 지나치게 선명하고 좁아 플라스틱처럼 보이면 Roughness 값이 낮거나 sRGB 설정이 잘못되었을 수 있음
- 비금속 표면에 색 반사가 강하게 나타나면 Metallic 마스크가 오염됨
flowchart LR
A[AI Base Color 생성] --> B[조명·그림자 제거]
B --> C[Normal·Roughness 분리 생성]
C --> D[채널 범위 검수]
D --> E[ORM 패킹]
E --> F[엔진 중립 조명 검수]
ORM 패킹으로 텍스처 채널을 어떻게 최적화할까?
ORM은 서로 독립적인 단일 채널 데이터를 하나의 RGB 텍스처에 합치는 방식이다. 아래 배치는 이 글에서 사용할 예시 규약이며, 실제 채널 순서는 엔진·도구·프로젝트 규약에 따라 달라질 수 있다.
| ORM 채널 | 포함 데이터 | Unreal Engine 머티리얼 연결 |
|---|---|---|
| R | Ambient Occlusion | Ambient Occlusion |
| G | Roughness | Roughness |
| B | Metallic | Metallic |
| A | 선택 사항: Height 또는 마스크 | 필요할 때만 사용 |
ORM 텍스처는 색상 이미지가 아니라 데이터 맵이므로 sRGB를 끈다. Unreal Engine 5에서는 압축 설정을 Masks (no sRGB) 또는 프로젝트의 마스크용 표준 설정으로 두면 된다.
패킹할 때는 출력 텍스처의 공통 해상도와 비트 깊이를 정하고, 필요하면 각 맵을 재표본화한다. Roughness는 8비트 그레이스케일로 시작할 수 있지만 부드러운 그라데이션이 넓은 재질은 압축 후 밴딩을 확인한다. 밴딩이 보이면 노이즈 디더링이나 다른 압축 설정을 시험하고, 화질과 메모리 사용량을 함께 비교한다.
텍스처 해상도와 밉맵은 어떻게 결정할까?
기본 해상도는 원본의 디테일이 아니라 화면에서 차지하는 최대 픽셀 수로 정한다. 4K 원본을 받았다는 이유만으로 모든 소품에 4K 텍스처를 유지할 필요는 없다.
| 에셋 유형 | 시작 해상도 예시 | 판단 기준 |
|---|---|---|
| 영웅 에셋 | 2048 또는 4096 | 근접 카메라와 반복 노출 여부 |
| 일반 소품 | 1024 또는 2048 | 화면 점유율과 재사용 횟수 |
| 배경 반복 재질 | 1024 또는 2048 | 타일 밀도와 텍셀 밀도 |
| 아주 작은 소품 | 256 또는 512 | 화면에서 식별 가능한 디테일 |
밉맵은 거리별 샘플링 안정성과 텍스처 스트리밍을 위해 유지하는 것이 일반적이다. 밉 단계 자체에도 메모리가 필요하므로 프로젝트 예산을 확인하고, UI나 의도적으로 픽셀 단위가 유지되어야 하는 텍스처는 별도로 판단한다. PBR 표면 텍스처에서 밉맵을 끄면 원거리 깜빡임과 앨리어싱이 늘어날 수 있다.
자주 묻는 질문 (FAQ)
AI가 만든 컬러 이미지를 그대로 Base Color에 써도 될까?
권장하지 않는다. 방향광 그림자와 반사 하이라이트가 남아 있으면 엔진 라이팅과 중복된다. 조명 성분을 제거하거나 처음부터 flat albedo 조건으로 생성한 뒤 검수해야 한다.
ORM 패킹은 언제 피해야 할까?
채널마다 서로 다른 해상도, 밉맵 정책, 압축 품질이 필요한 경우에는 분리 텍스처가 더 낫다. 예를 들어 높이 맵을 정밀한 패럴랙스 용도로 쓴다면 ORM의 알파 채널에 무조건 넣기보다 품질을 먼저 확인한다.
Normal 맵의 sRGB는 왜 꺼야 할까?
Normal 맵의 RGB 값은 색상이 아니라 방향 벡터 데이터다. sRGB 감마 보정이 적용되면 벡터 값이 왜곡되어 조명 반응이 틀어진다.
정리
AI PBR 재질 자동화의 목표는 생성 횟수를 늘리는 것이 아니라 후속 공정이 예측 가능한 입력을 받게 만드는 것이다. 프롬프트에서 조명 제거와 실제 스케일을 고정하고 채널을 독립적으로 검수한 뒤 ORM 패킹과 적절한 밉맵으로 런타임 비용을 줄이면 생성형 도구를 기존 아트 파이프라인 안에 안정적으로 넣을 수 있다.
