Three.js: WebGL2렌더러

아주 좋아. :) 사실 WebGL 2와 1의 복잡성을 처리하는 방법에 대해 약간 걱정했습니다.

UBO를 사용하는 것이 좋습니다. :) 그리고 BufferGeometry만 지원하는 아이디어가 마음에 듭니다. 이는 작업을 엄청나게 단순화해야 합니다.

포워드 렌더링을 고수한다면 대부분 동일한 셰이더를 지원하는 것이 멋질 것입니다. 어떻게 생각해?

WebGL2를 사용할 수 없는 경우 비슷하지만 더 느린 것으로 대체할 수 있도록 셰이더 호환성을 유지하고 싶습니다.

@mrdoob 엉덩이 만세! 그리고 BufferGeometry 가 독점적으로 사용된다는 소식을 듣게 되어 기쁩니다. 👍

나는 UBO를 선호한다는 @bhouston 의 제안을 두 번째로 합니다.

렌더러에서 조명과 그림자 처리를 완전히 분리할 수도 있습니까? 기본값은 정말 편리하지만 조명 및 그림자 논리를 완벽하게 제어하려면 WebGLRenderer 및 co. 그들이 싸운 것처럼 느껴집니다.

그리고 내가 위시리스트 y 유형 항목을 나열하는 동안 정렬 알고리즘을 '플러그 가능'하게 만들 수 있습니까? 세 가지 범위를 벗어난 정렬 요구 사항이 있으며 현재 WebGLRenderer 에서 정렬 기능을 재정의하는 것이 불필요하게 어려운 것 같습니다. 아마도 이것은 렌더러 객체를 생성할 때 선택적 설정이 될 수 있습니까?

WebGLRenderer 1을 수정하고 BufferGeometry 개체를 제외한 모든 지원을 제거해야 하는지 거의 궁금합니다. 그것은 앞으로 더 쉬운 방법일 수 있습니다. Geometry를 BufferGeometry로 변환하는 간단한 기능이 있으면 강제로 호출하게 됩니다...

WebGLRenderer와 WebGLRenderer2 간의 기능 패리티를 유지하려고 하기 때문에 이 말을 하는 것 같습니다. 두 개를 병렬로 유지하는 것보다 단일 코드 기반을 발전시키는 것이 더 쉽습니다.

WebGLRenderer 1을 수정하고 BufferGeometry 개체를 제외한 모든 지원을 제거해야 하는지 거의 궁금합니다. 그것은 앞으로 더 쉬운 방법일 수 있습니다. Geometry를 BufferGeometry로 변환하는 간단한 기능이 있으면 강제로 호출하게 됩니다...

이미 그런 기능이 있습니다. 하지만 그렇게 간단하지가 않다...

API와 지원되는 기능을 재고할 수 있도록 WebGLRenderer2 를 처음부터 빌드하는 것이 더 낫다고 생각합니다.

Firefox 51은 이제 WebGL 2를 지원합니다. https://www.mozilla.org/en-US/firefox/51.0/releasenotes/

기다릴 수 없어!

WebGL 2.0을 지원하는 Chrome 56이 출시되었습니다!
https://developers.google.com/web/updates/2017/01/nic56

WebGLRenderer2 을(를) 앞으로 이동하기에 좋은 시간입니까? XD

WebGLDeferredRenderer2도 생성해야 합니까?

다음 주에 이 모든 것을 조사하기 시작할 계획입니다! ✌️

당신은 이미 그것을 조사할 시간이 있었을 가능성이 있습니다! 쏘우 기대됩니다! (3D 텍스처)

@mrdoob
업데이트가 있습니까?
우려되는 사항이 있으면 공유해 주세요!
상담하고 도와드리겠습니다 ;D

아직 시간이 없었습니다. 곧 곧! 😇

https://blog.chromium.org/2017/03/faster-3d-rendering-with-webgl-20.html

업데이트가 있습니까? 저는 특히 일부 의료 이미지를 볼륨 렌더링하기 위한 3D 텍스처에 관심이 있습니다. 나는 또한 이 pull request가 성공하도록 도울 의향이 있습니다.

