핵심 정리
text
Graph asset
-> node 연결
-> property 노출
-> material에서 값 조절구조 이해
- Shader Graph는 셰이더 코드를 직접 쓰지 않고 시각적 노드 그래프로 셰이더를 구성하게 해 주는 도구입니다. 특히 아티스트와 테크니컬 아티스트가 머티리얼 표현을 빠르게 반복할 때 큰 장점이 있습니다.
- 가장 먼저 알아야 할 전제는 Shader Graph가 SRP 기반이라는 점입니다. 즉 URP나 HDRP 프로젝트에서 잘 맞고, 레거시 built-in render pipeline에서는 지원이 제한됩니다.
- Graph 안에서는 노드 연결로 계산 흐름을 만들고, Blackboard property를 노출해 material inspector에서 조절 가능한 파라미터를 만듭니다. 그래서 Graph는 표현 로직, material은 그 표현의 인스턴스라고 생각하면 이해가 쉽습니다.
- Shader Graph의 가치는 단순히 "코드를 안 써도 된다"가 아닙니다. 반복 실험, 파라미터화, 시각적 검토, 협업 속도에서 차이가 납니다.
- 다만 모든 셰이더 문제를 Shader Graph로 푸는 것이 항상 최선은 아닙니다. 복잡한 저수준 최적화나 파이프라인 특화 코드가 필요한 경우에는 hand-written shader가 더 적합할 수 있습니다.
체크포인트
| 상황 | 적합한 선택 |
|---|---|
| URP/HDRP 프로젝트에서 셰이더 제작 | Shader Graph 사용 |
| Built-in RP 프로젝트 | 지원 제한 → hand-written shader 또는 URP 전환 검토 |
| material마다 다른 파라미터 필요 | Blackboard에 Exposed property 추가 |
| 저수준 최적화나 파이프라인 특화 | hand-written shader가 더 적합 |
| 선택 기준 | Shader Graph가 더 잘 맞는 경우 | 코드 셰이더가 더 잘 맞는 경우 |
|---|---|---|
| 반복 실험 속도 | 아티스트·디자이너가 자주 조절함 | 저수준 최적화와 특수 분기 제어가 중요함 |
| SRP 전제 | URP/HDRP 기반 프로젝트 | Built-in RP 유지 프로젝트 |
| 파라미터 노출 | 머티리얼 인스펙터에서 많이 조절함 | 내부 구현을 코드로 강하게 제어해야 함 |
| 협업 방식 | 시각적 그래프 공유가 유리함 | 코드 리뷰와 버전 관리가 더 중요함 |
주의할 점
Shader Graph는 추상화가 크기 때문에 그래프가 커질수록 실제 비용을 잊기 쉽습니다. 시각적 편의성과 런타임 비용을 함께 확인하는 습관이 중요합니다.
text
// ❌ 그래프가 커졌는데 비용 확인 없음
100개 노드 연결 → 실제로 몇 개의 shader instruction이 생성됐는지 모름
// ✅ 비용 확인 방법
Shader Graph 에디터 > Graph Settings > Graph Inspector
→ Generated Shader 확인 (Vertex/Fragment instruction 수)
또는:
Material Inspector에서 셰이더 선택
→ Edit > Shader... → 생성된 코드 확인
런타임 비용:
Profiler > GPU 모듈에서 해당 오브젝트 draw call 비용 측정Graph property를 무분별하게 Expose하면 머티리얼 조절점은 늘어나지만, 실제로 어떤 값이 런타임 비용을 바꾸는지 추적하기 어려워집니다.
text
// ❌ 노출 가능한 값은 전부 Exposed
Color, Noise Scale, Rim Power, Distortion, Emission, Alpha, Blend...
→ 머티리얼 변형은 쉬워도 운영 기준이 흐려짐
// ✅ 자주 바꾸는 값만 Exposed
아트 팀이 실제로 만질 값만 Blackboard 공개
나머지는 Graph 내부 상수나 별도 variant로 관리참고 링크
3 sources