Thank you. I think its much improved but I’m still not convinced its 100%. I think I might be wrong though and its just a very tiny difference caused mainly by the controller mesh being used. Its probably me just seeing something that isn’t there. Best wait and see what other people think.
It is the same as the default controllers though, so it matches how Epic has it set up currently, my concern was matching the standard controllers.
As for the performance vs steamvr menu…
The Temporal Anti Aliasing doesn’t help because it blurs fast motion and when you have low FPS (hit the interleaved projection mark and get downscaled to 45 fps) you’ll see ghosting from it. Also I don’t think I have found a demo/game with as smooth of tracking as the default environment.
Did you make sure that you are hitting 90fps? With interleaved projection turned on if you can’t hit 90fps it automatically drops you down to 45fps and interleaves the frames so that the screen updates remain at 90fps. It might still feel like it is 90fps but the actual frame/update time is 45fps and that will cause more temporal AA blur and controller tracking latency. You can show the fps chart to make sure, but I was dropping to the 45fps mark in the template level due to the clutter.
I try to package in 4.12.2 and I get this error
PackagingResults:Error: Error Unknown Error
Does anyone have any advise on what I am doing wrong?
Here are the warnings
LogConsoleManager:Warning: Console object named ‘vr.EnableMotionControllerLateUpdate’ already exists but is being registered again, but we weren’t expected it to be! (FConsoleManager::AddConsoleObject)
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
LogMaterial:Warning: Material /Engine/EditorMeshes/ColorCalibrator/M_ClearCoatBlack.M_ClearCoatBlack needed to have new flag set bUsedWithSkeletalMesh !
MapCheck:Warning: Warning M_ClearCoatBlack Material /Engine/EditorMeshes/ColorCalibrator/M_ClearCoatBlack.M_ClearCoatBlack was missing the usage flag bUsedWithSkeletalMesh. If the material asset is not re-saved, it may not render correctly when run outside the editor. Fix
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
LogUObjectGlobals:Warning: Failed to find object ‘Class None.’
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
LogConsoleManager:Warning: Setting the console variable ‘r.ViewDistanceScale’ with ‘SetByScalability’ was ignored as it is lower priority than the previous ‘SetByConsole’
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
LogConsoleManager:Warning: Setting the console variable ‘r.ViewDistanceScale’ with ‘SetByScalability’ was ignored as it is lower priority than the previous ‘SetByConsole’
LogConsoleManager:Warning: Setting the console variable ‘r.EyeAdaptationQuality’ with ‘SetByScalability’ was ignored as it is lower priority than the previous ‘SetByConsole’
LogConsoleManager:Warning: Setting the console variable ‘r.BloomQuality’ with ‘SetByScalability’ was ignored as it is lower priority than the previous ‘SetByConsole’
LogConsoleManager:Warning: Setting the console variable ‘r.TranslucencyLightingVolumeDim’ with ‘SetByScalability’ was ignored as it is lower priority than the previous ‘SetByConsole’
LogPhysics:Warning: AddConvexElemsToRigidActor: [/Game/Environment/Lightblade.Lightblade] ConvexElem[0] invalid
Oh ok i see. Thank you for the info 
@Proteus I was wondering would you recommend switching to 4.12 soon or the oculus version of 4.11?
Was the performance worthwhile and were there any issues?
@Magneto I’m in the process of testing 4.12.2 with updated plugin. I’ll post an updated version later today/tonight.
Epic is making their own Forward rendering branch for the engine, I would wait on that one over using Oculus’s version as it won’t be following feature patches. That is unless you are looking to lock into your engine version right now.
when i package it on win10 64, get this error
and don’t konw how to fix it
ERROR: No modules found to build. All requested binaries were already part of the installed engine data.
Version 1.10 – UE4.12.2 : June 14, 2016
- Updated to 4.12.2
- Updated grab plugin
- Left and Right grab hands
- New vehicle controls: vehicle rotate with direction
- New environment with interactive consoles
- Chaperone poles spawn fixed
- Less settings; the rest will be in a future 3D menu
- Matinee changed for Sequencer
- Small glitches and crashes fixed
Onedrive at Microsoft OneDrive - Access files anywhere. Create docs with free Office Online.
The most stable version to date.
Fully tested for stable 90fps (GTX980), cooking & packaging Windows 10 x64
Comments / docs / tomorrow.
Have a nice day 
Nice work though after testing it again in a new project im still not sure about some of the examples and defaults you’ve gone with. The current grab style with hands is a bit awkward still and the vehicle/ultraman movement never did work right in my testing?
I know it’s all customizable and there’s a lot of good work but im thinking about people who just want a simple and intuitive template to start small projects in. I think it would be good to mix the best of yours and 's work. He has a polished looking teleport system and some practical interaction examples like menus and a browser. You’ve got a great vive pawn with plenty of options and potential.
If we can approach the polish of the lab as far as default setup and interaction examples go we’d have something great.
@Magneto You’re right. What I plan to do for soon:
Having multiple pawns. e.g. one pawn with grab function, one pawn for vehicle, etc. That way you would just have to drag and drop the pawn you need in your game.
Grab function: I’ll do a pawn with the plugin, and another with grab function. Both have their place depending on the situation. Again, the grab functions I did for the plugin can certainly be streamlined and I’ll reconsider each nodes. However it cannot be full simple, considering both hands and sockets.
Vehicle: I find it more intuitive this way. However the way it is right now you have to put your left controller horizontally and in front of you, rotate with L trackpad x and throttle with L trackpad y. It’s close to Hover Junkers but as I like the way you move your vehicle in this game I’ll redo it excactly the same manner.
Teleportation: Sure, teleportation of is more capable as you can orient your playground. I’ll have a look at these nodes. Hope he doesn’t mind if I find inspiration in some of his functions!
So I’m working right now at improving the template:
- Multiple/Streamlined, drag-and-drop pawns
- Grab with/without plugin
- Vehicle Hover Junkers style
- Teleport while rotating playground
Thank you for this great template 
Great template. Is there a realtively easy way to get two objects to snap together at sockets within VR - a bit like lego?
Thanks for the update, great work! I also no longer experience any lag on the controllers 
I’m wondering how I can change the angle of the Left and Right_Hand_Grip permanently. I can change their placement relative to the Vive controllers in the Vive_Pawn blueprint, but when I grab something they snap back to the (quite unnatural) default position and stays there.
Version 1.10.1 – UE4.12.2 : June 15, 2016
- Vive_Pawn_Complete, with every functions (except vehicle)
- Vive_Pawn_Vehicle, Vive_Pawn_Grab_Plugin (no lightsaber), Vive_Pawn_UltraMan will each do a specific function; only Vive_Pawn_Grab_Plugin uses the plugin; select pawn in Steam_GM
- Fixed chaperons’s poles and exit simple platform
The Vive_Pawn_Complete does everything, except vehicle
Following many requests, this is to facilitate the migration of the pawn into another project.
To migrate pawn in another project:
Migrate Vive_Pawn_Vehicle, Vive_Pawn_Grab_Plugin, or Vive_Pawn_UltraMan in another project
For Vive_Pawn_Vehicle, migrate the Vehicle Pawn also; for Vive_Pawn_Grab_Plugin be sure that the objects to grab have the blueprints and 3 interfaces and the the grab plugin is in the plugin folder
For all pawns, select the right pawn in the Steam_GameMode (GM); copy scalability and initial settings in level blueprint; in project settings set Engine/General Settings at USe Fixed Frame Rate 90, Engine/Rendering/Default Postprocessing settings: Uncheck everything (bloom is optional), choose AA method; Engine/Rendering/VR: Check Instanced Stereo. Put a post-process volume in the level and adjust it accordingly. Be sure that the SteamVR Game Mode (SteamVR_GM) and Steam_player_controller have followed if not recreate them.
You should now easily migrate one of these 3 pawns into another project. More example pawns to follow soon.
Great work yet again.
the last UE4 VR Grippable Motion Controller Plugin (Last updated 2016-06-10）
can not rebuilding on ue 4.11.2,
error: xxx could not be compiled,try rebuilding from source manually
Can you get me the build error for it? I attempted to keep the plugin backward compatible but I don’t have a 4.11.2 install to check with anymore, should be fixable still, there hasn’t been enough baseline changes since 4.11 that I can’t support both.
I came across a problem with the latest version, if you’re in a camera fade out zone then that you teleport to a normal zone, the screen stay black and walking in the room or teleporting again doesn’t help.
Edit : I fixed this by simply adding a “fade in” in the teleportation blueprint.
Edit 2 : I wanted to make a blueprint that would only be used to fade out the camera when the player enter a wall, but I have a weird behavior :
(It’s exactly what you did in the level blueprint)
The actor is only a collision box and when I enter this volume with the head, the screen stay normal and when I go out the screen start to fade out and now everything is reversed, like the collision box is a normal zone with a fade in and the rest of the world is a fade out zone. The weird thing is if I trigger the volume with the controlers, it is acting as expected (the same as what you did in the level blueprint). If I change the begin overlap by an end overlap, it is acting the same way for the head and reverse for the hands (so now the hands acts like the head). Any idea why this happen ?
(also I changed “from alpha” to 1 and “to alpha” to 0 to see what happens, and now when I enter the fade out zone it fade out but only to something like 0.5 transparancy, so I can still see the world but darker and when I go out of the volume, it fade in, so it’s better but I don’t know why the screen is only darker and not black ?)
Is there a built in method for swapping from the hands to the Vive model of the controllers?
Thanks for the project, looks very promising for learning the ins & outs of the Vive.