유니티 쉐이더의 구조

일단 유니티의 쉐이더는 세가지를 지원한다.

T&L 파이프라인, 서페이스쉐이더, 쉐이더(프로그래머블 파이프라인)

1)

다이렉트9버전까지의 그래픽지원은 T&L파이프라인만을 지원했다. 

이것은 그냥 짜여진 순서에 의지하여 그래픽을 계산해내는 것으로 프로그래머가 직접 개입할수 없는 쉐이더다. (이제는 쉐이더라고 부르기 어려운 ...)

InputData -> Transformation and Lighting -> Primitive Setup -> Resterizeation

->Pixel/FragmentProcessing ->Frame Buffer Bland (T&L파이프라인의 진행구조)

하드웨어적으로 제한되어 있어서 가감처리가 어려운 환경에서 사용하던 방식이라, 여러가지 효과를 위해서는 프로그래밍에서 트릭적인 테크닉이 필요했다고 함..

현재 유니티는 모바일에서 콘솔, PC까지 다방면을 지원하고 있어서 하드웨어적 제한이 있는 환경에 필요한 T&L파이프라인도 지원하고 있는 것이다

2)

그리고 다이렉트10이후로 프로그래머들이 직접 관여하여 코딩하고자 만들어진 지금의 쉐이더 (프로그래머블 파이프라인)를 지원한다. 

당연하게도 하드코딩으로 쉐이더를 짜면 pc에서 사용하던 쉐이더 그대로 사용가능하다.

Input Data -> VertexShading -> GeometryShading -> Primitive Setup -> Resterization

->Pixel/Frag Shading->Frame Buffer Blend (쉐이더 진행구조)

3)

이 쉐이더를 유니티에서 다듬어서 만든 형식이 서페이스 쉐이더다.

서페이스 쉐이더는  컴파일하면 결국엔 2번의 쉐이더로 변경된다. 

결국 2번의 쉐이더를 사용하면 결과적으로 유니티가 처리한것과 동일한 쉐이더가 된다.

다만 유니티에서는 지원하는 콘솔과 PC, 모바일 장치에 대한 모든 경우의 쉐이더를 작성한다. 그리고 맞는 플랫폼에 따른 쉐이더를 사용하는 시스템이다. 

그리고 실질적으로 유저가 바꾸고 싶어하는 부분(변경하고 싶어하는 부분) 인 버텍스쉐이더와 픽쉘쉐이더에 대한 변경할 부분을 함수로 빼놓고 , 그 함수부분을 커스터마이징 할수 있게 한 것이 서페이스쉐이더다. 

유저입장에선 기본제공하는 램버트/불린퐁 라이팅연산만으로도 디퓨즈와 반사조명의 효과를 어느정도 볼 수 있고, 필요한만큼 조명연산에 대해 커스터마이징 할수 있으므로 굳이 2번의 쉐이더 형태의 모든 뼈대를 작성할 필요가 없어진다. 

코딩에서 

{

}

가로로 묶듯이 

CGPROGRAM ~ ENDCG 로 묶고 

그 사이에 적는 것이 결국 커스터마이징한 쉐이더가 된다. 컴파일해보면 내가 커스터마이징한 이부분을 함수콜하는 형태로 2번의 쉐이더형식을 따르고 있는것을 볼 수 있다.

그래서 CGPROGRAM ~ ENDCG안의 내용은 쉐이더 언어인 HLSL언어로 작성하게 되는것이다.

결론적으로 유니티 유저는 서페이스쉐이더를 이용하면 긴코딩을 줄일수 있고, 이것만으로도 컬링,z버퍼,알파테스팅, 블랜딩 등 쉐이더를 이용하여 하고 싶은 것을 웬만하면 다 처리할 수 있으므로 적응된다면 시간을 줄일수 있을것이다.

하지만 평생 유니티만으로 코딩할게 아니라면 그냥 쉐이더를 사용한다면 유니티에서도 아무문제 없이 코딩할 수 있고, 혹시 서페이스쉐이더에서 지원하지 못하는 현상이 생기더라도 쉐이더를 직접 코딩했으면 여타 제작환경에서터럼 진행할 수 있다. 

단, 2번이든 3번이든 이 쉐이더는 다이렉트10이후에 생겨난 최신기술이다. 지원하지 않는 환경에선 1번을 따라갈수 있도록 

Fallback "diffuse"

처럼 예외처리를 해야한다. 

최종적인 내생각에는 2번의 쉐이더를 잘 다루는 사람은 서페이스쉐이더도 문제없이 다룰 수있고, 더 상급의 프로그래머일 것이라는 생각이다.  3번은 방법만 익히고 ,2번에 정진하자.

[출처] 고정기능 파이프라인과 프로그래머블파이프라인,고정함수파이프라인,프로그래머블파이프라인|작성자 znfgkro1