내 Pixel (1)에서 글리치를 확인할 수 있습니다. 그러나 아티팩트는 KHR_materials_pbrSpecularGlossiness 가 사용될 때만 발생하는 것 같습니다.

18042는 기하학적 안티 앨리어싱을 도입했습니다. 그러나 GLTFLoader 는 lights_physical_fragment 셰이더 청크의 코드를 다음으로 바꿉니다.

https://github.com/mrdoob/three.js/blob/3ba0553208cfc9113152f5f39b4036a448cf3f25/examples/js/loaders/GLTFLoader.js#L683 -L688

@toji 위 코드를 다음으로 대체하여 앱의 GLTFLoader 사본을 수정할 수 있습니까?

var lightPhysicalFragmentChunk = [
    'PhysicalMaterial material;',
    'material.diffuseColor = diffuseColor.rgb;',
    'vec3 dxy = max( abs( dFdx( geometryNormal ) ), abs( dFdy( geometryNormal ) ) );',
    'float geometryRoughness = max( max( dxy.x, dxy.y ), dxy.z );',

    'material.specularRoughness = max( 1.0 - glossinessFactor, 0.0525 );// 0.0525 corresponds to the base mip of a 256 cubemap.',
    'material.specularRoughness += geometryRoughness;',
    'material.specularRoughness = min( material.specularRoughness, 1.0 );',
    'material.specularColor = specularFactor.rgb;',
].join( '\n' );

@elalish 이 패치로 문제가 해결되지 않더라도 GLTFLoader 에 추가해야 하죠?

@ Mugen87 네, 물론입니다. Pixel 3에서도 재현 할 수 있는지 살펴 보겠습니다.

@toji 나는 Android 10이 모든 Pixel이 아닙니다 ...

드라이버 버그? 그래도 어떤 라인이 트리거하는지 잘 모르겠습니다. 기하학적 앤티 앨리어싱의 존재 / 부재는 어쨌든 그런 유형의 인공물을 만들지 않을 것입니다.

@toji 나는 또한 내

검은 하늘은 실제로 PMREM 생성이 완전히 실패했음을 의미하며, 이는 우리가 발견 한 이상한 버그와 해결 방법 ( https://github.com/GoogleWebComponents/model-viewer/pull/920) 때문입니다. 나는 이것을 r112에 넣으려고했지만 나에 의해 미끄러졌다. 그래도 OP의 버그와 관련이 없을 가능성이 있습니다.

Chrome과 Firefox 모두에서 OnePlus 5T의 OP 오류를 재현했습니다.

감사! 패치를 GLTFLoader 하고 밴딩 아티팩트가 감소했지만 제거되지 않았 음을 확인했습니다.

패치 전 :

패치 후 :

기본적으로 밴드 중 하나를 고정한 것처럼 보입니다. :) (Pixelbook에서 찍은 스크린 샷이지만 Pixel 4 XL에서도 관찰되었습니다. 현재 다른 테스트 기기는 사용하지 마세요.)

테스트하려는 다른 변경 사항에 패치를 적용하거나 로컬에서 테스트하려면 https://github.com/toji/xr-dinosaurs를 확인하십시오. (서버 구성 요소가 필요하지 않습니다.)

성능에 관해서는 : 정확히 버터 같은 것은 아니지만 나쁘지는 않습니다.

감사합니다. 😁 열심히 일했습니다. 이 경우 r112로 업데이트하는 동안 성능 회귀를 발견하고 @mrdoob 에게 그것에 대해 물었습니다. 그는 그것이 새롭고 더 정확한 표준 셰이더 일 수 있다고 제안했고 확인을 위해 일부 재질을 MeshLambertMaterial 로 교체 할 것을 제안했습니다. 어차피 환경 모델이 PBR 재질을 적절하게 구성하지 않았기 때문에 나는 그것을 Lambert에 강제로두고 거기에 남겨 두었습니다. 이것은 성능 회귀를 되찾은 다음 일부 (뷰포트의 큰 덩어리를 차지하기 때문입니다.) 표준 재료는 "영웅"자산이기 때문입니다.

참고 : 렌더러가 MeshStandardMaterial 확인하기 때문에 GLTFLoader 반사 / 광택 재질을 사용하여 메시를로드 할 때 Scene.environment 는 현재 작동하지 않습니다.

https://github.com/mrdoob/three.js/blob/dd81aad5513d66e35e51f3a3b42555bc8aef5cbc/src/renderers/WebGLRenderer.js#L1633

그러나 GLTFLoader ShaderMaterial 는 각 반사 / 광택 재질에 대해

환경 맵을 사용하지 않으면 밴딩 아티팩트를 재현 할 수 없습니다. 주변 조명 및 포인트 조명과 같은 간단한 조명 설정으로 Pixel (1)에서 모든 것이 잘 보입니다.

음, 환경 맵을 사용하는 물리적 재료에는 더 많은 문제가있는 것 같습니다. 다음 예제가 Pixel 1, Android 10에서 어떻게 보이는지 확인하세요.

