Dependencies in the stack about react-360 HOT 3 CLOSED

OVRUI handles most of the interface with three.js. the notable exception is the Pano, Meshes. OVRUI will be in it's own GitHub repo and will be supported outside of React VR

A base of Three.js was chosen because of our desire to focus on a solution that could coexist with common libraries and because of the popularity of Three.js this was the starting point. As a small team, we decided to focus on the React side and not write another renderer.

Abstracting out Three.js has definitely not been discounted.

Additionally with this release our aim is to support WebVR, WebGL and browser adoption via a common understood paradigm - React.

Do you have any uses that you can detail where Three.js causes problems in adoption? If so what frameworks are you using.

While we do have an internal cpp runtime which is being used within Oculus with the same React VR primitives this is not ready for an Open Source release.

from react-360.

The real issue has been the stability of WebGL on a WebView, on a mobile platform. From past experience this hasn't been reliable, so using react-three on Cordova (for example) hasn't provided a great experience.

That said, I think the interfaces and primitives are fine. For example, I think this model would transpose OK to HaloJS, which provides a WebGL like native interface on DirectX. So, I guess the WebGL layer doesn't need to be a full WebView, plus three-js could be swapped out to become the native layer in a react-native app (maybe resurrect three-cpp)

from react-360.

WebVR and WebGL in browser will be the focus of this release, and thank you for the links.

We'll be working closely with the team developing Carmel and making internal changes to make sure we are running reliably across the key browsers.

from react-360.