Quick Flow

Unity frame은 scene 전체를 무조건 그리지 않고 먼저 culling으로 후보를 줄인 뒤, 선택된 object를 lighting·shader·depth·blend 상태에 따라 render하고, 필요하면 post-processing으로 최종 frame을 만듭니다. 오류는 “shader” 한 곳으로 뭉치지 말고 어느 단계의 입력·state가 다른지로 좁힙니다.

scene object
  -> frustum / occlusion culling
  -> vertex 처리와 primitive 조립
  -> rasterization: fragment 후보 생성
  -> fragment 색 계산
  -> depth / stencil / blend 상태로 framebuffer 합성
  -> post-processing과 display

Unity pipeline과 graphics stages

일반 graphics pipeline에서는 vertex shader가 정점 위치와 attribute를 clip space로 보내고, primitive assembly·clipping·rasterization이 fragment 후보를 만들며, fragment shader가 색을 계산합니다. depth/stencil test와 blending은 final color를 framebuffer에 합성할지 결정합니다. Unity의 Built-in, URP, HDRP, custom SRP는 이 단계를 같은 방식으로 노출하지 않으며 pass 순서와 material compatibility가 달라질 수 있습니다.

Unity Manual의 큰 흐름은 culling, rendering, post-processing입니다. Frame Debugger에서는 이 큰 흐름이 실제 camera·renderer·pass·draw sequence로 어떻게 펼쳐졌는지 볼 수 있습니다. 따라서 shader code만 수정하기 전에 해당 renderer가 frame에 들어왔는지, 어느 pass에서 그려졌는지, 어떤 render state였는지 확인합니다.

depth와 blend의 순서

opaque object는 depth test와 depth write를 활용해 가려진 fragment를 줄일 수 있습니다. transparent object는 blend를 위해 뒤의 framebuffer 색을 참조해야 하는 경우가 많아 sorting과 depth write 정책이 중요합니다. transparent가 뒤집히거나 겹쳐 보인다고 fragment 색만 고치면 해결되지 않을 수 있으며, render queue·sorting·ZTest·ZWrite와 camera를 함께 봐야 합니다.

post-processing은 이미 만들어진 pixel buffer를 바꾸는 별도 단계입니다. bloom·color grading·depth of field 같은 결과가 이상하면 base material뿐 아니라 volume, pipeline asset, camera post-processing 설정과 render target format을 확인합니다.

pipeline을 먼저 고정하기

URP, HDRP, Built-in은 지원 feature·shader·debug tool이 달라 project 중간에 쉽게 교체할 수 있는 단순 quality option이 아닙니다. 성능 개선이나 custom render pass를 논의하기 전에 현재 pipeline asset, target platform, rendering path, camera 구성을 명시합니다. 다른 pipeline의 material·batching·post-processing 조언을 그대로 적용하면 compile은 돼도 기대한 pass에서 동작하지 않을 수 있습니다.