VR Expansion Plugin

[mordentral]

Thanks for the help! How would I go about building a plugin? I may just be out of my league here, but it wan't to much trouble getting it set up with 4.13 so I don't know if I am missing something obvious or if it has just changed a bunch in the last couple weeks. I am also confused because the file that I downloaded and used with 4.13 was around 300 megs and now the download file is only 123KB, so it is quite likely that I am downloading the wrong thing now. Thanks again!

You managed to snag a version of 4.13 with matching binaries for you, I had to remove them because the edit history on them was going to over fill my repository space.

To build your project it needs to have a c++ source file already so that it generates the .SLN file (ADD NEW button in editor, then source file / blank source file). Then you open the SLN, go to the top under build, and select build (or press f7 with visual studio open). This will be required for all projects with plugins that aren't installed in your engine directory or through the marketplace so I suggest you learn how to do it.

I won't commit to adding direct pre-built downloads like my other plugin yet as it would take too long to re-build all platforms over and over with each patch at the moment.

[mordentral]

Is this how the "Closest Primary Slot In Range" is supposed to be used? Or if left to default, does it automatically check for "P1" and "S1" as socket names to get "P1" as the closest and base the distance on the "PrimarySlotRange" var?
https://gyazo.com/ab7f454f049347b179bdb80aa0821c08

Closest primary slot in range can either be filled in by you any way that you like, or you can use the helper static function node in VRExpansionFunctionLibrary::GetGripSlotInRangeByTypeName and pass in the prefix for the slots you are looking for.

My Default implementation in the grippable components designates primary slots as "VRGripP" and then a number and secondary slots as "VRGripS" and then a number. The helper function searches through all slots on the mesh and checks ranges for the ones that start with the correct prefix.

There are only default implementations on the grippable objects though, any custom class that doesn't derive from one of those needs to fill out the function itself. You can also override the default in any of the grippable objects in blueprint by doing what you are doing.

[Fantasifall]

Thanks! If I were to make a suggestion, it would be to have a grippable object class for skeletal meshes as well. I wasn't planning on using the grip functionality, but you're two hand grab functionality future proofs my project so I refactored everything I wrote myself. I've said it before but your work is great!

[jayNose]

You managed to snag a version of 4.13 with matching binaries for you, I had to remove them because the edit history on them was going to over fill my repository space.

To build your project it needs to have a c++ source file already so that it generates the .SLN file (ADD NEW button in editor, then source file / blank source file). Then you open the SLN, go to the top under build, and select build (or press f7 with visual studio open). This will be required for all projects with plugins that aren't installed in your engine directory or through the marketplace so I suggest you learn how to do it.

I won't commit to adding direct pre-built downloads like my other plugin yet as it would take too long to re-build all platforms over and over with each patch at the moment.

Ah, it makes a lot more sense to me now. Thanks so much for the response, You're awesome!

[Gnometech]

You could also just set braking friction and max acceleration to a value high enough to force instantly the max/min speed you have set (IE: 2000048.0 just add two zeros to the default).

I've tried out both the high forces, as well as directly using RequestDirectMove(), and at slow walking speeds I can't tell the difference. So I think I'll go with your suggestion of using the high forces to get the effect I'm after. Thanks!

I've also noticed an error in the Vive_PawnCharacter Blueprint's CheckAndHandleHoveringMovement function. With the current logic you're checking if either motion controller thumbstick is greater than zero before processing the hover movement. However, I believe what should be there is a check for not equal to zero. Otherwise, it is impossible to move when the thumbstick is in the upper left quadrant (X and Y are both negative in that region).

I also wasn't sure if this was by design, but it appears that the secondary hand can grip the rifle at any location, effectively making the secondary grip anywhere. While holding the rifle in one hand, I can grab the stock of the rifle with the other hand and pivot between my hands, for example. This also makes it impossible to use the slider on the top of the rifle with my secondary hand, as I'm always gripping the rifle instead.

Thanks!

- Dave

[duma]

Also I'm curious, does anyone have any requests for the template? It is fairly easy to add content to it.

