VR Expansion Plugin

[michaelwbell]

Hello Mordentral, and fellow VRExpansionPlugin lovers. I have a new update for Espire 1: VR Operative, this time detailing the game's "Control Theatre" VR locomotion system and it's overall concept both of which are explicitly linked!

Overall Concept:
Espire 1: VR Operative drafts players as drone operators of the future. Players become "Espire Agents" and use "cutting edge Virtual Reality hardware" to remote-operate the Espire model 1 from the safety of their control theatre. The player will be standing within the Espire control theatre from the moment they launch the Espire 1 executable from their steam game library until the moment they quit.

Locomotion System
This control theatre is the game's key locomotion 'comfort' device. Any time the player performs any sort of artificial locomotion, Espire’s world shrinks down to the size of a floating "iPad", with the control theatre visible in the player’s peripheral vision.
The aim of this "VR within VR" concept is to:

• allow precise freedom of movement (A combination of sliding locomotion, climbing, jumping & tracked physical movement)
• minimize VR sickness
• maintain immersion.

Hopefully this concept makes it possible to deliver an optimized standing, 180 degrees, or 360 degree roomscale experience with the level of comfort that suits the individual player. They will be able to customize many aspects of the control viewer including it's size, distance from face, "follow speed" and the opacity of the control theatre walls. They can turn it off if they please.

I am a huge fan of sliding locomotion and think it is a good loco method for a stealth game. There is still a lot of work to do for it to effectively minimize VR sickness but with a lot of tweaking, it should work.
I am using many features of the VRExpansionPlugin and it's template VRCharacterPawn - obvious things like the widget lasers, gravity, collision and climbing, but also the VRAIController so the AI Guards correctly target the true location of the player, VRPosition/VRForwardVecotr helper functions and some of the plugin's booleans to detect artificial movement (pawn is colliding with geometry while player physically walks forward).

Thanks again Mordentral for making and releasing such an awesome plugin!

[mordentral]

Hello Mordentral, and fellow VRExpansionPlugin lovers. I have a new update for Espire 1: VR Operative, this time detailing the game's "Control Theatre" VR locomotion system and it's overall concept both of which are explicitly linked!

That static room / view looks really close to something I had been thinking about for awhile, I like the cutoff with the hands especially, pretty slick.

When you go and add in the ability to turn it off/on though you might want to expand the options a bit and allow for turning it off only during climbing, a lot of people have an easier time with climbing than sliding locomotion and would probably enjoy having full range of view and motion during that activity.


I'm actually curious too about the boolean for detecting walking forward, I don't remember exposing that but have always intended to go back and do so. Are you getting it in c++? (its public to that) I might want to go in and expose it to blueprint for people soon, I know there are uses for it but it keeps slipping my mind.

[KristofferF]

What would be the best way to override the movement of a pickuped actor? I want the actor to move along a spline when it is overlapping another actor.

[mordentral]

What would be the best way to override the movement of a pickuped actor? I want the actor to move along a spline when it is overlapping another actor.

Sounds like a job for the custom grip type honestly if you are trying to make it follow an actual spline. If you were controlling it in straight limited sections you could do it with the interaction settings but a spline will require too much custom logic for that to be viable.

You could technically do it by modifying offsets and the like, but a custom grip would be the easiest and quickest method.

[waysketch]

Hello,

Got the plug-in working beautify (Huge thanks for putting in so much work.) Two questions.

1: I downloaded the level you created and played around in it for a bit; Awesome. Is there a download so that I can look at your blueprints? I'm having a little trouble with some of the features you demonstrate.

2: When my VRCharacter (Simple) attempts to look outside a window or over a table my collision capsule pushes me backward. Is there a way to make it so that my VRCharacter can lean over objects without being able to pass them?

-Matthew

[kusokuso1]