현재 three.js webgl2 샌드박스가 작동하지 않습니다 :( https://threejs.org/examples/webgl2_sandbox.html
three.js 버전 빌드 문제일 수 있습니까?

온라인 <script type="module"> 이 이미 구현된 경우...
https://groups.google.com/a/chromium.org/d/msg/blink-dev/uba6pMr-jec/tXdg6YYPBAAJ

적어도 Mozilla는 https://bugzilla.mozilla.org/show_bug.cgi?id=1240072 에서 작업 중입니다.

@mrdoob , 이것은 WebGL 2.0으로 업데이트될 때 Three.js API가 <script type="module"> 를 활용할 수 있다는 것을 의미합니까? ;)

BTW 나는 WebGLRenderer에 WebGL 2.0 지원을 추가하는 것이 그 동안 가장 쉽다고 생각합니다. 이것은 점진적인 채택을 허용하고 WebGL 2 기능을 사용할 수 있는지 확인하기 위해 기능 감지를 수행할 수 있다고 생각합니다. 가장 어려운 일이 아닌가 싶습니다. 순수한 WebGL 2 렌더러와 대조적으로 약간의 복잡성을 초래한다는 것을 알고 있지만, 이는 중장기적으로 가장 쉬운 방법입니다. 그리고 WebGL 2가 90% 이상 채택되면 결국 WebGL 1을 남겨두는 곳에서 천천히 진화합니다.

Khronos는 webgl2에 대한 웹 세미나를 가졌습니다:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
미디어는 곧 나올 것이지만 프레젠테이션은 주로 슬라이드의 음성 해설과 슬라이드의 관련 데모였습니다.

이를 위해서는 기존 WebGLRenderer에서 "업데이트"하는 것이 아니라 새로운 시작이 필요합니다.

es6 모듈과 관련하여 현재 소스의 접근 방식은 es6 모듈이며 번들에 롤업을 사용하는 것이 여전히 "이중 빌드"를 지원하는 방법이라고 생각합니다.

저는 일주일 정도 이 작업을 수행했으며 Safari Tech Preview에서 모듈을 테스트하고 모든 브라우저에서 번들을 테스트했습니다. 실제로는 현재 번들뿐만 아니라 소스 트리도 빌드/가지고 있습니다. 현재 가지고 있는 한 줄짜리 롤업과 모듈용 소스 트리 사본.

@buston 유혹...

최신 상태?

나는 이것에 대해 어쩐지 만감이 교차한다. 처음에는 @bhouston이 제안한 것과 동일한 경로에 대해 생각하고 있었고 현재 WebGLRenderer 에 webgl2 기능을 점진적으로 추가하려고 했습니다. 그러나 그것은 렌더러를 더 복잡하고 두 버전 사이에서 가장 다른 기능을 다루기 어렵게 만들고 결국 분기와 조건 검사로 가득 찬 지저분한 코드로 끝납니다.
한 가지 옵션은 $# WebGL2Renderer 의 시작점으로 WebGLRenderer 를 복제하고 원래 렌더러를 망치지 않고 기능을 계속 제거/추가하는 것입니다.
가장 초기에 webgl2를 지원하는 Playcanvas와 같은 엔진을 살펴보면 UBO 또는 VAO와 같은 새로운 webgl2 기능을 활용하지도 않는 것을 알 수 있습니다. 엔진의 많은 부분.

동일한 렌더러에서 두 버전을 혼합하려고 하면 코드를 유지 관리하기가 더 어려워질 것이며 webgl2가 완전히 지원되는 즉시 우리는 이것을 리팩토링해야 할 것이라고 굳게 믿습니다. webgl2를 염두에 두고 처음부터 디자인하는 대신 호환성을 유지하기 위해 디자인을 따라야 했습니다.

그래서 제 투표는 속도가 느려지더라도 처음부터 WebGL2Renderer 시작하는 것입니다(webgl2가 100% 지원에 가까워질 때까지 여전히 개선의 여지가 있습니다).

렌더러 자체 이외의 일부 파일(예: 텍스처, 프로그램 등)은 수정해야 합니다. renderer\webgl2 하위 폴더를 만들고 해당 렌더러용으로 특별히 생성될 파일을 계속 추가해야 합니까?

