Hi, just starts with Unreal and try development to VIVE and watch that plugin. I have dowload last template. Migrated VIVE character to my one, copy the plugin folder and default input for controllers and the project opens without trouble, but can’t grip objects at all. For example in the template I add a cylinder or simple static mesh, activate simulate physics and works, but in my proyecto no, what I’m missing?
Overview of the new VRGestureComponent and related materials.
Hi, I’m having a problem with handling sword without wiggling.I’ll be appreciated if you guys can help me.
[quote=“vanreus, post:1979, topic:68709”]
Hi, I’m having a problem with handling sword without wiggling.I’ll be appreciated if you guys can help me.VR - YouTube
Use a stronger physics stiffness on it or switch to HybridInteractive.
Hybrid interactive doesn’t actually use a constraint to hold the object until it impacts something it collides with, then it converts to a physics grip. The stiffness also just strengthens the bond between the hand and the object. Also I wouldn’t turn off the center of mass setting for a physics grip with a sword unless you are manually setting the COM to the grip point.
If you don’t actually care about interactivity then you can also switch it to a PhysicsOnly grip type which won’t collide and doesn’t have any potential for wobble due to physics forces.
Edit Also it appears to be a rotation strength issue, you can enable advanced physics settings on it and up just the rotational stiffness to help correct it.
Hi, is possible to remove the “OutOfBody” parts (sorry for poor explain…)? or at least hide in game?. I have not tested the plugin since 4.16 and that is new for me, sorry if has been explained before…
Yeah? Delete it as a movement option…
It spawns a camera to use for OOB movement and if its never used the camera is never spawned.
Added a new game to the list of use cases
Pushed a new commit to the plugin and example repositories
Template
Added example content for the new VRGestureComponent and GestureDatabase DataAsset.
Plugin
Added new VRGestureComponent - allows you to record and detect gestures, also has some utility functions for drawing and managing them.
Added GestureDatabase DataAsset to store gestures.
I will update the documentation (compile binaries) and go into further details about them tomorrow (it is very late here).
Video going over the final state of them
4.19 Beta branch is out for template and plugin repositories.
I have a question about the constraints in the cabinet blueprint. I Replaced the mesh of the cabinet with a car mesh, then replaced the door meshes with car doors. I can now open and close the doors. Now I made edited cabinet a child of the Sedan blueprint so I could drive it and still have openable doors. The problem now is that the doors don’t move with the cabinet but remain in a fixed spot while the cabinet itself moves with the Sedan blueprint. Do you know how I can make the doors move with the Cabinet/Sedan? When I haven’t interacted with the doors, they do move with the Sedan nicely, but as soon as I have interacted with them, they won’t move with the Sedan.
Simulating objects unparent themselves when set to simulate, so when you go to drive off later they are left behind.
You have a couple of options.
#1: Stop simulating the door when it is released and attach it back to its parent, ensure that all doors are un-simmed and attached prior to allowing driving.
#2: Use a faked physics door instead that just sets rotation to follow the hand position offset.
#3: Use a lever component for the door, it will actually behave pretty much the same as a door assuming you have the zero point set correctly.
For #2 I intend to make a faked swing door component at some point but it hasn’t been high priority due to many examples already being out there for it and larger things to tackle as well as Lever components pretty much being the same thing minus a set pivot point and faked velocity after release.
Thank you, #3 works perfectly!
Has anyone gotten the mechanics for an on-wrist inventory working? Something similar to rec room?
I was doing a ray trace from the HMD to the wrist, and from the wrist to the HMD to make sure they’re looking at each other, but I’m almost sure is a super inefficient/practical way.
**
If you aren’t tracing on tick it isn’t that bad, but you shouldn’t need to tract to begin with, getting the heads location and forward vector and the component on the wrists up vector and location should let you figure out if they are generally angled towards each other and close.
Can run that check out of tick on a timer or something.
Hi ,
Thanks for all the work going into plugin, it’s working really well in my current project. I do have a minor issue with teleport that I didn’t have using the Epic template however. When teleporting on uneven terrain, there is a single pop of a frame where the viewpoint shifts up right after teleportation. It’s almost unnoticeable, but it is a little distracting. Any idea what could be causing ?
Depends, if you aren’t projecting to a navmesh then its possible that your trace hit location is underneath a higher point next to it, when the character teleports it will end up shifting upwards to the highest point touching the capsule to remain above the floor. Regardless the default teleport setup traces downwards for the floor after projecting to the navmesh so it shouldn’t be any different.
You could also be teleporting incorrectly by not adjusting for the HMD location “GetTeleportLocation” is a helper node that correctly offsets for that.
One last thing is that the VRCharacter has its 0,0,0 location at the players feet, the default character has it at the players center of collision capsule. It felt more natural to have it at the feet for roomscale as all of the offsets line up. however means that for teleporting you should no longer pass in the capsule half height as an additional offset for the teleport (though that should be an upwards offset not downwards).
I haven’t noticed a hitch like that myself though, no.
I love the plugin, and it has worked wonders for the game I’m working on, but I’ve run into a slight issue I was hoping somebody could help with.
I am working on a vr weapon system, and currently I’m trying to implement shotgun mechanics, but I’m having some trouble with the secondary grip. For other weapon types, I’ve simply made the bolt a grippable box with a static mesh child, then scripted whatever interactions I need.
For the shotgun, however, I need the pump to work as the secondary grip point on the gun, as well as have it work as a constrained interactable for the weapon mechanics.
Is it possible to make a child component’s grip act as the secondary grip on the weapon, or to make the weapon’s secondary grip interactable?
Or am I simply approaching from the wrong angle?
I’d appreciate any help, as I’ve been stuck on for a bit and it’s the last thing standing in my way before my system is largely complete.
You can have the pump as an entirely seperate grip on its own to move it, or just track the location of the hand relative to the barrel and handle it yourself.
You don’t want to try and re-orient the actor to face the pumps location as that also effects the pumps position since it is a child component.
So if you don’t want to do any custom setup, easiest would be to add a another grip to the pump when the secondary grip is started, and remove it when the secondary grip is stopped. However I think you could get cleaner results by doing the pump logic manually off of the secondary grips current location and the sockets location to get barrel offset.
Okay, was the route that I was attempting to go, but it turns out I was accidentally referencing the wrong controller, so it wasn’t working. Oops.
So I sorted that, but I suck at vectors and math, so I’m having an issue, in that, whether or not it works properly is determined by the direction the weapon is facing. Clearly I’m approaching incorrectly.
If anyone could tell me what I’m doing wrong here, I’d appreciate the help.
Thanks for the quick response and the help.
Inverse transform the position to be local to the gun, you don’t want to do in world space, making it local to the gun gives you only the forward (X…Y for marketplace guns) axis to worry about.