VR Expansion Plugin

[Sleeper_1]

Pushed a new commit to the plugin today

Merged the VRCharacter refactor into Master branch.

The great VRCharacter refactoring

Added OnBeginWallPushback and OnEndWallPushback events to the characters so people can
darken vision and set up things when pushback is happening.

Added vr.ForceNoStereoWithVRWidgets so that users can globally force stereo widgets
to use only normal widget rendering at will (Fantisfall).

Major overhaul of how the VRcharacter handles movement, cleans up many many interactions
and fixes the few broken features from the old system (bCanWalkOffLedges works now).
Also wall sliding is far cleaner and nicer now.

Basically instead of the old hacky method of adding a bit of movement input
in the normal direction of HMD movement (that I hated and proved more stable than
I had expected). Now during movement the movement mode rewinds the last delta of the
HMD and plays it back as part of the current movement mode.  allows it to act
as a true first party in the movement logic and keeps all of the normal character
interactions largly as they would be in a 2D pawn.

It is more accurate, smoother, and far more reliable in multiplayer (though will still go through some cleanup in the future).

Changed VRRootComponent so that it manually attempts to verify overlaps now if it ends a
scoped movement with detected overlaps but none on final position.  corrects the capsule
1 frame on and off overlap events.

Renamed camera transform replicated variable and RPC so that they show up
more clearly in NetProfile (.nprof) readings (Just read as ReplicatedTransform before, now reads
as ReplicatedCameraTransform).

I am compiling pre-packaged binaries now.

Great work man, will update my project tomorrow!

[AtmaStudios]

How can I slow the speed of movement for the ArmSwing locomotion?

[Virtuality (Warner)]

@AtmaStudios

How can I slow the speed of movement for the ArmSwing locomotion?

I think you can play with the ‘swing and run magnitude’ value in the Vive_Pawncharacter BP (default is 2.0, by making it larger movement should become less if I read it right).

[Silpher]

Hi ,

I’ve been trying to register the axis of the triggers, see pic attached.
Somehow nothing shows up when I try to print string it. Would you know why?

Thanks again!

[mordentral]

@Silpher

Hi ,

I’ve been trying to register the axis of the triggers, see pic attached.
Somehow nothing shows up when I try to print string it. Would you know why?

Thanks again!

Not really sure where that print screen is going? To tick?

It should be printing 0.0 if nothing else

[mordentral]

@Warner_V

I think you can play with the ‘swing and run magnitude’ value in the Vive_Pawncharacter BP (default is 2.0, by making it larger movement should become less if I read it right).

Or set walk speed on the character differently.

[Curs0]

drop object interface seems to be broken on multiplayer:
when dropping a skeletal mesh actor, it starts to jump slightly client side (seems like all its physics bodies have collisions enabled and collide with each other)
no issue in single player session or server-side in multiplayer sessions

if i comment “drop by interface” bp node call and use “detach from component” + “set simulate physics” bp nodes, it works correctly

edit: as I can see there’s also a problem with object scale: if root component as a different scale from 1, when dropping objects, client side there some sort of bones shifting

[mordentral]

@Curs0

drop object interface seems to be broken on multiplayer:
when dropping a skeletal mesh actor, it starts to jump slightly client side (seems like all its physics bodies have collisions enabled and collide with each other)
no issue in single player session or server-side in multiplayer sessions

if i comment “drop by interface” bp node call and use “detach from component” + “set simulate physics” bp nodes, it works correctly

edit: as I can see there’s also a problem with object scale: if root component as a different scale from 1, when dropping objects, client side there some sort of bones shifting

My gripping system doesn’t ever attach anything, when you call Detach From Component you don’t actually do anything that effects the grip, its only the set simulate physics that is doing anything there. You likely are retaining the grip and not using a physics one so it just doesn’t move the now simulating mesh. Setting simulating will detach a component from its parent anyway.

