can someone please explain how to get the hand-animation back ?
I need it urgently and cant figure out how, my try to copy the blueprint functions from the original ue-vr-template does not work at all and i´m afraid to screw up everything in my project =/
Its 4.15 Alpha branch only currently, due to the engine header change in 4.15 I split the plugin again (like I had to for 4.12-4.13 due to massive navigation system changes).
I didn’t want to keep engine #define checks around for the life of the plugin compiling different code just for 4.14. normally isn’t required, there have just been two major engine base overhauls recently that screwed with version compatibility.
When 4.15 officially releases I am going to merge that alpha branch into the master one. People wanting the climbing system in 4.14 going forward could manually pull in the commits related to it if they wanted to.
You can get seperate downloads for each branch at the following locations
You likely need to re-implement overlap detection, I use spheres on the hand, I think the template uses the hands themselves (don’t remember)? It shouldn’t be too hard to transfer over though.
Pushed a new commit to the plugin and the template for 4.15 alpha branches
Some of these things still need some additional testing, may roll out another commit tonight after I can fully run through them.
Fixed Important bug in DropGrip with the optional velocity variables and their order of use
Added naive Lerped smoothing to motion controller replication, bSmoothReplicatedMotion controls it,
should not be used if the expected FPS frame time is smaller or equal to the motion controllers update rate.
Added bReplicateWithoutTracking to use for FPS or testing characters to allow replicating custom controller movements.
Added climbing movement toggle directly into Movement Component, now is injected into FSavedMove and replicated with stored movements
should remove any hitching when moving between climbing or non climbing movement modes as a client.
Removed FBPReplicatedTransform's use of a packed BYTE for replicating controller ROLL, was not accurate enough. Now uses a packed SHORT just like the other two axis's
Added an Unpack() function to FBPReplicatedTransform, used to pre-unpack location / rotation so the new lerp is less CPU costly
(at the cost of a FVector / FRotator extra per motion controller in memory).
Edit Tested, appears to be working fine, I did switch all enums over to the new style in a seperate patch though.
hi , first of all many thanks for your fantastic plugin.
I’m trying to animate my full body skmesh not only when player moves using motion controller dpad (full locomotion - works fine), but also whenever player is moving on his roomscale space… camera and mesh are locked together so I can’t use add movement input to animate my mesh.
Any smart ideas?
thanks again
c.
Yes create an empty blank class, it will then give you a solution file to compile the project with.
Without pre-compiling all of the binaries and installing in the engine directory (not willing to do myself while doing lots of work on the plugin) is sadly a requirement.
Thanks for the info, got the example project up and running today and created something I have been trying to do for a while.
The issue was that I needed to create a C++ project within Visaul studio for it to ask me to install extra tools. Only after installing the extra tools it would then compile.
Took me some time to understand the actor structure using the GrippableStaticMeshActor, I used the door as a reference.
Using the physics constraints is a very nice way to work. Noticed some small issues with grabbing the mesh but nothing I can’t work round (I need to add some trigger checks).
I just tested it again, I didn’t know at first that when grabbing the object it grabs it by the mesh. I assumed it was the grabbing the collision volume of the object (like the blue UE4 vr box).
When I was grabbing the object quickly, the orb was passing through the mesh giving me the impression it was not grabbing correctly.
I can work around by adding handles to the objects, also helps indicate where to grab.
However is it possible to grab the object by its collider or volume? My first impression is that “GrippableBox Component” may be the answer?
I have it set in my trace function (blueprint) in the template to trace against complex collision as it is more accurate, if you change the trace to trace against simple collision then it will go off of that instead. The plugin itself doesn’t define where to grip an object at, it is given an offset from the hand that you want to keep something and then does its best to maintain that offset distance. I use sockets to define snap points on meshes for simplicities sake, you could also just pass in a custom relative transform instead with whatever you want.
If I’m understanding you correctly the trace function (blueprint) would be part of the controller (red lined sphere used to grab stuff), I guess that would be part of the VR Simple Character?
Im a little new to UE4 so not sure where that VRSimpleCharacter Pawn is, I guess its hidden by default?
Any way I just made my second interaction using your system, its a primitive way of setting an object in place.
For example a key in a door or in my case a keycard in a terminal :0…
Like the idea of sockets will test that out at some point time.
Hmmmmm, what to make next… You made a utility belt I think (fat belly to stick stuff to :)? I will experiment with that.
Amazing plugin!! thank you so much for sharing it, it is really good an very easy to use, I ported it to my project in just a few minutes
One question, Is it possible to make it work in slowmo? I’m developing a Gladiator game, and the physics go crazy when I activate the slowmo(I set global time dilation to 0.05). I tried to compensate the time dilation on the weapon actor with no luck.
I’m sorry to tell you that as far as I am aware is a physx issue that has persisted since UE4 came out where time dilation doesn’t work correctly with physics. I think its been reported but I’ve never seen a fix log for it. Physics runs on a seperate thread from the game thread and since it doesn’t appear to be taking up the dilation at the same time it likely would have issues since it would be running the simulation at a different speed from the game thread, or at least that is what I assume from the jumpy behavior I have seen it cause.
I wouldn’t know where to look for a fix, never had a need for slow motion physics so I have never looked at it.
I mean there might be a workaround, like I said its not VR related and I never had cause to look into it, just ran into reports of it from time to time.