Three.js: GLTFLoader : Normal-Tangent 테스트 모델 결과가 잘못되었습니다.

@ cx20을 작성해 주셔서 감사합니다.

더 많은 맥락을 위해 다음은 관련 정보 및 문제입니다.

• @donmccurdy 의 ThreeJS glTF 뷰어 인 donmccurdy / three-gltf-viewer # 10에서 유사한 문제를보고했습니다. 그러나 나는 이것이 뷰어가 아닌 ThreeJS의 glTF 로더의 버그라고 생각합니다. 따라서이 새로운 문제는 이전 문제보다 더 잘 배치됩니다.

• 위의 이전 호에서는 모델이 하늘을 향하는 데 사용되었지만 나중에 수평선을 향하도록 회전했습니다. 이렇게하면 위와 같이 수평선이 미친 듯이 회전하기 때문에 반사가 맞지 않을 때 쉽게 볼 수 있습니다.

• 모델 자체의 노멀 맵 사용은 KhronosGroup / glTF # 952에서 논의한 결과 올바른 것으로 확인되었습니다.

• ThreeJS의 노멀 맵 처리는 # 11315에서 질문되었습니다.

• BabylonJS는 최근에 유사한 문제가 발생하여 여기 에 수정되었습니다 . 다음 은 수정 사항이 적용된 BabylonJS의 glTF 2.0 로더의 라이브 데모입니다 .

감사합니다!

다음 줄을 추가하면 모델이 올바르게 렌더링되는 것처럼 보입니다.

materialParams.normalScale = new THREE.Vector2(-1, 1);

하지만 문제를 잘 이해하고 있는지 잘 모르겠습니다. # 11315를 이해하면 도움이 될 수 있습니다.

@donmccurdy 귀하의 조언에 감사드립니다.
normalScale을 조정하여 개선하는 것을 알았습니다.
그러나 glTF 모델이 맞다면 glTF Loader가 처리하는 것이 더 좋다고 생각합니다.

@ cx20 동의,이 수정은 이제 THREE.GLTF2Loader에 병합됩니다.

수정 중임을 확인했습니다.

Three.js + Normal-Tangent 테스트 모델 결과 :

이것은 r101과 r104 사이에서 퇴보했습니다.

https://github.com/mrdoob/three.js/pull/15749 참조 — 회귀는 의도적 인 것이며 모델에 접선을 포함하여 피할 수 있습니다.

이상적으로 우리는 이것을 완전히 해결하기 위해 mikktspace 탄젠트를 생성하기위한 JS 구현을 가지고있을 것이지만 그것은 상당히 복잡합니다.

나는 지금까지 # 15749를 몰랐습니다. 나는 이것에 의해 경계를 잃었다. 나는 우리가 적어도 런타임에 근사 할 수있는 glTF의 탄젠트를 정의하는 데 충분한 일을했다고 생각했다.

블렌더 내보내기는 기본적으로 glTF 탄젠트를 내 보내지 않습니다. 파일 크기를 줄이는 데 도움이되며 glTF의 주요 구현은 모두 탄젠트없이이 테스트를 통과했습니다. 이 변경으로 ThreeJS의 glTF 모델 대부분에 대한 노멀 매핑이 손상되었을 수 있습니다.

무슨 일이 일어 났고 왜 일어 났는지 더 깊이 이해하기 위해 모든 연결된 문제를 읽어 볼 시간이 필요합니다. 하지만 대부분의 모델이 기본적으로 해당 범주에 있다고 믿기 때문에 glTF 커뮤니티는 접선없는 모델을 다시 올바르게 렌더링하기 위해이 높은 우선 순위를 고려해야한다고 생각합니다.

다시 여는 중 😅

이 변경으로 ThreeJS의 glTF 모델 대부분에 대한 노멀 매핑이 손상되었을 수 있습니다.

나는 그것이 그다지 심각하다고 생각하지 않습니다. 우리는 항상 파생물을 사용하여 셰이더에서 실시간으로 탄젠트를 생성 해 왔으며 여전히 그렇게하고 있습니다. 우리는 이전에이 특정 테스트 모델을 수정하기 위해 발생한 해킹 ( normalScale.y *= -1 )을 포함했지만 다른 예제도 깨뜨 렸습니다. 그것이 언제 도움이되었는지, 그렇지 않았는 지에 대한 설명이 없기 때문에 저장된 탄젠트를 지원하면 해킹을 제거했습니다.이 경우 확실히 잘못되었을 것입니다. 이제 해킹에 의존하고 탄젠트를 포함하지 않는 모델이 손상되고 해킹에 의해 파손 된 모델 (탄젠트를 포함하지 않음)이 수정됩니다.