Hi mordental,
I think that the "cartridge example" from VRContentExample (video) can be an interesting addition to your template. This, combined with the "lever example" from this plugin, can create an effect like the intro of job simulator.

Anyway, thanks for your awesome work. I think UE4 really miss something to let beginners deal with roomscale VR basic interactions; the basic template shipped with 4.13 is good, but not enough. Are you planning to create something like vrtk docs? Maybe the community can help you with it?

[mordentral]

I've tried out both the high forces, as well as directly using RequestDirectMove(), and at slow walking speeds I can't tell the difference. So I think I'll go with your suggestion of using the high forces to get the effect I'm after. Thanks!

I've also noticed an error in the Vive_PawnCharacter Blueprint's CheckAndHandleHoveringMovement function. With the current logic you're checking if either motion controller thumbstick is greater than zero before processing the hover movement. However, I believe what should be there is a check for not equal to zero. Otherwise, it is impossible to move when the thumbstick is in the upper left quadrant (X and Y are both negative in that region).

I also wasn't sure if this was by design, but it appears that the secondary hand can grip the rifle at any location, effectively making the secondary grip anywhere. While holding the rifle in one hand, I can grab the stock of the rifle with the other hand and pivot between my hands, for example. This also makes it impossible to use the slider on the top of the rifle with my secondary hand, as I'm always gripping the rifle instead.

Thanks!

- Dave

Yeah that sounds like the wrong behavior with the track pad, i'll fix it today.

The gun though is intended and the top cube can still be gripped, I wanted to show that you don't need slots for dual gripping and that initial relative location doesn't matter. That being said I didn't tweak the collision sphere that I use to start my gripping trace from and it is rather large, i'll reduce it a bit so that gripping makes a bit more sense.

[gozu]

I made some onward style movement in c++ just the other day,
Maybe you can translate something similar to blueprint.
Just figured id share here seeing as we were talking about trackpad movement

Thanks again for the awesome plugin mordentral

// Move forward/back
void AProtonCharacter_VR::MoveForward(float Val)
{
	if (LeftMotionController && Val != 0.f)
	{

		//note: i tend to actually grab a bunch of info like this during tick. put here for convenience of sharing...
		if (LeftMotionController && VRReplicatedCamera) {
			LeftHandCurrentPosistion = LeftMotionController->RelativeLocation - VRReplicatedCamera->RelativeLocation;
		}

		//rotation/direction is from rotation of controller
		//you still need to deal with actor/control rotation in your project
		//this is just to generate movment :)
		const FRotator Rotation = LeftMotionController->GetComponentRotation();
		const FVector Direction = FRotationMatrix(Rotation).GetScaledAxis(EAxis::X);

		//FORWARD is scaled by distance of controller from camera
		if (LeftHandCurrentPosistion.Size2D() >= 10.f && Val > 0.f) {
			const float TrackpadMoveScaled = TrackpadMoveScale * LeftHandCurrentPosistion.Size2D();
			float NewVal = Val * TrackpadMoveScaled;
			AddMovementInput(Direction, NewVal);
		}
		//BACKWARD is not scaled from camera
		//and is nerfed down to 0.25, walking backward in vr sucks....
		if (Val < 0.f) {
			float NewVal = Val * 0.25f;
			AddMovementInput(Direction, NewVal);
		}
	}
}

// Move left/right
void AProtonCharacter_VR::MoveRight(float Val)
{
	if (Val != 0.f && VRRootReference)
	{
		const FVector Direction = VRRootReference->GetVRRightVector();
		//strafing in vr also sucks, so is nerfed to 0.25...
		float NewVal = Val * 0.25f;
		AddMovementInput(Direction, NewVal);
	}
}

Then you can just assign the axis in your project settings, and pass through to your character from your pc as per usual....

[mordentral]

Pushed some changes

Template Change Log

11/19/2016- Fixes

Fixed Hover DPad mode using incorrect comparison operators

Changed gun to have a grippable collision box on top instead of mesh.

Changed drawer example to have both physics and interactive examples.

Tightened up trace sphere to make gripping easier

Grip trace now traces against complex collision to further increase grip accuracy.

