VR Expansion Plugin

I can’t make the HeadMesh component of the pawn cast a shadow. It’s set up the same as the mannequin hands as far as I can see. Could the problem be due to the proximity of the head mesh with the camera?

Cheers

EDIT: I fixed it by replacing the skeletal head mesh box with the GenericHMD static mesh from Epic’s VR template.

Yeah it was just a box, shadow casting was probably turned off for it.

Also I’m not sure I should be removing twist and changing manipulation grips point of contact. The problem is that I will have to start passing in the hit location of grip attempts in order to move the interaction point and most uses of manipulation grip don’t require . It is more overhead for something that is rarely used and I can’t really support every possible interaction with just plugin grips anyway, which is why I added the custom grip in the first place. Also on overlap there IS no clean hit point so the logic on that case is difficult to take care of automatically as it pretty much depends on the how the user wants to interact with the object.

I think your use case would be better served by using a “custom grip” and manually constraining the hand and the object when the “OnGrip” event is fired, then “OnDrop” removing the constraint. will let you get the exact functionality that you want. That or adding a dedicated “handle” interactor to your wheel that you can grip instead that is then constrained to the wheel.

Edit Also your greyed out simulate is caused by the mesh not having a physics collision set up, also I made a “wheel” that is constrained in world to only rotate on the rim axis and it works fine with a stock manipulation grip. I’m not entirely sure what you are trying to accomplish though.

I think I understand the concerns you have about the overhead here but I disagree that the use I want to put the manipulation grip to will be rarely used. My preference is that the naked manipulation grip should act like grabbing an object between your thumb and finger (I get your point about being object/grip specific) and letting it hang free to be moved around without hand rotation playing a role (optional?). I think most people would expect behaviour as it is very useful for all sorts of situations.

Would you removing the hand twist from the manipulation grip and my custom grip point issue being handled some other way (by me) be a good compromise? If not then I’ll try to follow your advice and implement a custom grip. Would I have to handle all sorts of multiplayer stuff in the custom grip that you do in the plugin? I’m sure to muck that up… :frowning:

Thanks

EDIT: I already have a handle on my wheel where I place a VRGripP1 socket. I want the grip for point to be the manipulation grip I described above. Think rotating the large wheel/crank quickly, I don’t want any rotational hand input on the grip for the handle otherwise you turn the wheel like you do whilst gripping a steering wheel. is bad for things that aren’t steering wheels. Apols if I’m not communicating clearly.

Its injecting the hit location that is the problem (How to know where to put the constraint on the hand), there is no way to do it automatically off of the relative transform and I went through the effort of actually implementing it in the plugin morning as an optional in variable and I didn’t like it due to how much additional blueprint nodes it required as well as not being compatible with overlaps as they don’t throw a hit location. As far as wrist goes I don’t know for sure that people aren’t currently using that functionality and so I am loath to change it, more so when generally it doesn’t play into the standard interactions. However I WILL make a concession and add an additional grip type “ManipulationGripWithWristTwist” which will retain the classic functionality, with the original dropping the twist drive.

As far as multiplayer, custom grips will throw OnGrip and ReleaseGrip notifications on all authority clients for gripping, in the case of client side gripping that would be everyone, for server side it would be the server only. For custom grips the logic and what happens is all handled in the object being gripped (like Epics default template).

Pushed new commits to the template and the plugin

Plugin changes



Linked OpenVRExpansion module directly into VRExpansion to avoid code duplication
and allow for cross module class children.

Added a probably temporary child class to GripMotionComponent "OpenVRTrackedDeviceComponent".
Until epic stops checking for left/right hand index or creates a new tracked controller class, the default motion controller
will not work with the VivePuck after a recent firmware update that changes it to a tracked device/other instead of a motion
controller in the OpenVR system. - A child class to UGripMotionController was chosen in order to keep all OpenVR
specific code in the OpenVR module. Required opening up the PollControllerState function as public (could have been protected
but might be useful) and virtual.

Removed all direct instances of including Engine.h and replaced with the relevant direct header includes.
Should improve compile times across the board.

Added interface for getting handles to OpenVR HMD cameras and getting the frame buffer from them into a Texture2D.

