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.
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.
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.
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.
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.
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.
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.
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.
Using override CallServerMove now instead of custom function
New grip type Beta InteractiveHybridGripWithPhysics (when not colliding grip makes the constraint stiffness 10x what the setting is so the object matches the hand more closely)
Moved some magic numbers up into const static variables in motion controller component
Some bWalkingCollisionOverride fixes, needed to manually check for walking movement mode to ensure
that it can't run during falling and the like. Removed checking for it in floor find function.
Fixed having actor grips stop simulation on ALL components during grip with physics only.
Should only stop simulating the root comp now.
Made the notify grip and notify drop functions slightly more performant (can be even better but low priority)
Added ability to set a grips Stiffness and Damping after grip.
*Edit 04/20/2017 Pushed another commit to the plugin (Trying to get small bugs and cleanup done before 4.16 so the locked 4.15 branch is as stable as possible).
Fixed server sided navigation, client side was overwriting it.
(Still think client side is way to go for VR).
Removed extra code in GripNotify function now that is has been cleaned up.
Added some explanation to the LocalOnly_Not_Replicated grip replication mode.
Both in comments in source and on the wiki.
I had tried using the parentRelativeAttachment before, and would love to use it, but the issue for me is that I need to drive the base body movement from the pelvis and not the head. Otherwise my IK looks funky because when I rotate my head the whole underlying animation is rotated.
I tried adding an extra parentRelativeAttachment component besides the inherited one, and attaching it beneath my pelvis tracker in hopes that it would use that as the parent, but it still seems tied to the HMD as the parent. Is there any way to make it accept any parent rather than just HMD? I think if I could have the pelvis tracker as parent it would work well for my body tracking setup.
Mmmm, forgot that with that many trackers that you would be using a pelvis tracker. The problem is that with a pelvis tracker I need to do the orientation math differently and it has to be based off of the initial position of the tracker (trackers aren’t attached facing up for the waist and aren’t at center of mass but rather at rear or front of body).
I was going to start working on that anyway because my capsule location needs to have the option to work off of a tracker for waist tracking. It will just take some calibration functions or properties to manage (tracker relative location / rotation around capsule, ect).
I should have something done weekend, had to get my trackers functional again.
Hello ! I have a question about VR Character. Would it be possible for users to set the VRCharacter to move the root as well?
If I am correct, when anything is attempting to get the world location/forward vector of the VRCharacter, it can’t just generically get the actor’s location, it needs to cast specifically to VRCharacterPawn and get the VRLocation/VRForwardVector.
If people want to avoid , is the only real option to use the VR Simple Character instead?