Steam VR Template

I should have searched before I put together my own template setup:
I did things slightly differently and included a beginner level tutorial that covers basically all the VR features you’ll need to get started.
https://.com/watch?v=Layx29lUziQ

If you want, you’re free to grab anything you find interesting, because I don’t have much interest in being the template master =)

This is fantastic.
Thank you so much.

Note, that instanced stereo rendering option doesn’t seem to be on by default with this template, wonder what’s the reason to not use it by default?
(like maybe they are only available to newer GPUs?)

When I place the Vive_Pawn on a moving platform (a static mesh I created), the pawn doesn’t move along with the platform.

What settings do I need to change for this to actually work?

Thanks!

The instanced stereo is now enabled. I just did no think to enable it (it is off be default).
I’ll look at the mesh/platform problem
Thank you Paul if you don’t mind I’ve borrowed some nodes thanks.
The “tag floor” part is gone. Now teleportation is simpler with the trackpad and go/no go zones (aka navmesh+blocking volumes)
We’ve tried it on different systems and it always works. You have to start SteamVR before any instance of UE4. If you start SteamVR after UE4, the VR Preview should still be enabled but it does nothing. Closing UE4, checking/starting SteamVR and re-starting UE4 should do the trick. If VR Preview is grey it’s because SteamVR is off, Vive not detected. We also observed that some branches of UE4 recompiled from gave us the grey VR Preview. We are working with the official 4.11.1 version, so we don’t know for other branches, maybe yes, maybe no.

We’ve tried to “grab” the conductor’s baton without success. Somebody better than us for picking up things?

Oh nice!

You should totally polish this up and submit it to epic as a Pull request :slight_smile:

Excellent work, consider using a repo instead of one drive to allow others to feed back into the template.

Now I just need my vive to arrive. Any year now… check e-mail again

I go through this template yesterday and although quite well put together, the blue print side of thing looks (try to be polite) unpolished.
It have quite a few bad habits to keep(?) and would bite you in the butt once your game starts picking up in complexity.

Most notable one is abuse of EventTick, this is the event you will NOT want to use unless you exhaust all other possibilities. Think of this way, event tick runs every frame regardless, what kind of thing that absolutely needs to run every frame? If you don’t interact with the world, they would just peacefully be there, so why your pawn have to check every frame for some booleans for things to do? How about let the controller update does what you need? Cause controller, especially for VR, their update rate may very well surpass our frame rate by a large margin when next gen hardware comes out, those boolean control would fail badly when that happens. “delay” is also another node that you probably don’t want to use everywhere, especially in a EventTick chain. I demo it in my stream where you can trigger the teleport and then click somewhere else, you ended up teleport to new location instead of old location, usually to prevent this from happen any regular people would just put in a stat check. But NO, please don’t do that, it should be implement properly by using a scheduled event and a gate where open/close is also controlled by events.

I will spend sometime this weekend to try polish up those blueprints and contribute it back.

Proteus, please note that I am not giving you ****, you are doing a great job setting up all these. But from your blueprint I know for sure you probably aren’t into UE4 for a long time. I will help you as much as I can to make this template right, UE4 is not Unity, we should not put everything into a update() call. This will help everyone in the long run.

Thank you for your work on the Leap plugin getnamo! Although I abandon the idea of using Leap in my game, it still helps a lot while Leap pretty much put no resource in UE4.
I hope you get you Vive quicker, I know a friend that pitched his prototype to Valve and get Vive Pre on the same day as my CV1. So if you pre-order really late, you might want to consider this or the UE4 grant program, Epic also have 500 Vive Pre to “worthy” developer. And I think you definitely fit the bill with your Leap plugin alone.

This is awesome!!! thank you very much!

Thank you PenguinTD for the input. Event if I work on it since it’s release, I would qualify myself as 5/10 at UE4 :). Although I also try to flee like the pest event ticks, at first I did not avoid them in the 3 debugging functions since probably no one would enable these functions constantly in a game. However, I’m not sure if it’s avoidable in the teleportation system, setting apart enabling/disabling event tick.

I think that the main problem is the elusive SceneRoot problem. Although teleportation and interacting with meshes works, I have mainly 3 hints that SceneRoot doesn’t bulge and stays at 0,0,0 through the entire game:

  • Debugging spheres around controllers and base stations stay in the initial spawning area despite teleportation
  • Teleporting on moving platforms works, but we are not transported by them.

We worked with the DK1 and DK2 since the last 3 years and of course we didn’t have these problems. However it seems that room-scale opens a new conception of pawn movements through the game map.

What would be logical to do is enabling SceneRoot movements by moving objects. As an example, you are in a moving train (moved by matinee). Would it works to attach Vive_Pawn to the train? We don’t know yet since the initial spawn won’t be at 0,0,0 and will move rapidly. I guess if we succeed to have a Vive_pawn moved by one of the 2 platforms in v1.5, that would resolve the question.

I also tried the teleportation systems proposed in the videos of and also Paul. The results are the same as the ones in the template. Maybe a method would be more cost-effective than others, I’m not sure.

Also, enabling camera fade when clipping through blocking volume crashes the program. Beware.

Finally Getnamo — you are the Master of Your Domain concerning the Leap and the pickup things (i.e. Jenga). I remember well our discussions at OC2 and it seems you invented the device. We just enabled the plugin and stuck the device on the Vive – no results obviously. It is surely because the camera/player height thing with the Rift. Can’t wait you receive your Vive to try it out. I would lend you one but 5000km is a little far appart :cool:

