Download

VR Expansion Plugin

Development Discussion VR and AR Development
#1768

Hey, thanks a lot for the reply even though you’re so busy.

I initially built the latest master cl and just updated the closest grip nodes (in my old modified 4.17 template character) that were erring out. Was getting crashes so then I tried the latest char. movement refactor cl. Sorry, I wrongfully assumed that the movement improvements were happening on the backend, not in BP… What I should have said was that I tried both master (4.18) and latest refactor (4.18), not the latest char. I apologize for that.

I’ve no idea. Maybe. How does one lose calibration or check that it’s been lost? I googled around for info on it but didn’t find anything related.
I’ll try to run the Steam VR setup/calibration thing again. Thanks a lot for the help!

Edit: It looks like it got fixed just by running the simple SteamVR stand-up calibration. Thank you so much for the heads-up! And sorry for posting it here.

#1769

@AtmaStudios
One way to toggle between your desired two movement modes (assuming you’re using the VRExpTemplate character) is by slightly modifying the Cycle Movement Modes function in the Vive_PawnCharacter.

I pm’d you a screenshot of a modified right hand movement mode select. That’s the only modification I made. I left the enum as is. It just switches the mode to Armswing if the current mode is teleport, and to teleport if it’s not teleport.

#1770

Like Kuso said, you can modify the cycling, or just directly control it yourself and unlink the cycling all together. The latter would be better, the cycle is only there to demo in the template and you likely want the side grips for more in a normal game.

LeftHandMovementMode and RightHandMovementMode enums are pretty much all you need to set to choose movement modes.

#1771

Hi guys,

Is there any way to disable / get additional control over the “VRWall Slide” / Repulsion mechanism in the VRMovementReference?

I’m looking to have a little more control over what happens when the character collides (mainly to minimize nauseating effects for first-time users). For now, I was thinking about using a teleport away from the Wall/Object…

One possibility is to use a non-VR character, but then I need to build the build the pawn all over again - and I lose the possibility to control in-game how collision is handled…

Thanks for your thoughts!
Warner

#1772

Well you can always change the walls to overlap and do whatever you want with it then… There is also walking collision override for the root capsule which lets you only have wall collision during locomotion but during walking without locomotion you can walk through / into the walls as it uses a separate collision channel with that enabled.

The upcoming 4.18 beta branch that overhauls the main character also adds events for when the wall sliding begins and ends to allow people to customize further as well (blanking vision, adding stable boundaries so that the slide doesn’t feel personal, ect).

As far as disabling, you already have all of the control you need for that, the character follows all std engine collision protocol, I don’t touch teleport back from penetration or other solutions like that as there are many ways to handle it and they don’t fall into my ideal for the plugin.

Generally it isn’t an issue unless you are having tables or blocking obstacles provide pushback, which I would suggest be avoided. Really only walls should be doing that.

#1773

Hey there,
we decided to implement this plugin for the vr networking in our already working project. We use the distance between the MotionControllers to set the WorldToMetersScale to scale us up and down. After implementing this plugin we have strange behaviour on this. When the controllers are close together (10cm) it works as it was previously. When the controllers are further away (~60cm) the controllers start to jitter horribly and the scaling goes back and forth what causes the jitter to accumulate into a complete mess. Moving the controllers close together causes the jitter to stop. When the scaling is initialized with the controllers far apart (>60cm) the jitter starts immediately, even when the controller are not moved.
So whatever state of scaling we are in: Controllers far apart = horrible jitter, close together = everything normal.
The MotionControllerComponent is within the PlayerCharacter. Everything attached to the Component is in its own blueprint (like the controller mesh).

Another very interesting part: Just adding a SkeletalMeshComponent as child to the GripMotionControllerComponent within the PlayerCharacter prevents the jitter, for what ever reason (it has to be a SkeletalMesh!). It even is enough to add just one SkeletalMesh to one GripMotionController to prevent the jitter on both controllers.

So it looks like it has something to do with the childs of the GripMotionControllers. I had a look in the code and found UGripMotionControllerComponent::FGripViewExtension::GatherLateUpdatePrimitives which gathers the whole child hirarchy of the GripMotionControllers and adds those to the LateUpdate stuff when a child component is a PrimitiveComponent. I put in a breakpoint at the beginning of the function, but it never fired. So the function seems not to be called at all what makes it even more strange.

What is this late update stuff? I came across it now multiple times, but could not find an direct explanation. In terms of Unity engine this seems to be a tick(?) that comes up last within the engine loop, just before rendering. In terms of Unreal this seems to be the TickGroup. Some more explanation about this would be nice.

Edit: Engine Version 4.16

#1774

UE4 gathers scene proxies and late updates them in the rendering thread by re-sampling the controller / HMD location there and applying the difference to their visual location (not game location) since the game thread last moved them. This is because the rendering thread is a frame or so after the game thread and you can get significant offset with fast movements in VR in that time.