하지만 대부분의 모델이 기본적으로 해당 범주에 있다고 믿기 때문에 glTF 커뮤니티는 접선없는 모델을 다시 올바르게 렌더링하기 위해이 높은 우선 순위를 고려해야한다고 생각합니다.

위 참조. 일반적으로 접선없이 모델을 적절하게 렌더링한다고 생각합니다. 그러나 glTF 사양에 따라 mikktspace 탄젠트를 생성하지 않습니다. 내가 아는 한 JS 구현은 존재하지 않으며, 파생 기반 셰이더 구현은 단순히 "거의 충분히 좋은"근사치입니다. 이 샘플 모델은 근사치의 한계를 보여주는 의도적으로 극단적 인 경우입니다.

JS mikktspace 탄젠트 생성 구현을 갖게되어 기쁩니다. 그것은 THREE.BufferGeometryUtils에 좋은 추가가 될 것입니다. 그러나 공식 (네이티브) mikktspace 코드는 상당히 길고, 탄젠트를 생성하는 데 얼마나 많은 것이 필요한지 아직 충분히 파악하지 못했습니다.

우리는 이전에이 특정 테스트 모델을 수정하기 위해 발생한 해킹 ( normalScale.y *= -1 )을 포함했지만 다른 예제도 깨뜨 렸습니다.

다른 glTF 모델을 구체적으로 깨뜨 렸나요, 아니면 일반적인 예일까요?

야생에는 두 가지 유형의 접선 공간 노멀 맵이 있습니다. Substance Painter는 이것을 "DirectX Normals"와 "OpenGL Normals"라고 부르는데, 이것의 가장 큰 이름은 아닙니다. 차이점은 특히 y 채널이 반전되어 텍스처의 모든 녹색 채널 값이 반전된다는 것입니다. y *= -1 곱하는 것이 하나를 다른 것으로 변환하는 올바른 방법입니다. 소위 "DirectX Normals"는 왼손 좌표계를 사용하고 glTF는 노멀 / 접선 / 비탕 젠트에 대한 오른손 좌표계를 정의합니다.

내가 생각하는 것은 ThreeJS가 접선을 자동 계산할 때 노멀 맵이 반전 된 Y (DirectX) 스타일로 작성 될 것으로 예상하고 glTF에 대해 해당 채널을 뒤로 가져 오므로 반전이 필요하다는 것입니다. 그러나 접선이 제공되면 이러한 반전이 필요하지 않습니다.

mikktspace에 대한 질문은 이것과 별개라고 생각합니다. 사양이 mikktspace를 요구하고 대부분의 구현이 화면 공간 파생물을 사용하여 대략적으로 적용하는 것은 유감입니다. 두 가지가 얼마나 비슷한 지 모르겠지만 mikktspace에서 생성 된 노멀 맵은 맵의 왼손 / 오른손이 올바르게 수행되는 한 근사값으로 표시했을 때 합리적으로 잘 작동하는 것처럼 보입니다.