webgl2와 완전히 호환되는 렌더러가 렌더러를 작성할 때 염두에 두도록 하기 위해 수행해야 하는 변경 목록과 관련된 문제를 생성하고 MVP가 논의에 집중할 수 있도록 하는 기능 목록을 생성할 수도 있습니다. 이 초기 상태에서 구현에 대한 더 깊은 대화를 시작합니다.

개발에 대한 업데이트가 있습니까?

아직 아님. 이번 달에는 WebVR에 우선순위를 두었습니다.

위의 @fernandojsg가 제안한 대로 WebGL2 및 ES3 셰이더 언어로 빠른 인플레이스 변환을 시도했습니다. 여기 squashed diff가 있습니다. https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 사실, 처음에 예상했던 것만큼 나쁘지는 않습니다. 전략적으로 배치된 ifdef를 통해 두 가지 모두를 지원하는 것은 거의 보기 흉하지 않은 것 같습니다.
[편집: 업데이트된 링크입니다.]

@tstanev 작업 예제가 있습니까?

연결된 브랜치에 번들된 three.js 예제가 작동 중입니다(diff에서 볼 수 있듯이 이전에 확장이 필요한 예제를 변환했습니다). repo/branch를 복제하고 로컬에서 실행할 수 있습니다.

@tstanev webgl2 변경 사항에 대한 성능 비교를 온라인으로 하는 것은 어떻습니까?) 보기 좋습니다. (webgl2의 three.js 대 three.js)

안녕
이 최고의 아이디어에 감사드립니다.
내 프로그램에서 webgl2renderer를 사용하고 싶지만 프리컴파일 버전(r86)에서는 사용할 수 없어 소스를 가져오고 three.js 가져오기에서 webgl2renderer의 주석을 제거한 다음 빌드합니다.
이제 내 코드와 예제(webgl2-sandbox)가 오류 없이 실행되지만 아무 것도 표시되지 않습니다.

편집: 파이어폭스 54와 크롬 60에서 테스트했습니다.
bufferGeometry 및 ShaderMaterial을 사용하는 내 예는 webglrenderer에서 올바르게 작동합니다.

아무도 대답하지 않아? 지금 webgl2renderer의 문제는 무엇입니까?

@MHA15 아마도 아직 생산할 준비가 되지 않았기 때문에 빌드에 포함되지 않았을 것입니다.

여러분, WebGL2Renderer 개발은 어떻게 진행되고 있습니까?
처음부터 다시 만들기로 결정한 것으로 알고 있습니다. 하지만 시간이 많이 흘렀고 이 주제를 다시 만드는 데 많은 작업이 필요하기 때문에 이 주제에 대한 개발이 다소 느립니다.

이 시점에서 @mattdesl이 https://github.com/mrdoob/three.js/issues/8125 에서 했던 것처럼 WebGLRenderer 의 복제본을 만드는 것을 재고하고 WebGL2로 변경할 수 있습니까? 그런 다음 @fernandojsg 가 말했듯이 UBO와 같은 몇 가지 새로운 기능을 기반으로 렌더러를 수정할 수 있습니다. 결국 우리는 모든 webgl 1 레거시 코드를 제거할 것입니다.

제 생각에 렌더러를 처음부터 생성하려면 엄청난 양의 작업이 필요하며 이상적으로는 몇 명의 기여자만으로 시작할 수 있습니다. 이 대화는 1년 전에 시작되었습니다. 그리고 처음부터 몇 달 동안 풀타임으로 구축할 구세주가 있는 지경에 이르지 않는 한 내년에도 같은 입장이 될 것이라고 믿습니다.

제 생각에 렌더러를 처음부터 생성하려면 엄청난 양의 작업이 필요하며 이상적으로는 몇 명의 기여자만으로 시작할 수 있습니다.

사실입니다. 하지만 그럼에도 불구하고 모든 곳에 조건문을 추가하여 WebGLRenderer 를 유지 관리하기 어렵게 만드는 것보다 쉽다고 생각합니다. 저는 지난 5년의 대부분을 WebGLRenderer 를 읽고 유지 관리하기 쉽게 만드는 데 보냈습니다.

또한 @fernandojsg 가 앞으로 몇 주 안에 이를 시도할 계획이라고 생각합니다.

대단해. @fernandojsg의 멋진 작업을 기대합니다!!