https://threejs.org/examples/webgl_materials_envmaps_exr

https://threejs.org/examples/webgl_materials_physical_clearcoat

https://threejs.org/examples/webgl_materials_envmaps_hdr

내 iMac에서 이러한 인공물을 재현 할 수 없습니다.

내 컴퓨터에서 꽤 이상한 일이 일어나고 있습니다. 새로운 PMREMGenerator 를 활용하는 모든 예제에서 이러한 아티팩트를 재현 할 수 있습니다. 그러나 로컬에서 실행할 때만; 온라인으로 볼 때 (threejs.org 페이지에서) 모두 올바르게 표시됩니다.

나는 그런 문제를 경험 한 적이 없으며 그 원인에 대해 완전히 잃어 버렸습니다.

GeForce GTX 750 TI와 함께 Windows 10을 실행하고 있으므로 이것이 장치 관련 문제라고 생각하지 않습니다.

그러나 로컬에서 실행할 때만; 온라인으로 볼 때 (threejs.org 페이지에서) 모두 올바르게 표시됩니다.

dev 버전에는 아직 prod 없는 변경 사항이 있습니다. 현재 master 지점을 확인한 다음 로컬 테스트를 수행 할 수 있습니까?

현재 마스터 브랜치를 체크 아웃 한 다음 로컬 테스트를 수행 할 수 있습니까?

이 동작을 알아 차린 후 가장 먼저 시도한 것은 동일한 결과입니다. 정말 궁금합니다.

시크릿 창으로 테스트 해 주 시겠어요? 때때로 항목이 캐시되거나 브라우저 확장이 방해를 받아 정말 혼란 스러울 수 있습니다.

시크릿으로 시도했는데 동일한 결과 :(

이 밴딩이 발생하는 이유를 알고 있다고 믿습니다.
밉 생성 중에 내 로컬 (잘못된) 버전이 라이브 버전에없는 검은 색 밴드를 생성합니다.

이것은 낮은 mip 레벨에도 복제됩니다.

이것은 잘못된 좌표 샘플링으로 인해 발생할 수 있으며 이방성 필터링을 수동으로 비활성화하는 실험을 해 보았지만 문제는 남아 있습니다. 정확히 무슨 일이 일어나고 있는지 정확히 지적하기는 어렵습니다. 특히 같은 기계에서 두 가지 다른 행동을 보이는 이유를 머리로 감쌀 수 없기 때문입니다.

@elalish 여러 예제에서 몇 가지 테스트를 실행 한 후 이러한 아티팩트의 실제 원인을 정확히 찾아 낼 수있었습니다. 이전 게시물에서 말한 것과 달리 문제의 근본 원인은 잘못된 좌표 샘플링과 관련이 없지만 PMREMGenerator 이 devicePixelRatio 처리하는 방식과 관련이 있습니다.

공칭 부동 소수점 pixelRatio 에서 생성 된 텍스처에 "잘못된"밉맵 좌표가 표시됩니다. 따라서 작은 간격과 겹치는 영역이 있습니다. 또한 로컬 (0.899 ..) 또는 온라인 (1) 예제를보고 있는지 여부에 따라 내 컴퓨터가 devicePixelRatios 가 다르다는 것을 발견했으며, 이것이 바로 이러한 아티팩트를 로컬에서만 경험 한 이유입니다.

setPixelRatio 를 비활성화하여 간단한 테스트를 설정했는데 문제가 해결되는 것 같습니다. 다른 사람의 경우라면 PMREMGenerator 가 처리하는 방식으로 리팩터링하는 것이 가장 좋습니다.

@toji @ plut0nist 는 이러한 아티팩트를 제시 한 장치에서 다음 예제를 확인하고 있습니까?

DEV 예
테스트 예

@sciecode 근본 원인을

@sciecode : 내 기기에서 확인되었습니다. DEV 예제 테스트는 환경 맵에서 매우 분명한 검정색 선을 표시하지만 TEST 예제는 그렇지 않습니다. 멋진 디버깅, 감사합니다!

왜 PMREMGenerator 가 devicePixelRatio 를 계산해야하는지 매우 궁금해서 파헤 쳤습니다. renderer.setViewport() 는 DPR을 전송하는 모든 값으로 자동으로 인자하기 때문입니다. 이는 기본 프레임 버퍼가 아닌 렌더 타겟에 대해 분명히 잘못된 동작 인 것처럼 느껴지며, 그렇지 않은 정확한 픽셀 값으로 할당됩니다. 픽셀 비율을 전혀 설명하지 않습니다. 여기서 "올바른"동작은 내부적으로 rendere.setViewport() 이 getTargetPixelRatio() 사용해야한다는 것입니다. 그러면 활성 렌더링 대상이 기본값이 아닌 경우 1 를 반환합니다. 그래도 이전 버전과의 호환성 문제가 어떻게 발생할 수 있는지 확실히 알 수 있습니다.