Monday, December 8, 2014

Gear VR now on sale + some good articles

Looks like the Samsung Gear VR has just gone on sale!
http://www.samsung.com/us/mobile/wearable-tech/SM-R320NPWSXAR

Unboxing by Road to VR:
http://www.roadtovr.com/samsung-gear-vr-unboxing-includes-bonus-case-video/

Q&A with Samsung VP Nick DiCarlo:
http://www.engadget.com/2014/12/08/samsung-gear-vr-launch-faq/

Tom's Hardware: "Samsung Gear VR Suddenly A Real Thing, Yours For $200"
http://www.tomshardware.com/news/samsung-gear-vr-available,28178.html

Road to VR's Gear VR Review Part 1:
http://www.roadtovr.com/samsung-gear-vr-review-part-one-design-comparison-to-oculus-rift-dk2/

Rifty Business: I WANT TO SHOW EVERYONE
http://riftybusiness.com/2014/12/gear-vr-first-impressions-want-show-everyone/


It will be very interesting to find out what Samsung & Oculus learn from this product, and how that translates into improvements for the next one (and for the Oculus Rift).

Thursday, December 4, 2014

Titans of Space (Gear VR) - Recent Optimizations


I mentioned in my previous post that I removed sterescopic 3D in favor of player comfort and a few bells and whistles.   I then updated the post stating that I was able to provide an option to enable a 3D cockpit.  This post goes into some detail.

When I first started out with Titans of Space, it was using a layered camera system to render the cockpit on top of everything else outside of it.  This made things easy re: depth precision, and keeping the player at the origin.   Then, when working on the Gear VR port, I discovered that there were some performance issues with using multiple cameras and received advice to take a different approach.   The result was a single camera rig and carefully fitting the scale of everything into just that one view, and taking care of floating origin, etc.

As is, enabling full sterescopic 3D in Titans of Space for Gear VR results in less than 60 FPS and thus unacceptable judder for large objects that are moving across the player's view (such as planets). Note that for Gear VR apps where the player remains stationary and there isn't a lot of movement through the scene, async timewarp comes to the rescue and it will remain completely playable at less than 60 FPS with smooth headtracking.

Now that some time has passed with the Oculus Mobile SDK maturing enough to see a public release, and with newer & faster generations of hardware (the Note 4), I took another stab at a layered camera approach.   The idea is that if you can render the distant scenery just once and display it to both eyes, with the nearby scenery rendered twice for stereoscopy, you can avoid rendering all that distant scenery twice.   This has already been effectively implemented in a handful of demos for the DK2 (Time Rifters comes to mind).

The key question is whether it's worth it to do so, as there is overhead in rendering distant and nearby scenery separately, even if the distant scenery is only rendered once.  Turns out, this 2D/3D mode put Titans right on the edge of 60 FPS.   It was good enough most of the time that it was worth including as an option, but not perfect enough to make it the default mode.   By default, it will just render everything for the left eye and re-use it for the right.   While in 2D/3D mode, I also turn off chromatic aberration correction as that has about a 1ms GPU cost.

Another thing I optimized is Earth's appearance.  It's the first thing the player sees so it has to make a good impression.  The DK2 version renders Earth using three spherical meshes, with a high number of polygons in each.   One for the surface, one for the atmosphere, and one for the clouds which float above the surface.   This makes vertex count soar and incurs a ton of overdraw on the Gear VR.  So I simply got rid of the floating clouds, and they now appear on the surface texture itself.   The normal map for the surface has also been flattened out wherever the clouds are so that the clouds don't look like they are painted on.   Anyway, the end result looks good and doesn't kill performance (as much as it used to), and it means the clouds cannot move independently of the surface, but that's a small price to pay.


What's next for optimization:

I noticed in one of the Samsung Developer Conference (SDC) presentations that checking the box for GPU Skinning actually provides a benefit even if you don't use skinned mesh renderers, because it "activates the DirectX11 profile".  That was not something I'm familiar with so I'll be looking into that.  I currently have that unchecked simply because I didn't want Unity to bother worrying about a feature that I'm not using.  Very curious if this provides any kind of a benefit!

