Actually, i was just gonna write. It seems to be working by default, wow, so that’s great. Although in non-VR mode i’ve noticed gravity doesnt seem to turned on (it is working in VR mode), could be a bug?
Btw, another thing, i’m looking to add is a pair of IK based arms (shoulder and elbow positions will need to be predicted based of HMD and controller positions). feels quite generic so maybe it could become part of the plugin? At least if the shoulder and elbow positions were functions that you could ask the plugin for then you could make your own arms perhaps.
IK is fairly easy for arms, attach them to the parent component and set the wrists to the controllers with IK, seperate each arm and add them to the controllers late updates so they don’t lag behind. But no its not likely something I would add by default as each setup will be different and there are multiple IK plugins already.
Thanks again for a great example, !
Unlike the standard VR template from Epic, VR Expansion BP_Teleport_Controller blueprint’s TeleportCylinder and child (Arrow) components have visible lag/creep when you rotate the vive controllers quickly. It looks like the relative transform of TeleportCylinder is set, and maybe the controller pushes a late transform update, which updates the world transform of TeleportCylinder, too (at least that would explain it). But the original VR template doesn’t suffer from problem.
I’ve been trying to understand why that happens, and it looks like BP_Teleport_Controller’s TeleportCylinder works and is set up exactly the same way as the BP_MotionController, which doesn’t have problem.
Does anyone know why happens? I’d like to try to make TeleportCylinder not derive transform from the parent scene, is it possible?
So you are saying not that it is “lag” but that it is TOO responsive as it pulls the late updates and thus follows orientation? I could see that, it is directly parented to the motion controller, I didn’t think about the non spline sub components.
There are two easy options to fix it, i’ll choose one tonight to implement:
1.
Split the children in the teleport controllers into two scene components and make a new function in them to “Setup attachments” will attach the base scene to the characters root and the secondary scene component to the owning motion controller. That way it will perform the same as epics implementation without making the controllers outside of the character. The secondary scene component would have all of the items currently using late updates as children.
2. (better)
Honestly it doesn’t need the ArcDirection component at all and could just get the owning controllers forward vector instead. Could just be attached to character root then, the spline is being generated in world space not local so it doesn’t actually have to be attached to the hand at all and it is the only thing currently being used that was attached to the controller in the original template version.
Pushed a new template commit live
Fixed teleport components using controllers late updates
Changed pawns gripping nodes into a function call that is hand agnostic
Added FPSVive_PawnCharacter that is a subclass of Vive_PawnCharacter (not for game use, for testing)
Fixed a minor plugin bug
Edit I will be looking into the based component view rotation issue, its a result of the characters UpdateBasedPosition function which doesn’t work nicely with VR enabled cameras.
having issues opening the example project in .14. i requests a rebuild. if i dont do it, it exits and if i do, it starts to rebuild and gets stuck. am i missing something or? i just cloned the repo, converted project to .14 and tried to fire it up.
edit: nvm it just took really long
Any idea how I can extend framework so it works for mouse as an input when a VR device is not available? Particularly i’m interested in letting left mouse button trigger “Event Pickup” and right mouse button trigger “Event Drop”. There already seem to be some interactivity possible with the mouse by default, but functionality doesnt seem to have anything to do with Event Pickup/Drop from what I understand.
Eventually when is done I would like add Spacebar to trigger “Event On Used” the same way it does on VR.
How can i go about adding these extensions? Since theres already existing non-VR fallback support it should be possible to just extend.
Thank you so much!
Ok, think i’ve answered my own questions now. As far as i understand FirstPersonCharacter is the non-VR player, unfortunately it does a horrible job of implementing the functionality and is riddled with bugs. I don’t understand what the “trygrabserver” etc functionality actually does, but if its related to network code i have completely ignored that. So i basically have a decent proxy for developing without an HMD now. Cheers
FirstPersonCharcter was an old proto char that I never finished, it was only used to test things from time to time in my old project I had replaced it with a derived character long ago in that project. As of last night I made a new testing character FPSVive_PawnCharacter for the template that is based off of the normal character and just remaps inputs for it.
I wouldn’t suggest using that one for gameplay, but since it uses the same code as the VR character it should be able to be used to test without a headset / in multiplayer (need before going heavy into multiplayer integration).
I’ll delete the first person character from the template as it is confusing.
Pushed a new commit to the template and a few minor bug fixes to the plugin
**11/30/2016**- Fixes
Replaced original chars with ones that work with movement bases...every single variable and node is the same, but they work...w/e
Added example simple character
Edit there is also now a rotating platform in the level to show the based movement. If you feel like throwing up all over then feel free to step on it.
Thanks for the reply! I already rebased my project on the 11-30 code, but ill update again, i try to stay away from the example BP as much as possible in case of updates.
Your update worked fine btw, it’s much cleaner now, like you said the old FPSCharacter was a bit confusing. I just needed to add a few functions to FPSVive_PawnCharacter so you can drop the gun, and also point it in the right direction as its locked looking down the y axis right now (havnt done it yet, but was thinking you could hold a button to get mouse-look control of the VRController in case you are gripping something).
BTW, one more thing that’s a bit confusing at point, until now ive been using repo: https://bitbucket.org//vrexppluginexample/ (plugin + example)
Does come with the latest plugin code? Or should i get https://bitbucket.org//vrexpansionplugin/ separately and replace the /plugin/vrexpansionplugin folder in the example files?
Hello, Thanks for making available amazing plugin. I am just starting to implement in my project today, and before I migrate over my character BP content, I wanted to quickly ask if I will have the same success with the capsule component being moved via the hmd in both the VRSimpleCharacter and the VRCharacter classes?
I read on the wiki that:
“The VRCharacterActor has full level collision like a standard Character and the collision follows your HMD using the VRRootComponent.”
I’m very interested in that and just wondering if the VRSimpleCharacter works the same way as i noticed it uses a standard root component rather than VRRootComponent. In my setup I need to drive a full skeletal mesh for room scale. Would I be best served by the VRCharacter or VRSimpleCharacter, or does it not matter?
TIA!
Report it as a bug, i’ve seen the same thing from time to time recently, though only in editor so far. I doubt it happens in built lighting projects, it looks like a dynamic shadowing bug.
The template comes with the latest “stable” plugin code, I also have been updating the plugin with changes I make to it for the templates features. If I start work on a new plugin feature that is unfinished it will exist in a new branch on the main plugin repository until finished.
Currently there isn’t a difference between the two, i’m still deciding what I want to do.
The SimpleVRCharacter directly drives the actors movement with the HMD movement (linear). It doesn’t currently support the offset capsule that the VRCharacter does but it uses significantly less custom code and ties right in line with the engine so should be more update proof.
Basically if you don’t need the capsule collision offset behind you and don’t want to change the capsule height constantly to account for player height I would suggest the simple character, it should be more stable and uses slightly less network bandwidth and cpu.
They both have full world collision, VRCharacter is just a huge overhaul of engine standards, SimpleVRCharacter isn’t.
Thanks for your reply. I’m running a setup where my VR characters upper body is IK driven, and the lower body is animation driven for room scale. Of course I’m interested in the plugin to avoid the double transform on the child camera issue that we have with Epic’s normal character setup for room scale, but also to get around issue where the animation portion of my setup wants to correct back to the actor/capsule location. I’m currently getting around with relative transforms on my skeletal mesh, but it ends up giving me a pretty floaty looking result. I’m fairly new at , and not actually sure whether animation is positioned according to the actor location, or if it’s positioning based on the capsule location. If the capsule location has nothing to do with the animation positioning then the SimpleVRCharacter does sounds like the better way to go, but I really need the animation positioning to come along for the ride so would go with VRCharacter if positioning is at all capsule based. I don’t really care about the Capsule collision for actual collision in my game, and can just make a separate capsule for collision if the root capsule doesn’t play a part in the positioning of the animation. Just wanting to double checking before I start, as it’ll be a bunch of work to migrate everything to test.
Thanks again!
The simple character will keep the capsule and head together in world space on the X/Y axis’s, the VRCharacter moves the representation of the capsules collision with the HMD but not the actor/capsule itself.
Also capsule location is the same as actor location when it is the root component, and you can’t just “add” a capsule for collision to a pawn, only the root component is used for pawn collision unless you manually sweep or are talking about just physics interactions.
That being said, if you don’t want world collision then why bother using one of these characters, you could use my Parent Relative Attachment instead and attach the mesh to it. It would follow the HMD and character around for you and face forward with the camera (or make something like it in BP).
Looks like I spoke without thinking the capsule collision bit through last night. Maybe I was angry at my capsule. I will need that for blocking static objects and overlapping dynamic ones, and probably for a lot of other reasons I don’t know about. Thanks for clarifying about root component, and collision. From what you’ve said, it does sound like I’ll have what I need with SimpleVRCharacter and also need the Replication. Will give it a go today. Thanks again.
Does work for 4.14?