(I tried "thread search" but didn't find anything that matched).

tl;dr RR-like equippable/holstered items (weapons, and locomotion items) and climbing?

Is it correct to assume one of the best ways to do this is: Just create a Base Actor (similar to the Gunbase in the template, where it's got a VRGripInterface and Gameplay Tag Asset Interface) and then create children of that (with custom logic) for each holstered item?

Notes:
- In the Player BP I need to know which item, if any, is in each hand because pressing thumbpad while its equipped will automatically return it to the holster it was removed from.

- All of the equip-able items are skeletal meshes. And depending on the item the motion controller buttons do different things. (I need the trigger axis value on each motion controller; there's a shoot threshold, and the gun can be charged, so I can't use the USED event from the interface)

Background:
I started with a blank VR Character, and copied over the grip/drop and climbing logic over from the template pawn. Equip/Unequip is currently done via thumbpad press. And all the equip-able item logic is handled in the VRchar BP (all the meshes and stuff for those items is in the player). It's getting really messy. Climbing works, but it works even when things are equipped, because the items aren't using anything from the VRExpPlugin.

Thanks and sorry for the stupid question.

[mordentral]

Hello,

Got the plug-in working beautify (Huge thanks for putting in so much work.) Two questions.

1: I downloaded the level you created and played around in it for a bit; Awesome. Is there a download so that I can look at your blueprints? I'm having a little trouble with some of the features you demonstrate.

2: When my VRCharacter (Simple) attempts to look outside a window or over a table my collision capsule pushes me backward. Is there a way to make it so that my VRCharacter can lean over objects without being able to pass them?

-Matthew

The template link has all of the blueprints in it for the demo download (demo is just a packaged template).

For the simple character, it follows all of the normal collision rules for a pawn, so you can simply turn off collision on the pawn channel for something.

I don't implement faked "leans" with overlap distances because I don't like the concept generally (tends to result in players just walking that much farther instead of "leaning"), but you are free to have a collision sphere on the HMD and check for the distances yourself and warp the player back if they penetrate too far if you wish.

The VRCharacter (non simple) also has the added option of a neck offset (can get closer to objects) and freewalk when not using locomotion.

There is also of course vive tracker support as well but being developer only at the moment and confirmed dead on gen2 for currently sold ones I wouldn't bet too much on them yet.

(I tried "thread search" but didn't find anything that matched).

tl;dr RR-like equippable/holstered items (weapons, and locomotion items) and climbing?

Is it correct to assume one of the best ways to do this is: Just create a Base Actor (similar to the Gunbase in the template, where it's got a VRGripInterface and Gameplay Tag Asset Interface) and then create children of that (with custom logic) for each holstered item? All of the equip-able items are skeletal meshes.


I started with a blank VR Character, and copied over the grip/drop and climbing logic over from the template pawn. Equip/Unequip is currently done via thumbpad press. And all the equip-able item logic is handled in the VRchar BP (all the meshes and stuff for those items is in the player). It's getting really messy. Climbing works, but it works even when things are equipped, because the items aren't using anything from the VRExpPlugin.

Thanks and sorry for the stupid question.

That would be correct, you can manually grip any object by calling the function, but if you are working off of the template then the cleanest method would be making a weapon base class from a grippable mesh. This is because the template character has a ton of checks and balances that it runs with grippable / interfaced objects. You could also just implement the interface in any object even if it isn't one of the grippable base classes but it would involve more effort generally due to having to overload the interface functions.

If you are just using attachment for your object holding instead of the plugin grips you are free to have a boolean for each hand "Is holding" or something of the sort and just end the climbing check early if true.

Regardless for the holstering itself, you shouldn't have to do custom logic on each object, Base class "Weapon" with child "Weapon.HolsterHeld" and implement the holstering logic there, then you can freely make further children like "Weapon.HolsterHeld.Pistol" that just has different mesh and properties but doesn't have to re-do all of the holstering and base weapon logic.

[kusokuso1]

That would be correct, you can manually grip any object by calling the function, but if you are working off of the template then the cleanest method would be making a weapon base class from a grippable mesh. This is because the template character has a ton of checks and balances that it runs with grippable / interfaced objects. You could also just implement the interface in any object even if it isn't one of the grippable base classes but it would involve more effort generally due to having to overload the interface functions.

All this time I've been seeing mention of grippable mesh. I thought it was in reference to any static/skel mesh that could be grabbed. I just now realized it's an actual component/actor type. Thanks! I'll get my feet wet with basing children off a GrippableSkeletalMesh Actor Base Class.

If you are just using attachment for your object holding instead of the plugin grips you are free to have a boolean for each hand "Is holding" or something of the sort and just end the climbing check early if true.

Got it. That makes sense. I manually copied over almost all the gripping/climbing logic, so I'm aware of all the checks. It is indeed a ton. I think it'd be best to not add any more checks to the gripping/climbing. I'll stick with your first suggestion (using GrippableSkeletalMesh Actor for Base Class).

Btw, I didn't see much, if any, info on bitbucket regarding grippable Skeletal/Static mesh components/actors. You got all kinds of secret stuff in this plugin, it's ridiculous.

Regardless for the holstering itself, you shouldn't have to do custom logic on each object, Base class "Weapon" with child "Weapon.HolsterHeld" and implement the holstering logic there, then you can freely make further children like "Weapon.HolsterHeld.Pistol" that just has different mesh and properties but doesn't have to re-do all of the holstering and base weapon logic.

I've recently had bad experience working with embedded inheritance actors in RR mods. It's made me lean towards just inheriting once. By custom I was more or less just referring to gun logic VS locomotion logic. I'll rethink my approach with "Weapon.HolsterHeld.Pistol" in mind. Or maybe HolsterHeld.Weapon/Tool.Pistol-Lasergun-Rocketlauncher/Rocket-Parachute-

Thank you very much for your time! Extremely appreciated!

[mordentral]

All this time I've been seeing mention of grippable mesh. I thought it was in reference to any static/skel mesh that could be grabbed. I just now realized it's an actual component/actor type. Thanks! I'll get my feet wet with basing children off a GrippableSkeletalMesh Actor Base Class.


Got it. That makes sense. I manually copied over almost all the gripping/climbing logic, so I'm aware of all the checks. It is indeed a ton. I think it'd be best to not add any more checks to the gripping/climbing. I'll stick with your first suggestion (using GrippableSkeletalMesh Actor for Base Class).

Btw, I didn't see much, if any, info on bitbucket regarding grippable Skeletal/Static mesh components/actors. You got all kinds of secret stuff in this plugin, it's ridiculous.



I've recently had bad experience working with embedded inheritance actors in RR mods. It's made me lean towards just inheriting once. By custom I was more or less just referring to gun logic VS locomotion logic. I'll rethink my approach with "Weapon.HolsterHeld.Pistol" in mind. Or maybe HolsterHeld.Weapon/Tool.Pistol-Lasergun-Rocketlauncher/Rocket-Parachute-

Thank you very much for your time! Extremely appreciated!

You can still pick up any meshes with the plugin and it will still be considered in the grip array, the template just automates a bunch of the grip logic when picking up a grippable mesh because it implements the VRGripInterface.


Also yeah I do appear to have forgotten to place all of the grippables on the wiki, it will really just be a "Grippable objects" with a brief description but it should exist, i'll add a page today.


Generational inheritance is a huge part of this engine and game programming in general, I would suggest that you use it, but even if not, at least make an actor component that handles the logic for you and attach that to the base class. Something that abstracts the logic out of each separate object and into one place where it only has to be changed once when you make holster changes.

[Haircut]

First, thanks for the great plugin!

I'm having a great time taking the example project you made and tweaking Vive_PawnCharacter to use just the movement mode that I like the best. I was curious about the best method for syncing up to your latest plugin when you submit changes.

Also, the run in place doesn't seem to work. Is it supposed to just work out of the box?

Thanks again!

[mordentral]

First, thanks for the great plugin!

I'm having a great time taking the example project you made and tweaking Vive_PawnCharacter to use just the movement mode that I like the best. I was curious about the best method for syncing up to your latest plugin when you submit changes.

Also, the run in place doesn't seem to work. Is it supposed to just work out of the box?

Thanks again!

Run in place still requires a button press by default currently, its thumb pad like all of the other movement modes. You could use it without the button requirement but sudden sustained vertical movements like crouching up and down can trigger it with the default settings. Also the default settings take the controllers movements into account as well when calculating thresholds, there is a boolean to turn that off which will require no hand motion. (Unless I broke it by mistake recently when remapping buttons, I can run through it tonight)

Syncing up to the latest plugin is sadly not as fluid as I would like due to the binary status of blueprints, you would be best off keeping a seperate copy of the new version and moving nodes over. You could subclass from the character and move it over wholesale but its mostly intended as an example character. For games its likely you could delete most of the movement modes and many of the features to have a bare bones character.

[dcaspi]

Are you running steam and is the editor closed when you run the binary?

Also you can try downloading the packaged demo in the OP and seeing if steam connects for you with that.

Thanks for your help, it happened also on the demo but I found the problem.
It seems that the new SteamVR beta was causing the problem.
There was a new SteamVr process (forget his name) that I had to kill before launching the game and the error disappear.
Then I removed the SteamVR beta and problem was solved!

Thanks again for all your help you rock!

[KristofferF]

Sounds like a job for the custom grip type honestly if you are trying to make it follow an actual spline. If you were controlling it in straight limited sections you could do it with the interaction settings but a spline will require too much custom logic for that to be viable.

You could technically do it by modifying offsets and the like, but a custom grip would be the easiest and quickest method.

Thanks. I'm using custom grip but I wanted to check if this is the right way to do it.
I use a duplicate of the pickup cube from your template and when my pickuped object is overlapping a specific object I change what the overridden functions FreeGripType and GripLateUpdateSettings returns. I return "Custom Grip" and "Late Update Always Off" and that will let me control the object how I want to but I have to let go of the object and pick it up again to make the changes take effect. Can I call some update grip function or how should I update the Grip Type and GripLateSettings on the fly?

[Elleclouds]

If your controllers are "ghosting/blurring" then yeah, generally that means that you dropped below the 90FPS target, you are using objects too performance heavy for VR or your graphics hardware is weak. You'll want to look into optimizing the assets for VR.

Its weird because I have a 1080 graphics card, 16 gb ram and i7 processor and just a few items from an office pack drops all performance. Is there a way to reduce performance heavy objects for VR? I'll look up some tutorials on optimizing... thanks for everything

[mordentral]

Thanks. I'm using custom grip but I wanted to check if this is the right way to do it.
I use a duplicate of the pickup cube from your template and when my pickuped object is overlapping a specific object I change what the overridden functions FreeGripType and GripLateUpdateSettings returns. I return "Custom Grip" and "Late Update Always Off" and that will let me control the object how I want to but I have to let go of the object and pick it up again to make the changes take effect. Can I call some update grip function or how should I update the Grip Type and GripLateSettings on the fly?

*Edit* I forgot about my own function, edited

Setting late update settings you can do it directly by editing the interface struct or by the setting function SetGripLateUpdateSetting.
Setting the collision type you'll want to use SetGripCollisionType as it also re-creates the grip for you with the new type.



I am adding a check for when recreate grip is called so that it doesn't trigger the OnGrip events again after looking it over though, I don't think that should be the behavior.