There is also the matter of texture compression.  When setting up texture import options (either on a per texture basis, or in the override in Build Settings), there are several highly efficient texture formats to choose from, all with tradeoffs.   "ETC2 (GLES 3.0)" is the one recommended in the SDC presentation, and yet every time I fiddled with that in the past, I either get unacceptable texture quality, or there isn't any perceivable benefit to performance.   However, note that it says GLES 3.0 in parentheses.  I'm running with the "Force GLES 2.0" option, as forcing 3.0 causes an intermittent crash that Unity is aware of and is actively troubleshooting.   It's my understanding that getting the app to work in GLES 3.0 mode may also provide a large performance boost.   In any case, this is another example of why it helps to build something from the ground up for Gear VR -- I'm starting with an experience where texture quality is a big focus, and would rather not take a step backward there on a platform that is known for having very high resolution.

Speaking of resolution, the text in Titans of Space is just as legible on the Gear VR as it is on the DK2.   Despite the higher resolution display in the Gear VR, it is not much more legible, and the real benefit you will see in Titans of Space for Gear VR right now is a reduced screen door effect.   The reason for this is that I am still using eye textures that have a lower resolution (1024 x 1024).   I have experimented with increasing the resolution of the eye textures but wasn't able to raise it enough to see an appreciable benefit to text legibility while still remaining above 60 FPS.   As a test, I made an empty project with some spheres and cubes with detailed textures painted on, and ramped up the eye texture size to 2K x 2K.   The difference is absolutely unbelievable!  My mind was blown, and this is another big reason I am looking forward to continuing my optimization push.

The eye textures remain at 1K x 1K, but I also experimented with rendering only the information panel text at high resolution with everything else being the standard lower resolution.   It was a very successful test, but the overhead for it is unfortunately too high for there to be any benefit at the moment.  Perhaps other optimizations will enable this to be a possibility in the near future.

Finally, the UI system that I use in Titans of Space is not very drawcall-friendly.  It takes a drawcall per label, although many of them are being dynamically batched.   The existing UI code makes it easy to support multiple languages across multiple fonts, with smooth outlines around each character (unlike NGUI).  However, it uses bitmap fonts, and requires a bit of preprocessing work to get the right look for each font.  It also takes up a lot of texture space and bloats the final app size.   When you open up the options or help HUD, framerate clearly suffers and is a simple demonstration of how brutal it can be to add a few more draw calls on a mobile device.   I aim to overhaul all the UI stuff as soon as I can find a good replacement that can address each of these weak points.   Unity 4.6 with its new UI system is now officially out, and as far as I am aware works just fine with the Mobile SDK, but am not yet sure if it will meet all my needs.

Optimizing "TNG Engineering" for the DK2

After releasing TNG Engineering for the DK2 (which is now up on Oculus Share!), I received some requests to make a post about optimizing this to run so smoothly for so many.

To be quite honest, this experience isn't anywhere near optimized as it could be, but I did place a focus on avoiding hiccups / framerate hitches / frame freezes and generally getting the FPS up as high as possible with a minimum amount of work involved.    Just as an FYI, I used Unity Pro 4.5.5p3, and some of this may no longer apply in Unity 5.

Don't Move:

TNG Engineering is your standard static scene, where nothing moves. That alone opens the door to static batching, which is a big part of getting that "greased lightning" feel.  In my demos I tend to have a single Unity scene that fades in and out of different areas, such as the "face forward and press space" prompt, the title screen, and the main environment itself - in this case, the Engineering Bay. Only one area is active in the scene hierarchy at a time and the camera is moved from one to the next. So, in order for static batching to actually work, geometry marked static has to be active in the scene hierarchy when Unity is generating a build.  It cannot be inactive at startup and then later activated at runtime and still be able to participate in static batching. That little caveat was tripping me up for a while, but now I've got a script to work around that, with great results.

Also, since dynamic batching isn't providing any benefit (either to draw calls or to the framerate) for this scene, I disable dynamic batching just so that Unity doesn't bother trying.

Curing Hiccups:

Fading to black is a pretty straightforward way to cover up any heavy-lifting being done to load things up.  The key is to make sure that everything is loaded up right then and there, and not leave anything out that will cause a hiccup later.  Larger / more complex programs may instead need to carefully manage memory usage and resource loading in an incremental fashion, but this post is about simple scenes.

The player first starts out in a short hallway leading to the Engineering Bay, so when the player rounds the corner to see the rest of it, there can be some pretty serious frame freezes as things are being loaded and rendered for the first time. There are seemingly a lot of tools that Unity provides to address this, such as preloading all the texture resources, warming up all the shaders, uploading meshes to the GPU, etc, but the approach I took in TNG Engineering to make sure everything is loaded into memory and onto the GPU is to simply render it normally.

