No issues. I enabled this plugin for another project and forgot to disable it for this one. Just ignore it and make sure it is not enabled in the plugins section.
Thank you for this update. What did you change exactly to get the controllers to be matched perfectly? I am trying to get the controllers only ported over to my project but I must be missing something. They are slightly off.
@Osok. I resized them in Maya as per the real measurements. Placing the pivot was trial and errors to match the SteamVR menu controllers meshes placement.
Thanks for the info. I brought your meshes only to a fresh pawn and they don’t seem to line up exactly for some reason. I’ll have to mess around with it some more.
Also the 1.9 version is missing some meshes and has some other errors on load. Are these expected?
Everything is supposed to work fine. Which mesh is missing/ errors?
I have been unable to load version 1.9. It fails to load saying that the map may have been made with a newer version. I’m trying to open it with editor 4.11.1
Going to have a shot with version 1.8 and see if I have the same problem.
Nope, same issue with version 1.8
“Failed to open map file. This is most likely because the map was saved with a newer version of the engine.”
Were these versions created with a daily build you compiled yourself?
Hey Osok, I had the same error message. Just manually copy the content of “SteamVR_1_x\Content\Geometry” into your local installed program folder. In my case is “D:\Program files\Epic Games\4.11\Templates\TemplateResources\Standard\Geometry\Content”
I don’t think those files should not be in there but at least this will fix it.
Im still learning blueprints and was wondering what the best way is to remote control another pawn using motion control inputs?
I know how to posses and unposses in the first person template but when it comes to using the vive pawn theres so much going on im not sure where to start. Ideally id simply like one controller to always be controlling the other pawn vehicle. Similar to the couch knights demo but with normal vive movement and teleport working.
@Magneto so if I understand you would want to do the usual things with the Vive_pawn while controlling the vehicle with the other controller? I think the first move would be to remove everything related to let’s say the left controller in the Vive_pawn, and assign left controller only to vehicle. Then, since you are attempting to use two pawns, you’ll need to give the vehicle its own Controller; Player Controllers can only possess one pawn at a time. You have to spawn a second Controller and possess the vehicle with the second controller.
In the same subject, I’ll put there the nodes to embark/disembark a platform matinee/sequencer. What is the use of that? As an example, you could have a tram moved by a sequencer/matinee on which you embark/disembark. You have to put the Vive_pawn into the level (with auto-possess player disabled) and move also the Vive_pawn into matinee. The other way would have been to attach/detach the Vive_pawn to the tram as you could do it with a DK2, but it’s taking a severe toll on the performance. This way everything works fine (on this graph I use the menu button to embark/disembark matinee platform):
@Osok @jtengland I just checked the all files are there. Almost all errors encountered have been mixing up between template and project files:
" To install as a template, just unzip into the appropriate templates directory like C:\Program Files\Unreal Engine[Version]\Templates for launcher version or[ForkLocation]\UE4\Templates for source version. Launch a new project, and you’ll find it in the blueprint section.
To install as a project file, unzip in your usual projects folder. Then, delete the file SteamVR_x-x/Config/TemplateDefs.ini and you’re ready to go"
If you still have problems with try the .zip on the onedrive
Any thoughts on how to handle actors that need to be gripped with 2 hands for interactions? Think shotgun or 2 handed sword. I have gone through your source and am thinking about implementing this. Any pitfalls that you are aware of? My initial thought is to store multiple grips with one of them (presumably) the first hand to grip being a primary grip and the other one being secondary but with the ability to adjust the current grabbed actor world rotation based on the position/rotation between the 2 vive controllers to determine the new orientation.
You’ll have to alter the late update transform a well to manage two hands, that is trickier because each hand will perform the late update independently. Otherwise you’ll end up with one hand “floating” on the grip a bit, something that probably isn’t a big deal for a front hand on a gun but would be pretty noticeable in the sword grip instance.
The basic re-orientation is easy, but it doesn’t solve that issue.
Sounds good. That would be one of the pitfalls that I hadn’t thought about. In our implementation(at least our plan) is to actually hide the hands once something is gripped. At most a really dimmed/translucent mesh that shows only a faint outline for presence. This hasn’t affected anything too negatively so far in testing, but if I understand you right this would help with the float since there would be no visible mesh to see “floating”? I feel like any lag on the actual grabbed actor hopefully would be indiscernible to our eyes. We’ll see. Thanks for the quick reply.
VR Performance Tweak
New stuff to share for everyone!!
@Proteus, so during today’s stream, I found these settings that can further cut down the render time used.
(I have 21 InfinityBlades characters in the free asset overview level as my benchmark.)
- r.SeparateTranslucency 0 ,this will cut BokehDOFRecombine
- r.TranslucentLightingVolume 0 ,this cuts the translucent lighting cost if you don’t have anything that casts translucent shadows.(particle still works) And this will cause HZB items to show up in profiler. If you need this function, you can use this “r.TranslucencyLightingVolumeDim 32” to lower the quality(default is 64)
- in post process volume, check ON ScreenSpaceReflection Intensity but set it to 0, this will entirely cut off ScreenSpaceReflections showing up in the profiler.
I think the above combined gives me about 1.8ms less(5.3->3.5ms) in render time on a 980Ti, so it would definitely help more on lower spec cards.
So hopefully these can be a default settings in future templates. 
If people can find where to cut more I’d like to hear.
Things I’m not certain can cut or not.
Tonemapper takes up .11ms each eye, but it seems required by TemporalAA.
ReflectionApply also about .12ms each eye, but I just assume it’s applying basic cubic reflection maps.
SlateUI, takes about .30~.50ms, I doubt I can cut this until it’s a standalone game, PIE or new window still incur calls to the editor UI.
Btw, we should totally have a empty level that have a default post processing volume inside that’s setup properly. So we can just edit it and save to different level.
Cheers~~
If you handle late transforms from the main hand correctly I doubt it would be noticeable at all. For slow movements having no late updates at all wouldn’t be noticeable either with no hands.
@PenguinTD that’s a good idea, to have most settings in pp volume. However some settings are not within pp volume as you know it. Another thing in the next iteration.
So I’ve updated the book of charges for next iteration:
Know bugs
- Lightsaber: on/off left hand; glowing light same color as blade
- Teleport: Adjustable “safe” value to teleport on uneven surfaces
- Grab function: drop problem when both hands are grabbing objects at the same time
- Vehicle: Vehicle will rotate with controller input
- Chaperone bounds will spawn meshes instead of particles, retriggerable
- Disable Analytics and Substance plugin
Next new features of 1.10:
- Teleport/Exit matinee platform
- Penguin’s TD menus
- Rotate playground in teleportation
- Animated hands with 3-4 poses
- Most settings put in post-process volume
I’ve added the animation with both R and L hands. I checked on the marketplace, there’s no suitable hands solution to my taste. What I’ll do is that I’ll 3d scan and mocap/rig/skin my hands in various position like grab, point, etc and intregrate them to the Vive_pawn. I feel that this becoming important.
So next iteration will probably come in 7-10 days, to have time to fix everything, integrate new features and test them fully. I also have the idea of tweaking PenguinTD’s menu system to make a kind of Hover Junkers control system for the vehicle. From what I’ve experienced in various game that’s the best idea. I’ve put a joint in the vehicle to be able to rotate the handles with the hands, but it’s not really practical considering the Vive setup. So thanks again and please continue to bring bugs to my attention!
I also saw in another thread problems related to multiplayer – we’ve got here in our office 2 Vive and 2 rifts – I’ll begin multiplayer tests as soon as the basic SteamVR template is ready for graduation.
Thanks for this, I notice you have the default screen percentage at 150. That’s great. Just wondering how to I adjust this to 200… this is just for testing purposes.
You can change r.ScreenPercentage 150 in scalability settings in level blueprint, or just enter it as a console command
Beware depending on your rig there is a great probability (especially with tempAA) that UE4 becomes unstable (mine is not doing well over 175-180) cause too much taxing on ressources.