Sorry but no, that is not what I’m looking for. As mentioned in the OP, I recognize that you can link an advanced dynamic texture with a mesh; in the link you sent the mesh would be the sphere. In the case of a dome I don’t see any meshes to attach to. Again, take a look at the first link in the OP to see what I mean. That is the problem I’m trying to solve.
According to the “tracking positions” part of the docs, yes you can link to a mesh or use control.moveToVector3().
In the case of tracking meshes you could create empty mesh “markers” at the locations on the surface of the dome you want to track. You’d need to convert map locations (latitude and longitude) of each point on the globe to XYZ coordinates.
You can create an empty mesh like this:
var globeMarker = new BABYLON.Mesh("globeMarker", scene);
globeMarker.position = new BABYLON.Vector3(x, y, z);
playground example; if you turn around and look at woman’s face. Say I want to track her nose; the FOV multiplier makes it lose tracking. Is there some way to change the behavior of the texture to match the FOV change?
Note, I’ve also moved your marker so it’s the same distance away as the radius of your dome, so it’s exactly on the surface and should always track perfectly.
I considered that, but I hope to use this with the webXR mode. If you have VR device or chrome mozilla webxr emulator you can see from here: https://www.babylonjs-playground.com/#14KRGG#229 that entering VR environment changes FOV back to normal.
From topics in the past it looks like FOV changes with the XRexperience helper is quite cumbersome(How to change FOV of VR Camera? - #3 by Deltakosh) so I hope to avoid that. One message there says
I’m not familiar with how webVR becomes webXR, so I’m not sure what JCPalmer mean by that statement. Does it mean its not possible to change FOV from application-side in VR mode with webXR? Do you or anyone else have any ideas?
Ping @RaananW who might have a solution on the VR/XR front but yes the actual fov of the camera can only be the one of the device hence the special multiplier on the dome.
What @JCPalmer said is totally correct - FOV is actually ignored in a WebXR camera, since the projection matrices are coming from the browser itself and not calculated by us.
You CAN calculate them yourself, but there is no guaranty as to what the results are. I haven’t tested it, but if you actually unfreeze the projection matrix of the rig cameras of the XR camera, they will be calculated by babylon and the device’s values will be overridden.
From the other replies I’ve gathered that camera.fov changes aren’t feasible with the new WebXR, so
I think I’ll stick to the dome fov changes.
This suggests that I can somehow recalculate the marker in response to the dome fov change. I took a look at the source code of backgroundMaterial/photo dome as well but I can’t seem to pinpoint how that can be done. Any idea?