Yeah, its just a normal physx car, rebind the inputs instead of using the physical inputs. I only did physical controls because it is something neat that isn’t possible outside of VR.
Updated Contagion Outbreak VR link to actual store page.
Rad! Any demo keys before official release?
Pretty sure they have a free demo, you can just download it
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.