So in TNG Engineering, while the screen is faded out, the camera will actually move to 3 different positions and orientations and render one frame each, before ending up at the hallway where the player starts. This gets all the heavy loading out of the way while the player can't see anything. This approach may not work for every type of program.  For Titans of Space, instead of moving the player around, the program instead renders every planet and moon ahead of time in front of the player just before the tour starts, and then hides almost all of them and puts them back where they belong.

Lighting:

Direct lighting has a pretty significant impact on performance, and realtime shadows even moreso.  In TNG Engineering, no realtime lights are used (and thus no real-time shadows).  Instead, all lighting and shadows are baked beforehand.  This can increase the size of your project with lightmap textures, but it's a non-issue next to the boost in performance and visual quality.

Collision Detection for Player Movement:

Since I am letting the player move around, much of the geometry has colliders to prevent movement through the walls. In cases involving detailed geometry, it is usually overkill to create a mesh collider for exact collisions, so these are instead loosely represented by primitive shapes like cubes. There are still plenty of mesh colliders in use, though.

Collision Detection for Positional Head-Tracking:

And finally, since the DK2 has positional head-tracking, I like to fade the screen out to dark blue as a function of distance from the player's head to a wall or surface. My approach to this is to use the CheckSphere physics function once a frame, with a radius that is equal to where fading out just barely starts. If that returns true, then I do up to 2 or 3 more CheckSphere calls to narrow down how far away the player's head is from a surface. I end up with a granularity of 8 steps to fade out completely, which looks smooth enough in practice, and yet most of the time there is only going to be the one CheckSphere call to keep things performing well.


That's about it!


Tuesday, November 11, 2014

Titans of Space update, plus tough Gear VR decisions

Titans of Space has been updated to v1.70 for the Oculus Rift DK2.  Changelog and download links can be found here.   There are a lot of changes in this update, the highlights of which are: improved performance, a smoother experience, some planets and stars getting another facelift, support for more languages, a new zoom mechanic, a few new options, etc.   It is built against Oculus' new Unity plugin 0.4.3.1, which is working extremely well, and requires Oculus Runtime 0.4.2 or newer.

Along the way, most of these updates have also made their way into the Gear VR version.   I am still working out of the same Unity project for both platforms, and I am constantly switching back and forth so this helps a lot with ensuring that everything that is implemented for one platform ends up working for both -- unless it is too expensive a feature, in which case it's just desktop-only for now.

VR demands a smooth, high framerate experience, and for a mobile device like the Gear VR, this means that when starting out with a desktop experience and cutting it down to work for mobile, sacrifices have to be made.   I've been careful to sacrifice things that players probably won't notice, but in the pursuit of player comfort and very long play times, I made the decision to sacrifice something else -- a feature I thought I would never ever cut.

When I announced that Titans of Space was ported to Gear VR, it was running just fine, barely cruising above 60 FPS, but play times were short due to thermal constraints.  In fact, I wasn't sure how many players were going to be able to get through the whole tour in one sitting, especially the players that were most interested in learning about space, who would take their time.  Those are the very players that would be punished by short play times as it would abruptly alert them that their device is overheating and to take a break from VR for a while.   I was working on a fancy system to help these players pick up where they left off, but was a risky feature that wasn't always working as intended since the tour consists of a lot of moving parts, and starting the tour at in the middle was a tough thing to QA.

To combat the short play times, I was looking at deeper optimizations, and considering cutting more and more important features, and the farther this process went, the more depressing it was to see the original experience turned into a shell of its former self.

So I axed stereoscopic 3D.

"Blasphemy!" I thought to myself.  "You call yourself a VR developer?"

And yet, I think it will turn out to be the best move I've made.   Suddenly I had a bunch of breathing room to put critical features back into the app.  Suddenly I could turn on chromatic aberration correction!  Suddenly, the stars all came into sharp focus and I realized that the Gear VR's optics are extraordinary -- text is completely clear all the way to the sides.  Suddenly, the app could be played for a very very long time (I still don't know what the limit is, if any).   Suddenly, I was happy about the overall experience once again.   The funny thing is, some players that have tested this didn't even notice there was no stereo 3D.   It's actually quite playable, and comfortable.   It probably won't trigger any existential crises when players look down at their own body in VR, but it should still be an enjoyable & educational experience all the same.   This is only a temporary measure, after all.

Of course, not all experiences are going to need to do this.  I started with an existing experience that targeted desktop VR, and with a project like that, it's a struggle to cut it down to size for mobile.   For those building new experiences from the ground up with mobile in mind, I expect to see them playing great in stereoscopic 3D.

I'm really looking forward to seeing if the Gear VR comes to faster devices in the future.  It's amazing that just when I thought we have topped out with mobile tech -- the CPU speeds, the graphics power, the resolution -- it was all a silly race with no significant purpose except to have something to market, until now.  Now there are clearly some very real benefits to every new step forward in mobile tech, like being able to flip the switch to get stereo 3D back. :)

