
Show HN: A collection of useful items for building SteamVR titles in Unity 5 - thestonefox
https://github.com/thestonefox/SteamVR_Unity_Toolkit
======
strictnein
Great stuff. I'm hopefully setting my HTC Vive up tonight, so I'll be giving
this a shot very soon.

There seems to be a significant lack of simple starting points for common
scenarios in VR (and yes, I know it's very early). I'm just trying to work on
something for a field that is very outside of gaming (so there's no help for
me locally), and ramping up on all of this on your own is pretty dang time
consuming.

I've been working on prototyping some stuff for the Rift in Unity and, while
it's fairly easy to do, there's also a ton of outdated info out there already.
And I can't tell if I should just be spending more money on some basic assets
and prefabs or if there's a better route. Especially since I'm not looking to
make games.

~~~
tcdent
The ecosystem is still evolving very rapidly. Additionally, the vocal majority
of the existing Unity community aren't the most technically inclined. The
result is something akin to the front-end web development community before
Stack Overflow; essentially, lots of copypasta, not much published innovation.

I'm not sure how much of this linked library is even original; much of it
seems to be just copied from Valve. The concept of dependencies is not present
in much of what I have seen, so this isn't surprising.

Having not read any formal writing and coming from what I consider to be more
traditional systems (web dev), game dev has a lot of peculiarities. Adjusting
to the concept of the execution frame (a literal video frame) as a point of
reference for state, for example. The 10ms frame recommended by Alex Vlachos
helped me quantify this and comprehend what the frequency were programming
for, which makes something like the way keypresses are handled more sensible.

I've built two small projects in Unity, but am looking for another engine for
my next project. Today, it still probably stands as the best choice, but
Lumberyard, though riddled with bugs, is moving quickly in the right
direction. Using an alternate stack for simulation (though not necessarily
client-server) to get outside of the game loop has a lot of appeal. However,
latency and the corrective prediction techniques do not look like fun to me.

My next project involves heavier simulation, which, after programming very
simple AI in C#, has me looking to keep that codebase simple, specific and
flexible; outside of the game loop. It's likely that I'll start with the
simulation code only and add a graphical "front end" later. I can see this
being justifiable on simpler experiences, too: loading any content from the
internet will likely be less painful and faster if you pre-process it
externally.

It's still the wild west out there. The real smart people are employed by AAA
studios building proprietary engines writing really dense C++. Indie devs are
not primarily software people and Open Source gaming is a pretty sad effort.
But, since we're see more people like you and I getting interested due to the
general appeal of VR, I'm sure the shared knowledge will grow at an increasing
rate.

------
joeld42
Also don't miss the Valve OpenVR SDK, here's their "hello world" sample:
[https://github.com/ValveSoftware/openvr/tree/master/samples/...](https://github.com/ValveSoftware/openvr/tree/master/samples/hellovr_opengl)

if you want something a bit more low-level than Unity. There was one tiny
change I had to make, change "LoadTexture" to "LoadTexture_Async", there's a
couple of pull requests with the details.

I can't wait to start making vr stuff.

------
coppolaemilio
I wish to see other alternatives, Unity is not my editor of choice but it
seems like the new standard :(

~~~
Impossible
What engine do you prefer?

