Three.js: WebGPU 기반 렌더러가 있습니까?

이론적으로는 먼 미래에 있지만 WebGPU 그룹은 여전히 ​​첫 번째 제안 / 사양 / 초안 작성에 대해 적극적으로 논의 / 조정하고 있습니다. 완전한 사양을 갖추고 표준화 된 구현을 구현하는 데 몇 년이 걸릴 것입니다.

여기에서 WebGPU 개발에 참여 / 팔로우하는 것이 좋습니다. https://github.com/gpuweb/gpuweb/wiki 및 https://www.w3.org/community/gpu/

WebGPU가 우리 모두가 바라는만큼 강력한 것으로 밝혀지면 Three.js와 같은 라이브러리를 최대한 활용하려면 처음부터 다시 작성해야합니다.

안녕하세요.
그래, 난 동의. 나는 먼 미래가 될 것입니다.
코어를 처음부터 다시 작성하지 않고 three.js에 WebGPU 렌더러를 추가하는 것이 불가능합니까? threejs로 전체 엔진 (API)을 처음부터 다시 작성해야합니까? WebGPU가 나오더라도 한동안 공존 (WebGL / WebGPU) 할 가능성이 큽니다. WebGPU가 모든 WebGL 생태계를 죽일 것이라고 생각하지 않습니다.
그러나 WebGPU가 그래픽 드라이버의 간접 API 인 것과 달리 WebGPU가 기본적으로 & 직접적으로 지원한다면 매우 강력 할 것이라고 생각합니다.그리고 구글과 다른 거물들은 브라우저에서 더 나은 딥 러닝 성능과 고성능 그래픽 경험을 원합니다.

ThreeJS에는 WebGLRenderer, WebGL2Renderer, CSS3DRenderer, SVGRenderer ... API가 준비되면 WebGPU도 비슷하게 처리 할 수 ​​있습니다. 시간이 지남에 따라 라이브러리에 대한 더 깊은 변경도 가능합니다.

이 차세대 API도 사용할 수있게되어 기쁘지만 지금은이 문제를 마무리하겠습니다. :)

뿡뿡
과연 .. Three.js는 너무 유연해서 앞으로 WebGPU도 구현할 수 있겠죠?

WebGPU 제안에 따르면 그들은 Three.js 개발자에 대해 주요 타겟 고객 중 하나로 언급했습니다.

https://gpuweb.github.io/admin/cg-charter.html

웹 콘텐츠에 사용되도록 의도 된 GPU 라이브러리를 빌드하고 있지만 상위 수준의 API를 제공하고 사용자에게 낮은 수준의 그래픽과 계산 세부 정보를 대부분 숨기는 JavaScript 프레임 워크 개발자. 예 : three.js.

내 질문은 WHLSL이라는 다른 셰이더 언어를 사용한다는 것입니다.
https://github.com/gpuweb/WHLSL

내 질문은 WHLSL이라는 다른 셰이더 언어를 사용한다는 것입니다.

"우리가 도착하면 그 다리를 건너겠습니다."

현재 사용 가능한 OSX 용 Chrome Canary의 실험적 지원과 함께 Google I / O에서 발표되었습니다.
https://www.youtube.com/watch?v=K2JzIUIHIhc

Babylon.js는 출시 될 때이를 완벽하게 지원한다고 발표했습니다. 여기에서 확인하세요 :
https://forum.babylonjs.com/t/webgpu-is-coming-to-babylon-js/3122

ThreeJS 팀이 리드를 따르기를 바랍니다.

잠재적 인 지원이 언급되었으므로 왜 이것을 닫아야하는지 잘 모르겠습니다. 논리적으로, 우리는 문제를 "추적"하기 위해 열어 두었습니다. 닫으면 추적 할 다른 문제가없는 한 잊어 버립니다.

잊지 않을 거라고 장담 할 수 있어요 ... 😁

하지만 나는 관리자가 아닙니다. 개인적으로 webgpu를 채택한 첫 번째 프레임 워크를 따를 것입니다. 그리고 요점은 내가 아닙니다. 여러분이이 글을 닫는 메시지입니다. 그것은 "멋진 것, 확실한 것,하지만 상관 없어. 그것은 림보에 거기에있을 수있다"와 같다.

