이전에 렌더링 16에서 처음 본 부분은 투명 오브젝트에 대한 마지막 부분이 부족했는데 그 부분이 굉장히 신비롭고 전혀 이해가 되지 않았습니다.
그리고 그의 조작은 버전의 차이로 인해 여기에서 관련 조작 버튼을 전혀 찾을 수 없습니다.
여기에서 이 라이트 맵을 사용하기 전에 이것이 켜져 있는지 확인해야 하고 변형 키워드를 사용해야 합니다.
논리는 다음과 같습니다. 베이킹 및 기타 옵션을 외부에서 활성화할지 여부를 설정할 수 있으며 활성화는 셰이더의 키워드 생성에 영향을 미치므로 #if에서 판단할 때
외부가 켜져 있는지 여부에 따라 관련 계산을 수행할지 여부를 결정합니다.
또한 그가 여기서 말한 VERTEXLIGHT와 LIGHTMAP 사이의 상호 배제에 주목하십시오.
라이트맵이 샘플링되기 때문입니다. 그런 다음 uv를 사용해야 합니다. 여기에 UV의 두 번째 세트가 있습니다.
샘플링은 두 번째 UV 세트를 통해 수행되며 샘플링 전에 변환이 필요합니다.
이것은 이전 텍스처 좌표의 변환과 유사하지만 여기에서 이유를 말했을 때 그는 텍스처 언래핑에 대해 이해하지 못했습니다. . .
그런 다음 샘플링 작업이 있으며 샘플링 결과는 간접 조명으로 사용됩니다.
여기서 샘플링 결과도 디코딩이 필요합니다.
(앞서 언제 복호화를 하고 언제 복호화를 하느냐에 대한 질문을 하기 전에 이런 관점에서 보면 이미지 저장과 관련이 있고, 이미지가 특정 형식으로 저장이 필요한 경우 인코딩을 해야 하고,
그리고 우리가 얻은 몇 가지 텍스처가 있습니다. 그는 인코딩되어 있으므로 디코딩해야 합니다. )
다음은 라이트맵의 현재 사용에 여전히 문제가 있다는 것입니다. 간단한 사용에는 문제가 없습니다.
그는 항상 우리의 정면 물체가 단색 흰색이고 불투명하다고 생각하므로 불투명하거나 다른 색상일 때 몇 가지 문제가 있을 것입니다.
이는 불투명도를 0으로 변경하면 더욱 분명해집니다.
위에서 언급한 것처럼 불투명으로 취급하는 이유는 다음과 같습니다. 주로 그가 굽고 있을 때 그가 당신을 반투명하게 본다면 그는 _Color의 알파 채널을 참조하기 때문입니다.
하지만 여기에는 없기 때문에 불투명하다고 생각해야 합니다.
따라서 이것에 대한 해결책은 매우 간단합니다. 교체하십시오.
이 컷아웃의 그림자는 완전히 비슷하므로 이름도 변경해야 합니다.
여기서 베이킹을 할 때 베이킹의 결과가 간접광이라는 점에 주목하고 베이킹 효과를 고려할 때 씬의 간접광에 주목한다.
그래서 여기 색상에 대한 것이 있습니다. 물체 자체의 색상이 간접광과 어떤 관련이 있기를 원하는지, 단지 색상 번짐의 효과 등이 아닌가 합니다.
그러나 여기서 색상 번짐은 항상 흰색입니다. 즉, 이 라이트맵이 모든 오브젝트의 매핑된 라이트를 처리할 때
하얗게 되었습니다.
라이트맵 자체가 알베도, 자체 발광, 금속성 등을 포함하여 개체의 색상을 고려하기 때문에 색상을 변경하는 것만큼 간단하지 않습니다.
이러한 상황은 모두 색 번짐의 최종 결과를 결정합니다.
따라서 여기서 라이트맵이 올바른 효과를 주기를 원한다면 이 모든 관련 사항을 그에게 알려야 합니다.
이전에는 자르기와 투명도가 포함되어 있습니다.우리도 알려 줬습니다.차이점은 이전에 이름을 합의한 다음 해당 값을 빼는 것입니다. 그런 다음 값에 따라 간접 조명 효과를 생성합니다.
구체적으로 라이트맵이 생성될 때 관련 사항을 알리는 방법입니다. 새로운 패스가 필요합니다.
사용할 변수와 함수를 준비합니다.
이러한 함수가 작동할 때 이전에 많은 조건을 작성했으며 판단을 위해 이러한 조건에 의존해야 하기 때문입니다. 즉, 키워드가 적용되어야 합니다.
다음은 정점입니다.
사실 여기서 핵심을 이해하는 것이 좋다.
사실, 핵심은 빨간색 상자 안의 문장입니다. 즉, 우선 우리의 패스는 장면의 개체를 통과하는 것입니다.
그러나 우리가 출력한 결과는 카메라의 관점에서 원근투영으로 보이는 효과를 출력한 것이 아니다.
대신 라이트맵에서 텍스처 언랩을 수행하려고 합니다.
보풀이 시작되는 곳입니다.
첫째, 처음에 세계 공간의 객체가 무엇인지는 중요하지 않으며 위치가 무엇인지는 중요하지 않습니다.
이는 실제로 최종 렌더링 결과와 직접적인 관련이 없습니다.
최종 렌더링 결과는 조각에 전달된 위치와 색칠에 필요한 속성 정보에 따라 달라집니다.
전자는 출력 그래프의 콘텐츠 레이아웃을 결정하고 후자는 특정 콘텐츠 세부 정보를 결정합니다.
그래서 우리가 입력한 것은 장면이고, 이를 사용하여 라이트맵에서 이 텍스처 언래핑을 렌더링할 수 있습니다.
그것을하는 방법? 사실 가장 중요한 것은 출력의 위치가 어디인지 파악하는 것입니다.
장면의 각 개체에 해당하는 지점은 이 텍스처에 해당 지점이 있습니다. 이것이 우리가 라이트맵을 샘플링하기 위한 전제입니다.
사실 이 라이트맵을 원한다면 각 포인트만 꺼내면 되고 각 포인트는 장면의 한 포인트에 해당합니다.
그래서 씬의 포인트를 라이트맵의 포인트로 변환한 다음 프래그먼트에 위치로 전달하는 아이디어가 나왔습니다.
이런 식으로 간접 조명을 음영 처리한 다음 라이트맵에 저장하는 방법을 깨달았습니다.
물론 여기에는 2차원 좌표를 3차원 좌표로 변경하는 디테일이 필요한데, 2차원은 라이트맵의 정점에 해당하는 점들이 모두 2차원 좌표이기 때문이다.
여기에 z를 0으로 쓰면 됩니다.
여기서 플랫폼 관련 문제를 고려하여 삼항 연산자를 개발합니다.
프래그먼트의 경우 여기에서 두 개의 출력(알베도 하나와 방출 하나)이 필요합니다. 패스는 두 번 실행됩니다. 매번 출력하는 방법에 대해서는 Unity가 준비하는 데 도움이 됩니다.
관련 판단 인터페이스:
그의 정의에서 그는 알베도와 방출에 대한 판단을 내렸다는 것을 알 수 있습니다.
이 간단한 변환 작업입니다.
따라서 계산한 여러 수량을 전달해야 합니다. 따라서 다음 작업은 전달된 매개변수를 계산하는 것입니다.
다음은 간단한 호출입니다.
물론 여기에는 여전히 일부 자체 발광 문제가 있습니다. 즉, 베이킹할 때 오브젝트가 자체 발광하는 경우 자체 발광 계산 패스를 거쳐 라이트맵으로 출력해야 합니다.
결과가 있을 것이고,
그리고 이 문제는 자체 발광 오브젝트가 자체 발광 계산 패스를 통과해야 하도록 재료에서 처리해야 합니다.
주로 좌표 변환에 관한 구현에 몇 가지 문제가 있습니다.
꼭짓점의 샘플링 좌표가 클리핑 공간 좌표로 프래그먼트에 직접 전달되는 줄 알고 약간 오해가 있었습니다.
그러나 이것은 사실이 아닙니다.저자가 쓴 것은 샘플링 좌표를 객체 좌표로 사용하고 MVP 변환을 수행하는 것입니다. 그런 다음 조각에 전달합니다.
그런데 이렇게 해도 별 효과가 없고 여기서 디버깅할 때 프래그먼트에 직접 return red를 썼는데 별 효과가 없었습니다.
이것은 조각이 전혀 들어오지 않았다는 것을 의미합니다. 이유는 나중에 설명하겠습니다.
그런 다음 정보를 검색하여 다음과 같은 작성 방법을 찾았습니다.
Unity5의 MetaPass - Esfog - 블로그 파크(cnblogs.com)
그중 우리와의 차이점은 주로 좌표 변환에서 찾을 수 있습니다.
여기서는 패키지 함수를 직접 사용합니다. 매개변수는 정점 좌표와 2개의 uv이며, 2개의 내장 항목이 있습니다.
구현 코드 찾기
여기서 EDITOR_VISUALIZATION이라고 하는 것을 정의하지 않았으며 위 링크에서 언급한 것처럼 여기에 두 개의 분기가 있습니다.
실제로 x는 우리가 선택한 정적 GI를 나타냅니다. y 구성 요소는 동적 GI를 나타냅니다.
여기서 두 개의 uv는 실제로 하나는 정적이고 다른 하나는 동적임을 의미합니다.
따라서 여기에서 첫 번째 분기에 들어가고 내부 작업은 실제로 우리와 동일합니다. 유일한 차이점은 마지막에 MVP 대신 VP 행렬을 곱해야 한다는 것입니다.
위에서 조각으로 돌아가서 빨간색을 직접 쓰면 아무런 반응이 없다고 했는데 사실 이것은 M 행렬의 곱셈과 관련이 있습니다.
M행렬 출력은 디버깅 후 영행렬이어야 한다고 생각해서 위와 같이 곱한 후에는 아무것도 없기 때문에 모두 검은색으로 나오는 것도 MVP 곱셈을 설명할 수 있다.
그러나 실제로 M 행렬을 디버깅한 결과 그렇지 않은 것으로 판명되었습니다.
이 작업을 먼저 수행하는 것을 잊지 마십시오. 너무 이상합니다.
돌아가서 renderdoc 디버깅 배우기
여기 거친 금속의 경우 실제로 자체 색상의 반사 효과가 더 분명하므로이 점은 표준에서 보완됩니다.
이전에 달성한 효과에 대해 여기에서 또 다른 질문이 제기되는데, 이는 빛을 베이킹한 후 표면 세부 사항에 관한 것입니다.
주된 이유는 베이킹할 때 표면의 정점 정보에만 신경을 쓰고 조명 결과를 가져오므로 세부 사항에 대한 법선 성능이 손실되기 때문입니다.
따라서 세부 정보를 복구하려면 정상적인 정보를 고려해야 합니다.
이 격차는 별 반이 아닙니다.
여기에서 Directional을 켜는 방법은 약간의 개선이 있지만 그다지 크지는 않습니다. (위 사진 오른쪽이 개선됨)
주된 이유는 여기에서 라이트맵 샘플링 주파수가 충분하지 않기 때문입니다.샘플링 주파수가 충분히 높으면
(또한 위에서 직접광은 고려하지 않고 간접광을 베이크해서 노멀 디테일이 확연히 드러나지 않는 것이 정상입니다.)
이 방향을 켠 후 그래프를 하나 더 생성합니다.
이전에는 라이트맵이 장면의 특정 위치에서 받은 빛의 강도를 기록한 다음 이를 간접광의 색상 밝기로 직접 사용했습니다.
하지만 이제 위의 라이트맵과 일치하는 맵이 하나 더 생성되고 여기에 강도가 기록되고 일반적인 방향 정보가 여기에 추가됩니다. 왜냐하면 결국 그것은
간접 조명에는 정확한 방향이 없습니다.
그런 다음 빛의 일반적인 방향으로 음영 지점에 대한 주변광을 샘플링할 때 법선을 고려하는 확산과 유사한 음영 계산을 수행할 수 있습니다.
물론 빛의 방향은 대략적으로 흐려짐은 필터링을 의미하고 평균은 평균이므로 효과가 약간 향상되지만 그다지 강하지는 않습니다.
그래서 여기서는 지배적인 빛이 있을 때 결과가 더 좋아진다고 합니다.
항상 그렇듯이 관련 컴파일 지침을 먼저 고려하십시오.
여기서 놀라운 점은 데이터 및 샘플링 상태를 포함하는 텍스처 변수에 관한 것이며 후자는 일부 필터 모드 등을 포함할 수 있습니다.
일반적으로 텍스처는 둘 다입니다. 그러나 때때로 우리는 절약을 위해 하나만 유지하는 것을 고려할 수 있습니다.
여기서 방향성 및 강도의 샘플링 방법이 정확히 동일하기 때문에 단일성은 전자를 생성할 때 샘플링 상태를 생성하는 데 도움이 되지 않았습니다.
이때 동일한 샘플링 상태를 강도로 사용해야 합니다. 그런 다음 여기에 사용된 함수가 변환됩니다.
자체적으로 샘플링 상태가 없기 때문에 누구의 샘플링 상태를 사용하고 있는지 명확하게 표시해야 하므로 여기서 매크로를 변경하고 추가 매개변수를 전달합니다.
그것을 얻은 후에는 몇 가지 디코딩 작업과 다른 단위 길이 문제가 있으며 이러한 모든 Unity 기능이 우리를 위해 해결했습니다. 직접 호출하십시오.
전에는 어리석었고, 사용하기 전에 직접 비교해보니 당연히 효과가 없다.
여기에 이 법선을 적용한 후 실제로 훌륭한 최적화를 볼 수 있지만 직접 조명과 비교할 때 여전히 약간의 차이가 있습니다.
효과는 점점 좋아지고 있으며 문제는 하나씩 해결됩니다. 이제 여기서 다시 문제가 발생합니다.
베이크 라이트의 영향을 전혀 받지 않는 동적 개체에 관한 것이므로 베이크 라이트와 이 동적 개체가 장면에 있을 때
이 동적 개체는 약간 적절하지 않습니다. 극단적인 상황이 위에 나와 있습니다. 즉, 베이크 라이트만 있을 때 동적 개체는 바로 검은색입니다.
여기에서 동적 조명에 주변광을 추가하기 위해 프로브, 라이트 프로브가 사용됩니다.
과거에는 주변광의 계산이 현재 오브젝트 주변의 전역 환경 데이터를 기반으로 했지만 이제는 프로브를 사용하여 계산되며 주변 환경의 빛 정보가 프로브에 저장됩니다.
빛을 흡수하는 것으로 이해할 수 있으며 주변 환경의 빛을 흡수한 다음 동적 물체를 비춥니다.
이 프로브는 구형 고조파를 사용하여 만들어집니다.
다음은 프로브에 대한 몇 가지 기능입니다.
예를 들어 여기에 언급된 각 프로브는 분할된 다음 위치에 따라 구면 조화 함수를 보간하고 동적 개체를 점으로 취급합니다.
————————————————————————————————————————————————— —————————————————————————————————————————————————
표현
이전에 베이크된 효과의 간접광에는 많은 제한이 있습니다.
완전 실시간 및 완전 베이크 모두 고유한 제한 사항이 있습니다.
여기서 주로 간접광은 베이크 라이트가 소유하지만 실시간 라이트는 소유하지 않는다고 합니다. 그리고 그녀는 좋은 결과를 가져올 수 있으므로 결합을 고려하십시오.
이것은 실제로 가능합니다.
위의 설정 하나만 수정하는 것으로는 충분하지 않으며 조명 자체에도 설정을 지정해야 합니다.
빛의 모드를 혼합으로 변경하십시오.
여기서 이전 인지 오류를 수정하기 위해 모든 간접 조명이 이전에 구워진 것으로 생각했는데 이는 큰 실수입니다.
우리 장면에서 유일한 조명 모드는 베이크이기 때문에 이 평행광이 베이크되는 것이 분명합니다.
모두 bake의 간접광으로 간주되는 이유는 쉐이더에서 계산할 때 라이트맵을 샘플링한 결과를 indirect.diffuse에 할당하기 때문입니다.
사실 이 지점만 보면 간접광만 베이크하는 것 같지만, 전류 패스에서 직접광 계산 결과가 0인 것은 고려하지 않는다.
빛은 굽도록 설정되어 있기 때문에 직접 빛을 계산할 때 고려하지 않습니다.
따라서 모든 조명이 구워집니다.
하지만 조명 모드를 혼합으로 변경하면 간접 조명만 베이크할 수 있으며 직접 조명 부분은 실시간으로 계산됩니다.
따라서 간접광 부분에 대해서는 위의 라이트맵을 어둡게 하는 효과가 있습니다.
이때 문제가 다시 발생하고 그림자의 페이드 효과가 유효하지 않으며 그림자 거리를 줄여 더 명확하게 관찰할 수 있습니다.
주된 이유는 Unity가 이 그림자 계산에 대한 몇 가지 사항을 업데이트했기 때문입니다.
이전에 그림자 작업은 3부작이었습니다 먼저 좌표 변수를 만든 다음 좌표 변환을 수행하고 마지막으로 그림자 맵을 샘플링했습니다.
이제 처음 두 개의 매크로가 변경되었습니다. 위와 같은 형태가 되며,
여기에 주목할만한 점이 있습니다. 업데이트 후 평행광의 화면 공간 그림자 좌표만 보간기에 입력됩니다.
또한 라이트맵의 좌표는 섀도우 마스크에 사용됩니다. 여기에서 라이트맵의 좌표를 제공해야 합니다.
또한 여기에 버그가 있으므로 Interpolator를 초기화해야 합니다.
이제 우리는 이 그림자를 관찰합니다. 여전히 페이드 효과가 없습니다.
주로 실시간 조명과 베이크된 라이트맵 효과를 동시에 사용하는 혼합 모드이기 때문입니다.
아니 우리가 직접 작성해야지 다행히 렌더링 지연시 관련 내용을 이미 작성해두었기에 여기서 직접 값을 할당하고 약간의 수정을 가할 수 있다.
마지막으로 위의 매크로 정의가 필요할 때만 이 페이드를 수동으로 수행하면 되므로 판단을 추가하십시오.
여기에서 간접 굽기가 비용이 많이 들기 때문에 새로운 모드인 섀도우 마스크가 도입되어 간접광도 굽습니다.
그리고 실시간 직사광선.
전자가 하는 일: 모든 개체에 대해 정적 및 동적에 관계없이 실시간으로 진행됩니다. 그런 다음 베이크된 라이트맵에 샘플을 만들고 간접 조명 부분을 보완합니다.
위로 가다. 이 부분은 간접 조명만 있고 정적 개체에 대해서만 보완됩니다.
섀도우 마스크 모드의 경우 간접 조명과 그림자 감쇠를 라이트맵에 저장합니다.
사실 직설적으로 말하자면 빛을 저장하는 것은 필연적으로 그림자 감쇠 정보를 가지고 있기 때문에 전통적인 라이트맵입니다. 직접광의 존재를 고려하지 않은 라이트맵 역시
약간의 그림자가 있습니다. 여기 그림자입니다. 사실 간접광의 값을 기록하는 단순한 라이트맵 그래프입니다.
그런 다음 이전 화면 공간 그림자 맵과 유사한 그림인 shadowmask가 있습니다(0 또는 1인 그림).
간접 조명을 고려하지 않을 때 조명의 일반 계산, 그리고 그림자 맵을 샘플링하여 감쇠를 만드는 경우 여기서 라이트맵은 이전 조명의 일반 계산과 동일합니다.
후자는 감쇠입니다.
위의 아이디어에는 많은 오류가 있으며 모두 방귀입니다. 요약하고 정리합시다.
구운 간접광이란 무엇입니까? 구운 그림자는 무엇입니까? 객체는 구운 그림자를 어떻게 받습니까?
간접광만 고려한 장면의 경우 공과 바닥을 상상해 보십시오. 간접광만 고려한다면 사실 둘의 색상차이는 기본적으로 동일하고 볼의 바닥이 조금 더 진할 수 있습니다.
이때 전체 장면은 베이크된 간접광인 맵 에 기록됩니다.
굽는 그림자는 직사광선을 고려해야 합니다. 사실 그림자에 관해서 게임은 직접적인 그림자를 고려합니다. 즉, 직사광선에 의해 생성된 그림자입니다.
그리고 구운 그림자는 구운 빛이 있는 장면을 고려합니다 . 이때 물체에 조명을 비추는데 공이 바닥에 빛을 차단하기 때문에 바닥에 그림자가 생깁니다.
이것이 우리가 구운 그림자라고 부르는 것입니다. 이것의 한 가지 중요한 점은 베이크 라이트 여야 하며 라이트맵을 생성할 때 베이크 라이트만 고려된다는 것 입니다 .
여기서 처음에는 라이트맵이 생성될 때 베이크된 그림자가 모두 생성 되지 않는다는 질문이 있었습니다. 직접 샘플링
그림자의 결과를 얻을 수 있습니다. 그림자 영역을 기록하기 위해 0 또는 1 인 마스크 와 같은 그림자 마스크가 필요한 이유는 무엇입니까?
이 오해의 핵심은 동적 객체가 구운 그림자를 받아들이는 것을 고려하지 않는다는 것입니다.
우선, 정적 객체는 구운 그림자를 받아들이고, 그림자 영역이 모두 구워졌기 때문에 0 또는 1 인 그림자 영역 에 신경 쓸 필요가 없습니다 . 이것은 조명이 굽는 장면 입니다.
렌더링 방법. 정적 개체의 모든 색상은 샘플링에서 가져옵니다.
그러나 일단 동적 개체를 고려하면 방법이 없습니다. 베이크된 맵에는 전혀 정보가 없습니다. 샘플링할 수 없습니다.
그리고 그가 구운 그림자를 받기를 원한다면. 그런 다음 이전과 유사한 그림자 처리 방법, 즉 그림자 마스크를 준비하는 것만 사용할 수 있습니다 .
해당 영역이 베이크된 그림자 영역임을 나타냅니다. 이것은 베이크된 그림자 영역이므로 이 맵을 완전히 미리 생성할 수 있습니다.
사전 생성 후 렌더링할 때 샘플링만 하면 됩니다. 균일성을 위해 정적 개체는 받은 구운 그림자를 고려할 때 그림자 마스크 계산 도 사용합니다.
라이트맵 샘플링 대신 .
라이팅 모드: Baked Indirect - Unity 매뉴얼
이제 기사로 돌아가서 섀도우 마스크 모드에서
이 문장에서 간접 조명 및 그림자 감쇠는 라이트맵에 저장됩니다.
우선 간접광에 대해서는 의심의 여지가 없는데 여기서 언급한 감쇠 그림자란 무엇인가 사실 베이크드 섀도우, 즉 베이크 라이트에 의해 생성된 그림자가 라이트맵에 베이크된 것이다.
그런 다음 쉐도우마스크 모드에서 구운 쉐도우 형성을 위한 추가 텍스처가 생성되며, 이는 쉐도우마스크입니다.
다음은 그가 말한 내용이 약간 부정확합니다.
이 효과는 정적인 것이든 동적인 것이든 베이크된 그림자가 적습니다.먼저 그의 베이크된 그림자 정보는 라이트맵에서 얻을 수 있기 때문에 정적 개체가 적어서는 안 됩니다.
하지만 그러지 않았습니다.우리는 앞서 말했듯이 통일성을 보장하기 위해 그림자 효과는 동적 객체와 마찬가지로 섀도우 마스크 샘플링을 통해 이루어집니다.
지금까지 섀도우 마스크를 샘플링하는 작업을 수행하지 않았으므로 이 베이크된 섀도우의 효과는 전혀 없습니다.
사실 베이크된 섀도우는 라이트맵에 저장하면 안되는데, 하나는 베이크된 섀도우를 샘플링할 필요가 전혀 없기 때문이고, 다른 하나는 저장하면 라이트맵에 영향을 미치기 때문에
간접 조명의 샘플링이 영향을 미칩니다.
다음으로 이 구운 그림자 효과를 보완하기 위해 샘플링이 필요합니다.
우선 이것을 먼저 샘플링하여 bakedAtten을 구하는데, 사실 이것은 스크린 스페이스 섀도우맵과 마찬가지로 0 또는 1이며 이 값은 베이크된 섀도우의 감쇠로 사용됩니다.
그런 다음 감쇠와 결합하여 실시간 그림자의 감쇠입니다. Edge Shadow Fade에 대한 변수도 있는데 이 3가지를 종합적으로 고려하여
최종 폴오프 값입니다.
위의 문서 스크린샷에 주목하세요. 순수 섀도우 마스크, 정적 개체에는 실시간 그림자가 없고 구운 그림자만 있습니다. 이전 베이킹 간접과의 차이점에 주목하세요.
그리고 거리 섀도우맵이 있을 것입니다.
동적 개체의 경우 실시간 그림자가 드리우므로 다음과 같습니다.
여기서 말하는 것은 정적 개체가 실시간 그림자와 동적 개체의 구운 그림자에 동시에 영향을 받는다는 것입니다.
그리고 여기에 또 다른 문제가 있습니다. 구운 그림자의 경계 문제입니다.
보충: 동적 개체에는 LightMap_On 매크로가 전혀 없으므로 라이트맵을 샘플링하지 않습니다.
디퍼드 렌더링에서 쉐도우마스크를 고려할 때 사실상 하나의 쉐도우마스크 이미지만 더 저장하면 되고 나머지는 이전 쉐도우와 완전히 유사하다.
출력 gbuffer가 렌더링 대상을 사용하여 저장되고 렌더링 대상의 수가 제한되기 때문에 여기서 이후의 판단은 주로 플랫폼이 정상인지 여부에 달려 있습니다.
여기서 쓰일때는 여기서 셀렉터로 도트인데 주로 위에서 언급한것처럼 R 채널에 데이터가 저장되기 때문에 마스크 이미지는 모두 레드입니다.
관련, 여기서는 섀도우 마스크 아래 특정 빛의 섀도우 마스크를 꺼내는 것입니다. 그런 다음 감쇠로.
그러면 이 페이드에 대해서 우선 현재 패스의 광원 종류에 따라 볼의 쉐도우페이드를 계산하는데 예전 알고리즘에 따르면,
현재 조명의 직접적인 그림자 감쇠인 shadowAtten을 수정하고 있습니다.
사실 여기에 간접 그림자 감쇠를 가져온 다음 함수를 변경하여 최종 계산을 수행합니다.