Prior to 4.18 (.17 of my plugin because I implemented it early) they were using a method that caused some thread thrashing and jitter like what you were seeing. It mostly happened when moving at high velocities but I could see if happening with scaling the world as well.

TLDR: 4.17 of my plugin, or 4.18 of the engine likely fix this for you, it should be because of badly managed cross thread variables that they had in the late update system. However you can also just turn off late updates on the controllers during this scaling operation and it should also fix it.

I don’t know if you had late updates off in your original controllers? They should be using the same logic for the late update as epics in the 4.16 branch. Its possible that there is something missed, but I just went back over some of those areas recently.

Edit I have it on my 4.18 list to run down through the world scaling again since they made changes to how the components handle it (post 4.16). I can probably take a look back at the older version too.

#1775

Thanks for your fast reply.
Right now we can’t upgrade as we rely on a plugin that is not up to date yet.
I tried calling SetGripLateUpdateSettings with “LateUpdatesAlwaysOff” but it did not fix it.

As you describe it the late update is just a rendering thing. If so, why does it seem to mess with the location values on the game thread?

#1776

No turn the late updates off on the controllers themselves, also DOES it mess with their game thread values? You said that the hands were VISIBLY shaking, I would assume that if the game thread values were off that the scaling would shake as well.

Because that would be an entirely different thing.

Edit Just saw you say that the scaling goes back and forth…mmmm

Are you using the simple character? The code base is the exact same for the controllers between epics and mine EXCEPT for when using a simple character as I have to pull back the controllers in that case.

#1777

I’m using the AVRBaseCharacter. Only thing I’m doing is I have a child of AVRBaseCharacter that Destroys the controllers and replaces them with a child of GripMotionController (doing that in the constructor). Those child controllers just override TickGrip witch I made virtual. I don’t want TickGrip to be called, as we don’t use the grip stuff and there seems to be a lot of code in.
As everything is working when attaching a SkeletalComponent to the controllers, I assume I did nothing wrong there.

Flying:
We also need to fly the whole time of the game in multiplayer. However I’m not able to get the clients to “fly”. They are always falling down. I try setting SetMovementMode and SetReplicatedMovementMode on server and client to “flying”

Edit: Was a bit to fast. Managed to make the Clients “fly” but for now they are always reset by the server. Will have another look tomorrow.

#1778

Base character is just a proxy between the two different characters so that I can reduce code duplication (climbing and special flags that both need), it isn’t a fully functional VR character in itself…

Also TickGrip only does things when there are gripped objects, having no gripped objects it early’s out of the loops and only does two transform Gets. If you are making a child of the original controllers you will also want to be totally sure that you aren’t calling Super::TickComponent or you will start getting weird issues.

Edit I’ll note that while looking into the world scale thing today I didn’t find any issue with that hitch on 4.18, however I did find that Epics new late update system screws over the motion controllers location if the world scale is not 100.0f.

#1779

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

#1780

Wow, that was quick! You are a hero, Morden!

Also: agree that blanking/darkening vision during wall-slide sounds much better than the teleport (away from collision) I was working on.

Only thing I’m worried about is the fade-out: how to detect an impeding slide a few frames ahead so that I can start the fade? What do you guys think? Create a slightly bigger capsule and take collisions from that?

#1781

Thanks, I switched to VRCharacter.

Flying:
Managed to make server and client fly by Setting** CharacterMovementComponent:: DefaultLandMode **and CharacterMovementComponent::SetMovementMode both to flying.
Can move them around with Pawn::AddMovementInput. However adding movement in flying keeps the character moving after calling Pawn::AddMovementInput. Tried to stop moving using **MovementComponent::StopMovementImmediately **but that only worked on the server, could use a fix. I finally managed to stop directly after movement input by setting the friction to something high (CharacterMovementComponent::BrakingFriction only works when CharacterMovementComponent::UseSeparatBreakingFriction is true) on Server and Client.

#1782

Yeah you need friction in the air, and the StopMovement setup is normal for characters, Epic doesn’t replicate the current velocity, only current acceleration, and there is no flag for “StopMovementWasCalled”.

Flying should behave the same as it would with a normal in engine character. You might be thinking of some of the improvements I have been adding to get around limitations of the engines character like the replicated movement mode change.

You could use the new MovementAction system I added in 4.18 if you ever upgrade to handle that, it is inline with the movement tick and you can make custom ones that do whatever you want. Its main limitation is that it only supports one movement action a frame currently and that it replicates control variables by default that a custom action may not need. I need to figure out a way to define what a custom action uses so that I can lower that cost when one is used.

Edit If you want direct flying (no velocity retention) you can use the climbing mode to fly around in and turn off stepping up.

#1783

Great work man, will update my project tomorrow!

#1784

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

#1785

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

#1786

Hi Mordentral,

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!

#1787

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

It should be printing 0.0 if nothing else