Added GetGripByObject node, an obvious node after transitioning to all UObject base for the plugin that was forgotton about.
Should eventually remove the GetGripByActor and GetGripByComponent nodes.

Split manipulation grip into a With Wrist Twist and Without Wrist Twist version types.

Default no longer has the wrist twisting drive.


Template Changes




Added example of drawing an OpenVR HMD camera to a texture for the vive_PawnCharacter.

Removed debug print string from the gun base.


Roger that!
Thank you and respect for actually trying code out to address my ‘issue’ If you were unhappy with the consequences then that’s good enough for me. I’ll be able to make progress now with the wrist twist free grip :slight_smile:
I’ll re-visit the hit location problem in the near future. It is by nature very specific to a particular project/grip/object/whatever and understand why you feel it’s unsuitable and/or messy for you plugin.

Did I mention your plugins rock? :slight_smile:

Your updated manipulation grip has allowed me to close an issue that was open for 7 days(!). Cheers.
Was curious to look at your camera component but after enabling it in game it just shows that bubbly texture. I previously had a battle royale with my Vive refusing to detect the camera so it may be my setup or I’ve not enabled it properly. Not matter, it’s good to know the feature is there for future possibilities. I have something in mind, but it’s near the bottom of a very long list and prolly won’t work too well. Do you know what resolution the camera/capture is?

You have to have it enabled in SteamVR, so if you were having issues with it and disabled it then its likely not active / can’t be latched on to.

The resolution is rather poor, around 670/4xx or something like that off the top of my head, the “tablet” box auto scales by the res somewhat and the “HasVRCamera” node returns the width / height in pixels of the camera.

Edit It shouldn’t be polling the camera frames on tick like it is currently (when the tablet is up), it should be 30htz or so but my original texture write wasn’t liking timers (new one should be fine with them) and I haven’t bothered to limit it yet.

Regardless its fairly low cost since its resolution is so poor, and even the blueprint overhead of calling in to C++ to get the frame would go away with nativized node packaging.

After some fun I got the camera enabled and working on the Steam dashboard so all is good there. I’ll check your camera tablet again after my controllers recharge and I do some tasks I’ve been putting off.

I presume it will be straightforward to save out a still camera-frame to disk on an event. I could maybe quickly tryout the idea I have… I have a Photoscan license. Can you guess what I’m gonna try?

Hi , thanks for all the hard work. Question, will latest change cause any problems with cross-platform compiling for Android, Linux, etc., that do not have UE4 support for SteamVR?

Can I still just disable the OpenVRExpansion plug-in, stick to the non-OpenVR features and still be good-to-go?

I managed to get things working, multi-player and cross-platform with a few tweaks, so any advice in regard is appreciated.

Thanks!

Yeah the linkage is one way, OpenVRExpansion depends on VRExpansion but not the other way around. Sorry I should have specified that, I wanted to couple OpenVRExpansion back to it so that I could use some of the built in types.

As of a couple of engine versions ago I beleive that saving texture 2d’s to disk is a simple BP node: Export Texture 2D | Unreal Engine 5.2 Documentation

So yes very easy

Indeed, it couldn’t possibly be any easier. Thanks for the docs link. I have the camera capture BP nodes over in my project now and it works a charm. Must have been a Vive problem earlier, it does throw USB tantrums every so often.

The quality of the images is disappointing for feeding into Photoscan, I will see what results I can tease out of it. Good lighting will help and fortunately I have a couple of lighting rigs hanging around for MR use (when Epic get round to it, hopefully soon now the Vive Tracker is available) that I can use for experiments.

My post earlier took forever to get approved by a mod but was what I was talking about: Grip Test - YouTube

I’m new to UE4 so forgive me if I’m missing something, but it seems like getOverlappingComponents always returns nothing when the object is already being gripped, and only the sphere trace works? If I use componentOverlapComponents it works though.

I knew I shouldn’t have said that. My hubris has resulted in a fall at the first hurdle as I cannot save a single frame.

ImageUtils:Warning: Warning Unsupported source texture format provided.