UPDATE (Nov 20th): After receiving some encouragement from other developers, and poking around a bit, I'm happy to report that the Gear VR version will have a 3D Cockpit option right out of the gate. It makes reading text in the cockpit more pleasant, and of course it's always nice to see the volume of your own body. It currently runs right on the edge of 60 FPS so I'm keeping it an option for now until I can be sure that it gives every player a totally smooth experience.   Over time, I'll be adding more and more to the 3D rendering until the whole thing is full stereo 3D again. 

Wednesday, September 3, 2014

Titans of Space has been ported to Samsung GearVR

To me, Oculus and Samsung's partnership in bringing the GearVR into existence is pivotal in the rebirth of VR, especially when it comes to going mainstream, and I couldn't be more proud to be a tiny part of it as an early developer.

I thought I would go into detail of some of the challenges I faced while porting to the GearVR.  Since I did not create something from the ground up for mobile, and instead started with something that many are already familiar with, it was quite an undertaking to port the experience to a mobile device while still retaining the essence of the experience.  I had never touched an Android device beforehand, so it was all new. But, you know what they say about a deadline and a project!

While mobile devices today are getting more powerful by leaps and bounds, I quickly learned that porting something originally made for the PC to a mobile device and still have it run at 60 FPS was not an easy task. A lot of game systems required a rewrite, which I basically was going to do anyway so this was simply great motivation to get started.   It's just amazing to me that Unity can build games for a mobile phone using pretty much the same project that I've been using to build for PC's. To get things running fast though, Oculus provided a lot of helpful performance tips for the early developers. I ending up having to do several things:

----

1) Drop the vertex count way down. I started with 4.5 million vertices (across both eyes) and brought it down to 100K total (50K per eye). Had Carmack not explicitly said to target 50K per eye, I honestly never would have taken such a strict limitation seriously, but it really helped.  Most of the 4.5 million was in the cockpit detailing, the planets and stars, and the individual stars in the background. In Titans of Space for DK1, there are nearly 200K vertices used for rendering the background stars. This made them look pretty clean especially when zooming in, but definitely not an option for mobile. I stuck a custom LOD system on the planets and stars and tuned it the best I could to use the minimum number of vertices to give the appearance of a sphere at varying sizes and distances.

2) No more layered cameras. Before this, my usual approach was to render the cockpit on top of the "external" view of planets and space etc. That approach made it extremely easy to keep the player at the origin (to avoid jittery geometry), easy to keep the player at 1:1 scale (to avoid near plane clipping while also needing to have giant far clip planes for the planets and stars), and easy to decouple the ICD of each camera layer so that the player can feel like he's normal size but the surrounding space can feel huge even if it isn't huge within Unity's coordinate system.

 With those conveniences taken away, I redesigned it all to work with a single camera setup. This required reworking how the big stars are renderered at distance, it required implementing a floating origin, it required turning the individual stars into an actual pre-rendered skybox. Fortunately skyboxes finally work in VR as of Unity 4.5+ -- I just had to set up my own skybox rendering system to get a high quality cubemap (4K on a side), with real stars and milky way background lined up perfectly etc.

3) Pay attention to texture limits. No more 8K textures (which were only occasionally helpful anyway), and I had to be careful not to use too many uncompressed textures. Uncompressed textures are great for closeup detail with the zoom feature, and for normal maps that don't pop in and out, but they eat up a lot of storage space and memory, which are somewhat limited on a mobile device. I had to choose more carefully which textures to leave uncompressed.

4) Reduce draw calls down to ~100 or lower at any one time.  In Unity, things that share materials and don't move (static) can be batched, but there's not a whole lot that can be made static in Titans of Space now. The cockpit and everything in it used to be static and thus was very batchable, but not anymore due to not using layered cameras.  To make things worse, dynamic batching was broken for me on the mobile device for a few Unity versions and/or mobile SDK versions, and that forced me to be even more aggressive with this at the time.  I mainly addressed this by simplifying the cockpit and removing the debris field that surrounds the player.