추신. 나는 그것을 잘못 읽었다. 나는 그것이 "당신이 그것을 잊지 않을 것이라고 확신 할 수있다"라고 생각했다.

@MichelDiz 이 문제는 WebGPU를 지원할 계획인지 묻기 위해 열렸습니다. 질문에 대한 답이 있습니다. WebGPU를 지원할 계획입니다. 아직 작업하기에는 너무 이르지만 논의 할 준비가되면 새로운 문제가 열릴 것입니다.

@TimvanScherpenzeel 사용자로부터 추상화 된 특정 부분은 다시 작성해야하지만 전체를 "처음부터 다시 작성"해야한다고 제안하는 것은 엄청난 과장입니다. 버퍼 도형은 동일한 형식을 갖습니다. WebGL과 마찬가지로 WebGPU는 쉐이더 GLSL-> WHLSL을 기반으로합니다. WebGL 표준이 된 glTF 형식도 WebGPU 표준이 될 것 같습니다. 가장 많이 사용되는 모든 Three.js API는 99 % 변경되지 않고 새로운 WebGPU 렌더러가 내부에있을 것이며, 바라건대 성능이 크게 향상되고 높은 fps에서 큰 장면을 렌더링 할 가능성을 열어 줄 것입니다.

안녕하세요,
이것에 대한 업데이트에 많은 감사드립니다!
이런 기능에 대한 내 관점을 공유하고 싶었습니다. 우리의 경우 소비자 애플리케이션에 항상 WebGL을 사용하는 것은 아닙니다. 자산이 ~ 1GB 인 매우 큰 데이터 세트를 시각화하고 WebGPU를 활성화하기 위해 브라우저와 플래그를 제어 할 수있는 고정 하드웨어에서 로컬로 제공되는 WebGL 경험이 있습니다. 따라서 실험 모드에서도이를 지원하고 싶을 수 있습니다. 나는 우리가 소수라는 것을 이해하지만, 대화에이 견해를 추가하고 싶었습니다.

@sinokgr WebGPU 는 1GB 자산을 표시하는 데 어떻게 도움이됩니까? 내가 이해하는 한 기하학 데이터의 데이터 구조는 WebGL과 동일합니다.

@mrdoob 답장 주셔서 감사합니다. 100 % 솔직히 말해서, 차이점을 충분히 이해하고 있으며 온라인에서 찾은 정보가 매우 모호하다고 주장하지 않습니다 (어쨌든 내 연구에 따르면). 내가 느끼는 주된 느낌은 내가 좋아하는 @DVLP 의 마지막 메시지처럼 읽은 것입니다.

큰 성능 향상을 가져오고 높은 fps에서 큰 장면을 렌더링 할 수있는 가능성을 열어줍니다.

적어도 약간의 개선이있을 것이라고 생각하게합니다. 예를 들어 이러한 자산이 얼마나 빨리로드되는지, 더 나은 fps일까요? 잘 모르겠습니다.

일반 메모리에 대한 초기로드는 동일하게 유지되지만 전체 GPU API가 더 빨라지므로 GPU가 관련된 순간부터 더 빨라질 것입니다. 성능 향상의 출처를 확인하는 방법은 다음과 같습니다.

1. 브라우저에 모델 파일로드-동일한 속도
2. 모델을 구문 분석하고 지오메트리를 배열 버퍼에로드-동일한 속도
3. GPU 프로그램로드-더 빠름
4. 텍스처로드-처음에는 속도는 같지만 GPU로 넘길 때 더 빠름
5. GPU로 지오메트리 전송-더 빠르게
6. 프레임을 렌더링하기 위해 일련의 드로우 콜을 수행합니다.

@DVLP 설명에 많은 감사드립니다. 포인트 5와 6은 많은 재료를 가진 수천 개의 물체를 가지고 있기 때문에 나에게 매우 흥미롭게 들립니다.

WebGPU가 널리 채택되기까지는 오랜 시간이 걸릴 수 있습니다. 그때까지 메시 인스 턴싱을 사용하여 전체 속도를 높일 수 있습니다.
https://threejs.org/docs/#api/en/objects/InstancedMesh

인스턴스화를 사용할 수 없습니다. 모든 개체는 @DVLP 고유

https://github.com/mrdoob/three.js/pull/20254