게임 산업 트렌드

Unreal Engine 5.7 Substrate 실전 전환: 젖은 표면 레이어와 GBuffer 비용 관리

kr-gamedev 2026. 7. 11. 09:05

Unreal Fest Stockholm에서 발표된 Unreal Engine 5.7의 중요한 변화 중 하나는 Substrate가 프로덕션 단계에 들어섰다는 점이다. Substrate는 Default Lit, Clear Coat처럼 미리 정해진 셰이딩 모델을 선택하는 대신, 물질을 나타내는 BSDF Slab을 조합해 표면을 만든다.

특히 비에 젖은 도로, 도장 위 먼지, 코팅된 금속처럼 여러 성질이 겹치는 재질에서 효과가 크다. 기존에는 Material Function과 Lerp를 중첩해 흉내 냈지만, Substrate에서는 위아래 물질의 관계를 그래프 자체로 표현할 수 있다.

Substrate가 바꾸는 재질 설계

Epic Games의 Unreal Fest 발표 정리에 따르면 Substrate는 UE 5.7에서 기존 재질 기능과 주요 대상 플랫폼을 지원하며 신규 프로젝트에 기본 활성화된다. 기존 프로젝트는 Project Settings의 Rendering에서 직접 활성화해야 한다.

핵심 단위는 Substrate Slab BSDF다. Slab에는 Diffuse Albedo, F0, F90, Roughness, Mean Free Path처럼 물리적 의미를 가진 값이 들어간다. 여러 Slab은 다음 연산자로 결합한다.

  • Horizontal Blend: 진흙과 아스팔트처럼 두 표면을 마스크로 혼합
  • Vertical Layer: 금속 위 투명 코팅처럼 위아래 물질을 적층
  • Coverage Weight: 먼지나 물막이 덮는 비율을 조절
  • Add: 물리적 에너지 보존보다 연출을 우선할 때 사용

젖은 도로라면 아스팔트 Slab 위에 낮은 Roughness를 가진 물 Slab을 Vertical Layer로 올리고, 물 Slab의 Coverage Weight를 Wetness 매개변수로 제어하면 된다.

C++에서 날씨와 재질 연결하기

Substrate도 게임 코드에서는 일반 Material Instance와 동일하게 다룬다. 따라서 기존 날씨 시스템을 다시 작성할 필요 없이 동적 머티리얼의 매개변수만 갱신하면 된다.

#include "Materials/MaterialInstanceDynamic.h"
#include "Components/MeshComponent.h"

void AWetRoadActor::BeginPlay()
{
    Super::BeginPlay();

    WetMaterial = RoadMesh->CreateAndSetMaterialInstanceDynamic(0);
    SetWetness(0.0f);
}

void AWetRoadActor::SetWetness(const float Value)
{
    if (!WetMaterial)
        return;

    const float Wetness = FMath::Clamp(Value, 0.0f, 1.0f);
    const float CoatRoughness = FMath::Lerp(0.32f, 0.04f, Wetness);

    WetMaterial->SetScalarParameterValue(TEXT("Wetness"), Wetness);
    WetMaterial->SetScalarParameterValue(
        TEXT("CoatRoughness"), CoatRoughness);
}

여기서 Wetness는 물 Slab의 Coverage Weight에, CoatRoughness는 위쪽 Slab의 Roughness에 연결한다. 빗물 양이 증가할수록 표면을 덮는 비율과 반사 선명도가 함께 변한다. 여러 액터를 갱신해야 한다면 Material Parameter Collection을 사용해 전역 값 한 번으로 처리하는 편이 낫다.

Blendable과 Adaptive GBuffer 선택

Substrate의 비용은 Slab 개수와 GBuffer 형식에 크게 좌우된다. Blendable GBuffer는 메모리 사용량과 실행 비용을 예측하기 쉬워 60fps 게임에 적합하다. 반면 Adaptive GBuffer는 복잡한 물질 정보를 더 많이 보존하지만 지원 하드웨어가 제한되고 셰이더 컴파일과 프레임 비용이 증가한다.

재질 하나에 Slab을 계속 추가하면 조명 계산 비용도 거의 비례해 늘어난다. Horizontal Blend나 Vertical Layer의 Use Parameter Blending을 활성화하면 여러 레이어를 단일 매개변수 집합으로 단순화할 수 있다. Material Editor의 Substrate Stats와 Material Count, Material Bytes Count 보기 모드도 반드시 확인해야 한다.

기존 프로젝트의 안전한 전환 순서

전체 프로젝트를 한 번에 변환하는 방식은 피하는 것이 좋다. 먼저 복제 브랜치에서 Substrate를 활성화하고 대표 재질 5개 정도만 변환한다. 이후 PC, 콘솔, 모바일별 스크린샷과 GPU 시간을 비교한다.

기존 재질은 Substrate 활성화 후에도 호환 경로로 동작한다. 하지만 명시적으로 Substrate 노드로 변환한 재질은 Substrate가 꺼진 프로젝트에서 정상 표시되지 않을 수 있다. 공용 플러그인이나 마켓 에셋을 제작한다면 기존 재질 버전도 별도로 유지하는 것이 안전하다.

결론

Substrate의 가치는 그래픽 품질만 높이는 데 있지 않다. 젖음, 먼지, 코팅처럼 반복되는 표면 규칙을 물질 레이어로 표준화해 아트와 코드의 계약을 단순하게 만든다. 다만 복잡한 Slab 그래프와 Adaptive GBuffer는 명확한 비용을 가진다. Blendable GBuffer로 시작하고, Parameter Blending과 디버그 보기로 예산을 확인하며 필요한 재질만 단계적으로 전환하는 전략이 가장 현실적이다.