추신.. 컴퓨터 그래픽의 지평을 넓혀준 이 프로젝트의 모든 기여자에게 감사합니다. 앞으로 몇 가지 사례를 제공할 수 있기를 바랍니다.

나는 현재를 수정하는 것보다 새로운 렌더러를 처음부터 새로 만드는 것이 더 쉬울 것이라는 @mrdoob 의 의견에 동의합니다.
그가 말했듯이, 나는 다음 주에 그것을 시도하고 싶었습니다. 내 접근 방식은 화면의 간단한 상자에 필요한 것을 만들기 시작하고 이미 있는 것을 가져와서 리팩토링하는 대신 단계적으로 기능을 계속 추가하는 것입니다.
예를 들어 WebGLRenderer 의 현재 상태를 살펴보십시오. 더 모듈화되고 사용자 정의 가능하도록 만드는 것에 대한 많은 논의가 있었지만 여전히 내부 코드가 시간이 지남에 따라 계속 개선되더라도 외부에서는 그냥 블랙박스.
작업이 완료되는 즉시 PR을 열어 다음 단계에 대해 계속 논의할 수 있도록 하겠습니다.

5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox 가 다시 작동합니다(es6 모듈이 필요함).

@mrdoob 마스터/릴리스에서 언제 사용할 수 있는지 대략적인 예상이 있습니까? :) 나는 그것이 일어나고 있다는 것을 기쁘게 생각합니다! :)

@wdanilo 별로... WebGL2의 어떤 기능이 필요한가요?

@mrdoob 가장 큰 개선 사항은 Uniform Buffer Objects와 Sampler2DArray에서 나옵니다. 텍스처 배열은 알파 맵으로 마스킹된 여러 재료를 레이어링하는 복잡한 셰이더를 사용하고 있기 때문에 텍스처 단위 제한에 직면해 있기 때문에 현재 프로젝트에 매우 유용할 것입니다.

@mrdoob glsl 에서 flat 와 같은 새로운 키워드도 매우 유용할 것입니다.

내 프로젝트에는 3D 텍스처가 필요합니다.

흥미로운...
사람들이 WebGL 2.0을 필요로 하는 특정한 경우를 아는 데 매우 유용합니다.
계속 오게 해주세요!

3D 텍스처도 우리에게 큰 특징입니다. 우리는 또한 일부 셰이더 기능을 사용한다고 생각합니다.

때때로 나는 MRT를 원한다

여러 렌더 타겟에도 +1

다중 렌더 타겟은 이미 확장을 통해 WebGL1에서 지원되며, ThreeJS에 PR도 있습니다: https://github.com/mrdoob/three.js/pull/9358 ( demo ).

멀티샘플 렌더 타겟이 제가 가장 좋아하는 기능이라고 생각합니다. 대부분의 클라이언트는 사후 처리(블룸, LUT 등)를 요청하지만 사후 FX가 구현되면 적절한 앤티앨리어싱이 없다는 점에 실망합니다. MSAA 렌더 타겟을 사용하면 마침내 멋지게 앤티 앨리어싱된 _및_ 후처리된 장면을 가질 수 있습니다.

나는 동의한다. 효과 작성기가 있는 사후 처리된 장면의 앤티 앨리어싱을 위한 해결 방법 셰이더는 진정한 앤티 앨리어싱에 충분하지 않습니다.

그리기 피드백에 대해 +1. 아니면 이미 webgl1 확장으로 지원됩니까?
삼?

2017년 12월 14일 목요일 오후 9시 45분에 Kyle [email protected] 이 다음과 같이 썼습니다.

나는 동의한다. 사후 처리된 장면에서 앤티 앨리어싱을 위한 해결 방법 셰이더
진정한 안티 앨리어싱에는 효과 작성기로 충분하지 않습니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

여기에 몇 가지 사용 사례가 있습니다.

