If it is a grippable object base then you can simply change it in the VRGripInterfaceSettings on the object. There will be a grip type dropdown that you can change.
Thanks for the help! I’ll give it a try!
Pushed a new commit to the template and plugin - I’m still waiting on someone with touch to test something for me but the rest of it should be ok.
Template Changes
Changed up the VRCharacter so that gripping and using is also gameplay tag defined now.
Everything is now run off of one generic function that manages any button passed in
by comparing gameplay tags. Falls back to default tag values where appropriate.
*Note* Original character is now "VRCharacter_Legacy" and will be dropped at some point.
allowed me to delete many extra functions that were pretty much just re-implementing
drop or grip logic for different buttons.
Removed a bunch of functions from VR character that were not needed.
Sorted all functions in VR character into categories.
Unlinked all OpenVR specific code (except for the controller loading since it just fails when out of platform).
Added an example StereoViewIndex post process material with a custom node that returns the eye index both in AND out of instanced stereo mode. can be used for
stereoscoptic textures.
Added HadHandSpecificSlots to gameplay tags so that the GetCorrectSocketPrefix can return VRGripLP or VRGripRP / VRGripTouchLP / VRGripTouchRP.
Plugin changes
initial setup of lever component, working on physics side of it.
Combined axis enums from button and lever components into EVRInteractibleAxis
Couldn't find a generic public XYZ enum in engine already to use.
*Note c++ lever component is still unfinished in update*
Added an OverridePrefix string intput to the FindClosestSlotInRange function.
more easily allows the end user to do things like controller (touch vs vive)
or hand (Left vs Right) define custom grip sockets to a mesh.
IE: Pass in VRGripPLTouch for Left Hand Touch socket.
Moved secondary grip information into a seperate struct in the grip structure, not only does allow me to add some replication specific
additional properties to it. But it also should be more efficient to replicate as I can boolean control its replication without forcing
NetSerializer on the main struct. It also lets me just pass the struct for notification functions.
Added bIsSlotGrip to both primary and secondary grip structs, can be set when calling the grip function, useful for checking in the object later on.
Made it default to set physics gripped objects Center Of Mass to the controller location for the grip.
Added Option in advanced physics to turn off setting COM to grip location
Can you open the “Playable Template Demo” in the UE4 editor?
Thats a packaged EXE, the “Example Template” that you can download is what it is packaged from and can be opened from the editor.
I made a new project with the VR template and installed your OpenVR to “Plugins” folder in the new project but I’m not sure what to do now 
Follow the setup tutorial linked in the OP
I did and I’m still lost I just want the gun that you can hold with 2 hands at certain points of the mesh.
Well you can use the pre-compiled binaries, but the step by step of compiling is going to make things easier in the end with packaging and upgrading with engine versions.
Also I’m afraid to say that plugin isn’t totally without a learning curve / barrier to entry due to being far more complex than the built in template and containing source instead of being entirely blueprint.
Hello ,
I love the work you’ve done on plugin. truly fantastic.
In the VR Template, the collider on the VRRootComponent follows the X and Y movement of the HMD. makes sense, as it is a cylindrical “full body” collider by default.
Is there a way to have it follow the HMD’s Z movement as well, for a spherical “head only” collider?
I would normally just put the collider as a child of the camera, but I do want to block the head from moving through walls.
Ooooh. Well now I feel silly.
That does make things a lot easier. However, it seems that in certain situations that doesn’t quite work. I found that if the trace fails and it falls back on the “overlap” method, it will use the “ComponentOverlapComponents” function. It’ll pick the first value in that array and ignore everything else, and component might be the one set to not be blocked by VRTraceChannel. I found that means it’ll grab onto these components away if they’re attached to something that implements with VRGrip Interface. For example, if you have an actor consisting of a smaller static mesh surrounded by a larger collision box, you can grab onto the larger collision box on the event of an initial overlap despite it being set to ignore VRTraceChannel due to the fact that it’ll still implement VRGrip Interface.
My solution was pretty similar to the last one. Rather than picking the first object in the array, I removed any objects that ignored VRTraceChannel. After checking if anything is left, it’ll then pick the first object in the array. Probably not the best solution, so feel free to let me know if I’m being dumb again, but it seems to work just fine.
Also, since it was my first post I’m pretty sure the site made it invisible until it made sure it wasn’t spam. Probably why you missed it.
Hmm, your edge case is correctly bugged then and your solution is useable, I had not considered bounding geometry around the overlap attempt. However instead of directly denying it there I made a new function “IsValidGrabOverlap” so that the filtering can be overridden further. Newest version of the template has it corrected.
However what it does is loop through overlaps and returns with the first one in order that collides/overlaps VRTraceChannel.
I had forgotten that the grab sphere now overlap with all geometry not just vrtracechannel, behavior was caused by that.
Currently? No, that actually would involve a surprising amount of re-coding of the entire character system, due to how ingrained floor detection and offsets are it would be even more of an overhaul than the VRCharacter already is. Let alone trying to handle cases like the head moving over an object that is below the neck and deciding if it should be the new floor for the player or not.
I had proto code for adding a second collider only around the head and running additional logic around how both capsules behaved, however the results were inconsistent and not what I was looking for at the time, also without integrated waist tracking I don’t foresee them being good enough to spend a large portion of my time on.
If using only “flight” style movement something of the sort could likely be achieved by setting the capsule height to something very small and adding to the VRCapsuleOffset in the Z direction to center the capsule around the camera. However as soon as a walking / ground based movement was introduced it would break down as it would find the floor off of the new location.
Sorry for late reply, your post got buried. It should already work as an interactible hud, you can directly load the server menu up in one and use the options (that is what I was testing with initially).
Thank you for the swift reply, That’s exactly what I’ll do, as there won’t be any ground based movement.
On an unrelated note, After implementing the plugin into my project (following the instructions on page) https://bitbucket.org//vrexpansionplugin/wiki/How%20to%20add%20the%20plugin%20to%20a%20blueprint%20only%20project%20-%20Step%20by%20Step)
I can open my project once just fine, but from then on encounter the following error upon opening:
“The following modules are missing or built with a different engine version:
UE4Editor-OpenVRExpansionPlugin.dll
Would you like to rebuild them now?”
Which upon selecting yes, has yet to succeed (Although I haven’t given it longer than 20 min or so)
I’m currently using 4.16.
Is an issue that you’ve seen before?
We can test it out on Touch, . What is the test procedure?
The launcher does not correctly compile plugins, you’ll have to launch from the compiler and compile it.
I got someone to test for me, it was to see if the automatic oculus / vive check on BeginPlay when running under steamVR was working correctly.
So far it is, I wouldn’t mind some ModelIDs from people though for their hardware though:
https://drive.google.com/file/d/0B5cM3oP2O4-UU1gzT1hiWWs0MzQ/view?usp=sharing
Left controller should say the model ID of the HMD, right should say the model ID of the controllers. I’m curious as to if all current gen Vives say the same model designation as mine and what the touch controllers print out.
Getting strange green artifacts only when playing in vr preview. When in editor everything looks fine…
Looks like screwed up reflection captures or you have Global Illumination on and bugged.
Ashamed to say, but I don’t actually know how to do that. Could you point me towards a set of instructions to launch from the compiler?
The step by step should contain a section for actually compiling.
