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

CollisionTracker collisionValidity is this behaviour intended? #2046

Open
fight4dream opened this issue Aug 5, 2019 · 3 comments
Open

CollisionTracker collisionValidity is this behaviour intended? #2046

fight4dream opened this issue Aug 5, 2019 · 3 comments
Projects

Comments

@fight4dream
Copy link

Environment

  • Source of VRTK (GitHub).
  • Version of VRTK (GitHub master 9e7ea2c).
  • Version of the Unity software (e.g. Unity 2019.2.0f1).
  • Hardware used (Vive).
  • SDK used (OpenVR).

Steps to reproduce

  1. Open Example Scene
  2. Search for RightInteractor, there is a CollisionTracker component
  3. the collision tracker has a ForwardingSourceValidity rule CollisionValidity
  4. look into CollisionValidity. it basically says: the game object should Not contain IgnoreInteractorCollisionTag
  5. Search for WellBase. It has IgnoreInteractorCollisionTag.
  6. Use visual studio debug mode attach to unity, and put break point in CollisionNotifier.CanEmit()
  7. Use right hand to touch WellBase. Find out that the ForwardSource game object is the RightInteractor and the rule accepted (returns true) because right hand has no IgnoreInteractorCollisionTag.
    image

Expected behavior

I expect the intention of the set up is to check whether the 'target' can be touched (emit collision event) rather than always check on the 'source'.

Current behavior

The source checking has very limited use.

@fight4dream
Copy link
Author

I just find out there should be more component involved in the set up.

  1. CollisionTracker (forwarding source validity checks the source, you can leave it blank)
  2. hook CollisionTracker.CollisionStarted to CollisionNotifierEventProxyEmitter.Receive
  3. CollisionNotifierEventProxyEmitter has a ReceiveValidity rule, the RuleSource you can select 'Colliding Source'. This will rule check against the target collider's rigidbody gameObject (or collider's gameObject if no rigidbody attached)

Two issues I can see then.

  1. the Left/RightInteractor collision tracker's Forwarding Source Validity should leave blank, because target validity (check target for IgnoreInteractorCollisionTag) is handled by subsequent components
  2. CollisionNotifierEventProxyEmitter.RuleSource is missing an enum to handle non-trigger CollisionData.

@thestonefox
Copy link
Member

I'm not sure what the issue is here?

The rule is to make sure a Collision Tracker cannot pass the message on to a Collision Notifier

Not to check if a collision can occur between two objects.

Can you provide a really simple explanation as I may not be understanding fully?

@fight4dream
Copy link
Author

fight4dream commented Aug 6, 2019

I understand that the rule is to make sure a Collision Tracker cannot pass the message on to a Collision Notifier.

I notice that RightInteractor's Collision Tracker, when collided with WellBase (with a IgnoreInteractorCollisionTag), the message is also passed on to collision notifier.

The forwarding source validity rule is to ignore interactor collision tag. Its intention is clear that any touching "target" having that tag should not emit collision message. But because it is checking the "source", interactor never had the ignore tag and collision message is always emited.

There is no trivial logic error in the touch/grab interactions because the Active Collisions Container has a ActiveCollisionValidity rule that says only accept (InteractableFacade, ClimbInteracbleFacade, ControllableJointDriveContainerTag). WellBase has not one of them so it is not touchable. yet the collision message is emitted.

@thestonefox thestonefox added this to To do in VRTK Oct 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
VRTK
  
To do
Development

No branches or pull requests

2 participants