I would have to check on scale with skeletal meshes, the issue with skeletal meshes that that the rootbone transform isn’t correctly updated to the physics body so I have to adjust for it on grip, on release I don’t actually do anything special though so if you are getting weird scaling results its likely unrelated to the grip itself, and more related to improperly replicating meshes.

Also the “jumping” would be normal if you have multiple components colliding with each other and you simulate the parent which will now collide with its attached children…

Also want to make sure that you are calling the drop on the server side only unless it is a local grip.

[anonymous_user_650f1d25]

is likely a stupid question…

Which way would you guys recommend upgrading an older, somewhat heavily modified, template character (from early 4.18), to the latest and greatest character?

[mordentral]

is likely a stupid question…

Which way would you guys recommend upgrading an older, somewhat heavily modified, template character (from early 4.18), to the latest and greatest character?

The template character itself isn’t edited all that often, most of the changes from version to version are in the c++ side of things.

You can pick a choose a few things from the blueprint character to port over, the only recent changes I can think of are using the new MovementAction system for teleports instead of an RPC, and changing / cleaning up the overlap / tracing function for grips.

Everything else is in the automatic update (source changes) where you don’t have to do anything except compile the new version.

[mordentral]

Pushed a new commit to the plugin today (fairly minor but important changes, need to do some documentation updates now).

Changed the MoveAction system so that custom move actions can choose whether they use  
the rotator or location or both or none.  can save massivly on replicating them.  

Changed moveaction system so that it is a self contained struct now for ease of use and expansion.  

Added MoveAction_StopAllMovement - calls StopAllMovementImmediately from the movement component  
in line with the move action system (movement system).  

Changed the interactibles so that they re-construct their initial location values on grip  
from the Relative to controller grip transform.  corrects for the client to server delay  
creating an offset on where the grip is on interactibles in high ping scenarios.  

Also corrected the drop distance for slider components so that they run off of the correct  
transforms (relative instead of parent). 

[AtmaStudios]

I am almost afraid to ask question because it might be super complex… I am curious how hard it would be to have whatever object I grab/pickup replace the motion controllers or hands?

For example… If i pick up a screwdriver, my hand/motioncontroller becomes that screwdriver until I drop it and then it changes back to the motioncontroller. I think would be easier than making everything fit right to a socket.

[mordentral]

@AtmaStudios

I am almost afraid to ask question because it might be super complex… I am curious how hard it would be to have whatever object I grab/pickup replace the motion controllers or hands?

For example… If i pick up a screwdriver, my hand/motioncontroller becomes that screwdriver until I drop it and then it changes back to the motioncontroller. I think would be easier than making everything fit right to a socket.

? Hide the motion controller / hand visually, it is dead simple.

The point of sockets is to get the offset correctly, because otherwise you have to have the zero point of the object offset for the correct location or you have to provide an offset transform. They aren’t really there for the hand mesh to object to be correct as that is implied if the hand mesh is correctly setup to the controller in the first place.

Sockets are the fastest method of iterating over getting correct grip locations, you can do it without them as well, its just generally more work unless you keep in mind some distances like controller zero point to tip of palm, ect.

[AtmaStudios]

I think the hiding controller visually and just showing the held object instead might be the way I want to go so then I do not have to worry about hand grip animations/different holding positions, etc. Sockets make sense, but in many ways I feel I am over my head as I have not gotten a socket to work yet.

So to make the hand disappear and the object take its place while holding it would I just do something like “On pickup -> Cast to Motion Controller (L or R) -> Toggle Visibility of Handmesh” ??

Thank you

[mordentral]

@AtmaStudios

I think the hiding controller visually and just showing the held object instead might be the way I want to go so then I do not have to worry about hand grip animations/different holding positions, etc. Sockets make sense, but in many ways I feel I am over my head as I have not gotten a socket to work yet.

So to make the hand disappear and the object take its place while holding it would I just do something like “On pickup -> Cast to Motion Controller (L or R) -> Toggle Visibility of Handmesh” ??

Thank you

