In non VR mode the teleport doesn’t register when clicking beyond a certain distance from the camera.
When travelling a large distance it takes too long to get to the end point ( I mean long enough to go and make a cup of tea ). A better solution would be a set time to get from the start point to the end point regardless of the distance. 2-3 seconds ideally. This would mean that you’d be travelling faster over long distances, and slower over short distances (when inside for example).
In vr mode, after teleporting, once the destination is reached, the camera jumps forward to the nearest collision boundary. Only seems to happen in indoor spaces.
Thanks for reporting these issues. We will be working on a fix for 1. and an improvement for 2. They should be included in the next release.
I cannot reproduce point 3 or I do not understand it correctly. When you trigger the teleport (either with a controller button or with a gaze), the target position of the camera is determined as the 3D position of the clicked point except that the camera height does not change. Then, the camera is moved to the target via a straight line. If there is some colliding object on the line, the camera stops a small distance before the colliding object (so if you click on, say, a wall, the camera is moved a small distance before the wall).
For issue 2 we’ve made the speed of point-and-click movement proportional to the speed of walking configured in the Camera tab. Previously, the point-and-click speed had been a predefined constant. This should help for large exterior scenes, because they usually have much higher walking speed than the default value.
These changes will be included in the next release.
Is there any chance of having an option for the movement from start to end point to be a set time? This way if your covering long distances you’d move faster, and if you were covering short distances you’d move slower.
I’m just thinking if I have a scene where the user will be moving both long distances and short distances, short distances are going to feel a bit manic if the speed has to be set high to cater for the long distance movements.
You’re right, this is a better approach. We already thought about it after your first post, but we haven’t been sure if we would manage to squeeze it in for the next release. Eventually, we did. It has been implemented and should be released on Friday.
). A better solution would be a set time to get from the start point to the end point regardless of the distance. 2-3 seconds ideally. This would mean that you’d be travelling faster over long distances, and slower over short distances (when inside for example).