Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix/various fixes - fixes #1975 - fixes #1974 - fixes #1970 #1976

merged 10 commits into from Apr 9, 2019


None yet
2 participants
Copy link

thestonefox commented Apr 4, 2019

No description provided.

thestonefox added some commits Apr 4, 2019

fix(CameraRig): ensure TrackedPoseDriver is using correct settings
The UnityXRCameraRig had incorrect settings on the TrackedPoseDriver
component and these have now been updated to the recommended settings.
fix(Interactions): set rigidbody maxAngularVelocity to infinity
Unity sets a rigidbody maximum angular velocity to 7 mps by default
which is acceptable for most uses, however with tracking rigidbodies
to follow the angular changes of a posed controller then this max
velocity is not enough.

This manifests into an issue with using rigidbody tracking on the
object follow as the target object slowly rotating to keep up with
the source object.

The fix is to set the Rigidbody.maxAngularVelocity parameter to
infinity. This cannot be done on the Rigidbody inspector component
as Unity do not expose this parameter for some reason. Instead of
adding a new component, the BehaviourEnabledObserver has been added
to the Interactables that listens for when the InteractableFacade
is enabled and then sets the maxAngularVelocity on all of the relevant
fix(examples): prevent wind mill and floor from fading view
Due to an issue where if the headset starts in the floor it will cause
the view to fade due to the CollisionFader on the headset, so it's
easier to just exclude the floor from being able to fade the headset
as it's not likely users will be putting their head in the floor.

The Wind Mill also has an issue where the climbable mesh is a convex
collider which means the whole section even where there is no visible
mesh is considered a collider that will fade the headset, this means
that simply standing underneath the wind mill would cause the view to
fade. For the simplicity of the scene, it's easier to just ignore
the wind mill from fading the view. It also shows how it's possible
to exclude climbable elements from fading the view.
Copy link

bddckr left a comment

I can still break the shotgun. Do either one of these:

  1. Just only grab the pump. Now let go of the grab. The shotgun just moves somewhere. Additionally if you now grab the gun (not the pump) then the pump keeps in the air once you drop it. This continues forever now, so I assume the state is wrong from here on.
  2. Grab the gun (not the pump). Now use your other hand to grab the pump, too. Let go of the gun (not the pump). The gun drops down, previously it hung at the pump IIRC. Even then now you get the bug, too: Every time you now drop the gun the pump stays in the air.

Everything else looks good and works!

thestonefox added some commits Apr 4, 2019

fix(Interactions): prevent exception when attempting auto grab
The auto Grab method on the interactor and interactable was throwing
an exception due to the attempt creation of an ActiveCollisionContainer
was failing as the event data list was empty yet it was trying to set
the first element on a list.

This fix simply checks to see if the list is empty and if it is then
adds a default entry that can be set by the creation logic.
fix(examples): ensure InputAxisCreator prompt settings are per project
The InputAxisCreator prompt would not display in a new project if an
existing VRTK project had been created locally and the `Do not prompt
again` option had been checked. This is because the key was being saved
into the `EditorPrefs` which meant that the Unity editor would persist
that key across any project.

This fix introduces a GUID check for the `Assets/VRTK` directory to
make sure the key is unique per project. This has an issue that if
the `VRTK.meta` file is deleted, then a new GUID will exist and the
prompt will display again, however it's unlikely the `VRTK.meta` file
will be deleted so it's an acceptable side effect.
chore(Dependencies): update Zinnia submodule to latest head
Latest Zinnia changes bring the ability to provide a custom rotation
origin to the TransformEulerRotationMutator.
fix(CameraRig): use updated position mutator property on simulator
The TransformPositionMutator property for dealing with the direction
to move the Target has been updated in Zinnia from `RotationalOffset`
to `FacingDirection`.

As the SimulatedCameraRig used this property previously, it means the
setting had been deleted due to the property name change. This fix
adds the references back in.
fix(examples): ensure axis rotation uses headset as rotation origin
The axis rotation locomotion now uses the new rotation origin property
on the TransformEulerRotationMutator to ensure when the play area is
rotated that it rotates around where the user is standing (i.e. the
headset location).

Because the rotation origin must be a child of the target, a new
object follower proxy has been set up that is a child of the playarea
alias and simply follows the position of the headset alias.
fix(Interactions): ensure directional drive works in local space
The DirectionalTransformDrive would not work if it was nested to
another interactable object and the MoveToTargetValue was true
because the TransformPropertyApplier would always work in world space
which meant the drive was never calculating the correct position.

Now it's possible to work in local space which resolves this issue.

The directional and rotational drive also had an issue where they
would re-enable the rigidbody kinematic state when ungrabbed due to
the default behaviour of the Interactable. This has been configured
to never emit the rigidbody kinematic change events for either drive
as they should not be changing the kinematic states.

The Interactable Consumer Rigidbody can also now be null and the
relevant code that uses it will perform a null check. This won't
work for nested interactables because there will be no collision
catch rigidbody, however if a non-nested interactable is required
without a kinematic rigidbody, then this should allow for that.
feat(examples): use transform drive in shotgun
The shotgun prefab in the example scene now uses a
DirectionalTransformDrive instead of the DirectionalJointDrive as it
creates fewer issues than using a nested physics joint but still
gives the same effect of being able to pump to reload.

bddckr approved these changes Apr 9, 2019

@thestonefox thestonefox merged commit c4c0485 into master Apr 9, 2019

@thestonefox thestonefox deleted the fix/various-fixes branch Apr 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.