Add support for XR animation loop eventing into Core

[Truemedia]

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

• [X] I agree to follow this project's Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[alvarosabu]

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

[Truemedia]

@alvarosabu Yeh definitely, and thanks I'll be ready to make a new branch tonight

[Truemedia]

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.

[Truemedia]

@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.

• Avoiding triggering renderer resizing canvas events when in immersive/isPresent mode (I'll take a look at this one)

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

• Storing XR enabled/disabled in a global state (good first issue)

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.

[alvarosabu]

I will close this since the required functionality is now self contained Tresjs/xr#33