1. MRT가 필요합니다. 현재 동일한 셰이더를 4~5회 렌더링하고 다른 버퍼를 얻기 위해 속성을 변경하고 있습니다.
2. 앤티앨리어싱을 사용하여 텍스처로 렌더링하는 것은 우리에게 중요한 기능입니다. 시각화 미리보기가 포함된 "노드 편집기"를 만듭니다. 각 시각화는 우리가 무언가를 그리는 텍스처일 뿐이며 적절한 앤티앨리어싱이 없는 것은 여기서 고통스럽습니다.
3. "flat" 키워드 - 이제 float 속성을 사용하여 기하학을 인덱싱하고 있습니다. 이는 분명히 차선책입니다. uint로 인덱싱하는 것보다 더 나쁩니다. 이 속성을 꼭짓점에서 프래그먼트 셰이더로 전달하고 있으며 "flat" kwrd에 대한 지원이 부족하기 때문에 지금은 uint를 사용할 수 없습니다.
4. (작게) 3D 텍스처는 가까운 장래에 지원하고자 하는 고급 시각화에 적합합니다.

앤티 앨리어싱과 후처리를 함께 사용하는 것이 가장 중요합니다.

@mrdoob 내 상위 3개 WebGL 2 기능/사용 사례(중요한 순서대로):

1. 멀티샘플링된 렌더 타겟: 후처리에서 적절한 (MS)AA를 위한 것입니다.
2. 정수 텍스처: 서명된 디스턴스 필드와 같은 이미지 기반 알고리즘을 수행하고 DEM(디지털 고도 모델)과 같은 보다 이국적인 텍스처 기반 데이터를 사용합니다.
3. 변환 피드백: 파티클 시스템을 수행하는 데 사용됩니다.

@mrdoob 그런데 #9358 PR이 병합되지 않은 이유를 알고 있습니까? @mattalat 이 작성한 것처럼 다중 대상 렌더링을 threejs로 가져옵니다. 2년 전에 커밋되었으며 다른 변경 사항을 최신 상태로 유지하기 위해 여러 번 수정되었으며 지금까지는 없습니다 :(

SDF 모양 설명을 많이 사용하는 장면이 있기 때문에 그것에 대해 질문합니다. 각 모양은 6개의 서로 다른 출력을 출력하므로 이제 0에서 5까지의 셰이더 번호에 전달하여 6번 계산합니다. 여러 출력을 사용하는 것이 훨씬 더 좋을 것이며 단순히 5배의 성능 향상을 가져올 것입니다.

@wdanilo 아마도 적절한 시기가 아니었을 것입니다(당시 렌더러에서 움직이는 많은 것들이 있었습니다). 또한 충돌을 쉽게 일으키는 빌드가 포함된 것 같습니다. 새로운 PR을 할 사람이 있습니까?

/cc @edankwan

3D 텍스처와 멀티샘플 렌더 타겟이 필요합니다.

현재 사용할 수 있는 다른 방법이 없는 한 depthTexture.type = THREE.FloatType..을 설정할 수 있도록 사용하려고 합니다.

1 이외의 LineThickness가 Windows 및 WebGL 2.0에서 작동할 것이라는 희망이 있습니까? 그렇다면 일부 출력이 향상됩니다.

그리고 여기에서 나는 나 자신에게 대답한다. SO에서 Thickness-of-lines-using-three-linebasicmaterial을 읽고 나는 두꺼운 선이 어쨌든 미래에 기하학이 필요하다는 것을 이해했습니다.

@Richard004 이것은 WebGL 2와 아무 관련이 없습니다. 우리는 이미 이 기능 요청에 대한 PR을 가지고 있습니다. #11349를 참조하세요 👍

안녕하세요 @mrdoob 및 @Mugen87
프래그먼트 셰이더 내부의 비트 조작과 동적 배열 인덱싱이 필요합니다. 첫 번째 것은 아마도 흔하지 않을 것입니다. 그러나 CUDA 커널을 WebGL(GLSL)로 이식하려고 하고 다른 셰이더 언어는 비트 조작을 허용하지만 WebGL 1.0(GLSL)은 그렇지 않기 때문에 상관없이 필요합니다.

두 번째는 많은 개발자가 이점을 누릴 수 있다고 생각합니다. 즉, 변수가 있는 배열 요소에 액세스하는 것입니다. 현재 WebGL 1.0(GLSL)에서는 다음과 같은 프로그램이 실패합니다.

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

그러나 WebGL 2.0에서는 이것을 할 수 있습니다. 배열에서 다른 값을 가져와야 하는 루프 내부에서 종종 필요하지만 반복 루프(예: 위의 예에서 0 ~ 199)를 수행할 수 없습니다. 요소이며 정말 느립니다.

