VR Expansion Plugin

[duyth]

thanks a lot for this pluginmordentral
just a quick question, is it possible to implement move in space? I've been trying to figure out how to teleport in space (eg: teleport to near a planet) but the Nav mesh is tied to the floor and creating multiple floors isn't really an option in outer space environment

[mordentral]

thanks a lot for this pluginmordentral
just a quick question, is it possible to implement move in space? I've been trying to figure out how to teleport in space (eg: teleport to near a planet) but the Nav mesh is tied to the floor and creating multiple floors isn't really an option in outer space environment

Yeah, ignore nav mesh entirely and use a different method of deciding where to go.

The nav mesh system is only there to make it easy to define teleport capable spots, you can still do normal teleporting at will.

[AMIMA]

Have you seen if any of the tracker pins input/output are supported through the new motion controller class or in unreal engines implementation of the openvr api?

Pushed a new commit to the repository 4.17 branch (I won't be updating main page with changes until the release patch notes but these had to happen due to an oversight).

Deprecated the vive tracker component as motion controllers finally control it

[mordentral]

[QUOTE=AMIMA;n1344350]Have you seen if any of the tracker pins input/output are supported through the new motion controller class or in unreal engines implementation of the openvr api?

Pushed a new commit to the repository 4.17 branch (I won't be updating main page with changes until the release patch notes but these had to happen due to an oversight).

Deprecated the vive tracker component as motion controllers finally control it

I haven't checked, but it should, it binds to the same input pipeline, ie: the grip / trigger pins should trigger the same events in engine.

[AMIMA]

[QUOTE=mordentral;n1344352]

Have you seen if any of the tracker pins input/output are supported through the new motion controller class or in unreal engines implementation of the openvr api?



I haven't checked, but it should, it binds to the same input pipeline, ie: the grip / trigger pins should trigger the same events in engine.

Thanks for the reply. I just made some progress. Unreal was crashing on any events when the tracker was set to other and 'special 1'. I tried using the HTC tool to change the tracker to a controller again. With one tracker connected as a controller and set to 'right hand' haptic events are showing on pin 1.

[mordentral]

Did some more car work

[MagusShade]

That car looks awesome!

[mordentral]

Pushed new commit to the template and plugin repositories today

Plugin:

 Made "Light" versions of the RPCs that send saved movements to the server.  
 These do not pass in the RequestedVelocity and CustomVRInputVector.  
 They are called if both the RequestVelocity and CustomVRInputVectors are zero.  
 This cuts down on some of the additional overhead built into the replication in the VR characters.  

 Also the saved movement capsule Yaw value being sent over the network is now the same calculated Pure yaw that the GenerateOffsetToWorld  
 uses. This will make running back movements slightly faster, as well as slightly more accurate as passing  
 in just the normal HMD yaw before could yeild slightly different results when the camera is rotated off axis than  
 if calculating entirely off of the full rotator.  

Removed default of grippable actors base components replicating, this was an oversite.

Added a new boolean to all grippable components (defaulted: off), bReplicateMovement.

This emulates the variable of the same name on actors and controls whether grippables
will replicate their movement when set to replicate (IE: so gameplay tags can replicate).
The value of this property is overriden when the current grip type of the grippable is
serverSideMovement, then it forces allowing movement replication.

Turned bReplicates off by default on all grippable components, if you need to set interfacesettings
on placed objects that aren't set to load with the map for the client or have replicated gameplay tags then just turn it on for the component.

Better to have this directly set by the game developer than defaulted by me.
I now have more options in the grippable components for finer grained control of them when replication is turned on.

Template

  
 *Car has all 4 seats filled in now.*    

 I also went into the DropActor RPC in the blueprints for VivePawnCharacter and quantized the requested  
 angular and linear velocities as well as only passing in the object now instead of the grip (which grip  
 is now reconstituted on the other side by getting grip by object).  
 This cuts the bytes used to replicate this RPC to 1/5 of what it was.

Also a note, and text that I am adding to the plugin wiki's Tips&Tricks page so people can see it

Grippable Components and Replication

By default all components in the engine are set to bReplicates = false. The grippable components specifically have some properties that can be useful to replicate to clients (Gameplay tags and VRGripInterfaceSettings), if an object is not set to NetLoadOnClient and is placed in the level with custom settings over its base class the values will not replicate to the client unless you set the component to replicate.

bReplicateGripSettingsAndGameplayTags enables / disables them being sent when the component is set to replicate.

Also there is now a bReplicateMovement variable on all grippable components so that when replication is enabled they don't add additional overhead by also defaulting to replicate their position. When the grippables grip type is ServerSidedMovement it overrides this value and auto replicates movement when the component is set to replicate.

[mordentral]

Pushed some more changes to the plugin today

Added boolean to player controller (default true) bDisableServerUpdateCamera. When true it disables the automatic view replication from the camera manager for the camera. Typically we are already sending the camera's position / rotation in VR and the replicated value isn't that useful anyway. Unreal tournament turns it off and sends the look value from the clients when important actions happen and in VR most actions happen off of direct input instead anyway. (this removes a 1000b/s replication cost or so).

The boolean can be disable to return the typical engine functionality.

Added ExLight RPCS for char movement that activate when Acceleration is also zero

Removed the defaulting of Replicate movement on grippable components when movement is set to server side. After second thought I would prefer the bReplicateMovement be manually set by plugin users here.

Also added a new game to the "Projects using list"
Run Of Mydan

[mehdiyasstreet]

Hi , I couldnt figure it out how to control camera fov,

I tried inside Vive Pawn Character, where you toggle laser beams with shoulder button, I tried with tying up node "set fied of view" but it doesnt work. I need it for sniper rifle's zoom in option.

How can I solve this?
مشاوره تحصیلی

[IslandPlaya]

Hi Mordentral,
A small request. Could we have a IsInVREditorPreview node similar to IsInVREditorPreviewOrGame except that it returns false if in game please?
I have apps where desktop/VR mode is user selectable from a UI. My PlayerController decides which pawn to spawn. My default is desktop (fps) pawn. This works great except that VR Preview uses the fps pawn. I use IsInVREditorPreview to fix that. Maybe other people will find it useful for that.
Cheers.
Fyi, the door component of the door actor in the template map generates a warning. Changing the gameplay tag to DropType.OnTriggerRelease fixes it.

[mordentral]

Hi , I couldnt figure it out how to control camera fov,

I tried inside Vive Pawn Character, where you toggle laser beams with shoulder button, I tried with tying up node "set fied of view" but it doesnt work. I need it for sniper rifle's zoom in option.

How can I solve this?
مشاوره تحصیلی

They disable FOV with a VR enabled camera, regardless generally in VR you should be actually making functional scopes and rendering a view to the scope itself instead of altering field of view for the character.

Its still possible to force a new FOV but it would be VERY disorienting in VR and not likely to behave like you think it would.

[mordentral]

Hi Mordentral,
A small request. Could we have a IsInVREditorPreview node similar to IsInVREditorPreviewOrGame except that it returns false if in game please?
I have apps where desktop/VR mode is user selectable from a UI. My PlayerController decides which pawn to spawn. My default is desktop (fps) pawn. This works great except that VR Preview uses the fps pawn. I use IsInVREditorPreview to fix that. Maybe other people will find it useful for that.
Cheers.
Fyi, the door component of the door actor in the template map generates a warning. Changing the gameplay tag to DropType.OnTriggerRelease fixes it.

Thanks, I couldn't figure out where that gameplay tag was, they don't exactly give detailed warning information for gameplay tags yet.

Yea I can add that, no reason not to.

*Edit* its in, was like a 2 second addition so no reason to sit on it.

[mordentral]

Pushed a new commit to the plugin today

Plugin

Added replication smoothing to the camera like the controllers have  

Made the first replication directly set the location instead of beginning a lerp, all other replications  
after that are lerped too. This prevents the initial 'tick' of lerp going from 0,0,0.  

Added IsInVRPreview node to the VRExpansionFunctionLibrary

Template

Set the VivePawnCharacter to default smooth the camera replication and to a 60htz rate instead  
of the 100htz default.

[mordentral]

Pushed new commits to the repository and template


Template

fixed door warning

added offset to spawn logic so that player should arrive
correctly regardless of HMD offset.

Fixed car not using driver since I remade how it handles seats

Set the VivePawnCharacter to default smooth the camera replication and to a 60htz rate instead
of the 100htz default.

Changed how out of body movement works

Now I am spawning a camera actor locally instead of having an attached child actor component

First this removes a component/actor from non local characters per character, so it is a slight perf savings.

Secondly this removes the damned "vivepawncharacter needs to save" regardless of changes made to it.
Child actor components are still largely bug ridden and messy.

Plugin

Changed non post teleport teleportMoveGrip commands to ignore NoTeleport
and DropOnTeleport objects and exit. *This is actually more serious than it sounds, it could cause static objects that
aren't supposed to move to be able to slightly shift on initial grip*

Added replication smoothing to the camera like the controllers have

Made the first replication directly set the location instead of beginning a lerp, all other replications
after that are lerped too. This prevents the initial 'tick' of lerp going from 0,0,0.


Made some fixes to the movement merging/combining capability of the VRCharacter, should be more stable
and reliable now.

Now more appropriatley declaring Important moves so that they are sent again if not Acked
(prior to this CustomInputVectors and Navigation Velocity didn't trigger as important).

Made more nuanced checks for CanCombine in the saved movements that acutally allows for combining
movements with HMD movements attached. Uses the same Dot Threshold as the acceleration combinining does.
(5 Degrees by default).

*From initial testing it appears safe now to enable MergeMovements on the movement component, if it remains stable I will default it*

Removed Control Pitch and Control Roll from being replicated AT ALL in the VRCharacter.
We never use these two values. (This saved 3 bytes per rep send)

Upped CapsuleYaw from 1 byte compressed to 1 short compressed for sends
(this cost 1 byte per rep send).

(Overall this saves 2 bytes per rep send and has a higher accuracy of HMD yaw).

Added alt path to restore original control roll/pitch replication if character is set to follow it

I understand that this is a lot of additional code for a 2 byte per rep savings.