VRTK_Interact_Grab NullReferenceException

Using the interact_grab script on the controller on a default steamvr 1.1.0 camera rig will yield two nullreferenceexceptions.

NullReferenceException: Object reference not set to an instance of an object
VRTK_InteractGrab.Start () (at Assets/SteamVR_Unity_Toolkit/Scripts/VRTK_InteractGrab.cs:95)
NullReferenceException: Object reference not set to an instance of an object
VRTK_InteractGrab.Update () (at Assets/SteamVR_Unity_Toolkit/Scripts/VRTK_InteractGrab.cs:395)

which is

controllerAttachPoint = transform.GetChild(0).Find("tip").GetChild(0).GetComponent<Rigidbody>();

These is quite logical when looking at the order. SteamVR initializes the models lazily so the “tip” will only be created after some frames when the model is loaded. The lookup for the attachpoint should therefore also be delayed. A better way of doing it is probably to not do it once but wrap it into a “getAttachPoint” method that does the lookup ondemand if it is not done already or got reset (think of exchanging the controller model during play).

I was curious why it works in the examples and as it seems the model hierarchy was baked into the scene. That explains the difference but will only work with the example setup and not with the pure steamvr prefab.

[thestonefox]

The reason the camera rig prefab is different is because the steam vr plugin comes with 2. The one in the prefabs folder (the one you’re referring to) and the one in the test_throw example scene with the elements there in the editor (as explained in the readme of this repo).

The camera rig prefab included in this repo is the one from the test throw scene. I need to understand why valve included two in their repo before feeling comfortable removing the prefab from this repo.

In short, your issue is being caused because you’re not using the prefab from this repo

[thestonefox]

Fixed with commit https://github.com/thestonefox/SteamVR_Unity_Toolkit/commit/aa3dcf0d90e97dd3f97b0a1de175278e0f847954