-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
Add support for XR animation loop eventing into Core #668
Comments
Hi @Truemedia since you have the proof of concept with the local copy, could you help us with a PR branched from v4? I can help with the small details |
@alvarosabu Yeh definitely, and thanks I'll be ready to make a new branch tonight |
Got a forked branch I'm working on now to clean up https://github.com/Truemedia/tres/tree/feature/668-add-xr-eventing-handling The linter seems to be flagging some pre-existing stuff before I forked so just going to do git push --no-verify and double check its only flagging the pre-existing stuff. |
@garrlker Here is an initial todo list of the first steps to get the core side handling with a basic HMD (head mounted display) on a 3D environment where the user can view a scene as an immersive scene and move their head around naturally to navigate the scene.
Currently when entering immersive mode a watcher for the size height/width on the useRenderer composable is triggered causing a fatal error which crashes immersive mode as resizing the canvas is prohibited on the WebGL/WebXR spec. The solution for this is wrapping the resizing code in a if statement to safely check if the user is in immersive mode/isPresenting. Currently this is just hard coded out on my example. The code I had for this didn't seem to work but I think I can probably get it working if I take another look
Because a bunch of code around XR needs to be executed ASAP in the onMounted hook within the code for TresCanvas component for an XR based tres project we need some way of identifying that it is indeed an XR based canvas. Currently within Tres/XR the top level component of that package is which sits directly beneath TresCanvas. The way I see it we need a way to pass a boolean prop to TresCanvas for XR to indicate the canvas will be used for XR, or more ideally a way inside the TresCanvas component to detect that the child component is specifically XR, or even get the XR child component to handle all this. This true or false value then needs to be stored somewhere so that watchers around the true/false have access to where the value is store/togglable. Currently this is just a hard coded var with the value of true in TresCanvas component on my branch just to get it to run in my environment every time without fail. @garrlker I will add more points to this during the week, but these are the only 2 big issues that I know of that directly break Tres core. |
Description
Due to the way XR works while most of the code around XR functionality can sit within the @tres/xr repo, a section of code for handling an animation loop (needed specifically for XR) has to live within the main repo, similar to how is handled in R3F
https://github.com/pmndrs/react-three-fiber/blob/b15801f161fc046a70d9a9f592b3ea8e3eac3d6e/packages/fiber/src/core/index.tsx#L255
Suggested solution
I already have a proof of concept of this working with my own tweaked local copy of @tres/core incorporating this code with tres/vue specific code and just need a new feature branch to put it on and cleanup more
Alternative
No response
Additional context
Requires both @tres/core and @tres/xr modules working in unison
Validations
The text was updated successfully, but these errors were encountered: