VR Expansion Plugin

[mordentral]

Thanks for your reply. Sorry for being a noob. But how do you rebuild the plugin with visual studio? What do I do after I open the visual studio from the project editor?

Go to the top menu and select build, or right click on your project name over on the right and select build. Eventually either the plugin may be provided with all binaries pre-built and this won't be required anymore, but I change things too often at the moment for that.

[FatalFeel]

When I rebuilt solution in visual studio, this error comes up:


Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error Failed to produce item: H:\OpenVRtemplate\Plugins\VRExpansionPlugin\Binaries\Win64\UE4Editor-VRExpansionPlugin-1939.dll VRExpPluginExample H:\OpenVRtemplate\Intermediate\ProjectFiles\ERROR 1
Error MSB3075 The command ""C:\Program Files (x86)\Epic Games\4.13\Engine\Build\BatchFiles\Build.bat" VRExpPluginExampleEditor Win64 Development "H:\OpenVRtemplate\VRExpPluginExample.uproject" -waitmutex" exited with code 5. Please verify that you have sufficient rights to run this command. VRExpPluginExample C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets 41

[thejerenator]

Pawns by default have "Use Controller Rotation Yaw" enabled which will throw out the actors rotation and use the controllers rotation instead for yaw, disabling that should cause it to rotate with it, however the problem is that the player cameras don't work with pawn rotation currently, its not really a issue with my plugin, you would have to turn off the bLockToHMD boolean (which removes the late view updates for the camera) in order to have it work like you want, and that would require manually setting the cameras location then each tick.

I assume there is going to be a fix eventually, its probably possible for me to fix in my plugin but I really shouldn't have to.

Thanks for letting me know. I'll do some more tests here and see if I can find a solution. I'll also ask on UDN and see if Epic can give me some tips.

[mordentral]

When I rebuilt solution in visual studio, this error comes up:


Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error C1083 Cannot open include file: 'corecrt.h': No such file or directory VRExpPluginExample H:\Program Files (x86)\Microsoft Visual Studio\VC\INCLUDE\crtdefs.h 10
Error Failed to produce item: H:\OpenVRtemplate\Plugins\VRExpansionPlugin\Binaries\Win64\UE4Editor-VRExpansionPlugin-1939.dll VRExpPluginExample H:\OpenVRtemplate\Intermediate\ProjectFiles\ERROR 1
Error MSB3075 The command ""C:\Program Files (x86)\Epic Games\4.13\Engine\Build\BatchFiles\Build.bat" VRExpPluginExampleEditor Win64 Development "H:\OpenVRtemplate\VRExpPluginExample.uproject" -waitmutex" exited with code 5. Please verify that you have sufficient rights to run this command. VRExpPluginExample C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets 41

You need to fully follow the installation instructions for visual studio for the engine, you are missing some required headers.

[mordentral]

Ok, I lied, I ended up finishing the replication for the new character today and then testing that multiplayer was still stable in my test bed. Found a few bugs over the past few days that had to do with ripping out one of my grip types and fixed some missing checks in the default character for floors when falling.

However right before finishing I did compile a version of the template itself and ran it multiplayer and most of the things already work. Think I am pretty good to start digging into polishing it now, the simple character is essentially done, the only thing it is missing from the default is that it doesn't support a capsule offset at the moment, other than that it should be a more stable version.

[erik007]

Hey mordentral / guys,

I just wanted to say I started to use this plugin yesterday in 4.14 and so far it's super good, extremely motivating to have such a solid physical VR base.

I think this plugin has great potential, although it would be great if there was some instructions how to upgrade once a project is based on the "VRExpPluginExample.uproject" solution.

I will post pictures and a link once i have something more to show.

Big thanks!!

[mordentral]

Hey mordentral / guys,

I just wanted to say I started to use this plugin yesterday in 4.14 and so far it's super good, extremely motivating to have such a solid physical VR base.

I think this plugin has great potential, although it would be great if there was some instructions how to upgrade once a project is based on the "VRExpPluginExample.uproject" solution.

I will post pictures and a link once i have something more to show.

Big thanks!!

Upgrade to a new plugin version? Or to a new engine version? I would suggest keeping the template as a separate project entirely that you can pull blueprints and objects from to use outside of it. Kind of like the "content packages" that ue4 has except not automated. I will be adding thing to it often enough that trying to keep something working and get the updates at the same time would likely slow you down more than help you.

For engine versions, it should currently just upgrade, I have been trying to support the current / preview versions as it goes and when the preview goes live support the older version until the next preview if possible. 4.12 was an exception as the code base changes from it to 4.13 were too dramatic. I anticipate the plugin in its updated state losing 4.13 support and locking a branch for it when 4.15 comes out, the enum changes coming down the pipeline are not compatible.





Also, to anyone else: (going to post this in the OP as well)

I would like to note by the way that everything currently in the template is an example of what I think is best practices (though still needing a little polish as I made it over three days), not everyone is going to need the same set up and not everyone is going to need a full VRcharacter. Custom pawns that just use the motion controllers and camera / parent relative component would be useful to people that don't want gravity / collision. The entire plugin itself isn't so much a complete package as one (or for the character/grips, several) example(s) of how to achieve VR capabilities in UE4....like a big public research endeavor on my part. Some things I know I would have done slightly differently if I were to go back and start over (gripping code out of the motion controllers and into a custom component that has its own late update referencing the controllers for example).

I have not changed some things that I know could be slightly better if refactored as there are projects released on steam already that use it and I don't want to break compatibility beyond repair for them.


The new SimpleVRCharacter is a more sane method of creating a VR colliding character, when I made the original one I wanted every possible feature I could think of and I broke a bunch of "soft rules" to make it happen. The new one does none of that, so while slightly less feature complete it is more in line with standard procedure for the engine.

[erik007]

Upgrade to a new plugin version? Or to a new engine version? I would suggest keeping the template as a separate project entirely that you can pull blueprints and objects from to use outside of it. Kind of like the "content packages" that ue4 has except not automated. I will be adding thing to it often enough that trying to keep something working and get the updates at the same time would likely slow you down more than help you.

For engine versions, it should currently just upgrade, I have been trying to support the current / preview versions as it goes and when the preview goes live support the older version until the next preview if possible. 4.12 was an exception as the code base changes from it to 4.13 were too dramatic. I anticipate the plugin in its updated state losing 4.13 support and locking a branch for it when 4.15 comes out, the enum changes coming down the pipeline are not compatible.





Also, to anyone else:

I would like to note by the way that everything currently in the template is an example of what I think is best practices (though still needing a little polish as I made it over three days), not everyone is going to need the same set up and not everyone is going to need a full VRcharacter. Custom pawns that just use the motion controllers and camera / parent relative component would be useful to people that don't want gravity / collision. The entire plugin itself isn't so much a complete package as one (or for the character/grips, several) example(s) of how to achieve VR capabilities in UE4....like a big public research endeavor on my part. Some things I know I would have done slightly differently if I were to go back and start over (gripping code out of the motion controllers and into a custom component that has its own late update referencing the controllers for example).

I have not changed some things that I know could be slightly better if refactored as there are projects released on steam already that use it and I don't want to break compatibility beyond repair for them.

Thanks for the reply.

Upgrade to a new plugin version.

And what i meant to say was that it's a little bit confusing if you are using the template what exactly is the plugin and what is the template, for example say that i would start playing around with building a something inside the template level, can i break the functionality of the plugin? is part of the plugin based on logic in this level?

If I add another level (inside the template project), what do i need to do to get the same functionality as in the demo level? (as in, you can have a pair of controllers, you can lift and release objects, etc). Maybe a youtube video how to setup new levels would be really good.

Big thanks again,

[mordentral]

Thanks for the reply.

Upgrade to a new plugin version.

And what i meant to say was that it's a little bit confusing if you are using the template what exactly is the plugin and what is the template, for example say that i would start playing around with building a something inside the template level, can i break the functionality of the plugin? is part of the plugin based on logic in this level?

If I add another level (inside the template project), what do i need to do to get the same functionality as in the demo level? (as in, you can have a pair of controllers, you can lift and release objects, etc). Maybe a youtube video how to setup new levels would be really good.

Big thanks again,

The plugin is code based, the character and controller components/actors are from it. Anything you do within the engine itself shouldn't have an effect on it. New levels have no special setup aside from I have a custom game mode checking for if the client has a HMD.

[erik007]

Actually, i was just gonna write. It seems to be working by default, wow, so that's great. Although in non-VR mode i've noticed gravity doesnt seem to turned on (it is working in VR mode), could this be a bug?

[erik007]

Btw, another thing, i'm looking to add is a pair of IK based arms (shoulder and elbow positions will need to be predicted based of HMD and controller positions). This feels quite generic so maybe it could become part of the plugin? At least if the shoulder and elbow positions were functions that you could ask the plugin for then you could make your own arms perhaps.

[mordentral]

Btw, another thing, i'm looking to add is a pair of IK based arms (shoulder and elbow positions will need to be predicted based of HMD and controller positions). This feels quite generic so maybe it could become part of the plugin? At least if the shoulder and elbow positions were functions that you could ask the plugin for then you could make your own arms perhaps.

IK is fairly easy for arms, attach them to the parent component and set the wrists to the controllers with IK, seperate each arm and add them to the controllers late updates so they don't lag behind. But no its not likely something I would add by default as each setup will be different and there are multiple IK plugins already.

[Sergiy]

Thanks again for a great example, mordentral!

Unlike the standard VR template from Epic, VR Expansion BP_Teleport_Controller blueprint's TeleportCylinder and child (Arrow) components have visible lag/creep when you rotate the vive controllers quickly. It looks like the relative transform of TeleportCylinder is set, and maybe the controller pushes a late transform update, which updates the world transform of TeleportCylinder, too (at least that would explain it). But the original VR template doesn't suffer from this problem.

I've been trying to understand why that happens, and it looks like BP_Teleport_Controller's TeleportCylinder works and is set up exactly the same way as the BP_MotionController, which doesn't have this problem.

Does anyone know why this happens? I'd like to try to make TeleportCylinder not derive transform from the parent scene, is it possible?

[mordentral]

Thanks again for a great example, mordentral!

Unlike the standard VR template from Epic, VR Expansion BP_Teleport_Controller blueprint's TeleportCylinder and child (Arrow) components have visible lag/creep when you rotate the vive controllers quickly. It looks like the relative transform of TeleportCylinder is set, and maybe the controller pushes a late transform update, which updates the world transform of TeleportCylinder, too (at least that would explain it). But the original VR template doesn't suffer from this problem.

I've been trying to understand why that happens, and it looks like BP_Teleport_Controller's TeleportCylinder works and is set up exactly the same way as the BP_MotionController, which doesn't have this problem.

Does anyone know why this happens? I'd like to try to make TeleportCylinder not derive transform from the parent scene, is it possible?

So you are saying not that it is "lag" but that it is TOO responsive as it pulls the late updates and thus follows orientation? I could see that, it is directly parented to the motion controller, I didn't think about the non spline sub components.


There are two easy options to fix it, i'll choose one tonight to implement:

1.
Split the children in the teleport controllers into two scene components and make a new function in them to "Setup attachments" will attach the base scene to the characters root and the secondary scene component to the owning motion controller. That way it will perform the same as epics implementation without making the controllers outside of the character. The secondary scene component would have all of the items currently using late updates as children.

2. (better)
Honestly it doesn't need the ArcDirection component at all and could just get the owning controllers forward vector instead. Could just be attached to character root then, the spline is being generated in world space not local so it doesn't actually have to be attached to the hand at all and it is the only thing currently being used that was attached to the controller in the original template version.

[mordentral]

Pushed a new template commit live

Fixed teleport components using controllers late updates

Changed pawns gripping nodes into a function call that is hand agnostic

Added FPSVive_PawnCharacter that is a subclass of Vive_PawnCharacter (not for game use, for testing)
Fixed a minor plugin bug

*Edit* I will be looking into the based component view rotation issue, its a result of the characters UpdateBasedPosition function which doesn't work nicely with VR enabled cameras.