WebXR Movement Module Improvements

Feature requests
1

The new Movement Module features for WebXR are great but could use a few minor improvements.

Important items

  1. Option to replace Rotation with Snap turning. The new rotation controls work great, but this kind of motion can make some people sick in VR. The Teleport module has snap turning built in instead of camera rotation. It’s a lot easier for people to handle. It would be great if there were a way to replace the rotation features of the Movement Module with snap turning. I’d even go so far as to suggest that snap turning be the default and developers should have to opt in to manual rotation. Bonus: allow developers to customize the snap angles (45, 90 degrees, etc.)
  2. Option to disable sideways motion (strafing). This is another type of movement that can make people sick and it would be great if this could be deactivated. Bonus: allow separate configuration for forward/back motion vs. side to side motion.

Would be nice to have
3. Assuming a method to remove the sideways motion described in item 2, allow the rotation/snap turning controls to be attached to the same controller/thumbstick as the forward/backwards movement. This could free up the other controller for other uses.
4. Allow use of the teleport module in addition to the movement module. Obviously, the developer would have to customize the controls for one or both of these to get them working together. It would be great to use the Movement Module to move along a surface, but also be able to teleport to another part of the scene, for example: teleport from one surface to another.

Those are the items that I’ve thought of so far. I’m interested in what other folks think of these ideas and if there are other improvement that could be made to the Movement Module to make it more accessible for a larger group of users.

If you want to try out the Movement Module in VR, I have a Lab in my side project. You can adjust all of the options that are available so far. This can be a good way to nail down the values and settings you want to use before writing the code yourself. Most of the code in this lab just adapts what I found in the documentation. My code is a mess, but you can find it here if it helps.

can-lab-024
can-lab-0241038×1038 65.2 KB

Demo Video 1: https://twitter.com/vrhermit/status/1502712963479834625
Demo Video 2: https://twitter.com/vrhermit/status/1502984613232320516

3 Likes
2

cc @RaananW

3

The (truly amazing) movement feature was implemented by @syntheticmagus, so adding him to the thread as well.

Great suggestions! They all make sense IMO. Let’s see how we can address them in a future version of babylon

4

I think technically a lot of that can be done by how it was written to be extendable. To stop Strafing you can always set as zero sideways movement in a custom handler, for example.

Are you able to share your video as a playground? :smile: I could as add a checkbox for strafing.

5

I still think these ideas are worth consideration for a feature request so each developer doesn’t have to find their own workarounds for these.

The scene is part of a larger project with code being pulled in from several modules. I don’t see an easy way to recreate it in a playground. You can see most of the code for the scene in this file.

6

Yes, totally agree they are worth consideration! I see you already knew about custom configurations as you swapped handedness - I missed that you had linked to your lab on github!

  1. Snap turning. Do you mean 45 degree increments or snap to points as a list?
  2. Disabling strafing - that looks easy. For disabling forward/back same method.

Do you have a proposal for those new options for how to configure/name them?

Also, off topic, but in your lab how do you unregister window resize events?

ps: default behaviour is typically not changed to maintain backwards compatibility, so snap turning would likely be an opt-in

1 Like
7

Correct, snap turning by 45 degrees, 90 degrees etc. Basically, the same method of turning the camera that the teleport module uses (not the torus rotation during a teleport, but the stationary snap turn). That feature has a default value of pi / 8 and is customizable.

Since movement module already uses the word rotation for the free-form rotation, how about snapTurn?

  1. snapTurnEnabled : boolean - is this feature enabled?
    NOTE: turning this on could set rotationEnabled to false so both features are not enabled at the same time. Or one of these could always trump the other if they were both enabled. Personally, I think snap turning should be the detail feature with the free-form rotation being opt-in.
  2. snapTurnAngle : rotation / radian, default value of pi/8 to match the default use in the teleport module
  3. strafingEnabled: boolean - I suggest the default should be false for this one
  4. strafingSpeed : number - 0.25 of 0.5 are good values but there is a case to be made to have the default set to 1 to match the movementSpeed value and have developers change it.

Thanks for looking into this stuff!

Joe

8

ummm… I don’t. :sweat_smile: I should do something about that!

9

I forgot to correct my initial message to say that you are the one who implemented that. Thanks for answering!

10

vue exports an unMount, too - that’s what I use. if you use defineComponent with typescript can be sometimes easier (I use Vetur plugin).

1 Like