Early implemented a new method of handling the controller late updates that Epic is
using in the upcoming 4.18 patch.
It utilizes a double buffer for the scene references in the render thread and effectivly
solves the high velocity tracking issues that were very evident before (when moving fast
the controllers late update would send them flying all over).
also started adding some comments for incoming 4.18 changes to remind myself.
There will be a lot of changes incoming due to OpenXR starting to be supported in engine.
I have some custom hands set up similar to how they are in the VR project, where I reuse the right hand mesh with inverted scale for the left hand.
There’s a socket on the mesh of a Grippable Static Mesh Object where X, Y and Z is changed (none are 0). It works good on one hand, but the Y is flipped on the other. I was thinking of multiplying the Y by -1 before the attach but I think the attach/parenting happens in code.
Edit:
I think I found what I should be using.
Set the gameplay tag “HasSeperateSocketsPerHand” (on the grippable static mesh? I assume) and then create 2 different sockets named “VRGripLeft” and “VRGripRight” on the mesh.
Next Edit:
I added the HasSeperateSocketsPerHand game tag to the Grippable Static Mesh Base Class (verified it’s still there for the child Actor I’m testing it with), but it seems VRGripLeft, VRGripRight isn’t recognized. (tried VRTouchGripLeft/Right, too even though I’m on a Vive, but that didn’t work either)
I don’t actually attach anything and the gripping isn’t based off of the hand mesh, it is based off of the controller itself. Unless you actually flipped the scaling on the controller instead of the mesh you aren’t running into problems with that.
What you are running in to is that the socket orientation is correct, but only into one palm. You are correct that HasSeperateSocketsPerHand is the way to do it in the template but you used the wrong Socket Names.
VRGripLP
VRGripRP
LeftPrimary / RightPrimary
You can go in to the “GetCorrectPrimarySlotPrefix” function and change those if you wish, it really should be in a variable somewhere instead, but not the largest deal.
Added a bunch of functions/nodes to the OpenVR library to control overlay skyboxs and loading systems. They are detailed in the wiki entry below.
[https://bitbucket.org//vre...unctionLibrary](https://bitbucket.org//vrexpansionplugin/wiki/VRExpansionFunctionLibrary)
Corrected an issue that the Epic Motion Controllers have that was evident in my overrides of them, now removing the late update scene view if the motion
controller is deactivated. Otherwise late updates would continue to be used and visually it would appear as if the controller was still active.
Sheit, I apologize for wasting your time! You’re right, I wasn’t flipping the motion controller scale.
You actually told me you’re parenting it to the controller itself before, but I forgot…
Awesome thanks a lot. Yep, changing it myself is no problem at all. Thanks.
Jsyk, I actually searched the whole thread for “VRGrip” and didn’t get any VRGripRP/LP hits. Checked out Bitbucket VRGrip Interface section too, but didn’t see it there.
Damnit, sorry. I forgot I was using the (a hacked) template character.
Having hooked it up, unless I grab the object close to the socket it’ll just parent it to the controller with the offset.
Was it always like that? I thought if the mesh has the right-named socket it would always snap to the socket regardless of where the mesh is grabbed.
Edit:
I found that Closest Primary Slot in Range’s “Had Slot in Range” was returning false most of the time. Unless the grab sphere was almost perfectly encapsulating the socket it would return false. Looked for a range variable, in hopes of increasing the range, with no luck so instead just removed that check altogether.
Now it’s easier to grab stuff and have it snap to the socket, but if I grab an object such that the grabsphere is barely touching it, the mesh’ll launch in the direction of the socket without attaching. lol
There is a grab range variable, its in local space to the socket so object scale effects it, you can either up the range, or override the HadSocketInRange function in the object itself and always return true and one of the sockets.
You also likely have auto drop distance very low if it is dropping right after being picked up.
Cool thanks a lot for the superfast reply and info! I didn’t know scale affects it. Awesome!
I’ll look around for the grab range and auto drop distance vars. They were all left at default.
The original mesh, unscaled, is a sphere a little bit smaller than the size of a volleyball.
I’m seeing the issue about 20% of the time when it’s scaled down to half (xyz .5; size of a wiffle ball),
and 90% of the time when it’s scaled to about a quarter of original size (xyz .25ish; size of a golfball).
I’m away from work so can’t give exact values.
I could easily just import each of those meshes pre-scaled.
Would you recommend it’s best not to muck with scale in UE4, outside of the mesh scale functionality you added to VRGrippables a while back?
its in local space so that if the object is 10x normal size you don’t have to grip right as the center to grab there and if it is 0.1 size then it isn’t larger than the object itself.
You can just set the range waaaay larger, override the HasSocketInRange function, or pre-scale the object like you said.
It used to be in world space for the radius but it proved better to do it way for the reasons above.
If you set the radius to the size of the object itself then it should work though.
Just started playing around with plugin a bit using your template, looks very promising. I’m having a rather peculiar issue however, I added my own actor - a sword, just a simple grippable one. I can grab it just fine and swing it around - but after a few seconds, maybe 4-5 seconds it just disappears.
Am I missing something?
Also a pretty odd question, but what do you find to be the most convenient method of developing for the VR? I’ve got the deluxe audio strap, but it’s still quite a bother having to take the headset on and off every few minutes. I’m scared resting it on my forehead will mess up the lenses
I just found plugin while looking for help setting up collision on a VR pawn. Looks amazing. But it appears the template you have up for download is for 4.17 (even though the description says its for 4.16), and I was wondering if you still have the 4.16 version available somewhere? My school’s VR lab hasn’t updated to 4.17 yet, and I’d love to play around with .
Not quite sure either, just tried importing another mesh and it does the exact same thing. 4-5 seconds after gripping it - it disappears. time I imported a simple weapon mesh and modified the GunBase. Will do some debugging later and see if I can figure out why.
Are there any plans to add support for grippable poseable meshes? I reckon using a poseable would be a convenient way of managing various parts of a rifle(pulling the bolt etc) since you can easily manipulate bones with component. A bit cleaner than having to use separate meshes.
You can drive a poseable mesh off of one of the grippable sphere / box / cylinder components, ends up cleaner as otherwise you are going to be looking for overlap with bones on grip and gripping specific bones on the same mesh. Using these invisible components not only lets you define specific collision sizes for the grip, but also run additional logic easier.
Seperate meshes aren’t required, just pulling a % of travel off of the range it is allowed and driving a bone or animation off of it works fine.
Its also difficult to make something generic enough with defining grips on specific bones which may be chained so that it works for all uses, it is far easier way.
Anything super specific like following a spline can be done with a CustomGrip type anyway (though I think I will be adding a spline follower component soon).
Edit Or were you talking about making a custom grippable actor with a poseable mesh base so that it is easier? Because that is a valid point if so since they are only components in engine by default.
Aye, that’s what I meant but the former should definitely work as well. Will just have to experiment a bit, I’m so used to using poseable meshes as of lately as animating isn’t really my thing, whenever I fiddle with animations I break stuff. :rolleyes: But simple stuff such as moving a bolt back and forth shouldn’t be any issues.
I do like how you’ve set up the gun, that it eliminates minor erratic movement so you get a smoother experience. A lot of VR games with weapons fail to do and just forget the fact that you get majority of your stability by pushing the rifle up against your shoulder. Great job!
Hi mordental,
First thanks for you plugin which is a big help to become friend with VR in UE4.
I am using your VivePawn Character from your Template in my Map and I have a User Widget with a ScrollBox (with horizontal orientation) and I remark that the Laser Pointer can’t interact with the scroll bar.
Do you have any idea why the laser pointer is not working with?
Thanks for any help.
I’m working with 4.17.1 and your plugin version 4.17.
I have the same issue as mentioned above :
Result: The Scroll box cannot be scrolled by clicking and dragging the scroll bar
Expected: The scroll box in the widget component would be able to be scrolled by clicking and dragging the scroll bar
I will do some checking again.