5) Make shaders more mobile friendly.  There were a few nice-to-have features that I decided weren't worth the GPU cost, like having the limb of a gas giant ever so slightly translucent.  There's no point in having a giant, uh... gas giant be rendered on top of everything else as a transparent object -- the resulting overdraw hits fill-rate limits very easily so that had to go.  Planets like Earth also have a lot of overdraw. In the DK2 version, Earth has clouds that float above the surface, but the GearVR version just has the clouds combined with the surface texture.  The base of the cockpit is no longer translucent.  Lots of little compromises like that.

6) Figure out how to use one project to support both DK2 and GearVR. The Titans of Space project is about 5 GB in size and it's a huge pain to switch back and forth between Standalone PC and Android platforms, but I wanted to keep it all in one project as most of the changes I make for one platform apply to the other. However, there are a ton of details that differ, such as the level of detail in the cockpit, the nicer looking Earth vs the mobile-friendly Earth, certain options, etc.

I've kept a checklist of things to do every time I switch platforms, and I've automated other things via a central "is this a mobile build or not" checkbox and scripting defines.   There are some things I would do differently with the project knowing what I know now -- like making more use of prefabs to swap in and out depending on the platform rather than just activating/deactivating parts of the scene hierarchy.

In any case, the end result is, what you see on DK2 is what you see on GearVR, with the exception of a few changes to the cockpit and other easy-to-miss features that don't significantly impact the experience.

----

I learned a lot from the Oculus/Samsung partnership. Thanks to their combined wizardry, I have great hopes for compelling and rock-solid VR experiences on a mere mobile device. It's been both fun and maddening to watch /r/oculus speculate on the various rumors that had been swirling around. I have zero doubt that a new mainstream household activity has just come into being: taking the GearVR over to the couch to relax in VR. Also, being able to walk over to a family member (with device in hand) and say "hey check this [entirely other world] out" is cool too. :)

Sunday, August 17, 2014

New things

Titans of Space v1.52 with DK2 support has been released, and details + a download link can be found at  www.TitansOfSpaceVR.com.   Thanks to the wonderful VR community, I've received a few pages worth of feedback already, so expect further updates and improvements in the coming weeks.

I also wanted to share a link to KentBye's Voices of VR Podcast, where I explain why there hasn't been a new Rift Demo Round-up for a month, among other things.  :)



Monday, July 28, 2014

How to launch DK2 Unity demos

Since the "Direct HMD Access from Apps" Rift display mode does not seem to be working 100% yet, I've had to fiddle around quite a bit to figure out how to launch demos properly.

UPDATE:  For demos built with SDK 0.4.1 or newer, this is all *less* of a problem, but the below checklist is a great fallback.   There are still quite a few demos that do things differently, so I would like to recommend the "Unofficial VR Game Manager/Launcher by Bilago", which can be found here.  It can be a great help to experiment with what makes a demo tick, and then remember those settings for next time.

So after some trial and error, below is the checklist I go by now.



Note that this checklist assumes the following:
  1. You are using Windows 8 (though it may apply to other Windows versions),
  2. The Unity demo you are trying to run was built with DirectX11 turned off,
  3. You're using a single monitor + your DK2 (known issue that multi-monitor config results in judder).



1. Rift Display Mode: "Extended Desktop to the HMD" (via Oculus Runtime in your system tray)


2. Turn your DK2 *ON*.

3. Windows Desktop Mode: "Extend" (via "Second Screen" sidebar via Windows Key + P)





4. Main monitor: Primary, i.e. "This is your main display" (via Screen Resolution window, by right clicking on an empty area of your desktop)


5. DK2 monitor: Not primary, Landscape orientation.  (Most users with a simple monitor set up like mine will need to use Landscape, but others have reported needing to use Portrait or Landscape (Flipped), etc.  Whatever works for you -- the point is to feel free to change Orientation.)  Make sure the Rift display in this window is light blue like your main monitor.  If it's small and dark, it usually means you didn't set your desktop to "Extend".   If you did set your desktop to Extend and you're still seeing this, switch back to "PC Screen Only" and then back to "Extend", and then it should pick it up.



6. To run a Unity demo, use the DirectToRift executable that hopefully came with the demo in question.  The demo should then pop right up onto the DK2.   If you get any judder, get out of the demo, turn the Rift off and back on, then try again.

If anyone finds that this checklist doesn't hold true in all cases, please let me know.


Sunday, July 20, 2014

