Skip to content
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

Portable Reconciler (Bring your own three.js) #3353

Closed
wcandillon opened this issue Sep 13, 2024 · 7 comments
Closed

Portable Reconciler (Bring your own three.js) #3353

wcandillon opened this issue Sep 13, 2024 · 7 comments

Comments

@wcandillon
Copy link

As mentioned in #3352, we tried to run the Three-Fiber reconciler directly but encountered issues while doing so.

Here's a "full" example.

We encountered runtime issues with the "advanced examples," which was surprising.

Is it possible to use the reconciler in a portable way and integrate our own Three.js runtime (the one with WebGPU support)?

In Skia, we have our own reconciler, and we pass the Skia runtime as a parameter. We never import Skia directly because people use various Skia runtimes (headless Node.js, WebAssembly, native, etc.). All these different environments are tied to different platform APIs for gestures, animations, and so on. Therefore, it's important for us to have an isolated reconciler API. Does Three-Fiber use a similar model?

We are open to exploring different approaches to this problem. Our understanding is that Three-Fiber uses a "standardized" mapping from host components to the Three.js API. If this is correct, would it be possible for someone to write a reconciler that is fully compatible with Three.js?

I’m excited to hear your thoughts.

@CodyJasonBennett
Copy link
Member

R3F is truly compatible with three.js, more specifically the one you have installed. I'm not sure where your intuition for R3F having any hard dependency or wrapping of three.js comes from, but it's misinformed. No action is needed here.

@wcandillon
Copy link
Author

wcandillon commented Sep 13, 2024 via email

@wcandillon
Copy link
Author

Thank you for your answer. We got it to work. Standard react-three-fiber and three.js version.
The only patch we have to apply is to use the web version of three-fiber instead of the native:

-  "react-native": "native/dist/react-three-fiber-native.cjs.js",
+  "react-native": "dist/react-three-fiber.cjs.js",

Isn't that cool that we are so compliant with Web APIs that we prefer to run the web version instead of the native one? ☺️

Screen.Recording.2024-09-13.at.21.37.05.mov

@CodyJasonBennett
Copy link
Member

Why do you have to target our web entrypoint instead? This is not the selling point you think it is but a massive problem that will come up again.

@wcandillon
Copy link
Author

Good point the native build should work too actually (haven't tried it). Sorry if my message caused confusion.

The idea is that for the native build to work for us we would need to instead expo-gl, expo-assets, and so on. And we are not interested in any of that. We just want to use Web APIs.

@wcandillon
Copy link
Author

wcandillon commented Sep 13, 2024

Vision Camera and Skia uses this pattern for optional dependencies in React Native (in Skia Renimated and WebGPU are optional deps for instance):
https://github.com/Shopify/react-native-skia/blob/main/packages/skia/src/external/reanimated/ReanimatedProxy.ts

If you use this pattern for expo-gl and so on, we would get into a clean situation as described in the custom canvas section for the documentation. Re-opened to make sure we're on the same page but feel free to close it if needed.

@CodyJasonBennett
Copy link
Member

CodyJasonBennett commented Sep 13, 2024

I created #3354. It is intended for expo-gl and expo modules to be optional, but now we'll specify it for this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants