View Single Post
  #8  
Old 06-06-2022, 07:31 AM
rdkirkden rdkirkden is offline
Member
 
Join Date: May 2017
Posts: 20
By trial and error, I managed to create a Vizconnect file that:

1) uses a mouse_orientation tracker for turning;
2) also uses an Oculus DK2 tracker for turning (both head and body, not just the head*);
3) turns on the spot, not in a circle.

It was necessary to use a transport (game controller thumbstick) for translational movement, as the keyboard component of a mouse_and_keyboard_walking tracker did not integrate well with the Oculus DK2 tracker. Although translational movement with the transport is associated with undesirable accelerations, it is possible to tweak the settings to minimise the nauseating effects of forwards/backwards acceleration (e.g. auto breaking drag coef = 1, acceleration = 6, max speed = 4). It is only the use of a transport for turning that really needs to be avoided, as the nauseating effects of acceleration when turning cannot be minimised by tweaking settings.

*If the HMD is only required to turn the head, this is much simpler to achieve, using just a ‘mouse_and_keyboard_walking’ tracker and no transport. I suppose this is a naturalistic set-up, where the person can turn their head to look around as they continue to walk in the direction the body is facing. But for a seated participant wearing a HMD, it can be quite difficult to precisely re-orient the head in a forward-facing direction after turning it, so that the participant often ends up moving obliquely to the direction they are facing, and this can become nauseating. Therefore, I required the HMD to turn the body in the same way as the mouse, so that the avatar always walks in the direction they are facing. This can only be achieved via a transport.

To achieve turning on the spot, not in a circle, it was necessary to make the ‘mouse_orientation’ tracker (more precisely, the group tracker that took the yaw value of the ‘mouse_orientation’ tracker) the child of the transport by switching the tracker and the transport around on the inheritance tree (see attached image). This resolved the turning-in-a-circle problem, because the mouse could now see the translational movements generated by the transport. However, walking direction (with the transport) now ignored turning with the mouse. So it was necessary to add some code to the ‘postInit’ method to set the transport’s orientation equal to the ‘mouse_orientation’ tracker’s current orientation.

Moving the mouse now changed walking direction, but for some reason that I don’t understand a mouse rotation of x degrees resulted in a walking direction rotation of x/2 degrees. It was as if the mouse turned the head at twice the rate of the body. In order to fix this, I had to use some more code to recalculate the direction in which the body was facing according to the orientations of the Oculus DK2 and mouse. This was a pretty crude hack, but I couldn’t see another way.

Code:
If body yaw <= 180:
body yaw = mouse yaw + head yaw 

If body yaw > 180:
body yaw = mouse yaw + head yaw – 360
(As the view is rotated, instead of increasing from 0 to 360 degrees, the yaw increases from 0 to 180 degrees, then changes abruptly from 180 to -180 and continues to increase from -180 to 0.)

The resulting Vizconnect program behaves well in the Vizconnect Interface. Unfortunately, it does not behave so well when I try to integrate it with my main Vizard program. It’s fine as long as my main Vizard program does not attempt to set/reset the avatar’s viewpoint. I have not managed to resolve this yet and frankly it’s looking very difficult. Anyway, I attach my Vizconnect program in case anybody finds it useful.
Attached Thumbnails
Click image for larger version

Name:	vizconnect_config_HMD - mouse_orientation - working - screenshot.png
Views:	888
Size:	380.9 KB
ID:	997  
Attached Files
File Type: txt vizconnect_config_HMD - mouse_orientation - working.txt (16.7 KB, 711 views)
Reply With Quote