is emitted by the Export Texture2D node when called with CameraRenderTarget. The pixel format EPixelFormat::PF_R8G8B8A8 you chose seems sensible. Although the doc page mentions HDR textures I can find nothing else about the export node.

Any ideas?

Hmm, I’ll have to check out the export texture node when I get a chance, R8g8b8a8 is actually fairly non normal for the engine, I chose it because that is the native format for OpenVR’s camera buffer so it could just use a memory copy. Could be as simple as converting the format.

Yeah I turn off collision with the actor when gripping an object (MoveIgnoreActor with the pawn), otherwise the engine spams BeginOverlap events and the bIsColliding check for the late updates triggers wrong. Using ComponentOverlapComponents is a valid fix for the second hand, I didn’t think about it, since it is an external sweep check it doesn’t obey the movement, thats a good idea, i’ll make the GetClosestActor function use that instead of the currently overlapping components.

Edit Strange thing is that during tick the overlap is correct as the hand animation plays, it is wrong from the pick up function though.

im trying to integrate aspects of the plugin to work in a project thats built using nvidia’s flex source. do you think your plugin would work using that? i’ve tried to generate project files, but I am unable to build the project because of several errors. I’ve adding the names of the plugins to the PublicModules in my build. Then I try to build straight from the project file. it tells me to build manually. i generate an .sln and try to build within visual studio only to get errors. do you have any suggestions?

Yeah someone else already built it under flex and I helped them with it. Flex has a new module that ties into the physics system so it has to be included in the plugins “public module includes” or it fails to compile since I have to dig into the physics code a bit. I can’t include module normally as it doesn’t exist in the standard engine.

That being said it also depends on what engine version you are using with Flex integrated and what version the plugin is. If you post the compile log with errors in


 tags in here or in PM I could let you know if anything else needs to be done.

Oh, awesome, i’ll dig around to see what I find. I’m building it using 4.15.0 flex release version. and there are the errors I am getting:
Severity Code Description Project File Line Suppression State
Warning MSB4011 “C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCTargets\Microsoft.Makefile.props” cannot be imported again. It was already imported at “C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.cpp.props (31,3)”. is most likely a build authoring error. subsequent import will be ignored. [D:\UnrealProjects\FlexVRTemplate\Intermediate\ProjectFiles\FlexVRTemplate.vcxproj] FlexVRTemplate 31
Error C1083 Cannot open include file: ‘NvFlex.h’: No such file or directory FlexVRTemplate c:\program files\unrealengine-flex-4.15.0\engine\source\runtime\engine\public\PhysXIncludes.h 80
Error C1083 Cannot open include file: ‘NvFlex.h’: No such file or directory FlexVRTemplate c:\program files\unrealengine-flex-4.15.0\engine\source\runtime\engine\public\PhysXIncludes.h 80
Error C1083 Cannot open include file: ‘NvFlex.h’: No such file or directory FlexVRTemplate c:\program files\unrealengine-flex-4.15.0\engine\source\runtime\engine\public\PhysXIncludes.h 80
Error Failed to produce item: D:\UnrealProjects\FlexVRTemplate\Plugins\VRExpansionPlugin\Intermediate\Build\Win64\UE4Editor\Development\UE4Editor-VRExpansionPlugin.lib FlexVRTemplate D:\UnrealProjects\FlexVRTemplate\Intermediate\ProjectFiles\ERROR 1
Error MSB3075 The command ““C:\Program Files\UnrealEngine-FleX-4.15.0\Engine\Build\BatchFiles\Build.bat” FlexVRTemplateEditor Win64 Development “D:\UnrealProjects\FlexVRTemplate\FlexVRTemplate.uproject” -waitmutex” exited with code 5. Please verify that you have sufficient rights to run command. FlexVRTemplate C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.MakeFile.Targets 41

Yup, in the plugins VRExpansion.build.cs file in the array for PublicDependencyModuleNames.AddRange, add another line with “FLEX”.

I don’t actually think I can check for a Flex definition because come to think of it the module loading order isn’t exactly set in stone, so it will have to be a manual addition by you.

Edit I will also note, a quick check over the flex branch shows flex only adding any libraries in windows 32 and windows 64.