Yeah…but the sockets aren’t just for with visible hands though, even without visible hands you are going to need a way to define where the held object is in relation to your controller or it will feel weird if you aren’t free picking it up…

IE: if you snap a baseball bat with a zero point at its center to your hand then you will end up holding it halfway up it and it won’t feel right.

Sockets are just the easy way of doing that can be done with no guess work and in the editor. Otherwise you will have to add offsets, modify the transform of the gripped object, or model it / set the zero point to where you want to grip it at, which also makes it harder for multiple grip snap locations.

Basically unless what you are doing is literally just inflexible gripping of base objects, you will regret direct attachment without alterations down the line somewhere.

You also have to keep in mind that the VR grip sockets use prefix’s for their names to define what ones are grippable, you can check out the gun model to see what I mean, otherwise there wouldn’t be a way of knowing what the socket is for.

[AtmaStudios]

Sweet, thank you. Your gun model should point me in the right direction. Thank you again for the clarification.

[anonymous_user_4f284332]

Dear ,

one long time request (pardon if answered earlier) Can we make the preview resolution 1920 by 1080. Currently its a strip where as most of the other experiences are full screen.

thanks and regards
Jo

[mordentral]

@Jomax3d

Dear ,

one long time request (pardon if answered earlier) Can we make the preview resolution 1920 by 1080. Currently its a strip where as most of the other experiences are full screen.

thanks and regards
Jo

You mean the mirror mode? Epic added native support for that in 4.17 (and then improved it in 4.18 since Vive was buggy). Otherwise is requires ENGINE source changes in earlier versions to fix it, something I can’t access with a plugin without re-writing the separate VR plugins themselves.

Its an easy change in earlier versions in the source to fix, but you would have to compile the engine from source for that.

[MAGtechnologies]

Awesome Plugin. I have been working on floating pawn movement with physics for a while, it took some work to get the parent changed from pawn to the VR character, but it was worth it. I am just using the pawn for collision and movement to make my current pawn much more solid in game. I have put you in credits, so be sure to check it out. I will PM you with a steam key when the new update will go live tomorrow on steam: Reficul VR on Steam with changing to system.

I just have two issues, which are probably linked to the same problem, I have spent hours on it and more hours looking through pages on thread.

I have everything working except AI - which looks at as spot 2 feet in front of me while attacking my current position (Using Behaviour trees, based on the detour-crowd AIcontroller (Parent) - if that is of any use. At the same spot 2 feet in front, when I add yaw input to my pawn, for 3drudder (using Add Controler Yaw Input) it is rotating 2 feet in front and throws my teleport - direction totally off. Is there any way to make central to where my camera is located?

The AI issue with looking and attacking 2 feet in front is fixed if I reparent to Simple Character. But VR character which has the customisations I need for my custom pawn. Any advice on would be really helpful.

[mordentral]

@Swilliams

The AI issue with looking and attacking 2 feet in front is fixed if I reparent to Simple Character. But VR character which has the customisations I need for my custom pawn. Any advice on would be really helpful.

I have a custom VRAIController in the plugin that you can set for the AI. All it does is override the

GetFocalPointOnActor
LineOfSightTo

functions so that they correctly target the offset HMD location, is much like what RR did for their AI. The detour controller overrides the base AI controller so that it can set a custom path following component, you would either need to copy my VRAIController code (the two functions over), or copy the detour AI and re-parent it to the VRAIController, either method would work.

Edit I don’t know how often the detour crowd controller is used, it may be worth overriding it as well in the plugin at some point. I added a note to my private trello about it.

Also for the teleport rotation you need to teleport around a Pivot (being the HMD). I have a shortcut node RotationAroundPivot in the VRExpansionfunctionlibrary that will do for you and provide an output rotation and new location. The template also shows how works.

Both of these things you ran into are because the VRCharacter retains the engines current default of the HMD being offset from the actors zero point. The simple character locks the camera movement to the characters movement, however that in itself limits some of the things it can do compared to the full VRCharacter.