-
-
Notifications
You must be signed in to change notification settings - Fork 35.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Provide a WebGPU build that re-exports from three #29156
Comments
+1 from me. Besides the missing exports, I think what also should be clarified is how libraries are supposed to start adding support for WebGPU – not everyone will be able/willing to provide/maintain separate bundles for webgl vs. webgpu. That unclarity includes three.js examples themself – an example:
|
+1 from me as well but there is a forum topic which suggests that this might not be happening. |
My feeling here would be that we may need to work out a way for GLTFExporter not to import a renderer. Either to require pre-processing the scene, or specifying some configuration on the exporter that provides a decompress implementation or renderer. |
How about doing something like this: const exporter = new THREE.GLTFExporter();
exporter.setTextureUtils( utils );
|
To clarify the proposal in this issue with regards to the forums post
In my mind this issue is not in opposition to having another WebGPURenderer build that does not contain WebGLRenderer exports, this would primarily support use cases where bundlers are not used. However, using that same build for bundler use cases is problematic, which is why this issue is asking for the Something we can anticipate will be common during the transition period is libraries exporting both WebGLRenderer and WebGPURenderer versions of utilities. Without the proposed change, libraries cannot easily do this. |
How does this work? Does the project need a specific configuration in its |
I imagine we could approach changing
|
How about we introduce a new package? Package We'd have to figure out how to publish two packages from a single repo... Then, maybe in 10 years (😶)... We could make both the same? /cc @sunag |
I think that would force each thing in the ecosystem to also provide multiple packages, instead of being able to support "three" with WebGL and WebGPU with one ecosystem package... My opinion is that re-exporting with WebGPU, making sure the code in three supports both systems, and providing examples for how third-party code supports both systems would be better. |
Yes, I am worried If we had no other solution, then publishing two versions (not two packages) under The suggestion from @isaac-mason sounds workable to me, @mrdoob do you have |
Another idea is re-exporting from |
I like @CodyJasonBennett's proposal in #29404. Possibly related... do we need/want the |
Description
When using the WebGPU build introduced in r167 with vite, using recommended aliases configuration, I am unable to use renderer agnostic exports from libraries that also have webgl imports. Bundlers will have errors attempting to import webgl specific imports that are not exported by the webgpu build.
Solution
If the three/webgpu build re-exported from three, aliases would not be required to use the webgpu build with bundlers, and libraries could export both webgl and webgpu utilities that import from both three and three/webgpu.
Alternatives
A build that has both webgl and webgpu exports could solve some issues, but this is not as desirable as the proposed solution as bundler aliases would still be required to prevent duplication issues.
Additional context
https://twitter.com/onirenaud/status/1824688713542341119
The text was updated successfully, but these errors were encountered: