I was in the process of converting an older character to the new refactored character (using the Vive_PawnCharacter BP from the latest template).
I noticed an issue that would cause the Right Controller Relative Velocity to not get cleared. Maybe it’s already been fixed but I thought I’d say something about it just in case:
It’s in the second part of the sequence in the ClearMovementVelocities function:
(I just call SetHandle both on Child Grip and on Child Grip Release)
The issue I have is with the “Handle” as a separate component attached to the main “Door” component:Everything works great when I use a regular Static Mesh Component, but (predictably) the Child Grip/Release are not called, so the handle doesn’t rotate when I grab the “Handle” (it only rotates when I grab the main component (“Door”)
So, I’m trying to use a third component (a Gripable Box/Capsule, or for testing just a Gripable Static Mesh Component with SM_Cube)
When I use a Gripable Static Mesh Component, the component doesn’t properly attach (even when I explicitly attach it with AttachToActor). It stays in place until, when I grip it, it separates from the door. The handle does rotate properly when I grip the box (meaning it’s connected in the BP).
When I use a Physics Constraint (to connect the separate box to the door), it still separates from the door when I grip it
When I use a regular Static Mesh or Box component it attaches properly, but (as above) I can’t get Child Gip/Release to be called so the animation of the rotating door handle doesn’t play.
Any thoughts? Is a bug in the implementation of the Gripable components? Am I setting it up wrong?
For the grip type you likely want a manip if you are using constraints, the default interactive grip is a full physics grip and will try to pull it away from the door too much, that or you are using a PhysicsOnly grip where there are no constraints involved.
Now…that being said…the handle could be done a lot cleaner if you use a VRDial or VRLever (depending on lever or knob style) and when it gets past a set point either adding another grip to the door so the hand is holding both, or ungripping the knob and gripping the door instead (or I guess simulating the door and changing grip type to a manipulation one).
Both the Dial and Lever would play the rotation for you without any extra work, and both have events and rotation feedback that would make it simple.
Edit I’ll note that I recently went in to the template and changed the door grip into an AdvancedPhysicsSettings Force grip instead of the default acceleration grip. It promotes better behavior with the constraint and doesn’t try to fight the limits. Acceleration directly sets the acceleration of the held object, a force based grip applies force in the desired direction instead.
I’ve had it on my TODO list for awhile to show knobs, but since the Dial and Lever make them far simpler I was waiting to finish the c++ versions of those, and then other more important things came up.
Re-edit
If you literally just want it to make the handle turn on grip…make it a custom grip, it will trigger the events but won’t move anything unless you manually move it.
There are a lot of ways to go about honestly, it depends on what you are trying to do really.
If the “handle box” is moving away from the door when constrained and it is using one of the constraint type grips then you have the constraint set up wrong (too weak or just not actually constraining it).
I was trying the Dial/Level… but I don’t manage to make them move together with the door (besides, since I use the movement mostly for visual feedback it seems to me to be a bit overkill). Anyhow, if you say it’s better to use that I can give it another try.
With the custom grip setting, the handle stays attached properly, and it turns when you grip it, but the door doesn’t move when the grip is with the handle (it moves only when the grip is with the door).
Great tip with the AdvancedPhysics Force grip: it makes the movement much smoother.
If you want the door to move with its sub component you would either need to manually rotate the door yourself (IE: mitchs template or how the lever works), or run everything fully physics and constrained to each other. The moment you simulate something in engine it detaches from its parents because it is then being controlled by the physics scene.
For physics to rotate that door while holding the handle you would need the door to be simulating and the handle to be simulating and constrained to the door.
Which is why I suggested the easy method being to trigger a new grip when a dial or lever hits a set angle and either re-grip with just the door, or grip both at once. Since the dial/lever use custom grips they should stay attached, though you will likely need to have them parented to a scene component attached to the door, otherwise they would probably get detached anyway unless you remove their physics body entirely.
Gotta work around how the engine works…
But you just wanting a visual indication on the door…why even give the handle collision at all? Let them grip the door, rotate the handle when the door itself is gripped.
Or OnGrip for the door have it be a custom grip and add another grip to the handle as a dial, if the handle turns a set amount then change the door grip to a physics one.
The problem is that you are working with multiple components here, and the engine generally expects Parent - (change) - child, not Child - (Change) - parent.
You could have the knob be the parent and the door attached to it, but then rotating the knob would require special effort…
That was sort of what I was going for… but I found it’s confusing for the player when he grabs the handle and nothing happens (in fact, I’m just trying to extend the ‘range’ of the grip from being only the door, to being both handle and the door…)
That’s a great idea. I’ll try moving the grip from the handle to the door after the handle rotates…
Thanks a bunch! I look forward to seeing what you come up with when you get around to a door setup in the demo template :). If you want I can send you some assets (doorframe/door with hinge and handle) to use.
Do you keep a changelog of tweaks like 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 one.
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 ? I am primarily an artist so I am not too great with blueprints and I am doing 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.
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.
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 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.
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.
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.
