Thank you for this. 1.6 seems to be working good. There are some load errors though that others have mentioned already.
Btw, I solve the playerStart problem yesterday. Basically, you don’t need to have your pawn thrown into level. You just need to still make playerStart off the ground so initial spawn can work properly.(instead of spawn failed and thus you control only default pawn’s camera and thought controllers are failed to track).
Then in the pawn begin play, do a trace and find the closest ground location to offset/teleport. This will then allow level designer to place playerStart anywhere and also allow using different pawn on the fly if GameMode are designed to switch Pawn classes.(ie.player class picked before join the lobby.)
Also, I found that somehow controller is not matched 100% from time to time, so there might be a need to feed to check/reset position/orientation. I’m not 100% sure yet, so will report back if I make any progress.
Where were you finding the controller not matched? It sounds like a loss of tracking issue with your lighthouses to me. You might need to angle them downwards more and re-define the play area.
Note, the mismatch is minimum, if you hold it on hand you probably won’t be able to perceive the changes. But use ground it’s pretty obvious.
Yes, I think the offset happens after controller lose and then regain tracking. But since I didn’t have time to fully test it so I’m not 100% sure about this.
Usually after regain tracking and move a bit more, it will fix it self. But yesterday, during stream I demoed how to recalibrate floor. But right after that, when I did some other test, one of the controller no longer sit on ground properly.
(left hand perfectly sits on ground after some test before I end stream, but right hand controller is float a bit higher.)
So what I said is just a head up, so we can look into this problem more seriously.(instead of rely on the firmware to fix tracking over time.
Ug, well this was more annoying than I thought it would be, but I think I have a fairly generic plugin now that has a custom motion controller with pickup functionality that includes sweeping collision (if asked for when calling the grab function). It also has an option to just sweep the root components of all attached actors as well.
It takes an input transform that defines how far away from the controller to retain the object, so if you have sockets on it you can offset the retention transform by the sockets location and have snap to grip location functionality as well. The default would be to just pass in the actors worldtransform and it will do as the video below shows.
0hCXV0-YDyQ
That sounds great PenguinTD. I literally was just logging on here to discuss this issue and your post was the first one I read. I had my Player start set at 0 height before adding the Vive_Pawn… everything worked fine (after also fixing my VRCharacter’s capsule collider which was pushing up the start height). After switching the pawn in my game mode with this Vive_Pawn, the hand controllers vanished. If I move the player start above 0, using the default player start capsule’s height above the ground, the hand controllers reappear. But then, the start height of the experience is too high above the ground, like you start out floating above the scene. I’m really surprised the player start height issues (with the hmd and hand controllers) aren’t reconciled by the SteamVR plugin within Unreal. It seems everyone is just left floundering to find solutions. Very disappointing. Getting Vive going in Unity was a cake walk compared to this.
Looks great! Have you thought about using IK to keep the hands from moving while stuff is colliding?
Anyways, in other VR dev news. I may have mentioned I am developing a realistic weapon system for VR. Well, one thing I have learned is that we can no longer use the same cheats for guns we have in the past when it comes to aiming in vr. Yes, that means you need to properly zero guns, and, even more problematic, red dot/holographic sights have to function like they do in the real world (hint: the dots are not stationary in the viewport). Also, because sights need to be zeroed at specific distances hitscan becomes undesirable (you need bullet drop at this point). There is a way to use hitscan without zeroing but its function is a workaround and it won’t work with holographic sights without some inelegant hacks.
Just food for thought. If anyone is curious i can explain more thoroughly.
Version 1.7 changelog
- Detailed documentation
- Disabled picking up until next iteration
- Added Settings Menu
- Added Ghost move
- Added particles system with teleportation method 1
- No go teleportation zones with camera fade out
- Basic vehicle (early version): Step near the vehicle to take possession / control with left trackpad; disembark with right menu button
- Fixed the 2 moving platforms for testing purpose:
one by simple actor move (embark/disembark by triggering overlap volume)
one by matinee (press left menu button to embark & move and to stop platform)
@PenguinTD Feel free to modify/branch the template whatever you like. It’s an open-source project. What I propose is to try everything that is submitted and integrate it within weekly releases. But off course one-size fits all is not always the best thing for every project, so specific needs may require different branching. For what I think the engine have a hard time moving the SceneRoot and managing pawn movements on its playground when it’s not directly under a controller influence. Dynamic shadows are very resource intensive and I would think they are the topping on the cake that makes it difficult. For now on in 1.7 the 2 platforms are without glitch but I’ll plunge into profiling to find the culprit. I’m developing on a 980 but I’ll try it also on a OC 980Ti.
The playerstart is a good point. However, 2 things: Am I dumb but now (with 1.7) whatever I put a PlayserStart in the level, and whatever I put my Vive_pawn or not in the level, I always start at 0,0,0. Do you have an idea I think I tried everything.
@dmorgan I’ve not been able to replicate the error. 1.6 worked well but try 1.7 instead.
@spaceWumpus For what I know r.setres will set the resolution of the mirror on your monitor. I set it up to 2560x1440 because it’s the resolution of my main monitor. r.ScreenPercentage will supersample and attenuate the blurriness carried out by anti-aliasing methods. You can try it yourself the lower you set screenpercentage the blurrier it gets; values higher than 150-175 will make the engine unstable.
Next iteration v1.8:
- I’m amazed by ** plugin**, and if he doesn’t mind I’ll put it along the template when he’ll release it. I’ll put also objects/tools/weapons along to try picking up things. The reason why I will not use environments like the stylized low poly one on the marketplace is to keep this template open-source, without any copyrighted assets and as small as possible.
- Fixed vehicle: Embark/disembark switch (with controllers), will look at vehicle location in relation to vive pawn; probably will be better following hands collision pickup
- Inclusion of Vive_Character
- Vive_pawn and Vive_Character spawn on PlayerStart
Feel free to contribute !
Thank you. A wonderful article
Hero! I will test it as soon as I can! Thank you so much!
You could hide the default controller mesh when grip starts and spawn a new one with same transform and attach it to the gripped object, that way they wouldn’t separate from each other but the hand would also be stopped (other methods would cause them to still separate on collision as each would collide by themselves). The default template controller mesh is parented to the controller component so it will work weirdly for what you want if you try and just offset that one.
That being said it feels strange to have your visual representation of your hands be blocked by things that don’t block you in reality, would probably want ghosted controllers still or just not stop the hands.
Ok the plugin is located here: https://bitbucket.org//ue4-vr-grippable-motion-controller-plugin
I haven’t built all .dlls for it yet so you’ll need a compiler setup to use it with blueprint only projects and I am currently making sure that it packages. This is just an early version to see how hard/easy it is to use off the bat and if people have issues.
I would highly suggest that you read the readme, there are some things of note with using it that will save me (and you) some pain in debugging and using the plugin.
@ - Awesome work man, your system seems to have all the features I want 
My current implementation is similar but uses a physics handle, and thus isn’t ideal for the reasons you mentioned previously in the thread.
@PenguinTD Forget it it seems I had a problem with the DefaultSceneRoot. I replaced it with a fresh one and now PlayerStart works.
I’ll try plugin tonight, that should solve the vehicle bug at the same time.
@ - Have you tried networking your Grip plugin yet?
I imagine the naive implementation of just replicating the position and location of the motion controllers to remote clients, then doing some interpolation would probably be alright, if not perfect.
Yeah it isn’t going to be the hardest thing to get working, it just wasn’t immediately a concern. You’d have to replicate the GrippedActors array and handle authority with movement, the controller location is already replicated. I would worry most about how best to handle the late render updates and keep attachment smooth on the client side.
In this new 1.7 template I keep getting spawned inside nearby geometry when I put my Vive pawn on an imported static mesh. It doesn’t appear to be inside the collision box either. Anyone else experiencing this?
@AxelHunter I just installed UE4.11.2 on a new computer today and opened the .zip file I sent yesterday (so on a 3rd computer on my side) and everything works. Did you opened it as a template, and with 11.2 (not 10.4)? Pretty sure there no files problem with 1.7
Very cool, do i need to wrap my blueprint project in c++ to use it?