Hey / guys,
I just wanted to say I started to use plugin yesterday in 4.14 and so far it’s super good, extremely motivating to have such a solid physical VR base.
I think plugin has great potential, although it would be great if there was some instructions how to upgrade once a project is based on the “VRExpPluginExample.uproject” solution.
I will post pictures and a link once i have something more to show.
Big thanks!!
Upgrade to a new plugin version? Or to a new engine version? I would suggest keeping the template as a separate project entirely that you can pull blueprints and objects from to use outside of it. Kind of like the “content packages” that ue4 has except not automated. I will be adding thing to it often enough that trying to keep something working and get the updates at the same time would likely slow you down more than help you.
For engine versions, it should currently just upgrade, I have been trying to support the current / preview versions as it goes and when the preview goes live support the older version until the next preview if possible. 4.12 was an exception as the code base changes from it to 4.13 were too dramatic. I anticipate the plugin in its updated state losing 4.13 support and locking a branch for it when 4.15 comes out, the enum changes coming down the pipeline are not compatible.
**Also, to anyone else: (going to post in the OP as well)
**
I would like to note by the way that everything currently in the template is an example of what I think is best practices (though still needing a little polish as I made it over three days), not everyone is going to need the same set up and not everyone is going to need a full VRcharacter. Custom pawns that just use the motion controllers and camera / parent relative component would be useful to people that don’t want gravity / collision. The entire plugin itself isn’t so much a complete package as one (or for the character/grips, several) example(s) of how to achieve VR capabilities in UE4…like a big public research endeavor on my part. Some things I know I would have done slightly differently if I were to go back and start over (gripping code out of the motion controllers and into a custom component that has its own late update referencing the controllers for example).
I have not changed some things that I know could be slightly better if refactored as there are projects released on steam already that use it and I don’t want to break compatibility beyond repair for them.
The new SimpleVRCharacter is a more sane method of creating a VR colliding character, when I made the original one I wanted every possible feature I could think of and I broke a bunch of “soft rules” to make it happen. The new one does none of that, so while slightly less feature complete it is more in line with standard procedure for the engine.
Thanks for the reply.
Upgrade to a new plugin version.
And what i meant to say was that it’s a little bit confusing if you are using the template what exactly is the plugin and what is the template, for example say that i would start playing around with building a something inside the template level, can i break the functionality of the plugin? is part of the plugin based on logic in level?
If I add another level (inside the template project), what do i need to do to get the same functionality as in the demo level? (as in, you can have a pair of controllers, you can lift and release objects, etc). Maybe a youtube video how to setup new levels would be really good.
Big thanks again,
The plugin is code based, the character and controller components/actors are from it. Anything you do within the engine itself shouldn’t have an effect on it. New levels have no special setup aside from I have a custom game mode checking for if the client has a HMD.
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.
