We currently have 2 movement types we switch between. One is an OrbitController derived from the OrbitControls movement by ThreeJS. The other is a self-written FirstPersonController. We switch between the 2 by a dropdown menu.
But currently, I’m walking into a problem where we still have a target in the camera, and we can’t remove it entirely so that we can use our other FirstPersonController movement logic.
Reproduction steps
Use the OrbitControls.
Set that bool to false.
Enable another movement controller.
Then you’ll see that the camera still has a target and makes it so we can’t use that new movement controller properly.
Code
Scene.instance.cameraController.orbitController.orbitControls.enabled = false;
Scene.instance.cameraController.orbitController.orbitControls.dispose();
Scene.instance.cameraController.orbitController.orbitControls.target = null; // This isn't possible to do, but is where we think the problem rises.
Scene.instance.cameraController.orbitController.orbitControls.target0 = null; // This isn't possible to do, but is where we think the problem rises.
Live example
There isn’t one, currently in a closed Development space.
Screenshots
Here you can see we’re able to use the orbit controls. But as soon as we switch, we can only still zoom to a certain target but aren’t able to look around with the camera:
This is how the FirstPersonController should act without any targets to look at:
I think it’s best if you reproduce the issue with a live example. Disabling the controls should actually be sufficient to avoid influence on the camera.
I’m afraid I won’t be able to make an example, it takes too much time to do so, and this isn’t permitted by my boss to work on. As our current project is done in Vue and Typescript and it would take too much time to convert. So I’ll have to find a solution myself, thanks tho!
I’m thinking that currently the problem is that the camera still has a reference to the target of OrbitControls for some reason. And we can’t really remove this target. So how would we fix this?
Yeah, I have. It also seems that the eventListeners are still working, which should also be disabled. But in that case, we would need to call dispose() and don’t have a way to add those even listeners again when we switch back to the OrbitControls.
When it come to orbitcontrol, I go overkill…just to be sure
posted a sample here for a full reset (target included), maybe it can help despite it’s a blind guess.
Sadly this didn’t work. Still the same behaviour. I’m considering rewriting the OrbitControls from ThreeJS and adding a regular add/remove EventListeners method. So we can even remove the .enabled.
Or just creating a whole new camera every time we switch between the 2 might work as well.
We have managed to fix the issue by creating a new camera, setting the whole instance of OrbitControls to null, and creating a new one. Every time we switched between the two movement controllers.
