Do you keep a changelog of tweaks like this by any chance (stuff you change in the template in blueprints etc)? I’m using my own project mixed with some of your work and so it doesn’t update with the template although I’d like to keep some of the better fixes in such as this one.
I normally list it with the Template Changes log, that one I overlooked adding in. I was planning on listing it next time I posted an update.
Excellent, thanks for the answer!
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.
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?
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.
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
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.
Trying the default template, but there the Checkbox “DisableLowLatencyUpdate” does not even fix the dispositioning. Camera seems to have the same issue as described above.
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.
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.
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
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.
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.
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.
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.
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?