VR Expansion Plugin

[mordentral]

Hello,

I don't know if it has been posted before or not, tried searching but nothing was coming up. I am on the first version of the 4.18 Template, and I am encountering a problem with gripping skeletal meshes, for some reason they are at least 20-30 units from the hand itself. Is there any reason behind this? I am primarily an artist so I am not too great with blueprints and I am doing this for my 3rd year project at uni.

Any help to point me in the right direction would be greatly appreciated.

Thank you

PS: The picture might be a bit dark but the Top of the lantern where I start the grip is no where near the hand.

What does the root bone of that lantern look like? And is it rotated heavily?

Also what does the collision for the lantern look like?

[Rumbleball]

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

I'm on a good way to get everything working regarding the scaling. However on the client it is still broken and the controllers jitter like hell. So I gave your Temple a try to see if its working with the latest updates you applied.

But even this simple setup


causes most weired behavior. The controller skelletal meshes are still at the original location (like I'm 100% scale). The DrawDebugSphere shows inbetween the actual real controller location and the headset.

[mordentral]

I'm on a good way to get everything working regarding the scaling. However on the client it is still broken and the controllers jitter like hell. So I gave your Temple a try to see if its working with the latest updates you applied.

But even this simple setup


causes most weired behavior. The controller skelletal meshes are still at the original location (like I'm 100% scale). The DrawDebugSphere shows inbetween the actual real controller location and the headset.

Turn off late updates on the controllers, Epics current late update system broke with WorldToMeters and only treats it like it is 100.0f. The game thread however is correctly offset.

[Rumbleball]

Turn off late updates on the controllers, Epics current late update system broke with WorldToMeters and only treats it like it is 100.0f. The game thread however is correctly offset.

You wrote that already, shame uppon me. I gues you mean the "DisableLowLatencyUpdate" checkbox on the MotionControllerComponent, that worked, thanks.
And thanks for your amazing support regarding this plugin, wish you could get that support on everything. And I'm still wondering how you handle that plugin despite its just some freetime work you do. Got yourself a patreon.

Edit: Well, bit to early for joy. The VR relative positions are adjusted but the camera viewport does not change. So you are basically small, but you view like a big one. Difficult to describe. It feels like you just lay down on the ground and view the world from there.

[mordentral]

You wrote that already, shame uppon me. I gues you mean the "DisableLowLatencyUpdate" checkbox on the MotionControllerComponent, that worked, thanks.
And thanks for your amazing support regarding this plugin, wish you could get that support on everything. And I'm still wondering how you handle that plugin despite its just some freetime work you do. Got yourself a patreon.

Edit: Well, bit to early for joy. The VR relative positions are adjusted but the camera viewport does not change. So you are basically small, but you view like a big one. Difficult to describe. It feels like you just lay down on the ground and view the world from there.

I hadn't noticed that when testing in 4.18, but I wouldn't put it past the setup for the camera suffering from the same issue.

They did already make some late update changes in the unreleased 4.19 branch, but I didn't see anything that I would assume would fix that.

*Edit* Not entirely sure what you mean either by "view like a big one" btw

[Rumbleball]

I hadn't noticed that when testing in 4.18, but I wouldn't put it past the setup for the camera suffering from the same issue.

They did already make some late update changes in the unreleased 4.19 branch, but I didn't see anything that I would assume would fix that.

*Edit* Not entirely sure what you mean either by "view like a big one" btw

If you scale yourself small the object in front of you should feel bigger than it was before scaling. But that is not the case. You see the object like it was before, just from a different perspective. Basically the camera does not scale down.

[mordentral]

If you scale yourself small the object in front of you should feel bigger than it was before scaling. But that is not the case. You see the object like it was before, just from a different perspective. Basically the camera does not scale down.

Ah, so you aren't getting the perspective difference.

Yeah you might want to check that in a standard 4.18 UE4 VR template. I need to report the controller issue anyway but if the camera suffers from the same thing it should be part of the report.

[Rumbleball]

Ah, so you aren't getting the perspective difference.

Yeah you might want to check that in a standard 4.18 UE4 VR template. I need to report the controller issue anyway but if the camera suffers from the same thing it should be part of the report.

Had my try on the default template but it seems so broken I don't even know what real anymore. Camera seems to have the same issue.

[Rumbleball]

BugReport:
Had a try on your StereoWidget (UE4.16)
-Renders nicely in StereoLayer, but it does not acount for the pivot property of the widget component. The widgetcomponent itself is where it should be (pointer interaction), but the render in StereoLayer is always with Pivot(0.5;0.5).
-I attached the StereoLayer widget to the controller. The render into the StereoLayer was rotating realy weird and does not stay fix like a normal relative component. (World locked? What ever that means. Just came about it in the patch notes)
-StereoLayer component of Unreal renders into -x, your StereoLayerWidget renders in +x direction. I know, Unreals WidgetComponent renders in +x as well. Weird stuff.

[dillBrickle]

I'm currently working on a pump-action shotgun using this plugin, and it seems that grippable child components in the GrippableStaticMeshActor blueprint aren't able to move the parent actor as a whole. For example, if the pump alone is gripped it can be moved back and forth in its constraint on the blueprint, but the gun as a whole stays stationary and cannot be picked up or moved unless it is gripped directly. Ideally I would like to be able to **** the gun using the handle alone with the gun's inertia as seen

[mordentral]

BugReport:
Had a try on your StereoWidget (UE4.16)
-Renders nicely in StereoLayer, but it does not acount for the pivot property of the widget component. The widgetcomponent itself is where it should be (pointer interaction), but the render in StereoLayer is always with Pivot(0.5;0.5).
-I attached the StereoLayer widget to the controller. The render into the StereoLayer was rotating realy weird and does not stay fix like a normal relative component. (World locked? What ever that means. Just came about it in the patch notes)
-StereoLayer component of Unreal renders into -x, your StereoLayerWidget renders in +x direction. I know, Unreals WidgetComponent renders in +x as well. Weird stuff.

Yeah I reversed the render direction so that the widget and stereo layer would line up, otherwise when switching between stereo and 2D mode they would be inverse.

As for being attached to the hand, it would need to be set to track the motion controller instead of the HMD then, currently it assumes the HMD, it would also have to be switched to relative space, should be fairly simple, though getting it with the late updates is another matter, you are seeing offsets because the controllers late updates are enabled.

I'll check on the pivot, forgot that it existed


Thanks though, not too many people test the stereo layer widgets.

[mordentral]

I have an experimental branch up where I have been thinking about the best way to make the car seat setup a native part of the VRBaseCharacter and implement it cleanly and correctly over the network. It has accumulated several changes besides that from me fixing / changing things as I go, so if I don't finish the seating part before the holiday I will likely strip those out separately and push them live.

The most notable change is stripping out all reliance on the VRExp module from the OpenVR module so that it can be used by itself (no more tracked device requirement so I can finally do this). This happens to be just in time for 4.19 bringing in true model loading for VR tracked devices natively built into the engine ;p so I will at some point be removing the code for loading the SteamVR models as well when their implementation proves stable.

Just wanted to give a heads up why no commits were happening lately.

[Apokrif78]

Good afternoon. Thank you for your work. Thank you for the opportunity to access your plugin. I'm new to UE4. I wanted to ask you a question: "How should look like (EventGraph), the interaction of" laser pointer "with" static mesh. " That it worked as well as with the "Widget buttons" (Navel laser pointer on the "Static Mesh" pressed the "trigger manipulator" - "Static mesh" performs the specified action.
Example 3d widget. Has included "Laser Pointer". I chose the menu button. I pressed "Triger". With that, I understand. How to do the same, only not with the menu button, but with the "Static Mesh" ?.
Sorry for my english
I hope my request, you will not be hindered.
Thank you for your contribution.

[KelbornKad]

Hello. What is correct way of making slot gripping? I've put slots on mesh and named them VRGripP#. It was okay for one hand, but another is rotated towards its forward axis by 180 deg. I use Vive_PawnCharacter with my hand meshes, where one is scaled -1 on z but motion controller components are unchanged. Thanks.

[MagicBots]

So I was trying to achieve the following, and wondering if you might have any insights. I created some subclasses of the Vive Pawn Character each with a different skeletal mesh assigned under parent relative attachment, and I've added an box overlap trigger with the idea to possess on overlap characters placed around the level. Problem I'm running into is that even though tick is disabled for those characters placed around the level, the parent relative skeletal meshes are moving around with my default possessed character, and I have duplicate controllers following me around as well. Is there a way to completely disable the vive pawn character until possessed? Or any other way of achieving this type of interaction with the vive pawn character?