Rift Demo Round-up: Jul 6th - Jul 19th

Below is a list of 27+ free native VR demos, all with playable downloads right now, that have come out of the community in the last 2 weeks - either as new demos or significant updates to older demos.

These demos come in various shapes and sizes, some more polished than others, and many with excellent ideas.   I am sure the developers would love to hear your thoughts, even if just a one-liner to let them know someone is playing them.

Here we go, in alphabetical order:

New Demos:


Updated Demos:

(includes new demos that have been updated already)
(Green denotes an epic update, does not apply to new demos)


Drash's Top 5:

(in no particular order, only applies to new demos)



Please note that the Top 5 list is merely my own personal opinion, and only reflects how I feel about an overall experience after playing it.  I am not able to play 100% of these demos, so please take this list with a grain of salt.   Lastly, there are more than 5 awesome demos in this list -- it was a tough decision to pick only 5!

As always, if I missed any, please let me know.


Sunday, July 6, 2014

Rift Demo Round-up: Jun 22nd - Jul 5th

Below is a list of 34+ free native VR demos (57+ if you count the 24 small demos by Jose), all with playable downloads right now, that have come out of the community in the last 2 weeks - either as new demos or significant updates to older demos.

These demos come in various shapes and sizes, some more polished than others, and many with excellent ideas.   I am sure the developers would love to hear your thoughts, even if just a one-liner to let them know someone is playing them.

Here we go, in reverse alphabetical order:

New Demos:


Updated Demos:

(includes new demos that have been updated already)
(Green denotes an epic update, does not apply to new demos)


Drash's Top 5:

(in no particular order, only applies to new demos)



Please note that the Top 5 list is merely my own personal opinion, and only reflects how I feel about an overall experience after playing it.  I am not able to play 100% of these demos, so please take this list with a grain of salt.   Lastly, there are more than 5 awesome demos in this list -- it was a tough decision to pick only 5!

As always, if I missed any, please let me know.


Sunday, June 22, 2014

Rift Demo Round-up: Jun 8th - Jun 21st

Below is a list of 32+ free native VR demos, all with playable downloads right now, that have come out of the community in the last 2 weeks - either as new demos or significant updates to older demos.

These demos come in various shapes and sizes, some more polished than others, and many with excellent ideas.   I am sure the developers would love to hear your thoughts, even if just a one-liner to let them know someone is playing them.

Here we go, in alphabetical order:

New Demos:


Updated Demos (includes new demos that have been updated already):


Drash's Top 5 (in no particular order, only applies to new demos):



Please note that the Top 5 list is merely my own personal opinion, and only reflects how I feel about an overall experience after playing it.  I am not able to play 100% of these demos, so please take this list with a grain of salt.   Lastly, there are more than 5 awesome demos in this list -- it was a tough decision to pick only 5!

As always, if I missed any, please let me know.


Sunday, June 8, 2014

Rift Demo Round-up: May 25th - Jun 7th

Below is a list of 50+ free native VR demos, all with playable downloads right now, that have come out of the community in the last 2 weeks - either as new demos or significant updates to older demos.

These demos come in various shapes and sizes, some more polished than others, and many with excellent ideas.   I am sure the developers would love to hear your thoughts, even if just a one-liner to let them know someone is playing them.

Here we go, in reverse alphabetical order:

New Demos:


Updated Demos (includes new demos that have been updated already):


Drash's Top 5 (in no particular order, only applies to new demos):



Please note that the Top 5 list is merely my own personal opinion, and only reflects how I feel about an overall experience after playing it. I am not able to play 100% of these demos, so please take this list with a grain of salt.  Lastly, there are a lot more than 5 awesome demos in this list -- it was a tough decision to pick only 5!

As always, if I missed any, please let me know.


Sunday, May 25, 2014

Rift Demo Round-up: May 11th - May 24th

Below is a list of 35+ free native VR demos, all with playable downloads right now, that have come out of the community in the last 2 weeks - either as new demos or significant updates to older demos.

These demos come in various shapes and sizes, some more polished than others, and many with excellent ideas.   I am sure the developers would love to hear your thoughts, even if just a one-liner to let them know someone is playing them.

Here we go, in alphabetical order:

New Demos:


Updated Demos (includes new demos that have been updated already):


Drash's Top 5 (in no particular order, only applies to new demos):



Edited to add "SVVRCon 2014 Matterport Demo" and "UE4 Stylized Demo" to the list.

If I missed any others, please let me know!