Thanks @PenguinTD you can’t imagine how it is appreciated! The rapid turn around time is motivated by the strong motivation of converting/enhancing our DK2 experiences to Vive room-scale. That’s why I won’t be satisfied and will work like a slave until all features work 100% of the time.
It seems I still have some things to understand on how SteamVR is handled in UE4. Let’s say that there’s no withcraft into developing a character who can grab things and teleport on platforms on a standard port or even the DK2. Give me an hour starting with the FPS template and it will be . But for the sake of humanity, everything works differently with the Vive. As Yoda said, “You must unlearn what you learnt”. In the last few days in the office and at home I looked like a madman trying to grab an imaginary wand in front of me!
You’re right about the gates it’s exponentially more elegant and reliable than bools. However, it’s more rapid for development and debugging, at the cost of inducing itself bugs. I’ll try to banish them as well and redirect data through gates.
Sorry for the rapid development pace in the future I’ll announce on my next iteration date. I thought it would have taken 1 hour to solve the grabbing thing and finally it took me 2 full days to have a method which is randomly reliable. @bitcloud1 I updated yesterday to 4.11.2, standard launcher. Don’t know if it still works, but probably, with .1 or .0. I’m too busy today but I’ll dive into it again and examine closely Penguin’s changes tomorrow night! Thanks!
@Proteus I think the grabbing difficulty might have something to do with the controller setup, in order to “grab”, you can’t collide and then the collision send it too far away where it left the trigger volume.(assuming you are using a trigger volume for grabbing.)
In VR things, hands moves a lot faster compare to mouse which basically don’t move if you don’t touch it. One thing to do is to setup a haptic feedback where if things are in volume, let user know they can grab. Then you will know the timing, if you never get feedback, it was hit away by collider, if you get feedback but can’t grab, your volume is too small, if you have feedback way too early, then volume too big. Normal human reaction is about 250ms+, with anticipation it’s much faster. While I “think” grab is easier, it’s better do it first before claiming this way. lol, also thanks for your hardword, kept me on my toe to try keep up with the update. yep, an update announcement is good, other wise I might enjoy myself too much in other VR games.
Proteus, first off…Thanks for putting all this together. Its amazing. I’m new to UE4 so your work (and everybody’s contributions here) have been a big help to me. In regards to the grab/pickup solution: I’ve been struggling with a proper method for a few days now myself. Last night I was able to get a single hand working pretty well utilizing a physics handle and attach to node. Its not pretty but perhaps this will help people as a reference. Its not without its own issues. Also if anyone knows a cleaner way of accomplishing this, please let me know. Like I said, I am really green, so for all I know this could be complete trash or have a ton of redundancies.
I started by trying to apply tesla dev’s physics handle tutorial to motion controllers. Using the physics handle worked great (allowing me to pick up any object that simulated physics), but the rotation of the grabbed object was not quite how I wanted things to react with the motion controllers (things kind of floated out in front of me). To remedy this I added an attach to / Detach from parent nodes to the BP and things worked exactly as intended.
I’m currently dealing with trying to get this to apply to the L hand (things went to **** when I tried duplicating the nodes and swapping out the R vars for the L vars). In that process it also added a fun bug where the R hand action works as intended but if I move the controller to fast when holding and object (I.e. throwing an object) the object locks to the hand and then after a few clicks of the trigger both the object and my hand mesh vanish.
If you are attaching it to the controller than you might as well not be using the physics handle at all. To change the physics handle to not have the object “jiggle around” you need to set Constrain Rotation when calling “Grab Component”. When you attach it with weld enabled the physics handle isn’t doing anything anymore as it is then locked to the controller itself.
Attach to has issues with clipping as it will not stop moving when passing through objects but is a perfectly valid way of doing it on its own.
Thanks ! I did try constraining rotation but all it did was keep the object from rotating crazily while it still floated out in front of me and not moving as if it were in my hand. Would you say there is a way to get the physics handle method to operate in the intended “hand held” manner? Or is this an action better suited with the attach to node? I appreciate the input!
I wonder also if scaling/transforming the controller mesh can also play a role in the grab precision. I’ll go back in Maya and arrange properly the controller mesh/pivot .
You need to set the target location/rotation per frame pretty much. Physics handles are a problem with motion controllers though, they LERP to their intended position and so they don’t “stick” to you like they should. I think really to do it right will need a combination of “Attach To” and if it is colliding with something to offset it’s position locally so that it doesn’t pass through or something of the sort (probably a custom physics handle is going to be required).
I guess you could fake that by doing what you are doing currently and leaving it attached with a physics handle, and if it collides with an object you un attach it until it is no longer colliding, that way it would interact with objects but you would still get the free movement positioning otherwise.
@ it seems you have more experience at this grabbing part. Can you briefly list what’s currently available mechanism in blueprint? What they actually do and what’s their limitation.
Ideally, we need to achieve 3 things:
to be able to grab things and move with our hand with no visible delay, preferably the object orientation stays where it was right before we grab, or fixed orientation(for things like weapons/guns)
since object will feel weightless to us, anything velocity(angular as well) we applied need to apply right after we release the item.
grabbed object clipping can be switched on/off, some game design decision might need the object to clip through(like light sabre), some need to hit object adhoc(like grab a hammer to smash object), some need to bounce off/stick(like if you grab a ball but your hand clip through wall, ball need to bounce off wall)
The first two are just “AttachTo” using “Keep World Position”, like I said before I have an overlap collision only sphere on my controller and when I press the trigger I attach the object to the controller if it is overlapping. For specific grips I have a component that designates grip points, if the grip location is overlapping the grip point then when it attaches to the controller it uses the grip orientation and position instead.
Anything with collision attached to the controllers will have their angular and linear velocity states change when the controller moves, you can just set to simulating on release.
Clipping is harder, the current physics handle is NOT up to snuff as the translation from the current position to the target position is way too slow, I started modifying it in a new class but so far haven’t found a good way to get the non colliding state of it to track fast enough yet, I may end up cheating it instead.
The physics handle just uses a physics constraint btw.
That’s wonderful, UE4 community is fantastic.
What I propose here is to update the template weekly with the best solutions,. Iteratively, we should be able to define a high quality template. Most of features can be adressed in different ways, I intend to keep every possible solutions that works well cause the best solution can vary between games.
I’ll try every suggestions found in the thread and others, and if contributors could eventually point links or gits that could help put the efforts on resolving problems rather than spend hours figuring out how to enable these functions
I’ll also try to add hands meshes and animations, as well as toys to play with to test the interactions. It would be interesting to have a plyground similar to toybox to test the Vive.
Anyway, I propose tuesdays 21h00 EST as weekly deadlines to integrate everybody’s weekly contributions and release a new version. In the mean time I’ll begin to test local multiplayer, just to give it a try.
Something you might want to consider Proteus is that the collision for the controllers is just one giant oblong shape right now that is significantly larger than the model itself. I auto generated a closely fitting convex hull for it and that solved a lot of the collision issues where the controller wasn’t touching the object yet.
The problem is that as soon as you attach something it can no longer collide with stuff (stuff can collide with it though). I am making my own vive vr system with guns and realistic reloading. Epic needs to allow children to keep their collision after attaching. Its on them and there is no work around.
Please fix this epic. You are letting Unity beat you in the VR space worth this negligence.
@ Thanks I don’t know why I overlooked the complex collision on the controller. . It improves a lot the grabbing, even on my crappy 1st pick up iteration.
I returned to the basic pawn and I have few basic comments
Deleted the arrow component since it’s your position an orientation relative to the scene root (the center when you calibrated it) that is taken into account when you begin game. The starting position in UE4-Vive is relative to the center of your playground when you calibrated the Vive; your orientation is the north of your playground. If you want to offset your orientation just rotate the Vive_Pawn in the level. The orientation of PlayerStart in the level has no meaning/effect. @PenguinTD on my first attempt to grab things I was using “OnActorBeginOverlap” which is not exactly a trigger volume. I did so to be able to rapidly extend the pick up ability to all things around. Very good idea using the ff when approaching volume. One more thing in the next update. @dreetjem Yes at least in 1.6 I can teleport on stairs (it will follow the mesh collision volume whic is not 100% accurate – you could have a 100% accurate collision hull by adjoining 8-10 collision boxes, but I don’t see the point). However, the stairs are like 30 cm wide each and of course in room scale you’re glued to your real-world setting so you cant follow the relief unless you have the exact same thing laying in your real-life playground. That’s an interesting new thing to consider in room-scale. @OneShotGG did you open a ticket with Epic? Surely this can be fixed. I know Unity has been faster in implementing the Vive (and even now the Hololens – don’t start me on this) – but I’m confident they’ll keep up.
Now the questions
1)In SteamVR mode, you’re carrying your “house” like a snail: basically your SceneRoot (the center of the playground, grounded) and everything around and in relation to it, including you. But what would be the ideal capsule half-height and radius? Leave it to the default one (which is 96 and 55 by default in the FPS template) Ideally, should it be tailored to player height? Is is still relevant? From my inductive thinking, I consider that only head collision (attached to the Camera) and controllers collision (handled by their PhAt, which is driven by the auto-generated complex hulls collisions) are considered. Standard, pawn capsule collision is irrelevant since 3 things are tracked: HMD and 2 controllers. I removed the pawn collision capsule and kept only head collision.
2)Any other suggestions to resolve the flickering (possibly caused by the frame-skip) when on platforms? The solution will probably also resolve the difficulty to escape them.
Doing a great job with this. I just got my vive the other day and playing around with it in here. From next week I will definitely start helping out and give some commits back with some extra functionality.
Creating a Toybox style level seems like a good open source project and something that would be very helpful to a lot of people. I will probably start working towards something like that while I figure out all the different capabilities of the roomscale and tracking with Vive so will happily push it back into this project.
I looked into it, it is fixable, but not BP only. You are correct though, default implementation only simulating objects collide with an attached actor. I’m mulling over which would be the simplest fix out of a few options.
I don’t think Epic is going to “fix” it by the way, as far as they are concerned for standard games it is the correct behavior. I’m pretty sure it will require a new derived pawn with some overridden functions to do correctly with VR. They might do that themselves in the future but for right now it appears to be on us.
@CatherineYT I’ve been unable to recreate this error. However SetActorLocation is only used in the level blueprint to move the platform #1 (the building error point at this function). There is the function as seen in 1.6:
If we are doing this, do you think we should have a branch? or should we work on a “plugin” style that have this extra pawn class and other exposed function until Epic release their official build?
Since I also really want to have some OpenVR function exposed in blueprint. I haven’t fully go through how Epic integrate OpenVR api yet, so I can’t say for sure how self contained we can do if going plugin style.
Another impact is this would definitely need to have binary build that can go with this template, install and howto would be a bit more complicated.
Well, it’s new, so I guess people will have to endure this.
Would probably be best to release as a plugin so it will work with BP builds, much like some of the other plugins I’ve made. I think I found a workaround with a new motioncontrollercomponent subclass, trying to clean it up so I can test tonight.
Plugin is not a bad idea it’s more user-friendly than branching, unless there’s a critical component in need of additional tweaking. From discussions it’s becoming evident that some coding is required in the form of a plugin.
However it will be entirely onto us to test/update it with every new Unreal update. Guess it’s the way to go until it’s integrated within standard release.
Normal human reaction is about 250ms+, with anticipation it’s much faster. While I “think” grab is easier, it’s better do it first before claiming this way. lol, also thanks for your hardword, kept me on my toe to try keep up with the update. yep, an update announcement is good, other wise I might enjoy myself too much in other VR games. 