후처리의 앤티앨리어싱은 확실히 도움이 될 것입니다.

이 모든 것의 밑바탕에는 다음과 같은 질문이 있습니다. Three를 위한 새로운 아키텍처가 필요한 시점입니까?

나는 최근에 D3, 버전 4를 사용하기 시작했습니다. 완전히 재설계되었습니다. 에스6
모듈. 그리고 훨씬 더 중요한 것은 30 개의 모듈이 각각 고유한
레포. D3 아키텍처를 살펴보는 것이 좋습니다.

3에 이것이 필요하다는 말은 아니지만 다음을 고려할 수 있다고 생각합니다.
메이저 버전 범프. 부분적으로 webgl2 때문입니다. 그러나 또한 필요로 인해
하위 모듈.

예: D3 "선택" 리포지토리/하위 ​​모듈이 있습니다. 너의 기본이야
jQuery DOM 모듈이지만 DOM의 모든 자세한 정보는
기능적인 체인 디자인. 나머지를 사용하지 않고 그대로 사용할 수 있습니다.
D3.

모든 webgl을 만든 세 개의 독립적인 모듈을 사랑하지 않으시겠습니까?
장황함이 사라진다? webgl ctx/shader를 위한 여러 하위 모듈일 수도 있습니다.
관리, 버퍼 관리 등. 실제로 버퍼 지오메트리는
이렇게 많이. 부품에서 셰이더 생성도 마찬가지입니다.

그냥 생각.

@fetox74 이미 AA를 할 수 있다고 확신합니다 https://threejs.org/examples/?q=fxaa#webgl_postprocessing_fxaa

@elunty FXAAShader는 원래의 앤티앨리어싱에 비해 충분히 좋은 결과를 생성하지 못합니다. 저는 그것을 야생에서 사용했습니다.

저는 주로 VAO에 관심이 있고 해당 사양에서 가능하기를 바라는 밉맵에 글을 쓰고 있습니다.

@pailhead 관련 #8705 :윙크:

EXT_shader_texture_lod 에 대한 기본 지원을 기대합니다.
대부분의 Android 장치와 MS Edge 및 Internet Explorer에서 MeshStandardMaterial 및 MeshPhysicalMaterial 를 사용하는 동안 생성되는 아티팩트를 해결할 수 있습니다.

@mrdoob 귀하 또는 귀하의 팀에서 Threejs를 Webgl 2.0으로 업데이트할 계획이 있습니까? 이 스레드는 말 그대로 몇 년이 걸리며 다른 모든 프레임워크가 이미 진행되는 동안 실제로 변경되는 것은 없습니다. 나는 곧 어려운 결정을 내리게 될 것입니다. 우리는 아마도 바빌론이나 다른 곳으로 이주해야 할 것이고 저는 정말로 Three에 머물고 싶습니다. 나는 현대화를 위한 어떤 계획이라도 있을 것입니다.

@wdanilo WebGL 2.0이 프로젝트의 우선 순위라면 Babylon으로 마이그레이션하는 것이 좋습니다. 일부 three.js 기고자들이 작업을 계획하고 있다는 것을 알고 있지만 개인적으로 WebVR 및 아티스트 워크플로(svg 지원 등)에 집중하고 있습니다.

@mrdoob 빠른 답변에 정말 감사드립니다. three.js를 버리지 않았으면 합니다. 저는 lib가 후드 아래에서 구성되는 방식과 "게임 중심" 등이 아닌 "일반" 프레임워크라는 가정을 좋아합니다. 어쨌든, 정보를 제공하고 이를 명확하게 유지해 주셔서 감사합니다.

(다시 한 번 @takahirox 에게 감사드립니다. 이 스레드를 알고 있었습니다.) 방금 풀 리퀘스트 #13692를 했습니다. 나는 초점이 우리의 목적이 아니라 우리의 목적을 위해 잘 작동하고 있다는 것을 이해합니다.

관련 #13702

#9965 및 #12250 다음에 WebGL2 기본 분기를 만들었습니다.

레포: https://github.com/takahirox/three.js/tree/WebGL2Base
예: https://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

WebGL2.0 + Three.js를 시작할 수 있습니다.

( @yoshikiohshima 작업과 충돌해서 죄송합니다)

