VR Expansion Plugin

[thedog88]

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

[erik007]

Any idea how I can extend this 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 this functionality doesnt seem to have anything to do with Event Pickup/Drop from what I understand.

Eventually when this 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!

[erik007]

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

[mordentral]

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 this before going heavy into multiplayer integration).

I'll delete the first person character from the template as it is confusing.

[mordentral]

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.

[erik007]

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).

[erik007]

BTW, one more thing that's a bit confusing at this point, until now ive been using this repo: https://bitbucket.org/mordentral/vrexppluginexample/ (plugin + example)
Does this come with the latest plugin code? Or should i get https://bitbucket.org/mordentral/vrexpansionplugin/ separately and replace the /plugin/vrexpansionplugin folder in the example files?

[MagicBots]

Hello, Thanks for making available this amazing plugin. I am just starting to implement this 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!

[UTwelve]

What's this?what should I do?

[mordentral]

What's this?what should I do?

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.

BTW, one more thing that's a bit confusing at this point, until now ive been using this repo: https://bitbucket.org/mordentral/vrexppluginexample/ (plugin + example)
Does this come with the latest plugin code? Or should i get https://bitbucket.org/mordentral/vrexpansionplugin/ separately and replace the /plugin/vrexpansionplugin folder in the example files?

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.

Hello, Thanks for making available this amazing plugin. I am just starting to implement this 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!

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.

[MagicBots]

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 this issue where the animation portion of my setup wants to correct back to the actor/capsule location. I'm currently getting around this with relative transforms on my skeletal mesh, but it ends up giving me a pretty floaty looking result. I'm fairly new at this, 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!

[mordentral]

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 this issue where the animation portion of my setup wants to correct back to the actor/capsule location. I'm currently getting around this with relative transforms on my skeletal mesh, but it ends up giving me a pretty floaty looking result. I'm fairly new at this, 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).

[MagicBots]

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.

[Shanowzer]

Does this work for 4.14?

[grizly32]

Hey Mordentral,

Have another question if you have a sec.

I am starting the game with your VRCharacter, then possessing a pawn in which I reset the VR using "Set Tracking Origin" (Set to Floor Level) and "Reset Orientation and Position" (Default settings).

Things are fine until I try to go back to possessing a new VRCharacter...when I do the camera falls down to the floor.

Is there any way to get the VRCharacter camera back to the way it was before the pawn possess?

Thanks!