(작년 KhronosGroup / glTF-Sample-Models # 174에서도 이에 대한 논의가 있습니다)

특히 노멀 맵 의

노멀 벡터는 + X가 맞고 + Y가 위인 OpenGL 규칙을 사용합니다. + Z는 뷰어를 가리 킵니다.

이 문장은 모델을 접선 벡터없이 배송하여 공간을 절약 할 수 있도록합니다.

테스트 해 봅시다. 여기에서는 페인트 프로그램의 얼룩에서 비정상적인 높이 맵 (범프 맵)을 만들었습니다.

이 높이 필드를 바깥 쪽 범프로 정의 해 보겠습니다. 여기서 흰색 픽셀은 뷰어에 더 가깝고 검은 색 픽셀은 더 멀리 떨어져 있습니다.

온라인 변환기 (품질이 의심 스럽지만 잠시 후에 결과를 살펴 보겠습니다)를 사용하여 높이 맵에서 노멀 맵으로 변환했습니다. 여기에는 3D 모델, UV 좌표, mikktspace 계산 또는 지오메트리가 없습니다. 노멀 맵으로 변환 된 높이 맵입니다. 나는 glTF의 지시에 따라 온라인 변환기를 수동으로 구성해야했다. X는 맞고 Y는 위로, Z는 뷰어를 향하도록했다. 결과는 다음과 같습니다.

다시 페인트 프로그램으로 가져 와서 색상 채널을 제거하여이 벡터가 가리키는 위치를 확인합니다. 아래에서 각 색상 채널은 고유 한 회색조 이미지로 분리되었습니다. 검정색은 -1.0 , 중간 회색은 0.0 , 흰색은 +1.0 의미하는 것으로 해석됩니다.

그래서 적어도 올바르게 구성한 후에는 온라인 변환기가 glTF가 요청한 것을 수행했다고 생각합니다. 빨간색 (X) 이미지에서 오른쪽의 기울기에 흰색 픽셀 (+1.0)이 있으며 이미지의 오른쪽 가장자리에있는 X 벡터를 가리 킵니다. 빨간색 이미지의 왼쪽에서 검은 색 픽셀 (-1.0)은 이미지 왼쪽에있는 X 벡터를 가리 킵니다. 녹색 (Y) 이미지에서 범프의 상단 경사를 따라있는 흰색 픽셀은 이미지 상단의 Y 벡터를 가리 킵니다. Z 값은 가장 직관적이지 않지만 범프의 끝과 뒷판 자체는 모두 뷰어를 가리키고 모든 측면의 경사가 먼 쪽을 가리 키므로 모두 고르게 어둡습니다.

OpenGL 스타일 노멀 맵을 받아들이는 (glTF와 마찬가지로) Blender Eevee에 이것을로드하면 어떨까요? UV 맵이 회전되거나 반전되도록 배율이 조정되면 어떻게됩니까?

이것은 잘 작동합니다. 사실, 이런 방식으로 접선 공간을 정의하는 요점은 소프트웨어가 벡터에 미쳐 가도록하는 것이 아니라, 지오메트리에 관계없이 노멀 맵이 올바른 방향으로 배치되도록하여 텍스처 아티스트에게 약간의 온전함을 허용하는 것입니다.

그러나 모든 소프트웨어가 OpenGL 규칙을 사용하는 것은 아닙니다. 일부는 다른 규칙 (때때로 DirectX 규칙이라고 함)을 사용합니다. 여기서 Y 벡터는 상단이 아닌 이미지 하단을 가리 킵니다. 다음은이 형식의 내 이미지의 분해 된 Y 채널입니다. 더 밝은 픽셀은 이미지 하단을 향하는 픽셀입니다.

이러한 DirectX 스타일 노멀 맵 중 하나를 Blender Eevee에로드해도 여전히 작동 할 것으로 예상 할 수 있습니까?

아니요. 블렌더는 + Y를 예상했습니다. 수학은 틀렸고 반사 된 수평선이 사방을 돌고 있습니다.
OpenGL 스타일의 노멀 맵을 + Y 다운을 예상했던 엔진에로드하는 경우에도 마찬가지입니다.

이것이 NormalTangentTest 모델이 테스트하려는 것입니다. 각 행은 UV 좌표를 다른 방향으로 회전하여 반사가 이러한 다른 방향에서 오른쪽 위를 향하도록합니다.

프리미티브와 UV 좌표가 주어 졌을 때 고독한 프리미티브에 대한 탄젠트를 계산하는 방법과 바이 앵 젠트에 사용할 W 기호에 대한 구체적인 공식이 스펙에 여전히 필요합니다. "OpenGL 법선"및 "DX 법선"은 공식을 도출 할만큼 정확하지 않습니다. 그들은 관습을 언급 할 수 있지만, 구현 자로서 그것을 어떻게해야할지 모르겠습니다.

내가 현재하는 일은이 특정 샘플과 일치시키기 위해 MikkTSpace에서 뒤집힌 TangentW를 방출하는 것입니다.

다른 glTF 모델을 구체적으로 깨뜨 렸나요, 아니면 일반적인 예일까요?

보고 된 버그는 특히 glTF 모델과 관련이 있습니다. 즉, FBX 또는 COLLADA를 통한 머티리얼 내보내기에 대한 확신이 충분하지 않아 이러한 노멀 맵 규칙이 완전히 이해되고 테스트되었다고 말할 수있을 것입니다.

차이점은 특히 y 채널이 반전되어 텍스처의 모든 녹색 채널 값이 반전된다는 것입니다. y * = -1을 곱하는 것은 하나를 다른 것으로 변환하는 올바른 방법입니다.

감사합니다. 이것은 우리가 그것을 구현했을 때보 다 우리의 "해킹"에 대한 훨씬 더 나은 정당화입니다. 😇

사양이 mikktspace를 요구하고 대부분의 구현이 화면 공간 파생물을 사용하여 대략적으로 적용하는 것은 유감입니다.

MikkTSpace가 탄젠트를 생성하는 가장 강력한 방법이라는 사양은 맞습니다. 런타임에이를 자동으로 수행하는 것이 보편적으로 올바른 선택이 아니라고 생각합니다. 더 저렴한 대안이 특정 모델에 맞아 보인다면, 더 좋아 보이지 않는 더 비싼 것을 할 이유가 없습니다. 근사치를 허용하기 위해 사양 언어를 느슨하게 할 수 있지만 이것에 대해 강하게 느끼지 않습니다.

프리미티브와 UV 좌표가 주어 졌을 때 고독한 프리미티브에 대한 탄젠트를 계산하는 방법과 바이 앵 젠트에 사용할 W 기호에 대한 구체적인 공식이 스펙에 여전히 필요합니다.

MikkTSpace 알고리즘이 이산 식으로 표현하기가 그렇게 쉬운 지 잘 모르겠습니다 ... 표준 MikkTSpace 코드에 대한 대안을 요구하고 있습니까? 아니면 MikkTSpace 사용 지침 외에 추가 정보가 있습니까? 헉헉

원래 문제의 경우 normal.y *= -1 배율을 어딘가에 복원해야하는 것 같습니다. 이를 수행 할 수있는 세 가지 위치가 있습니다.

• (a) GLTFLoader에서 접선이없는 메시의 경우
• (b) GLTFLoader에서 모든 메시에 대해
• (c) WebGLRenderer에서 모든 메시에 대해

threejs가 실제로 DirectX 규칙을 사용하고 있고 예를 들어 Blender가 그렇지 않은 경우 (c)의 경우를 볼 수 있습니다. 하지만 빠르고 안전한 솔루션을 위해 (a)를 사용하고 싶습니다.

내가 생각하는 것은 ThreeJS가 접선을 자동 계산할 때 노멀 맵이 뒤집힌 Y (DirectX) 스타일로 작성 될 것으로 예상한다는 것입니다.

아니, three.js는 ...

three.js는 + Y가 접선 공간에 대해 "위쪽"이고 증가하는 V는 uv 공간에 "위쪽"이라고 가정합니다.

즉, three.js는 uv (0, 0)가 텍스처의 왼쪽 하단 모서리에 있다고 가정하고 glTF 사양은 왼쪽 상단을 가정합니다. 이것이 GLTFLoader 가 texture.flipY 을 false 설정하는 이유입니다. (three.js는 기본적으로 texture.flipY 를 true 로 설정합니다.)

탄젠트가 없으면 three.js는 화면 공간 파생물을 사용하여 탄젠트를 추정합니다. 체인 규칙을 사용하여 그렇게합니다. 이 계산의 가정은 접선 공간과 uv 공간이 동일한 방향을 갖는다는 것입니다.

적절하게 작성된 glTF 모델의 경우이 가정은 올바르지 않습니다. 그러나 glTF spec_을 _ 적절하게 준수하는 모델에 대해 normalScale.y = - 1 를 설정하여 보상 할 수 있어야합니다.

또한 셰이더에서 flipY 플래그를 사용하여이 문제를 자동으로 수정할 수있는 것 같습니다.

normalScale.y 이 작동하지 않으면 다른 작업이 진행 중입니다.

이 설명에 감사드립니다. 나는 우리가 앞으로 나아갈 길이 있다고 생각합니다.

또한 셰이더에서 flipY 플래그를 적용하여이 문제를 자동으로 수정할 수있는 것 같습니다.

예, glTF가 자체 탄젠트 벡터를 제공하는 경우를 제외하고는 그렇지 않습니까? 자동 계산 탄젠트에만 flipY 테스트와 y 의 해당 부정이 필요합니다.

그렇지 않은 경우 ... 내 NormalTangentMirrorTest 모델에 잘못된 접선이 인코딩되어 있음을 의미합니다. 즉, Blender glTF 내보내기 자체가 glTF 모델에 잘못된 접선을 넣는 것입니다.

편집 : 내 보낸 접선 벡터의 정확성을 확인했으며 Y 반전이 필요하지 않습니다. 필요한 경우 자세한 내용을 게시 할 수 있습니다.

그러나 올바른 조치는 자동 생성 된 접선 (제공된 접선이 아님)이 flipY 플래그와 함께 사용될 때만 normalScale.y 을 뒤집는 것 같습니다. 생각?

이전 게시물에서 속성 탄젠트가 없을 때 반전 된 법선을 수동으로 보정하는 방법을 설명했습니다. 화면 공간 파생물이 사용되지 않기 때문에 접선이 존재할 때 보상 할 것이 없어야합니다.

또한 셰이더에서 flipY 플래그를 사용하여이 문제를 자동으로 수정할 수 있다고 제안했습니다. 그러나 normalScale.y 뒤집어서 자동으로 고칠 것이라고 말하지는 않았습니다. 사용자 설정을 변경해서는 안된다고 생각합니다.

어쨌든 우리가 그 길을 가기 전에이 가설을 검증하는 것이 필수적이라고 생각합니다.

glTF 사양을 제대로 준수하는 모델에 대해 normalScale.y =-1을 설정하여 보상 할 수 있어야합니다.

올바르게 렌더링되지 않는 모든 모델에 대한 설명이 있어야합니다.

사용자 설정을 변경해서는 안된다고 생각합니다.

네, 죄송합니다. 그런 종류의 구현 세부 사항을 지시 할 의도는 없었습니다. 화면 공간 탄젠트 생성을 위해 _ flipY 플래그를 존중하는 것 _이 수학적으로 의미하는 바에 대한 오해가 없는지 확인하려고합니다.

올바르게 렌더링되지 않는 모든 모델에 대한 설명이 있어야합니다.

그것은 잠재적으로 큰 세트가 될 수있는 것처럼 들립니다. 실제로 공식 테스트 모델과 근본적으로 다른 작업을 수행하는 모델이 있지만 여전히 glTF에서 노멀 맵의 유효한 사용으로 간주 될 수 있다면 발견하는 것이 중요합니다. 테스트 모델은 정적 (변환되지 않은) 지오메트리에 대한 노멀 맵의 유효한 사용을 다루기위한 것입니다. 특히 뷰어 생성 탄젠트 벡터에 의존하여 다른 좌표계에서 모델을 구성하면서도 유효한 glTF라고 주장하는 방법은 없어야합니다.

이 문제와 밀접한 관련이 있다고 생각합니까? https://github.com/KhronosGroup/glTF-Sample-Models/issues/174

@WestLangley 지금까지 찾은 내용입니다. 기본적으로 khronos-NormalTangentTest (탄젠트 포함 안 됨)는 잘못 보입니다.

normalScale.y = -1로 설정해도 여전히 잘못되었습니다.

대신 normalScale.x = -1로 설정하면 올바르게 보입니다.

렌더링이 약간 픽셀 화되어 보이는 경우를 제외하고, 특히 금색 반사경에서는 더욱 그렇습니다. 이것은 화면 공간 근사치 또는 다른 버그의 표시로 예상됩니까?

접선이없는 다른 좋은 테스트 모델이 있으면 내 방식대로 보내주세요. 대표 샘플이 있는지 확인하고 glTF 사양에 맞지 않는 샘플이 있는지 확인하고 싶습니다.

@elalish 그 테스트 베드는 나에게 말이되지 않고, 나에게 결코 말이되지 않았고, 아마 결코 그렇게되지 않을 것입니다. 그래서 .. 설명하는 데 도움이되지 않을 것입니다.

이 예는 너무 난독 화 된 IMHO입니다. 무슨 일이 일어나고 있는지 이해하기에 충분한 시각적 자료를 제공하는 일관된 테스트 케이스가 필요합니다.

BTW, 우리는 버퍼 지오메트리를 지원하기 위해 부활 할 수있는 VertexTangentHelper (# 3511)을 사용했습니다.

@WestLangley NormalTangentTest를 더 명확하게 만드는 방법을 알았 으면합니다. 그것은 이상한 일을하지 않고 단순히 각 샘플의 방향 (UV 공간에서)을 회전시킵니다. 세 개의 열은 다른 재료를 테스트하기위한 것이며 금색 열만으로도 충분할 수 있습니다. 그 외에는 테스트 모델이 훨씬 더 간단 해지고 이러한 다양한 UV 방향을 테스트 할 수 있다고 생각하지 않습니다.

UV 회전에도 불구하고 2D 이미지로 볼 때 노멀 맵의 이미지는 벡터가 가리키는 방향에 대해 상당히 일관됩니다. 이미지의 2D보기에서 모든 반구의 오른쪽에는 높은 빨간색 채널 값이 있고 모든 반구의 위쪽 가장자리에는 UV 좌표에 관계없이 높은 녹색 채널 값이 있습니다. 이는 UV 공간에서 빨간색 (+ X)이 텍스처의 오른쪽을 가리키고 녹색 (+ Y)이 UV 공간에서 텍스처의 상단 가장자리를 가리키는 glTF 사양을 따릅니다. 이 작업을 수행하기 위해 제공된 탄젠트 벡터가 필요하지 않습니다. 일반적으로 주어진 삼각형에 대해 + U 축이 어느 방향인지에 대한 간단한 화면 공간 추정은 BabylonJS 및 CesiumJS가 수행하는 것처럼 탄젠트 및 이중 탄젠트 벡터를 계산하기에 충분합니다. 물론 ThreeJS도 마찬가지지만 아직 설명되지 않은 normalScale 축 반전이 있습니다.

glTF가 flipY 플래그를 사용하여 UV 공간에서 V 좌표를 반전시키는 혼동의 지점이 있습니다. 이미 잘 알고 있다고 생각합니다. 나는 이것이 설명되지 않은 normalScale 플립에서 역할을한다고 오랫동안 의심해 왔습니다.

이미지에 작은 베이킹 오류도 있습니다 (제 잘못입니다. 저는 몇 년 전 Substance Painter를 처음 사용했습니다). 특히 금 반구의 평평한 부분에서 약간의 대각선 이음새가 보입니다. 그러나 이것이 전체적인 효과를 손상시키지 않아야합니다. 베이크의 주요 원형 부분은 잘 나 왔으며 3D 또는 UV 좌표가 모든 방향과 접선으로 회전하는 것과 관계없이 일반 텍스처의 전체 2D 이미지에서 "위쪽"과 "오른쪽"이 일정한 효과를 잘 보여줍니다. 생략됩니다.

이는 아티스트가 텍스처 이미지를 만들기 전에 UV 또는 접선 좌표에 액세스 할 필요가 없기 때문에 3D 지오메트리가 생성되기 전에 반복되는 노멀 맵 텍스처를 제작하는 아티스트에게 중요한 효과입니다.

@WestLangley 내가 본 것 중 최고이기 때문에이 테스트를 좋아합니다. 제가 지적한 다른 테스트 모델을 사용하게되어 기쁩니다.

또한 플롯이 두꺼워집니다. 원래 테스트는 양면 재료입니다. # 17804 때문에 단면으로 시도하기로 결정했습니다. 기본적으로 여전히 잘못되었지만 이제 normalScale.y = -1로 설정하면 정답을 얻습니다.

적어도 양면을 변경하는 것이 전면의 렌더에 영향을 미치지 않는다는 데 동의 할 수 있기를 바랍니다.

@emackey 도움이 될 수있는 또 다른 테스트 모델은 용접 된 법선이있는 반짝이는 입방체와 둥근 대신 입방체 모양으로 만들도록 설계된 해당 법선

@emackey 이것에 대한 모든 작업에 감사드립니다. 대단히 감사합니다. 아티스트와 함께 발생할 수있는 다양한 문제와 극복해야 할 문제를 모두 이해합니다.

아마도 당신은 @elalish 와 함께

@elalish 이전에 이러한 문제를 해결했습니다. 한때 나는 모든 것이 잘되고 있다는 인상을 받았다. 간단한 테스트 케이스가 있으면 bisect 를 사용하여 문제가 발생한 위치를 식별 할 수 있습니다.

용접 된 노멀이있는 반짝이는 큐브와 둥글 지 않고 큐브 모양이되도록 설계된 해당 노멀 맵.

완료 : normal_map_flat.zip . Draco 팀이 작성한 탄젠트 예제를 사용하여 탄젠트 속성이없는 추가 버전을 만들었습니다.

한때 나는 모든 것이 잘되고 있다는 인상을 받았다.

모델에 접선이 포함 된 경우 모든 것이 작동하는 상태에 도달했다고 생각합니다. 그렇지 않은 경우 일반적으로 문제가 없지만 특히 UV 이음새 주변에 가능한 가장자리 케이스가 있습니다. 이 경우 사용자에게 접선을 추가하도록 권장합니다. 또는 @emackey 가 https://github.com/mrdoob/three.js/issues/11438#issuecomment -507027586에서 언급했듯이 GLTFLoader에서 normalScale.y *= -1 플립을 복원해야합니다. 정점 접선을 생략합니다.

@donmccurdy 감사합니다. 나는 오늘이 문제에 대해 시간이 없지만 여전히 평평한 큐브 측면으로 어려움을 겪고 있습니다. 빛나는 표면 ( metallicFactor: 1, roughnessFactor: 0.1 )을 갖도록 모델을 편집하면 큐브 측면의 반사가 꽤 많이 헤엄 치는 것을 볼 수 있습니다.

내 테스트 모델에서 동일한 효과를보고 있습니다. 더 나쁜 것은 Substance Painter에서 일반 베이킹을 수행하는 것과 Blender Cycles에서 베이킹하는 경우 다른 효과입니다. 각 프로그램은 자체 뷰포트에 맞게 베이크하지만 다른 프로그램에로드 할 때 혼합에 glTF가 없어도 완벽하게 평평하지 않습니다. 매우 가깝지만 평평한 표면에서 가장 작은 차이로 인해 좋은 방식이 아닌 펀 하우스 거울이됩니다.

SP 대 Blender 대 다양한 WebGL 엔진에서 삼각형의면을 가로 지르는 정점 사이에 일반 벡터 (또는 TBN 공간)가 보간되는 방식에 미묘한 차이가 있다고 생각합니다. 나는 Gimp를 사용하여 SP 베이크와 블렌더 베이크의 "차이"를 실행했고 각 버텍스에서 검은 색 (동일한 RGB 값)이 나왔지만 버텍스 사이의 공간은 매우 희미한 강도의 소용돌이 차이를 보여줍니다.

나는 미묘한 펀 하우스 효과를 기대할 것이지만 현재 얻고있는 것은 아니다 (접선 없음 버전).

with tangents 버전은 실제로 더 좋지 않아 이것이 실제로 유효한 glTF인지 궁금해합니다.

@emackey @donmccurdy가 제공 한 이러한 모델 중 하나 또는 둘 모두가 실제로 유효한 glTF인지 여부를 말할 자격이 있다고 생각하십니까? 그렇다면 큰 문제가 있다고 생각합니다.

이 특정 큐브는 내가 무엇을 말해야할지 또는 물리적으로 사실적인 반사가 공정한 기대인지 알 수없는 극단적 인 예입니다. 노멀 맵은 메시의 전체 표면을 변형시키는 것이 아니라 범프 및 움푹 들어간 부분과 같은 세부 사항을 추가하기위한 것입니다. 접선이 올바르게 읽히거나 생성되는지 테스트하는 매우 효과적인 방법이었습니다. 나는 normalScale.y *= -1 변경이 그것을 고치기에 충분하지 않다는 것을 압니다. 이것은 우리가 처음에 저장된 접선을 지원하도록 유도 한 예 중 하나였습니다.

반사는 BabylonJS에서도 거칠어 보입니다.

확인 된 유일한 문제가 NormalTangentTest에 있고 실제로 잘못 렌더링되는 모델을 사용자가 제시하지 않은 경우 여기서 변경을 보류해야할까요?

나는 여전히 normalScale.y *= -1 승수를 복원하는 것은 괜찮지 만, 문제의 예가 부족하다는 것은 그러한 극단적 인 예를 만들어야한다는 표시 라기보다는 문제가 사소하다는 표시처럼 보입니다.

확인 된 유일한 문제가 NormalTangentTest에 있고 실제로 잘못 렌더링되는 모델을 사용자가 제시하지 않은 경우 여기서 변경을 보류해야할까요?

수정 : https://github.com/mrdoob/three.js/issues/17804 는 양면 재질로 인해 실제로 무언가가 퇴보했을 수 있음을 시사합니다. 더 자세히 조사 할 가치가있는 것 같지만, 단순함과 온전함을 위해 지금은 저주받은 큐브를 그대로 두어야합니다. 😇