Thanks it’s working now with the Offset by HMD toggle. I noticed they are showing up under “Invalid” with “getValidTrackedDeviceIds” after the driver rollback, but they’re still working though your plugin without SteamVR beta branch somehow, and thanks for enabling more trackers.
Mmm, Invalid is just on epics end, I just assumed that the rollback would have changed their index’s back to the old values, but appears not. So should be good to go for awhile.
I didn’t realize that you were opening two projects at once, that WILL break SteamVR, actually I am surprised that it let you get away with it, used to fully crash out of the editor if something else tried to take over.
I downloaded your project anyway but it doesn’t appear to have anything wrong in it, I would suggest never loading up two projects at once with VR plugged in, if you want to migrate then use the migration feature or just don’t expect the tracking to work in both projects at once. Even when not running PIE the editor still keeps hands on SteamVR due to being able to hotload into and out of the VR editor, as well as the SteamVR Plugin module loading up references when accessed.
Edit Also for future reference, if sharing a project in the future, delete all Intermediate and Binary folders (one for the project and one for each plugin module). will greatly reduce the size of the upload / download.
Thanks a lot for the info. I actually looked around for threads about running 2 projects (not VR, tho) at the same time, but didn’t find anything. I know now it’s not.
Whenever I open up that rocket2 project while another, good project is running, the good one gets permanently ruined (whether I save or not before killing everything, and then relaunching the formerly good one solo).
Is there some kind of cache (like in SteamVR) somewhere that’s mucking up the motion controllers?
You got it. I apologize for that. I’ll never do that again unless instructed otherwise.
I’m trying to do a sanity check and was hoping some other could chime in with experience. I’m trying to figure out what is different between a clean install of the examples project for the VRextension plugin and the vanilla epic VR template in a fresh project. (Switched to the forward render) as far of optimization or performance with lighting.
I’ve got a really small scene about 16ft x16ft with with only 30-50 at any time in a scene. Nearly everything is a moveable object and I’m not using any static lighting.
- 1 Direction with Shadows (moveable) Lighting Channel 0 (default)
- Skylight pulling from a texture (moveable)
- 1 point light NO SHADOWS on Lighting Channel 1 lighting 2 characters
- 1 point light NO SHADOWS on Lighting Channel 2 lighting some set objects
Everything runs smooth in the default Epic template, but one of those shadowless point lights in the VRextension example scene will induce judder on a Vive.
Anyone have any thoughts. I can’t find much talking about dynamic lights in the forward render an what is a good target. I wish I could bake some lights, but I’m moving and turn them off over and over.
Would love anyone one’s thoughts on . I’m going to go take a walk.
I’m just going to chalk it up to too much overhead in forward rendering. I wouldn’t think shadow-less point lights would be such a hit. But I’m just guessing. For the moment, I just dialed back the screen percentage in the Player Controller from 150 to 110 :(, at least it’s buttery smooth again, and that it’s my number one goal. I’m working with a 980, so considering it’s a target machine experience, I might see if we can work with a Titan or something extravagant.
I’m just happy to have to points in separate channels and a direction (with skylight) running smooth, but it’s tough after looking at the sharper res.
Seems once I reach a certain velocity threshold, the motion controllers’ position tracking gets more sensitive while airborne. (Using “launch character” on “get player character”.) I mean, at higher speeds the slightest change in pos/rot of the actual Vive controller produces an extremely exaggerated/amplified pos/rot of the one rendered in game.
is the same issue I had experienced before using plugin, when I had everything (Camera and motion controllers) parented to a box. (Using “add force” on the “box collision”.)
Yeah, its because of the late update transform, it doesn’t handle high velocities very well, you can turn off the late update at high velocities to prevent it happening. I started investigating a fix for it last week but still haven’t entirely tracked down the root cause yet (or if I can fix it just for the plugin, not all of the scene information is accessible and they opened up a function specifically for late updates that they use).
Epic also switched over to a new method of attaining the transforms for the late update but it has the same problem as well.
Edit mmm, even has a ticket for it, been unresolved since 10/16 Unreal Engine Issues and Bug Tracker (UE-37811)
Forward renderer while mostly functional is also still somewhat unfinished, if you are finding issues with it you should report them in the top thread of forum subsection to let the developers know so they can look into it.
Hey .
I’ve been attaching my weapon AActors to UGripMotionControllerComponent in the usual way (GripObject()), with the default GripCollisionType of EGripCollisionType::InteractiveCollisionWithPhysics. The weapon behaves exactly as I want it when it comes to blocking collisions. However, I’ve noticed that the gripped actor doesn’t remain perfectly locked to my hand’s skeletal mesh (which is a child of the UGripMotionControllerComponent). I’m assuming has to do with the full physics simulation going on. Switching over to EGripCollisionType::InteractiveHybridCollisionWithSweep seems to have solved , which is perfect. I’m very glad you added in hybrid collision type.
However, in your wiki docs at https://bitbucket.org//vrexpansionplugin/wiki/VRGrippableMotionController I see you’ve marked InteractiveHybridCollisionWithSweep as incomplete. Anything I need to be aware of while using collision type? So far it seems to be working perfectly, but are there any known cases where it could break? I’ll be using these gripped actors in a multiplayer game.
Thanks!
Since it is a simulating object that is “constrained” in away to your hand it doesn’t get the perfect 1:1 that a non simulating object gets. You can up the constraint strength and lower the damping to reduce effect but you have to accept the fact that the higher strength the constraint is the less “giving” it is when colliding with surfaces. I changed the gun in the template last month at some point to increase the constraint strength so that it kept to the hand cleaner.
The hybrid grip works perfectly in 99% of cases, that 1% edge case just bothers the hell out of me so I refuse to flag it as finished (it clips through geometry in very narrow circumstances).
Pushed new commit to template and Plugin, will likely be the final update before I move the main branch to 4.16 and lock 4.15 down (major changes in 4.16 to a lot of relevant systems). I wanted to make sure that these changes and features got in on 4.15.
Template
Made several changes to correct blueprint compile errors due to new OpenVRExpansionLibrary setup.
Plugin
Final refactor push before 4.16
Added GoogleVR to HMD Types in GetHMDType to keep sync with Epics
Finally was able to convert OpenVRExpansionFunctionLibrary to a blueprint library only now
that it is in its own module. Uses a static OpenVRGenericInterface just like SteamVRHMD.
***WILL REQUIRE BP NODE CHANGES: Due to not being a component anymore all Expansion library nodes will need to be replaced with the same node again
but without the parent calling component.
**
Added more notes for incoming 4.16 upgrade (Plugin should be good to go day1 of 4.16).
Added SteamVRKeyboardComponent that allows for displaying, interacting with, and getting
data back from the SteamVR Keyboard while in game. Positions itself with the component
wherever it is and polls the events from the keyboard through an overlay it creates to host it.
Is a little finicky due to the keyboard eating controller inputs and displaying the other steam overlay objects.
But is a nice tool at the very least for dev work.
Component has several events that can be Binded to in Blueprint and the OpenVRKeyboard and CloseVRKeyboard
functions.
Hi .
I’m running into a issue with using SimpleVRCharacter with an IK plugin I’m using. The plugin apparently uses the actor/capsule forward vector for things like knee pole vector positioning, and SimpleVRCharacter is currently only moving the capsule around according to the HMD transform and not rotating it when moving around in roomscale. is causing the pole vector locations to appear locked to the original yaw orientation for knees with the IK setup. I’m wondering if there is any way with the plugin to also have the capsule yaw rotation aligned with HMD and not just position for room scale movement? I tried adding my own yaw rotation to the actor/capsule via the HMD on tick in blueprint, but it caused a double rotation.
How do I update the plugin to the latest version if I already have an older one implemented?
Not without breaking a lot of what epic set up for VR behavior (room scale bounds for one, they will rotate with you then which is incorrect, though I guess they are likely already incorrect for simplechar). Also driving view rotation off of character in a networked environment was not something I felt comfortable doing.
If your IK plugin does not have a variable to expose to drive different elements than I suggest you contact the dev and ask for some, because a closed IK system is not exactly suited to VR (or lots of other uses honestly). Generally any good IK system should allow you to pass in your own Forward vector…which would be the VRForwardVector. Without that, it is incompatible with literally every VR setup currently in use in the engine.
I could maybe add an optional rotate with HMD option, but like I said, I don’t like the concept currently.
Safe Method, should be hassle free, has more steps
-
MAKE A COPY OF YOUR PROJECT (can’t stress enough, if you don’t have a backup system you do regardless of plugin updates, even just engine updates).
-
Replace the current vr plugin folder with the new one (delete old one first)
-
Delete the intermediate folder for your project
-
Right click on the UProject and Generate Project Files
-
Compile
-
Make any required blueprint changes for things that were changed.
Unsafe method, may have to revert to safe method if the engines reference precompiled files are messed up
-
MAKE A COPY OF YOUR PROJECT (can’t stress enough, if you don’t have a backup system you do regardless of plugin updates, even just engine updates).
-
Replace the current vr plugin folder with the new one (delete old one first)
-
Compile
-
Make any required blueprint changes for things that were changed.
Thanks! Will update soon then. Your plugin is amazing btw, saved me a bunch of time setting up basics like movement and multiplayer.
I would like to note that I did finally get around to testing on 2017 and it all compiles fine, you just have to make sure that the editor is set to use Visual Studio 2017 and re-generate the solution so that it is correctly set up.
Oh, something else, if it just pulls rotation from what it is attached to, then attach it to the ParentRelativeComponent instead of the root capsule.
Hi ,
Many thank you for your plugin, it has been great to play with. I have a question regarding the Rift and your plugin, do the Run in Place/Arm swing work with touch controllers as they do for vive controllers? If not, is that mechanic possible with the rift?
It should work the same yes, button mappings in the template are likely to be wrong for Oculus since I don’t own any of their hardware anymore but that is obviously fixable.
Ok, makes sense. It wasn’t the capsule forward vector it was using, but the knee bones’ forward vector according to the character input anim, and I was confused because there is basically no input anim, so just the T pose. Yesterday, I was able to get around issue by just rotating my skeletal mesh T pose, in the anim graph before the IK does it’s thing. So far it’s working for me. In the worst case I can just make my own look at behavior for the knees. Out of curiosity would VRCharacter have room scale capsule rotation capability, or same behavior there?
Yeah VRCharacter doesn’t move the root itself, it moves the physical representation of it in the physics scene and uses the offset location in every function instead of the actual actors location. It far more complicated but allows for some additional features, it still doesn’t rotate the actor with it though.
Like I said in my second reply though (you may have missed it), if the problem is the skeletal mesh having to have a rotation (IE, be parented to something that follows rotation), use a Parent Relative Attachment attached to the camera and place the skeletal mesh under that. The whole point of the parent relative attachment is to provide a solid base for Bodies and waists and chests and such and to rotate them with the YAW/Z axis of the head.