@mrdoob three.js/dev-2.0과 같은 WebGL2Renderer에 대한 분기를 가질 수 있습니까? 아니면 webgl1과 webgl2 사이에 여전히 많은 중복 코드가 있는데 dev에 병합할 수 있습니까?

저는 이 문제에 대한 과거 개발에 익숙하지 않습니다. @takahirox , 귀하가 취하고 있는 전략과 https://github.com/takahirox/three.js/tree/WebGL2Base에서 지원하는 전략을 요약할 수 있습니까? (그리고 다시 한 번 내 무지에 대해 유감스럽게 생각합니다) 그러나 WebGL2를 지원하기 위해 많은 중복 코드가 필요하다는 것을 알지 못했습니다. 문제는 무엇입니까?

@mrdoob three.js/dev-2.0과 같은 WebGL2Renderer에 대한 분기를 가질 수 있습니까? 아니면 webgl1과 webgl2 사이에 여전히 많은 중복 코드가 있는데 dev에 병합할 수 있습니까?

이것이 왜 새로운 분기가 필요한지 확실하지 않습니다. 중복 코드가 있는 이유는 무엇입니까?

충돌은 없어 보입니다. 이제 WebGL2.0에 대한 두 가지 요구 사항이 있습니다.

1. 전체 WebGL2.0 기능을 지원하고 최적화하기 위해 WebGL2Renderer 만들기
2. 기존 WebGLRenderer 에 webgl2 지원을 추가합니다. 그러나 우리는 WebGL2.0 기능을 완전히 지원하지 않으며 렌더러를 엉망으로 만들고 싶지 않기 때문에 WebGL2.0에 최적화하지 않습니다. 기본적으로 이것은 Three.js + WebGL2.0 + GLSL3.0의 초기 액세스를 위한 것입니다.

내 작업은 1용이고 그의 작업은 2용입니다. 중복 코드가 없고 2용 새 분기를 만들 필요도 없습니다.

@takahirox 당분간 같은 지점에서 일하는 게 나을 것 같아요.

개선하면...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

webgl2 예제는 클래스를 직접 가져옵니다(빌드 필요 없음)...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

갈등이 없어야 합니다.

WebGLRenderer 하나에서 WebGL2.0 지원을 시작한 것 같기 때문에 지금까지 내 WebGL2Base를 잊어버릴 수 있습니다.

우리는 여전히 WebGL2Renderer 구현에 대해 생각하고 있습니까?
나는 최근에 WebGL2 지원을 추가하기 위해 많은 것을 찾고 있었고 takahirox가 광산을 리베이스하기 위해 변경하기를 기다리고 있습니다. 그러나 약간의 변경을 수행한 후 WebGLTextures 개체뿐만 아니라 렌더러를 다시 작성하는 것이 정말 좋은 생각이라고 생각하기 시작했습니다. 아직 화제가 된다면 기꺼이 참여하겠습니다.

그렇게 생각합니다. 현재 WebGLRenderer 에 기본 webgl 2.0 지원을 추가하는 것은 WebGL2Renderer 에서 작업하는 동안 무언가를 갖는 것뿐이라고 생각합니다.

자유롭게 렌더러를 다시 작성하고 PR을 보내십시오(이상적으로는 단계별).

당연한 걸 묻는다면 죄송하지만 이 전체 문제를 읽은 후 반년 전 마지막 게시물과 마스터 소스 코드와 예제 모두에서 webgl2에 대한 몇 가지 참조를 찾은 후에도 여전히 잘 이해하지 못하는 것 같습니다. .

Webgl2가 Three.js의 현재 상태에서 사용할 수 있는지 궁금하십니까? (단순한 버퍼 지오메트리 메시를 렌더링하더라도) EffectComposer가 webgl2-context-enabled 렌더러와 함께 작동합니까? 렌더 타겟을 어떤 식으로든 조정해야 합니까?

물론 가장 큰 질문은 사용자 정의 패스와 함께 작곡가를 사용할 때 적절한 앤티앨리어싱을 얻을 수 있는지 여부입니다.

결국 WebGLRenderer 에 WebGL 2.0 기능을 추가한 것 같습니다.
WebGPU는 확실히 WebGPURenderer 가 필요합니다.