ConvertToControllerRelativeTransform node in pickup testing now being passed in to be gripped item to check for rotationless interactive settings in order to get a modified transform.

Fixed issue where since the stopper was parented to the flask on initial grip it could turn gravity off on the flask.

All interactive objects with a locked linear path updated to use rotationless grip for more accurate useage and a better feel.

NEW VERSION REQUIRES REBUILD DUE TO PLUGIN CHANGES

Plugin Change Log

11/19/2016- Fixes

Added method for rotationless interactive grips, requires use of the ConvertToControllerRelativeTransform node on client side if networked due to not wanting to bloat the gripping struct any more.
Works without the helper node if single player.

Added grippable skeletal mesh actor/component.

Changed server side physics to correct a bug.

Removed all instances of Interactive Component/Actor from grip target and grip target enum / interface, is not actually needed.

Grip Actor/Component/Object now checks if object is interactive and uses rotationless grip, if true and not a socket grip or already relative transform it will adjust the transform to remove 
the controllers rotation on grip.

If the transform is being passed in as already relative (client to server for example) it will need to use the ConvertToControllerRelativeTransform node with the object passed in to remove 
the controller rotation from the relative transform. Otherwise interactive actors with rotationless grip won't work perfectly.

[Sergiy]

I've been playing with your sample, great work, thank you!

Is it supposed to work in multiplayer as-is? I tried packaging the sample project and running it on 2 different machines with Vives, on the same LAN, but they don't seem to connect.

Here are my command lines:
(Machine 1, IP: 192.168.0.11) VRExpPluginExample.exe ?listen -log -vr
(Machine 2, IP: 192.168.0.5) VRExpPluginExample.exe 192.168.0.11 -vr

[Gnometech]

The gun though is intended and the top cube can still be gripped, I wanted to show that you don't need slots for dual gripping and that initial relative location doesn't matter. That being said I didn't tweak the collision sphere that I use to start my gripping trace from and it is rather large, i'll reduce it a bit so that gripping makes a bit more sense.

OK, good to know. In my particular case, I'm more interested in having the secondary hand only being able to grip specific areas, as you would on a real gun. I'll work through the example and see what needs to change.

Thanks!

- Dave

[mordentral]

OK, good to know. In my particular case, I'm more interested in having the secondary hand only being able to grip specific areas, as you would on a real gun. I'll work through the example and see what needs to change.

Thanks!

- Dave

In the gripping function, just have it fail if it returns no secondary gripping point in range. Or if you want it to always work but go to the front, just increase the radius of the secondary slot range to something large enough to cover the entire gun.

Honestly the checking for secondary grip portion should be done client side anyway, it is currently server side in the template which will have some small offset due to latency.

[mordentral]

I've been playing with your sample, great work, thank you!

Is it supposed to work in multiplayer as-is? I tried packaging the sample project and running it on 2 different machines with Vives, on the same LAN, but they don't seem to connect.

Here are my command lines:
(Machine 1, IP: 192.168.0.11) VRExpPluginExample.exe ?listen -log -vr
(Machine 2, IP: 192.168.0.5) VRExpPluginExample.exe 192.168.0.11 -vr

Its defaulted to steam at the moment, if it can't load steam than null connections should work but you can go into the game config and change the default online platform to null instead of steam.

The gripping and movement and things should all work in multiplayer with the template, but the items with custom logic haven't been worked over yet for multiplayer and I am not running any checks for if other players are holding objects yet.

[Gnaw]

How would you go about having the mesh hands from unreal 4.13+ template with the animations into this template? Also being able to set how far someone can teleport when in the teleport mode?

[mordentral]

How would you go about having the mesh hands from unreal 4.13+ template with the animations into this template? Also being able to set how far someone can teleport when in the teleport mode?

In the player there is a OnPossesed node path that downloads the controllers from steam, just unlink those nodes and the default template hands are there (I hide them for the controllers).

Teleport distance can be set in the TeleportController blueprint that is spawned in to control Epics teleportation system.

*Edit* You would want to adjust the collision spheres attached to each hand, their location defines the sphere trace for gripping, they are currently set up to feel most natural with controller models.