Of course I think following resolution of main problems we could clean it, optimize it, giving it an elegant look and then submit it to Epic? We always thought that not having a DK1/DK2 template despite having 300k of them in the wild has always been an aberration…

That’s it don’t panic I won’t continue to release a version-a-day, it’s now on and maybe I could put only major advances from the group on the onedrive since I know not everybody is comfortable with git. And I hope together we’ll iron the probs and go back to our fabulous room-scale experiences and games – if nobody does it I’ll maybe propose another template for the Rifts when we’ll receive ours in 2 weeks.
Ciao!

If you mean the draw debug call, they won’t follow you anyway. I didn’t see other debug “component” mesh you mentioned so don’t know what you refer too.

About moving platform, although it’s not encouraged for VR, but for people that have stomach for it, I think it’s doable.
You basically have something that triggers enter moving platform volume, save to scene root reference to an array and then during animation playback/update, move the all the scene root with platform with teleported offset.
When you leave volume, remove reference from array and then you don’t get update, that’s pretty much it.

I did a Ultraman test today and it’s quite fun, by manipulate the world to meter value and some scale update. Still have to make some tweaks cause it’s making camera by tracked unit converted, so you are also moving away from scene root while growing big. But since your head are always moving, it’s kind of interesting problem to solve the offset problem. I think Paul’s teleport is pretty simple and working, while yours I kinda run into moving ground level problem.(ie. if I put controller IRL ground after teleport, it’s usually not on the in game ground.)

Ok I didn’t know that it was normal for debug calls for controllers and base stations to not follow.
As the moving platform I thought more something like a vehicle (train, or something like Hover Junkers). My first reflex was also to create a volume around the platform but I did not pushed the idea further.
I did not test it enough to encounter the ground level problem but probably Paul’s teleport is the best solution.
I’ll do an updated video to show features / problems for fellows devs who did not received their Vive yet.

What I mean is if you use “DrawDebugXXX”(box, sphere, line) those won’t follow you.
Basically things that will follow you are components that attach to your pawn or something attach to one of your sockets(like weapons.)

Also Widget Component doesn’t seem to work properly in VR.

Thanks for all templates
When i test, or build a project. i see always in the Vr headset with a lot of blur on texts and textures.
I was thinking templates UE4 VR was setting to a lower screen resolution but… i doubt that.
is SteamVR do an adaptive rendering for PC with lower scoring ?
like with a CPU or GC to low

(I have actually a i5-4670K CPU @3.4GHz and R9 285 Dual X, PerfTest 3.1)

I would check to see what AA settings you have on for the Unreal Project. Unreal’s AA setup will add a blur to stuff when its enabled. Also check to see what your projects texture compression quality / baking is set to. Higher number is better quality while lower number is just a faster back and will end will a lower quality.

You also might check any post process settings you may or may not have turned on (motion blur, ect.)

Thanks man. This is great.

Yansko: check the level blueprint for scalability settings. I’ll update ths part soon but globally they adress what you’re looking for. Also the post-p volume is also tuned for VR.
I solved the teleport function by tweaking Paul method which did not account for blocked volumes
I set some nodes for plaform teleport as per Penguin but too tired to continue tonit…Penguin would you be immensely grandiloquent and post a picture / link of these/similar nodes?

As for Epic support for VR…I find it on/off depending on updates. I think they must adress a wide range of devs and not sure that vr is a very big part of it, i.e. when compared to mobile… At least 4.11 had a lot of imprvements for rift/vve and even dk2. Anyway, for now we’re taking the matter in our own hands. I hope that we will have adressed main probs (listed under “bugs”) within the following week. Things like accessing camera and tweaking chaperone will probably take longer time or someone develop a plugn to access these features. I just hope we’ll soon use the vive to it’s potential and put it at the face of Epic :rolleyes:

Thanks, I’ll go check that

Ok, after testing
i think a mesh textured is blur beyond > 1m
change sg.ResolutionQuality 25-300 seem have not effect

Only AA setting by
sg.AntiAliasingQuality change
Post-process AA quality (0-3)
but… 0: = it’s blur without AA and 1: blur with little AA, 2: blur with more AA, ect…

Post proccessing setting seem better with “TemporalAA”

Is it just the too low resolution of these first headsets result a constant blur effect, or a process to limit SDE ?

Scalability settings with Vive.

The sg ones is in fact a group of r settings. For a thorough explanation see Scalability Reference | Unreal Engine Documentation
Specifically for VR, visit also http://www.tomlooman.com/getting-started-with-vr/

I played a lot with these settings and I found that with the Vive:


FXAA is less ressource hungry, provides crisper images but there still some aliasing
TempAA is ressource-intensive, provides images that are bit blurrier but removes all aliasing
Personnaly, I prefer the look of tempAA, even if farther textures are a bit blurry. I found the sweet spot between ressource/usage and image quality is a screen percentage of 150. I can crack it up a bit but over 175 a begin to have serious drops in FPS (in tempAA). Note that the sweet spot can vary between rigs. Note that for textures within let’s say 2-3 m I don’t see any differences between settings, they are all super crisp.
Other settings like adjusting streaming poolsize and setres should be tailored accordingly to your GPU VRAM and main monitor res.

Also, I like the command enable/disable all screen messages cause sometimes it can be annoying and be still found in your baked game. However for developing/debugging purpose they should still be on.