Group Group Group Group Group Group Group Group Group Forums

Advanced VR Mechanics With Unity and the HTC Vive Part 1

Learn how to create a powerful, flexible, and re-useable interaction system for your HTC Vive games in Unity!

This is a companion discussion topic for the original entry at

The elephant in the room is surely “why not just use VRTK?”

Possible answers:

  1. You think it’s flawed. In which case - it would be useful to know why
  2. You think it’s important to learn the underlying SDK rather than an abstraction built on top of it. Fair enough but this point of view needs to be made explicit as there is a cost as well as a benefit.

In any case - with VRTK become the de facto library for VR in Unity - it’s odd to do a Ctrl+F and find no references to it. At the very least you should mention it’s existence and explain your reasons for not using it.

Thanks for a Great course! Looking forward to Part 2. :slight_smile:

PS. To hell with VRTK. Id rather maintain my own code, than somebody elses.

I’m all for the asset store and how it allows anyone to achieve great results easily, but to suggest that there’s no point teaching how to do these things is simply absurd! :rolling_eyes:

I’ve tolerated you asset flippers without complaint. Isn’t it fair you do the same for those of us that actually want to learn? :smiley:

Give a man a fish and he’ll eat for a day. Teach a man to fish, and well you know the rest…

Thanks for your input.

This tutorial builds upon the previous VR tutorial by showing some more advanced things that are possible simply using SteamVR and some coding. Some might say I’m reinventing the wheel here, but sometimes it’s good to take a step back see what the wheel is made out of, even if it’s just out of curiosity.

I might cover VRTK in a future tutorial though as it’s pretty handy for quickly getting stuff done. I haven’t used it since one of the first versions so I wonder what’s new!

Thanks! The next part is coming out next month. :smile:

@blackdragonbe I wasn’t criticising the fact that you were teaching to code without VRTK - simply that it was odd not to mention it - considering your audience. When a toolkit/library/whatever becomes ubiquitous then I would argue that it should at least be mentioned in passing in any tutorial - even if merely to explain why you’re not choosing to use it.

@kief - you’re being absurd and slightly rude. If one takes your argument to it’s logical conclusion then we’d all be coding in assembly. Why are you using Unity and not writing your own engine? Why are you using the Steam SDK and not pushing bytes to hardware ports?

If you want to call me an “asset flipper” then feel free but name calling doesn’t really cast your own position in a terribly positive light.

If I was reading an article on web development in Ruby, I’d expect the write to mention Rails at least in passing. If I was reading an article on machine learning then I’d expect it to acknowledge the existence of Caffe or Torch even if it wanted to start from first principles.

People need to make educated decisions on how far down the stack of abstractions they want to go. We’re not all Mel:

I didn’t mean to come off as rude. I was just playfully breaking your balls. no ill will intended. :slight_smile:

I wish I could say I didn’t expect this weak argument as response. I would’ve pre-covered myself for it if I could even find the words adequate enough to descibe how nonsensensical it was. like scripting game mechanics in unity is even remotely comparable to building an engine. I know I wouldn’t have a single chance of building an engine. but setting up physics interactions in Unity is more than well within my capabilities. and no doubt, the knowledge gained from doing so will serve in other areas of game design. Don’t be so negative.

@kief You seem to misunderstand how much VRTK does for you. It’s not a “VR construction set” - it simply removes the need to do a bunch of the tedious stuff that you’re going to need to do on nearly every VR project. There’s plenty of scope left to write code - but your efforts will be spent on what makes your game different - rather than reinventing all the bits that make it the same.

I’m sorry if you think this is a weak argument. We must have very different philosophies about development as it strikes me as fairly self-evident. If there’s a solid library for something, I use it and move on.

It’s difficult to even call VRTK a library, since it aims to handle the most top-level game mechanics. every game that uses it will feel the same. which is evident in the amount of garbage in the Made with VRTK list. After trying some of the examples, I didn’t like how a lot of it felt and through trying to please everyone, it has become bloated & unwieldly.

If Owlchemy was to share their interaction system, I might have to reconsider my stance. but VRTK is far from perfect.

I realise different people have different goals and methods of working. but your way isn’t the only way. live and let live.

@kief Sorry. My apologies. I didn’t realise you were just trolling.

Looking at that list it contains several highly regarded titles. Feel free to post your own VR portfolio for comparison.

Please keep the discussion civil and on the subject of the tutorial.
Respect the opinion of others even if yours differs, attacking each other won’t do anyone any good.


I didn’t say all of them were bad. QuiVr is actually great (no wonder it’s at the top of the list), but none of the others have any chance of making it on to my playlist. I wouldn’t go out of my way to discredit anyone’s work, but you’ve kinda put me on the spot with your steadfast refusal to accept my opinion.

Thank you so much for this tutorial!

This might be a silly question (because I’m just now learning principles of object oriented programming), but would there be any advantage of making the RWVR_InteractionController class inherit from the SteamVR_Controller class, since we end up accessing that particular method a lot? Or is there a reason why we don’t do this?


We don’t want to inherit from SteamVR_Controller for several reasons. It’s not a MonoBehaviour, but a standard class that holds all kinds of handy methods and variables to make it easier to get the input from a tracked object.
It’s meant to be used this way to make it easier for all sorts of objects to poll the device input.

Read this for more info about inheritance and when it should be used:

In our case, the interaction controller isn’t a steamVR controller, but it does use the class to call some methods and get some values out of it.

Hope that helps!


It appears that the latest Steam VR Unity plugin build (1.2.2) is breaking these scripts in some way. Any idea what significantly changed? From what I can tell I am unable to grab and hold objects with the latest plugin. The snap grab will snap the arrow to my controller, but will not stay connected. The simple grab has a similar effect.

This tutorial is more than six months old so questions are no longer supported at the moment for it. We will update it as soon as possible. Thank you! :]